🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #2803

Re: syntactic extensions

#2803
From: David Gudeman
Date: Tue, 19 Feb 1991 22:32
49 lines
2805 bytes
In article  <jrukre6em@snitor.uucp> Doug Moen writes:
]gudeman@cs.arizona.edu (David Gudeman) writes:
]>You can't do it with (entirely) pre-compiled grammars like those
]>produced by yacc, but modern computer speeds make those superfluous.
]>Table-driven parsers with run-time modifiable tables are plenty fast
]>enough these days.
]
]There are many languages out there that *do* support user defined
]operator syntax, with unary, binary, and mixfix operators, within
]the confines of a fixed, yaccable grammar...

]The one thing you can't do with a fixed grammar is support user defined
]operator precedence...

Then you don't really have user-definable operator syntax.  In Prolog
you can define precedences, allowing the user to create a large number
of familiar and novel notations.  If you can't define precedence, then
you can't do this in general.  C++ just has operator overloading, not
definition of new operators.  Smalltalk just has a strange function
calling notation: "x1 f x2 f3 ... fn xn" (where the fi are lexical
tokens associated with f) instead of f(x1,x2,...,xn).  Far from
letting the user define operators, Smalltalk restricts you to their
own peculiar syntax.  When Smalltalk lets you choose the lexical
tokens for seperating arguments, that's no different from another
language letting you choose function names.

I have similar complaints with APL and Lisp.  All of these so-called
solutions to the problem of letting users define their own syntax
begin by eliminating most of the syntaxes that users want.  Then
they talk about how this isn't a problem "in practice" once you become
comfortable with their notation.  I don't want to become comfortable
with their notation.  I want to define notations that I am already
comfortable with.

]...  If a language has the above properties, then a human,
]knowing the language rules, can pick up an unfamiliar piece of code
]and immediately know how to parse it, without needing to first
]track down all of the operator definitions...

This (like many other arguments given by proponents of paternalistic
languages) sounds like sour grapes.  The problem was hard to solve, so
someone decided that we didn't want to solve it anyway.  Sadly, once
those arguments make it into the popular wisdom, then even when a
solution comes along, it is not used because people already decided
that they didn't want it.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman
Technical Details
Message-ID: <531@coatimundi.cs.arizona.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!noao!arizona!gudeman

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!noao!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: syntactic extensions
Message-ID: <531@coatimundi.cs.arizona.edu>
Date: 19 Feb 91 22:32:05 GMT
Sender: news@cs.arizona.edu
Lines: 49