Re: Grammars for future languages

timd@Starbase.NeoSoft.COM (Mystic Monkey)
Mon, 30 Oct 1995 19:09:31 GMT

          From comp.compilers

Related articles
Grammars for future languages schinz@guano.alphanet.ch (1995-10-22)
Re: Grammars for future languages torbenm@diku.dk (1995-10-24)
Re: Grammars for future languages mfinney@inmind.com (1995-10-24)
Re: Grammars for future languages RWARD@math.otago.ac.nz (Roy Ward) (1995-10-26)
Re: Grammars for future languages wdavis@dw3f.ess.harris.com (1995-10-26)
Re: Grammars for future languages timd@Starbase.NeoSoft.COM (1995-10-30)
Re: Grammars for future languages jaidi@technet.sg (1995-11-09)
Re: Grammars for future languages martelli@cadlab.it (1995-11-04)
Re: Grammars for future languages schinz@guano.alphanet.ch (1995-11-05)
Re: Grammars for future languages ECE@dwaf-hri.pwv.gov.za (John Carter) (1995-11-07)
Re: Grammars for future languages mbbad@s-crim1.daresbury.ac.uk (1995-11-08)
Re: Grammars for future languages szilagyi@szilagyi.mit.edu (1995-11-09)
[8 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: timd@Starbase.NeoSoft.COM (Mystic Monkey)
Keywords: syntax, design
Organization: NeoSoft Internet Services +1 713 968 5800
References: 95-10-103 95-10-129
Date: Mon, 30 Oct 1995 19:09:31 GMT

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


--


Post a followup to this message

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