"demiourgos at 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

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!