Talk:First class environments

So it's what, the thing we normally call "closure"? --Ledrug 09:14, 30 June 2011 (UTC)

No, because a closure cannot be handled independently from the code, e.g. stored in a variable and activated at some other time with a piece of code.--Abu 09:19, 30 June 2011 (UTC)

This looks like what most people would call an "object". Since we already have examples of objects, I am not sure how this task is interesting. --Rdm 20:56, 30 June 2011 (UTC)

I guess it's more about directly rebinding variable names than accessing objects; in the PicoLisp example the job funtions accessed N as if it were the only instance out there. The C cheat code is more of an object, though. --Ledrug 21:22, 30 June 2011 (UTC)

If that's the case -- if this is a dictionary or whatever -- perhaps the task ought to have something about dynamically generated names? --Rdm 21:28, 30 June 2011 (UTC)

A dictionary encapsulates keys and values (must be explicitly accessed/fetched), but not variables and their values (transparently changing the behavior of the code).--Abu 06:00, 1 July 2011 (UTC)

No, nothing to do with objects. Objects encapsulate code and data. Environments encapsulate variables and their values (closures minus code).--Abu 06:00, 1 July 2011 (UTC)

What are variables other than references to data and/or code? And, if it's that variables have mutable names (which would not actually be the case in many compiled languages), how is a variable name any different from a dictionary key? Using different words does not make the concept different -- you have to spell out the differences or illustrate them with examples. --Rdm 10:54, 1 July 2011 (UTC)

Concerning the question whether the C solution "fits the spirit": I would say yes, though instead of switching the pointers to 'sec' and 'cnt' I would save and restore the actual values. This would better simulate the "binding" of the "environments".--Abu 15:17, 30 June 2011 (UTC)

Well, that's quite a bit more work. Right now I can just swap the links (addresses) and forget about it (which is in a sense more "real"), if I copy values, I'd have to copy them back after each job switch, can't exit job control loop whenever I want, etc. The way I look at it, just pretend the "*" is a special marker for environment variables. In the worst case, the job function itself can copy and restore them to stack if really needed. --Ledrug 16:40, 30 June 2011 (UTC)

Flyweight?

What is the exact relationship between this and the flyweight pattern? --Michael Mol 16:44, 30 June 2011 (UTC)

Is there any at all? --Ledrug 16:47, 30 June 2011 (UTC)

I can't detect any. Flyweight patterns seem to be mainly concerned about sharing data structures, not about runtime variable bindings.--Abu 16:58, 30 June 2011 (UTC)

Ledrug's initial question was quite close. A "closure" is a combination of environment and code. AFAIK, in most languages the environment cannot be separated from a closure, and stored, retrieved and manipulated explictly. In PicoLisp it is the other way round: Environments can be constructed from normal Lisp data, and then perhaps be used to build a clojure, but also for other purposes.--Abu 17:17, 30 June 2011 (UTC)

Runtime_evaluation/In_an_environment?

The concept seems close to Runtime_evaluation/In_an_environment. The initial implementation there was Common Lisp, by the way. —Sonia 18:36, 30 June 2011 (UTC)

Yes. However, Runtime_evaluation/In_an_environment requires the manipulation of environment contents (setting a free variable), while this task is about handling environments as first class objects (maintaining a set of environments).--Abu 05:50, 1 July 2011 (UTC)