As I mentioned, Smalltalk-71 was never implemented -- and rarely mentioned (but
it was part of the history of Smalltalk so I put in a few words about it).
If we had implemented it, we probably would have cleaned up the look of it, and
also some of the conventions.
You are right that part of it is like a term rewriting system, and part of it
has state (object state).
to ... do ... is a operation. The match is on everything between toand do
For example, the first line with "cons" in it does the "car" operation (which
here is "hd").
The second line with "cons" in it does "replaca". The value of "hd" is being
replaced by the value of "c".
One of the struggles with this design was to try to make something almost as
simple as LOGO, but that could do language extensions, simple AI backward
chaining inferencing (like Winograd's block stacking problem), etc.
The turgid punctuations (as I mentioned in the history) were attempts to find
ways to do many different kinds of matching.
So we were probably lucky that Smalltalk-72 came along .... It's pattern
matching was less general, but quite a bit could be done as far as driving an
extensible interpreter with it.
However, some of these ideas were done better later. I think by Leler, and
certainly by Joe Goguen, and others.
Cheers,
Alan
>________________________________
> From: Jakob Praher <ja...@praher.info>
>To: Alan Kay <alan.n...@yahoo.com>; Fundamentals of New Computing
><fonc@vpri.org>
>Sent: Tuesday, February 28, 2012 12:52 PM
>Subject: Re: [fonc] Error trying to compile COLA
>
>
>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
>> directly. The Early History of Smalltalk 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' The Early History of Smalltalk 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'
>and
>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?
>
>Best,
>Jakob
>
>
>
>>
>>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 <ryan.mitch...@gmail.com>
>>>To: fonc@vpri.org
>>>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@vpri.org
>>>http://vpri.org/mailman/listinfo/fonc
>>>
>>>
>>>
>>
>>
>>_______________________________________________
fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
>
>
>_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
