-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
About the usage of Lazy #2
Comments
If it wasn't for that, I would probably try to go for a pure solution with levels in the domain, but since it's already impure, I chose (locally) unique integers because they're more convenient when you can afford them. I wonder if it'd be possible to implement a new kind of mutable reference that doesn't have the performance problems of |
I see now the I haven't yet tried interleaving, I always just blithely unsafeperformed. Basically, In my planned implementations, the main complication of unsafe |
BTW, I'm warming up to your version of |
This might be faster than using an IORef, though I don't notice any difference when measuring. The API should be safe even though it's implemented using unsafe functions. Ref. #2.
This might be faster than using an IORef, though I don't notice any difference when measuring. The API should be safe even though it's implemented using unsafe functions. Ref. #2.
I've just switched to Interesting remarks about |
Am I correct that the reason
Lazy
is used in evaluation, is that evaluation returns in the strictM
monad, hence returned values are always forced?As I see
M
only does fresh var generation. What do you think about using de Bruijn indices and levels? In that case, would eval be pure in your setup, and thenLazy
could be dropped?The text was updated successfully, but these errors were encountered: