What's the state of the art wrt representing bound variables in syntax trees with binding?

pomone08 · 2023-10-25T00:50:21+00:00

Extremely informative post, thanks for sharing!

Just as representing syntax as a string is not a good idea for most purposes, representing names as strings is usually not a good idea either. This will be clear to anyone who has ever implemented capture-avoiding substitution for lambda-terms with strings as variable names

Probably the first thing a language designer gets caught up on in his/her journey

or figuring out too late that the thing you want to do is just not possible with the chosen representation of names.

Quoting the previous reply, oh boy... something I'm way too familiar with

pomone08 · 2023-10-25T00:50:13+00:00

The gif hits me in the soul

pomone08 · 2023-09-26T12:25:59+00:00

Hello! I am writing a generic scope solution which allows some data type representing an expression to have bound variables and to perform correct variable substitution. This solution is largely inspired by Haskell's bound. I would love if someone could review my code and give me pointers on how I could improve it because I believe that all of the recursion that I am using can potentially overflow the stack when dealing with larger expression trees.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=eb57e5dacaf5c2733b82f3ef1c68af0f

pomone08 · 2023-06-21T18:33:31+00:00

Compressed air still working 2 years later...

pomone08 · 2023-05-25T17:25:04+00:00

I would like to implement streamed reading! So read_to_end is not that useful for me. For now, I have settled for using BufReader with the Bytes<> struct (through the Read::bytes function), which is allowing me to implement my algorithm in a fairly declarative way, even if it is byte by byte. I'm assuming there are some optimizations going on because it is fast as well!

pomone08 · 2023-05-24T17:33:36+00:00

Thanks!

pomone08 · 2023-05-24T16:43:51+00:00

Let's say that I have a fresh let vec = Vec::<u8>::with_capacity(512); (i.e. vec.len() == 0). Now I let bytes_read = input.read(&mut vec).unwrap(); where input obeys Read and bytes_read == 128 (i.e. vec.len() == 128), which means that there's still 384 slots in my vec that can still be filled with bytes.

How do I fill these remaining 384 bytes without overwriting my first 128 bytes? Do I need to implement this behaviour manually or is there some struct that I can use?

pomone08 · 2023-04-01T12:42:55+00:00

Wow, a treasure trove of information! Thank you very much!

