Subject: Re: Better Dylan syntax?
From: Erik Naggum <>
Date: 1997/08/29
Newsgroups: comp.lang.dylan,comp.lang.lisp
Message-ID: <>

* Kelly Murray
| Another one I think is a confusing in Lisp is the single quote character.

I think I'll make the objection a little wider than just single quote
characters.  reader macros are bad, one might argue, because they introduce
new syntax.  the "syntax disease" is to create new syntax just because you
need a new language feature.  Common Lisp should not suffer from this
illness, one might argue, because it destroys all the benefits of the

instead of (list 'a), one could equally well write (list (quote a)), and
instead of (member <item> <list> :test #'equalp), one could equally well
write (member <item> <list> :test (function equalp)), but things do get a
little hairier with other construct that have been given special reader
macros.  #(foo bar zot) must be written #.(make-array 3 :initial-contents
(quote (foo bar zot))) -- oops, I meant (load-time-value (make-array 3
:initial-contents (quote (foo bar zot)))).  suddenly, we find ourselves
arguing against read-time construction of non-trivial constants.

while we could get rid of ' and #' in exchange for a little more typing, we
could _not_ get rid of reader macros as such without serious overhaul of
the way data is read and written in Lisp.  first, we don't want to go the
route of the spastic syntactics (Perl, C++) and create languages so hard to
parse nobody gets it right except the compiler (and that only if you're
lucky).  second, we really do _not_ want to break the distinction between
read-time construction of constants and evaluation (compile-time or
run-time, although the latter is so hard to get right today that a simpler
syntax would be tempting :) -- or we end up with different languages for
code and data, and we can't read source programs as data, anymore.

note that reader macros control the interpretation of the input stream as
data, not the grammar of the language.  while "need a new language feature"
is a commonality between any creation of new syntax, their kinds and the
reasons for their needs are radically different between Lisp and most other

| It is quite unsettling to see (list 'a) if you've never seen or
| understood Lisp before.  (not to mention many editors/wordprocs want to
| match quote chars)

I saw (list (quote a)) before I ever saw (list 'a), and I have never even
considered what you think is a problem as any more than a 5-second lesson.

| There is no reason single quotes can't be matched ...

well, if (list 'foo) would become (list 'foo'), then '(foo) would become
'(foo)', and (list '|foo bar|) would probably become (list 'foo bar')
because it's obvious that the space would be a stupid error and it might as
well be put to use, but then '(foo)' in the uncommon Lisp would be
interpreted as '|(foo)| in Common Lisp, right?  likewise, is (list 'foo
'bar) in the uncommon Lisp the same as (list 'foo' bar) or an error?

is (list 'foo''bar') really a list of a single symbol |foo'bar|, the way
doubled quoting symbols are used in many languages?

is '(foo bar 'zot' quux)' and (quote (foo bar (quote zot) quux)) the same,
or is it the error it looks like it is?  anybody remember the arcane syntax
of the `` process output operators in Unix shells and its interaction with
internal quoting mechanisms in Bourne and C shell?  modern shells use a new
syntax $(...) instead of `...`, and, amazingly, the quoting problems just
disappeared.  I see no reason to reinvent the syntax of the C shell.

so, how about using matching delimiters for quoted constants, instead?
then we could write [(foo bar [zot] quux)] without ambiguity at any level,
and the pretty-printer could just be told to print (quote x) as [x], but
before we re-invent the syntax for `quote', it would be of immense benefit
to all programmers everywhere if _strings_ could have opening and closing
delimiters so it was possible to determine whether you were inside or
outside a literal string without parsing the entire file from the start to
wherever you are.  to those who have ISO 8859-1 available to them, and get
this in the full glory of 8-bit transport, I would like strings to look
like this: «hello, elegant» instead of "goodbye, stupid".  I can easily add
reader macros that read this correctly, but printing strings from the Lisp
with this new syntax is much harder.  I don't think it should be.

| Try to explain THAT one to a non-Lisper, or better yet #'(lambda () ).
| Sure anyone can get used to it, and perhaps quickly, but will they get
| past it?

once people have heard that 'x is _identical_ to (quote x) and #'x is
identical to (function x), I have never seen them have any problems of any
kind using these abbreviated forms.  I suppose that if you never told them
about this, they would never realize that (car (read-from-string "'foo"))
is the symbol `quote', not the symbol `foo', and they would also think they
needed ' before symbols that weren't to be evaluated, even in quoted lists.
(well, that is actually a question that was posted to comp.emacs a few
months ago, but the person who asked was positively _delighted_ to learn
what 'x actually meant.  seems somebody had just taught him "raw syntax" in
the beautiful C/Perl/C++ tradition.)

| I've found the reaction to my syntactic changes highly negative from just
| about all existing Lisp programmers.

well, the reason _could_ be that they're just plain bad suggestions.

| In my opinion, Lisp people complain loudly how others are hung up about
| syntax, but they are the worst complainers of all when someone wants to
| change Lisp syntax.

yes, they are, but there is no contradiction in this observation.

we observe that "the others" are hung up in their syntax for _grammatic_
reasons, while Lisp purists maintain that each _type_ should have a unique
read and write syntax that facilitates transparent interchange of permanent
objects over text streams.  (unfortunately, there are serious flaws in how
this is done in practice when the writer doesn't know what the reader will
accept, and the reader doesn't know what the writer used to think when it
wrote what it tries to read, as alluded to above for strings.)

whenever somebody wants to change the Lisp syntax, it's a pretty safe bet
that it is for grammatical reasons, but this is against the Lisp tradition
for its type-centric syntax, and thus it will be rejected, and it _should_
be rejected, because grammatical syntax is fundamentally _wrong_.  if Lisp
is afflicted with it, the reactions are just as fierce as when we find that
the syntax-grammarians insist on adding more hieroglyphics to their caves.

also, Lisp's syntax is 100% configurable.  nothing whatsoever keeps you
from installing a brand new readtable that doesn't even recognize Lisp, but
you get to install a brand new printer, as well, and this is more boring.
you could even read your input with an LR(k) parser with "keywords" and
conflicts and whatnot, instead of the simple LL(1) language that Lisp
parses with its recursive descent technology.

| We will all just end up using C/Java syntax in the end it seems.

only if we buy into their _grammatical_ syntax and abandon the _type_
syntax unique to Lisp (or nearly so, anyway).  Lisp will never abandon its
type-centric view of syntax, so we will not end up using syntax for grammar
any time soon.

(note: I just named these concepts "grammatical syntax" and "type syntax",
ignorant as I am of any prior art in this important field, and I'm not even
sure these concepts are all that valid in the first place.)

[also, greetings to all from my cat, Xyzzy, who stretched out in her sleep
and rested her head long enough on the `delete' key while I got up to get
some more coffee that I had to retype major parts of this message, and thus
had time to figure out the two syntax concepts.]

404 You're better off without that file.  Trust me.