Arc Forumnew | comments | leaders | submitlogin
1 point by rocketnia 4510 days ago | link | parent

I'm afraid I still find code examples like this one hard to understand:

  $lets: Top:  get-current-env
         N:    $quote nou
         Old:  (Top) N
    eval Top: $quote $use! foo
    set! Top N Old
This is how I'd place the parentheses, if I had to guess:

  ($lets (Top  (get-current-env)
          N    ($quote nou)
          Old  ((Top) N))
    (eval Top ($quote $use! foo))
    (set! Top N Old))
Is this right? If so, what does it mean to call Top as a function like that?


2 points by Pauan 4510 days ago | link

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 4510 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 4510 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.

-----