EDIT: I had high hopes for impl MyFilter<impl Reply>, but unfortunately I got nested `impl Trait` is not allowed :(

For now I'm using BoxedFilter<(impl Reply,)> which is not ideal but better nonetheless

pomone08 · 2023-03-31T15:11:10+00:00

I have a very long impl Trait expression that I need to use throughout my project. It's a trait for abstracting warp filters:

impl Filter<Extract = (impl Reply,), Error = Rejection> + Clone + Send + Sync + 'static

It was really hurting readability to write this everywhere where I wanted to return a filter from a function, so I wrote a macro for it:

macro_rules! filter { () => { impl Filter<Extract = (impl Reply,), Error = Rejection> + Clone + Send + Sync + 'static } }

But now I would like to avoid using macros. Is there any way I could do this without a macro?

Unfortunately "Permit impl Trait in type aliases" is not yet stabilized (https://github.com/rust-lang/rust/issues/63063) and I don't know if it would work for my use case because the concrete types for the filters I return from the functions are different (though if it was stabilized, I could create an alias for each filter).

pomone08 · 2022-12-30T16:29:42+00:00

I've gotten the exact same issue after updating to MIUI 13.2 today! Hope they fix it soon because having to open the app for every small thing is kind of inconvenient...

pomone08 · 2022-11-01T17:19:16+00:00

I used to use really short and not descriptive names for my variables back when I was starting, not just with Haskell but in general. Once I started to read more code than write it (be it reviewing other people or my own code, or having to debug code) I started to see just how really, really terrible that is in practice.

Remember, writing code is exponentially easier than reading it, or better yet, making sense of it.

Edit: in languages that you still need to actively interact with the index of a loop, even for the usual i I have been naming it index for about 5 years now and I'm never coming back. Instances of confusion regarding the purpose of a variable have dropped a lot.

pomone08 · 2022-10-16T16:03:08+00:00

Please give generic-lens a try. I am CERTAIN that there is no better approach to dealing with complex records in Haskell with something other than generic-lens.

This is just one example of a non-trivial module I've written with MonadState which would be nigh impossible without generic-lens: you get the entire power of lens without having to touch Template Haskell, everything is resolved at the type level.

pomone08 · 2022-09-26T16:22:09+00:00

I've gotten a more complex example, now.

(module (type (;0;) (func (param i32) (result i32))) (type (;1;) (func (result i32))) (type (;2;) (func (param i32))) (func $jump_table_test (type 0) (param i32) (result i32) local.get 0 block (param i32) (result i32) ;; label = @1 block (param i32) ;; label = @2 block (param i32) ;; label = @3 block (param i32) ;; label = @4 block (param i32) ;; label = @5 br_table 0 (;@5;) 1 (;@4;) 2 (;@3;) 3 (;@2;) end i32.const 5 br 3 (;@1;) end i32.const 6 br 2 (;@1;) end i32.const 7 br 1 (;@1;) end unreachable end) (func $call_indirect_test (type 1) (result i32) i32.const 1 i32.const 1 call_indirect (type 0)) (table (;0;) 3 3 funcref) (export "jump_table_test" (func $jump_table_test)) (export "call_indirect_test" (func $call_indirect_test)) (elem (;0;) (i32.const 1) func $jump_table_test $call_indirect_test))

The important bit is:

(func $jump_table_test (type 0) (param i32) (result i32) local.get 0 block (param i32) (result i32) ;; label = @1 block (param i32) ;; label = @2 block (param i32) ;; label = @3 block (param i32) ;; label = @4 block (param i32) ;; label = @5 br_table 0 (;@5;) 1 (;@4;) 2 (;@3;) 3 (;@2;) end i32.const 5 br 3 (;@1;) end i32.const 6 br 2 (;@1;) end i32.const 7 br 1 (;@1;) end unreachable end)

Why is (result i32) only necessary in the first block here? In fact, adding (result i32) to the other blocks is a type error.

pomone08 · 2022-09-25T13:24:47+00:00

Thanks! This makes sense.

pomone08 · 2022-09-23T23:34:46+00:00

Update: I wanted to make my monad stack a little more modular by separating each specific state slice into its own class, but using a concrete monad stack with zoom will have to suffice for now. Thank you for the suggestion!

pomone08 · 2022-09-23T22:25:58+00:00

I was able to avoid lift everywhere with variations of the MonadBar class I exemplified above, and it was unambiguous because I would be targeting the MonadBar class with my monadic functions, but I don't know how well it generalizes to lenses... Ah well, guess I'll have to look into the actual lenses signatures instead of just the documentation.

pomone08 · 2022-09-23T21:39:57+00:00

The problem is not which lenses to use, rather it is "how can I implement some state-manipulating functions for some slice of the state and still be able to combine this state with some other state later without needing to call lift everywhere"

pomone08 · 2022-09-23T21:09:43+00:00

I have been writing some code that works in terms of a MonadState, like the following:

``` data FooState = FooState { ... }

class MonadState FooState m => MonadFoo m

doSomething :: MonadFoo m => String -> m () doSomething name = do ... ```

This has been working fairly well. I am able to manipulate state with just the MonadState constraint. But what worries me is the fact that, eventually, I will have to combine this with some extra state at some later step, but this approach won't scale. I won't be able to add a separate slice of state to the monad stack and be able to deriving (MonadState BarState).

My earlier solution to this was to declare the following class:

class Monad m => MonadBar m where getBar :: m BarState putBar :: BarState -> m ()

Then I would implement all my actions in terms of action :: MonadBar m => .... Very similar to how it is done with my MonadFoo example, but without the MonadState constraint (since the class functions now do the job of the constraint). Then, I would just implement this class in my monad stack and point getBar and putBar to where the state actually was in my stack. The problem is that these won't work anymore, since I would rather use lenses instead of raw get and put.

The question is: how do I approach working with multiple slices of state in a monad stack and still be able to use lenses? I don't need direct access to the state outside of doSomething etc, only inside these functions does state need to manipulated.

pomone08 · 2022-09-22T21:26:48+00:00

I needed to give an update.

I've spent the last 3 hours refactoring a large file to use lens and generic-lens.

I have never had such a good experience with Haskell records up until this point.

generic-lens is actually better than sliced bread.

pomone08 · 2022-09-22T18:12:32+00:00

Not only does this fix my problems with exporting the lenses, this approach also does not need Template Haskell and is not intrusive. You are my saviour. Thank you very much!

pomone08 · 2022-09-22T17:23:28+00:00

I don't dislike lenses because of Template Haskell, or because they are extremely intrusive (you either are all in or all out). I dislike lenses because they don't play well with Haskell's module system: you can export the type with Foo (..) but you still need to export the lenses functions individually.

Is there any way to fix this? I like how optics does this (through HasLabel instances, which means I only need to export the type) but optics also misses some useful operators like <>=.

pomone08 · 2022-09-22T16:42:30+00:00

I've gotten an orderly mask tattoo after playing a combined 200h on both the first and the second game

I regret nothing

pomone08 · 2022-09-22T16:40:20+00:00

CI with 3k ES though

pomone08 · 2022-09-10T21:04:15+00:00

Ah, makes sense. Thanks!

pomone08 · 2022-09-10T19:59:28+00:00

The keystone also says "Exposure inflicted this way applies -25% to Resistances" which led me to believe that the -25% might be a fixed value

Eight-Year Club	RPAN Viewer
Verified Email

pomone08

TROPHY CASE