Andres --

I am on your side in spirit. Smalltalk-72 allowed one to put a grammar on
each class, and this allowed quite a bit of syntactic extension. The result
was good until we tried to share code -- then we found it difficult to read
each other's "perfectly obvious syntaxes". Dan Ingalls did a cool thing
when he designed Smalltalk-76: make an operator/keyword grammar that all
can read regardless of where the code was written. At the time I made your
suggestion that the compiler could know about other forms, and the very
good answer was that this could make it very difficult again to write code
that would not generate lots of syntax conflicts. The best solution to this
problem that I have seen is CodeWorks by Mark Lentzner, in which a little
more flexibility is allowed in where the keywords can go, but in which the
language is still unambiguous to read and write.

Better readability is one of the main issues we are addressing over the
next months and year, so perhaps some of your hopes will be realized ...

Cheers,

Alan

-------

At 1:37 AM -0000 11/3/98, sqrmax at cvtci.com.ar wrote:
>Hi.
>
>>[Incidentally, that would be (aBitStream next: (40 bits))]
>>Knowing what method selectors exist in the image would not be enough. If
>>there existed #next:bits, #next:, and #bits, you would not be able to tell
>>which interpretation of "<expr1> next: <expr2> bits" was the proper one
>>without knowing (and you can't) the types of the expression results.
>What's
>>even worse, in a dynamic environment where selectors come and go, adding
>or
>>removing a selector would mean potentially changing the parse tree of some
>>of the already compiled methods.
>
>What I also wanted was a way to tell the compiler that the method indeed is
>#next:bits, and then no ambiguity can happen (I guess).
>
>Andres.