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.
>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'
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 <mailto: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
