Re: Grammars for future languages

Torben AEgidius Mogensen <torbenm@diku.dk> wrote:
>[...]
>While Lisp-like grammars may have the advantage that you don't have
>to remember very many syntactical constructs [...]
>I find that the Lisp syntax is a problem when reading old code.


Ditto.


>[...]
>An alternative to dropping mathematical notation on the basis of
>little use, is to extend the use of mathematical notation to
>non-numerical computations. This is done succesfully in functional
>languages like Haskell, where (for example) you can write code like
>
> [(f . f) x | f <- fncs, x <- elems, x < 17]
>
>which takes the functions f from the list fncs and the elements x from
>the list elems, such that x<17 and applies the functions obtained by
>composing each f with itself to each x, constructing a new list
>therefrom. [...]


Ouch! This is pretty hard for me to parse. The idea of using
set notations, etcs. in languages is good. But, gee, does it
have to be so cryptic?


>[...]
>The breaking point here is not so much having a simple and uniform
>grammar, but rather that the programmer has access to a parser for the
>language, a parser that can be extended to include new features. Macro
>features support this to some extent, but a full parser is more
>flexible.


Well, I don't know how critical this is. There several languages
that allow it. For example, PROLOG. But you can program just
fine without it. Generally, the model of being able to write
and call your own modules will let you handle the needed
functionality sufficiently. I think this is oriented toward
too much dependence on notations.


>[...]
>Parsing is not the hard part of compiling. [...]


True.


In fact, for most pramatic examples, it is pretty much a "solved
problem." I would personally suggest focusing on advances
beyond specifying grammars and more toward smarter editors,
portable intermediate formats, visual interfaces, etc.


-t


--

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