Closed shawwn closed 5 years ago
Basically, (lexenv)
returns a list of triplets: variable name, getter, setter. So (let x 42 (lexenv))
returns a way to get and modify x
.
This is also how deduplication of the fns*
table works in laarc.
Awesome. Not obvious to me if you're uncertain about this change for some reason but in general feel free to just push straight to head if all the tests pass. PRs are still great for when you want comment.
For major new features like this I'd also love to see a message on the Arc Forum.
I like the concept. I've been figuring this exact operation (lexenv
) could be completely user-defined someday (i.e. defined in arc.arc), as a sort of milestone to show that the macros receive their caller environment information in a sufficiently expressive format.
With that in mind, could you refactor this to store what it needs in env
rather than using global state? Would you mind if I try out that refactoring? I'm not sure what parts of this you're relying on, so some tests might be good.
Oh, took me too long to reply, huh? :-p
Feel free to refactor it. :)
I'm honestly not sure how to do global state in Anarki. That's the main roadblock to #151 too.
With what I have in mind, I don't think this feature will even use global state. Or... well, it might, but only because I think making env
use the same data structure as the global namespace will let us have a notion of "local definitions" that has the same semantics as top-level definitions. XD
But for #151 purposes, I think this comment I made around the same time might help a bit: https://github.com/arclanguage/anarki/pull/147#issuecomment-457815448
In short, the state is always looked up from the current-namespace
somehow, and it may be initialized multiple times per program (when different instances of Anarki are created), which I hope is made easy enough by the behavior I've given xdef
.
Useful for things like an inline debugger.