Re: syntax extenstion, was Why context-free?

haberg@math.su.se (Hans Aberg)
1 Nov 2005 00:21:36 -0500

          From comp.compilers

Related articles
Why context-free? nmm1@cus.cam.ac.uk (2005-10-06)
Re: Why context-free? bobduff@shell01.TheWorld.com (Robert A Duff) (2005-10-07)
Re: Why context-free? nmm1@cus.cam.ac.uk (2005-10-08)
Re: syntax extenstion, was Why context-free? haberg@math.su.se (2005-11-01)
Re: syntax extension, was Why context-free? 148f3wg02@sneakemail.com (Karsten Nyblad) (2005-11-01)
Re: syntax extension, was Why context-free? haberg@math.su.se (2005-11-02)
Re: syntax extension, was Why context-free? henry@spsystems.net (2005-11-26)
Re: syntax extension, was Why context-free? haberg@math.su.se (2005-11-27)
Re: syntax extension, was Why context-free? mpah@thegreen.co.uk (2005-12-08)
Re: syntax extension, was Why context-free? rfigura@erbse.azagtoth.de (Robert Figura) (2005-12-15)
| List of all articles for this month |

From: haberg@math.su.se (Hans Aberg)
Newsgroups: comp.compilers
Date: 1 Nov 2005 00:21:36 -0500
Organization: Mathematics
References: 05-10-053 05-10-061 05-10-062
Keywords: parse, design

  johnl@iecc.com (John R Levine) wrote:
> As far as extending the syntax on the fly, that avenue was
> extensively investigated in the 1970s in languages like IMP-72 and
> EL/1, all of which died. We discovered that if you can write every
> program in a slightly different language, six months later you won't
> remember what each language was and you won't be able to read any of
> them. OOP style type extensions seem to be reasonably easy to
> understand, but new and improved ternary operators and mobius loops
> are not.


This seems to lead to an interesting language design principle:


When I studied physics, I was told that one's notes to describe the
experiments one is doing much be sufficiently detailed that one self can
read them six months later. They quoted some guy who six months later
could not write the paper or thesis, whatever it was, due to insufficient
notes explaining how that special, crucial experiment was performed.


So, in language design, there must be a balance: The language must be
sufficiently rich to admit the programmer express the programming task
at hand. If the language is not sufficient in itself, the
extensibility features must be such that the semantics can fairly
easily be deduced.


I am somewhat interested in this question, writing on a theorem prover,
because in pure math, there is not universal accepted notation: each paper
can in principle have its own syntax, even though heavily dictated by the
notions at hand, as well by traditions. So this calls for some
extensibility. But too much extensibility will probably be quite unusable
from the practical point of view. So there is a question what might be
suitable to tuck this syntax problem conveniently away, from the
implementation point of view.


--
    Hans Aberg


Post a followup to this message

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