Re: Grammars for future languages

schinz@guano.alphanet.ch (Michel Schinz) wrote:


> Also, even if being close to the mathematical notation was once very
> important, because the vast majority of programs used mathematics a
> lot, this isn't true anymore. Ok, there are still a lot of
> mathematical programs, but there is also a wide range of computer
> applications which simply do not need a special notation for
> arithmetic operations (compilers are an example).


I disagree with this. I have been working on a ReWrite Compiler for the
past while. This is my own new language, so I can choose whatever syntax
I like.


In the earlier versions, I had a consistent syntax (everything was a
prefix function, somewhat like Lisp).


After quite a while of this, I had got used to (but still didn't like)
seeing things such as


+[a,1]


throughout my code, so I have now broken that consistency, so that
it now reads


a+1 (or plus[a,1] see below).


What I had realized is that no matter how much more consistent it was,
with my background in _algebra_ (not programming), the infix notation
was pretty firmly entrenched (in me anyway). This from someone who
had programmed for years in postfix on a Hewlett-Packard calculator.


I suspect that most people have seen enough infix notation in non-computer
areas that this becomes 'more natural', although I wouldn't take that as
far as to use the Pascal like if ... then ... structure.


If[ I ever need to implement 'if' , it will be done like this ];
because there is not such a strong model to mimic - there are a variety
of ways of naturally expressing 'if' in natural language. 'If ... then ... '
is the usual one, but that requires too much of a special syntax for my
liking.


The application that I was working on? ReWrite is written in
itself, so what I wanted this infix notation for was compiler writing.


> Simple and uniform grammars also have a great advantage when one wants
> to add new features to a language, like object-oriented capabilities.
> With simple grammars, user-defined constructs look just like
> predefined constructs. That means that it is possible to add new
> language features without modifying the grammar, and thus the
> compiler. For example, it is possible to add OO-capabilities to
> Lisp-like languages (see for example CLOS) without modifying the
> compiler at all. On the other hand, you can't make a C compiler
> compile C++ code without modifying it, because new grammar constructs
> are needed for the OO-features. (Ok, I agree, this argument has some
> weak points: it is not just because of its grammar that
> OO-capabilities can easily be added to CommonLisp: macros and other
> things are required. Also, it might be possible to add OO-capabilities
> to C without new grammar constructs. But the fact is that this is not
> the way it has been done, and I think that the grammar is one of the
> main cause of this situation.)


what I have done with ReWrite to maintain _some_ consistency of notation,
is that I have defined operation such as plus, not, etc. and effectively
defined the infix forms as being equivalent to the prefix ones, so


a+b is _exactly_ equivalent to plus[a,b]
!a is _exactly_ equivalent to not[a],


so I can deal with these functions in the same way as any others.


(The reason that I have used words rather than symbols for prefix operators
is that I have chosen that 'names' must be (alpha)(alpha|digit)+ and it is
good to be able to 'get at' these functions)


Admittedly, I haven't implemented full objects yet (still trying to decide
what I want) so I don't know how tough this will be.


[SNIP]


> I think that this issue is an important one, because if all new
> languages are designed to have a simple grammar, parsing could slowly
> become much easier, and its importance in compilation would decrease.


I could be wrong, but I would imagine that there are enough tools and
techniques around so that parsing should _not_ be the big difficulty with
compiliation. Not to say that syntax doesn't require very careful thought
for userbility considerations.


My summary would be that syntax should be designed to make the language
as easy to use and intuitive as possible, without breaking the ability
to extend the language. Neither completely uniform grammars or completely
ad-hoc grammars are the be-all and end-all, although uniformity is desirable
where reasonable.


Cheers,
Roy Ward.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.