Fear and loathing of the "perlification" of Smalltalk
Alan Kay
alan.kay at squeakland.org
Wed Sep 5 02:39:17 UTC 2007
At 06:08 PM 9/4/2007, Mathieu Suen wrote:
>I thinks he mean: don't add syntactic rules when you are using your
>language.
No, I didn't mean that.
Right now in Smalltalk-80 one can choose a variety of syntax patterns
(from a fixed set) when one defines a method. In Smalltalk-76, Dan
Ingalls allowed more patterns (including prefixing, call by name, and
the overloading of <- for setters and getters, etc.). This was nicer
IMO. In Smalltalk-72 you could actually define the input grammar when
writing a method. This was even better IMO (even though we perhaps
went too far).
One variation that lies between the ST-80/ST-76 and the unrestricted
grammars of ST-72 (and earlier: Irons' IMP language) that we've
talked about over the years but never done to Smalltalk-80 is to make
up an interface language (that is, a grammar for making grammatical
extensions which allows more forms to be defined but curbs
thoughtless anarchies).
Also/or, the ST-72 approach could be easily fixed and made into
something that would not produce any ambiguities at run time....and
would allow full compilation.
Each of these would probably most naturally be handled by modifying
what can be said in the heading of a method.
In any case, what I meant was that it is too opaque to redefine a
pragmatically written compiler etc., for making most graceful
extensions. This is generally what is required for Smalltalk-80 and
leads away from a base language that is extended to an explosion of
different languages. So I meant that all extensions to the base
language should be simply visible as part of the new code that is
added by the extender and not be hidden in low level mechanisms if at
all possible.
But there are many ways to do graceful useful extensions without
redefining the base language. ST-80 would have to be fixed a little
to allow this, but this kind of deeper extension would pay real
dividends in many areas.
At a deeper level, why not just make a better language than ST-80?
But partly do this by making a better meta-system so that the simple
needs for new forms and behaviors don't have to spark so much
reverberating discussion in the year 2007.
While at this, I think I'd also be tempted to try to make a more
fruitful architecture than ST-80 supplies for dealing with semantic
variants (cf the long discussions about problems of packages,
Monticello, etc.). The problems come from lacks of architectural
semantics for dealing with this kind of modularity and I don't think
trying to supply "life support" in the form of external tools is
going to help much in the long run. This is an important problem that
no language and DE handles well, and it's worthwhile trying to figure
out a stronger semantics to deal with it.
Cheers,
Alan
At 06:08 PM 9/4/2007, Mathieu Suen wrote:
>On Sep 5, 2007, at 2:45 AM, Peter William Lount wrote:
>
>>I wonder Alan, if you could, expand on what you mean by "but it
>>needs to be done at the same level as regular programming (so it
>>can be used by any base version of the language)"?
>
>I thinks he mean: don't add syntactic rules when you are using your
>language.
>
> Mth
>
>
More information about the Squeak-dev
mailing list
|