Skip to content
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

Add boxed evaluation #156

Merged
merged 1 commit into from
Feb 6, 2019
Merged

Conversation

shawwn
Copy link
Member

@shawwn shawwn commented Feb 6, 2019

arc> (let x 42 (eval 'x (lexenv)))
42

arc> (let x 42 (eval '(= x 99) (lexenv)) x)
99

Useful for things like an inline debugger.

@shawwn
Copy link
Member Author

shawwn commented Feb 6, 2019

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.

@akkartik
Copy link
Member

akkartik commented Feb 6, 2019

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.

@shawwn shawwn merged commit 2f42517 into arclanguage:master Feb 6, 2019
@rocketnia
Copy link
Member

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.

@rocketnia
Copy link
Member

Oh, took me too long to reply, huh? :-p

@shawwn
Copy link
Member Author

shawwn commented Feb 6, 2019

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.

@rocketnia
Copy link
Member

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: #147 (comment)

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants