Dear All!

Curiously not wanting to provoke you or offend you, Smalltalk was
  > the only language among Basic,  Fortran ( I studied Fortran when I
  > was nineteen years old and a Biological Sciences student concerned with
  > ecological modeling - my ex-husband was the professor, he was teaching
  > a graduate course for electronic engineers! I was the best student! I
  > got
  > 10 and he has not at all helped me! Indeed he hated to teach me
  > anything!)
  > , Pascal, C,  Modula, Oberon, Simula,
  > C++, Eiffel, Sather, CLOS, Beta (The Mjolner Beta System and the
  > Simula system)
  > that I was unable to study by myself!

  This is fun because for me this is the opposite. But I come from a lisp
  background and I not syntax-aware and not polluted by {}.

OK! Let's check how wonderful and didactic it is to study Smalltalk
and associated languages!

First of all, I have read nine pages from the paper The Early History of
Smalltalk that may be downloaded from

and has recently been published at ACM SIGOLAN Notices, vol. 28 no.3
March 1993
Alan Kay is very honest and makes evident how naïve and simple ideas
dawned on the computer scientists to keep the ball rolling are woven into
computer systems!
Then it is up to the users to reject them or simply pretend they are doing
research on computer science that is really having impact on the change
of the quality of life on Mother Earth! Sorry if I do not manage to teach
seventeen-year old architects how to program complex systems such
as to design and plan sustainable cities, I do not see mankind is really
building a sustainable basis for our cities. Hence everybody will face
collapse soon! Nobody cares about this of course! But I do care! This is
my mission!

Alan Kay says: The bridge to an object-based system could be in terms of each object as a syntax-directed interpreter of messages sent to it. = unify
OO semantics with the ideal of a completely extensible language

Just perfect:-)! Then to continue reading the rest of paper he takes for
granted that I know about car, cdr,  cons eval apply functions, lambda
expressions, quotes conds etc!
Then I start reading On Lisp from Paul Graham you can download on site or html?

Of course not only does he explain nothing about car, cdr, cons etc  and
worse introduce lots of expressions and commands I have never heard of!!!
For example can someone explain to me how can I understand the following
closure to make a new database?

(defun make-dbms (db)
      #'(lambda (key)
           (cdr (assoc key db))
      #'(lambda (key val)
           (push (cons key val) db)
       #'(lambda  (key)
            (setf db  (delete key db :key  #' car))

For me this is a nightmare! And the same obstacles I find when I try
to delve deeper into Smalltalk and Self!!! It is worse than biochemistry
because in biochemistry every new enzyme or organic product that appears
one knows why! I mean it is a coherent whole!
Special thanks and apologies for complaining, but I do need to understand
the gist of exploratory programming. Is it the same as bottom-up programming
what's the difference?
Have a fun-filled peaceful creative weekend
Albertina wrote:

James McCartney <> writes:

> It depends on the Smalltalk.
> A full closure can be returned from a function and still refer to that
> function's variables. Self disallows this, as do some Smalltalks I
> beleive. If you support this feature you can no longer put all your
> local variables on the stack, because references to them may outlive
> the function activation in which they were created.

This is a fiction that the Smalltalk crowd likes to talk about, and
it's a shame that the Self crowd also repeats it.

In languages which support closures, it is rare to return them.  Most
functions never return them.  So you can store such local variables on
the stack just fine, for all but the minority of functions which
return closures.

But what about the ones that do?  Well, if you didn't return a
closure, you'd have to do something else to hold the same data, some
kind of allocation, and that has just whatever cost the alternative
non-stack compilation has for the same data.

There is a wrinkle because Smalltalk and Self use internal closures
(whether real or pseudo) for control structures to a higher degree
than Lisp/Scheme usually do.  However, it is still very rare to
actually return them.

A Lisp/Scheme system therefore can use non-stack allocation for any
function where a closure is created, even if it is not returned (that
is, if it can be taken to have dynamic extent).  But this is not
strictly necessary--Smalltalk and Self do just fine with
pseudo-closures, that is, closures with merely dynamic extent.

So, since Smalltalk/Self code is more aggressive in creating closures,
which are typically not returned, the trick is for the compiler to
detect ones which won't be returned.  This is in general a matter of
detecting aliasing, and it's not too tough for the common uses of
closures in Smalltalk and Self.

So, my suggestion is to bite the bullet and do it right.  Demand real

If you think this is "too hard", then what are you doing with
Smalltalk and Self anyhow?  The whole glory here is that things that
are "too hard" can, indeed, be made quite tractible through good
compilation.  In the case of closures, the techniques are well-known,
and it's a shame that the Smalltalk/Self crowd mostly disregard them.

Your use of Yahoo! Groups is subject to