🚀 go-pugleaf

In article <TMB.92Nov16140138@arolla.idiap.ch> tmb@idiap.ch writes:
>In article <1e775rINNslq@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:

>     Prof. Rubin wants to use a syntax which cannot be parsed with the
>   "standard" tools of compiler contruction kits.  Think of 
>   the old standbys "lex 'n' yacc"---he essentially wants something in
>   which the "tables" themselves could somehow be altered using langauge
>   statements.  Maybe the world doesn't revolve around statically generated
>   context-free unambiguous grammars.

>   Too many computer scientists think that "syntax is trivial" or "syntax
>   is uninteresting", which it may be to the inside of a compiler, but isn't
>   to ordinary users.

>Far from it. In fact, a lot of research in computer science is
>directed at coming up with ways of letting people specify syntax and
>syntactic transformations as conveniently as possible. Reality is that
>this is a hard problem. That's why there are only compromises
>available.

I must agree with Matt's statement.  Probably dozens of articles have
been posted saying that if the semantic aspects are there, the syntax
is not important.  

>The available compromises are the following:

> * Programming languages themselves nowadays only let you specify very
>   limited syntactic extensions, because such extensions are difficult
>   to scope properly (mind you, the computer and the parser have no
>   problem with this, it is the humans that can't deal with it).  This
>   isn't the result of some kind of "language fascism", but of market
>   forces: languages that have allowed more general syntactic
>   extensions simply never caught on, presumably because such
>   extensions were causing more hassle than they were worth.

I am not at all convinced that this is the case.  I doubt that they were
left out of C++ because humans could have problems with them; if that is
the case, a warning should be sufficient.  I believe that the reason the
extensions of this type have not caught on is that they were either extensions
to languages which would not otherwise catch on anyhow, or that they were
highly restricted extensions with a horrible syntax, so it would not be an
improvement.

As for the problem with market forces, this is why I would like to see a
separate macro processor.  This would allow the user to work through the
implementation of a translation to what the compiler can handle once, and
separate from the code generation. 

> * Some programming languages use limited syntax but allow very
>   general transformations (e.g., Lisp macros).

> * There are a number of general-purpose tools for writing systems
>   that perform syntactic transformations (yacc, TXL, Prolog, ...).
>   Such systems let you express just about any syntax you might want
>   to, but because they are so powerful, they are more difficult to
>   use.

>Now, there is certainly room for improvement, so if you don't like
>what you are getting right now, maybe you can come up with something
>better.

Provide me with a few GOOD CS graduate students, and I might be able to
do it.    t they had better be "hacker" quality.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)