On Sat, 29 January 2000, Robert Withers wrote:
This raises a question, Jan. What is the full set of variable bindings in Smalltalk (VW). Global, makes some sense, but what about semi-global and local. Would this be the difference between external bindings in a closure versus argument bindings to the closure?
The next step from here seems to be the impact of namespaces on these concepts. Or rather, do these concepts help in the structuring of a namespace?
[snip]
Well, before I embraced Smalltalk, I was enthusiastic about functional languages, ones where functions were first class objects. The power there came from two places. One was the ability to map things like
[:listItem | ...]
over datastructures. In some sense the mapping was "parameterized" to accept the block as its "innards". The second was the emerging calculus of "computing" or "deriving" programs from specifications. That's pretty erudite.
But, while managing huge states (like a global COMMON) was surely something to be avoided, the need for state always pressed when one was programming with pure functions. Indeed, SCHEME was an attempt to handle the needed state stuff elegantly.
But objects are better, acknowledging that what's needed are self-contained packages of code+state with well-defined interfaces. Thus, to attempt the closure idea within Smalltalk or Squeak, one realization might be to package into the closure a copy of the objects that are visible at the moment the closure is formed. On a monolithic processor, these all could be by reference, and one could have some kind of epoch label or tag to identify the levels of values, differentiating between values held by different instances or between values held by different classed. The idea would be to build the realization so that variables were like base registers in LISP, and objects would "hang" off of them like property values, indexed by these tags.
If one distributes this across a network, then the pointer model either needs to be enriched to object pointers, as in the XML framework, or copies need to be sent.
I think I agree with Vassily that the built in Smalltalk mechanisms for blocks and processes are a superior way to go. Keeping track of closures tucked away in variables is pretty hard when there are very many. Indeed, most programs which use closures make and use one or two in very special and restricted places.
I think it's rather like exception handling in most languages. One can use that as one's primary control structure, but that doesn't make it a good idea.
Hope I was clear. --jtg
______________________________________________________ Jan Theodore Galkowski www.smalltalk.org/ http://www.scguild.com/usr/1707I.html demiourgos@smalltalk.org www.marssociety.org/ ********************************************** PGP Key Fingerprint: 2757 F86D AA51 677D 38D7 964B 9A8D 7852 A494 3790 ********************************************** Get my Public Key from my home page at: http://home.stny.rr.com/algebraist/ **********************************************
______________________________________________
Get free e-mail at http://www.britannica.com
"demiourgos@smalltalk.org" wrote:
On Sat, 29 January 2000, Robert Withers wrote:
This raises a question, Jan. What is the full set of variable bindings in Smalltalk (VW). Global, makes some sense, but what about semi-global and local. Would this be the difference between external bindings in a closure versus argument bindings to the closure?
The next step from here seems to be the impact of namespaces on these concepts. Or rather, do these concepts help in the structuring of a namespace?
[snip]
-- I'm not sure this answered my question above (but Vassili addressed in another post so let's base from there...) but you have raised some other interesting issues, I think. I have recently become familiar with Functional Language concepts (HOF, Lazy eval, currying, ...). One interesting aspect was the ability of changing or adding state, in some FPLs, would only store a diff to the original, for space complexity savings. That's pretty neat. I believe that's what you talk about below...
(more below...)
Well, before I embraced Smalltalk, I was enthusiastic about functional languages, ones where functions were first class objects. The power there came from two places. One was the ability to map things like
[:listItem | ...]
over datastructures. In some sense the mapping was "parameterized" to accept the block as its "innards". The second was the emerging calculus of "computing" or "deriving" programs from specifications. That's pretty erudite.
But, while managing huge states (like a global COMMON) was surely something to be avoided, the need for state always pressed when one was programming with pure functions. Indeed, SCHEME was an attempt to handle the needed state stuff elegantly.
But objects are better, acknowledging that what's needed are self-contained packages of code+state with well-defined interfaces. Thus, to attempt the closure idea within Smalltalk or Squeak, one realization might be to package into the closure a copy of the objects that are visible at the moment the closure is formed. On a monolithic processor, these all could be by reference, and one could have some kind of epoch label or tag to identify the levels of values, differentiating between values held by different instances or between values held by different classed. The idea would be to build the realization so that variables were like base registers in LISP, and objects would "hang" off of them like property values, indexed by these tags.
If one distributes this across a network, then the pointer model either needs to be enriched to object pointers, as in the XML framework, or copies need to be sent.
I think I agree with Vassily that the built in Smalltalk mechanisms for blocks and processes are a superior way to go. Keeping track of closures tucked away in variables is pretty hard when there are very many. Indeed, most programs which use closures make and use one or two in very special and restricted places.
-- I jive with that. Program structure should be modelled in classes, not anonymous closures or complex exception systems. However, isn't it of benefit to realize full closures?
cheers, Rob
I think it's rather like exception handling in most languages. One can use that as one's primary control structure, but that doesn't make it a good idea.
Hope I was clear. --jtg
squeak-dev@lists.squeakfoundation.org