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
>
>