Subject: Re: Better Dylan syntax? From: Erik Naggum <erik@naggum.no> Date: 1997/08/29 Newsgroups: comp.lang.dylan,comp.lang.lisp Message-ID: <3081880885081198@naggum.no> * 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 language. 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 languages. | 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.] #\Erik -- 404 You're better off without that file. Trust me.