Arc Forumnew | comments | leaders | submitlogin
2 points by Pauan 4303 days ago | link | parent

You get used to it (I hope). Anyways, it's actually like this:

  ($lets (Top  (get-current-env))
         (N    ($quote nou))
         (Old  ((Top) N))
    (eval Top ($quote $use! foo))
    (set! Top N Old))
...Which just caused me to see a bug, woohoo. Anyways, the reason it calls Top is because (as subtly pointed out in the article) environments are variables. Calling a variable returns whatever the variable is pointing to[1]. So we first call Top which returns an immutable data structure, and we then call that data structure to return the value at the key.

Basically, the reason why we're doing this is, a data structure might contain a variable or a value, so we're grabbing the variable-or-value from the current environment, and then assigning it back again after the call to `$use!`

---

* [1]: This isn't set in stone yet, and I'm still thinking about the right semantics for variables.



1 point by rocketnia 4303 days ago | link

Ah, so (get-current-env) returns the variable. I like that. ^_^

I wasn't thinking of it as "environments are variables"; I was thinking of it as "environments are immutable, and variables often hold them."

-----

1 point by Pauan 4303 days ago | link

Right, but all the built-in things that deal with environments usually wrap them in a var. There's no special "environment data type", it's just an ordinary dictionary that is wrapped in a var and treated like an environment[1]. So you could pass in your own custom dictionary to eval, for instance. At least, that's the plan.

---

* [1]: Actually, I was thinking that it might be a good idea to have a special environment data type, which is exactly like a normal dictionary except that if you try to set a key that isn't a symbol, it throws an error. Not sure about that yet.

-----