Dear Alan,

Am 28.02.12 14:54, schrieb Alan Kay:
> Hi Ryan
> Check out Smalltalk-71, which was a design to do just what you suggest
> -- it was basically an attempt to combine some of my favorite
> languages of the time -- Logo and Lisp, Carl Hewitt's Planner, Lisp
> 70, etc.
do you have a detailled documentation of Smalltalk 71 somewhere?
Something like a Smalltalk 71 for Smalltalk 80 programmers :-)
In the early history of Smalltalk you mention it as

> It was a kind of parser with object-attachment that executed tokens

>From the examples I think that "do 'expr'" is evaluating expr by using
previous "to 'ident' :arg1..:argN <body>".

As an example "do 'factorial 3'" should  evaluate to 6 considering:

to 'factorial' 0 is 1
to 'factorial' :n do 'n*factorial n-1'

What about arithmetic and precendence: What part of language was built
into the system?
- :var denote variables, whereas var denotes the instantiated value of
:var in the expr, e.g. :n vs 'n-1'
- 'xxxx' denote simple tokens (in the head) as well as expressions (in
the body)?
- to, do are keywords
- () can be used for precedence

You described evaluation as straightforward pattern-matching.
It somehow reminds me of a term rewriting system -  e.g 'hd' ('cons' :a
:b) '<-'  :c " is a structured term.
I know rewriting systems which first parse into an abstract
representation (e.g. prefix form) and transforms on the abstract syntax
- whereas in Smalltalk 71 the concrete syntax seems to be used in the rules.

Also it seems redundant to both have:
to 'hd' ('cons' :a :b) do 'a'
to 'hd' ('cons' :a :b) '<-'  :c  do 'a <- c'

Is this made to make sure that the left hand side of <- has to be a hd
(cons :a :b) expression?


> This never got implemented because of "a bet" that turned into
> Smalltalk-72, which also did what you suggest, but in a less
> comprehensive way -- think of each object as a Lisp closure that could
> be sent a pointer to the message and could then parse-and-eval that. 
> A key to scaling -- that we didn't try to do -- is "semantic typing"
> (which I think is discussed in some of the STEPS material) -- that is:
> to be able to characterize the meaning of what is needed and produced
> in terms of a description rather than a label. Looks like we won't get
> to that idea this time either.
> Cheers,
> Alan
>     ------------------------------------------------------------------------
>     *From:* Ryan Mitchley <>
>     *To:*
>     *Sent:* Tuesday, February 28, 2012 12:57 AM
>     *Subject:* Re: [fonc] Error trying to compile COLA
>     On 27/02/2012 19:48, Tony Garnock-Jones wrote:
>>     My interest in it came out of thinking about integrating pub/sub
>>     (multi- and broadcast) messaging into the heart of a language.
>>     What would a Smalltalk look like if, instead of a strict unicast
>>     model with multi- and broadcast constructed atop (via
>>     Observer/Observable), it had a messaging model capable of
>>     natively expressing unicast, anycast, multicast, and broadcast
>>     patterns? 
>     I've wondered if pattern matching shouldn't be a foundation of
>     method resolution (akin to binding with backtracking in Prolog) -
>     if a multicast message matches, the "method" is invoked (with much
>     less specificity than traditional method resolution by
>     name/token). This is maybe closer to the biological model of a
>     cell surface receptor.
>     Of course, complexity is an issue with this approach (potentially
>     NP-complete).
>     Maybe this has been done and I've missed it.
>     _______________________________________________
>     fonc mailing list
> <>
> _______________________________________________
> fonc mailing list

fonc mailing list

Reply via email to