Anonymous user
Talk:First class environments: Difference between revisions
m
added a section header to the 1st talk topic, forced a TOC.
No edit summary |
m (added a section header to the 1st talk topic, forced a TOC.) |
||
| (6 intermediate revisions by 2 users not shown) | |||
Line 1:
__TOC__
== closure? ==
So it's what, the thing we normally call "closure"? --[[User:Ledrug|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.--[[User:Abu|Abu]] 09:19, 30 June 2011 (UTC)
Line 14 ⟶ 18:
::::::: If first class environments are a true language feature, they give additional control to the programmer, over closures, continuations and other constructs. Not a big thing, but useful. For example, the PicoLisp GUI uses them to pass state between HTML pages and forms/dialogs across HTTP transfers. --[[User:Abu|Abu]] 09:32, 2 July 2011 (UTC)
:::: This is interesting. In some languages variable names are really just dictionaries, such as Perl package variables or "named variables" in PostScript. This fact may be used both for and against having this task, but personally I think the task is worthwhile, even if only to show how each language handles name lookups. --[[User:Ledrug|Ledrug]] 22:34, 1 July 2011 (UTC)
:Perhaps this article helps to explain the issue? http://picolisp.com/5000/!wiki?firstClassEnvironments --[[User:Abu|Abu]] 07:22, 9 June 2012 (UTC)
:: Unless we are saying that we want to implement picolisp for this task, basically that page just seems to be saying that we want distinct sets of symbols, where the same names can resolve to different values depending on which set we are using. That's a "first class environment" in the context of the page you refer to, but a dictionary accomplishes the same thing, as does an object (though, depending on the language, a dictionary or an object might use different syntax). There can be *subtle* syntactic issues between otherwise similar constructs. But those are not relevant here, because subtle syntactic issues are language specific. --[[User:Rdm|Rdm]] 13:17, 9 June 2012 (UTC)
:::I don't think a dictionary does the same. It doesn't bind variables. A proper implementation e.g. in C would be to have the code use global variables, and the environment sets those variables dynamically before executing the code. A dictionary or object is not concerned about ''binding'' variables, instead they allow a dynamic ''lookup'' of values, which is something completely different. I was in the hope that the above article makes this clear, but obviously it doesn't. --[[User:Abu|Abu]] 16:11, 9 June 2012 (UTC)
::::Is the following more clear? While you can simply execute 'print(x,y)' after setting an environment, you have to call (in pseudo-code) 'print(get(dict,x), get(dict,y))' for a dictionary, and 'print(object->x, object->y)' for an object. In both cases, you still carry an explicit binding around with you, either the dictionary 'dict' or the object. --[[User:Abu|Abu]] 16:18, 9 June 2012 (UTC)
::::: Except "binding a variable" may be exactly what a dictionary does *depending on the language you are working in*. The distinction between "binding a variable" and "associating a name with a value" is not one that is meaningful across languages. It's only a distinction when you have specific implementations of "binding" and "associating" which you are trying to distinguish between. For that matter, the distinction between a "variable" and a "name" is also a language-specific issue (and sometimes a context-dependent issue within a language). For that matter, '''x''' is not a valid variable name in some languages (perl is a good example for that). Also, even in picolisp you can take an expression and modify it so that what originally looked like a variable reference is turned into an appropriate dictionary reference. Also, the distinction between "first class" and "not first class" is itself language specific and context specific -- "first class" is typically shorthand for "simple to use" but that's a subjective and comparative and context dependent issue. It can be quite meaningful in a narrow context but it loses a lot when you try to treat it like it's something generic. --[[User:Rdm|Rdm]] 16:52, 9 June 2012 (UTC)
:::::: That said, if you will allow that in some languages "dictionary" and "first class environment" are identical things, it is true that there's a meaningful distinction between them in some other languages. --[[User:Rdm|Rdm]] 16:55, 9 June 2012 (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".--[[User:Abu|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. --[[User:Ledrug|Ledrug]] 16:40, 30 June 2011 (UTC)
== Flyweight? ==
Line 23 ⟶ 34:
::I can't detect any. Flyweight patterns seem to be mainly concerned about sharing data structures, not about runtime variable bindings.--[[User:Abu|Abu]] 16:58, 30 June 2011 (UTC)
:[[User:Ledrug|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 closure, but also for other purposes.--[[User:Abu|Abu]] 17:17, 30 June 2011 (UTC)
== Runtime_evaluation/In_an_environment? ==
| |||