Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!ukma!tut.cis.ohio-state.edu!ucbvax!hplabs!otter!sfk
From: sfk@otter.hpl.hp.com (Stephen Knight)
Newsgroups: comp.lang.lisp
Subject: Re: (Long) Code as data (Lisp's syntax - Answer to Stephen Knight).
Message-ID: <1350022@otter.hpl.hp.com>
Date: 13 Jun 89 09:45:32 GMT
References: <2727@ski.cs.vu.nl>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 110

> Any problems with e.g. [x+y*z], where the brackets are used to indicate the
> switch in syntactic style (that is, if one writes in infix Pascal style
> only, no brackets are needed)?

Essentially, no.  Lisp's which support this infix syntax are mostly good news.
What I am asking for, however, is a presentation of Lisp with a totally 
different syntax, including printing of expressions, error messages, and 
the support of an agreed standard.

> Another thing, of course, is
> whether one should have many data types in the first place, but once they
> are there they should be denotable.
                 ^^^^^^^^^^^^^^^^^^^
There's no need.  Why clutter up the language?

> >Lisp has slowly but surely over the years acquired a concrete syntax whose
> >relationship with the underlying parser tree is less and less direct.
> 
> Well, roughly a syntactic construct per data type. What is "less direct"
> about that?

A fair question.  In the syntax I sketchily outlined, there is also a syntactic
construct per data type (rather less in fact) with a one-to-one correspondance.
But I don't make the claim that my syntax has an obvious relationship to the
parse tree.  So I don't consider this to be a rebuttal.  I think it is the
role of concrete syntax to present the abstract syntax in a more readable and
inevitably less direct form.

> I can only interpret this if I assume that you indeed were confused 

Well, its a fair cop, guv.  I forgot at the time of writing that '|' is not
a quote at the semantic but only at the syntactic level.  This doesn't actually
affect the underlying argument.  It just makes it harder to understand :-)

> All literals *may* be quoted already, and *only* literals can be quoted.
> Self-evaluating expressions are an optional addition for ease of writing.

And the ease of writing is at the expense of machine tractability as the
two programs 0 and '0 are equivalent.  I frequently find myself writing
canonisation programs to eliminate this (and other) ambiguities.

> Have you had expreience with a good Lisp environment (e.g. Interlisp)?

You're too quick for me!  I've done no serious work on any dedicated Lisp 
hardware, which seems to be virtually synonymous with this.  For reasons
I've already explained, I don't believe it makes sense for programmers to
use infix-syntax *in the current situation*.  What makes my fantasy a fantasy
is that it supposes the situation will change!

> Except the standardisation part, this is the current situation.  And see what
> happens: almost everybody sticks with the old syntax.

Yes, I've seen it happen.  I've used Lisps with multiple syntaxes & no one,
including me, switched.  I tried to outline the reasons in my first letter.

> Hey, going back to the olden days of M-expressions? What about EVALQUOTE?
> No, seriously, I think there is a reason why S-expressions won from
> M-expressions once they were introduced.

I'd be interested.

> >* The list syntax of Prolog is admirable because it elegantly integrates
> >  bracketing with list appending without the need for quoting (as in Lisp
> >  and Pop11) and *also* works in a functional context, unlike other Prologian
> >  ideas.
> 
> But what would a literal list look like, then?  Remember that

This is a very pertinent question indeed.  Semanically, you need a quoting
mechanism.  So what is the syntax going to be?  Pop11 has two suggestions to
make.  Firstly it has a pair of "compile-time" or quoting brackets.  Secondly,
it has a class of identfiers (lexical constants) whose values are established
at compile time.  I will take the first approach for simplicity, as the second
approach requires more explanation.  The quoting brackets will be #< and >#.
(OK, you think they look ugly?  Good, they're meant to be.  They're
potentially dangerous.)  So encoding the suggested examples, and assuming
that word quotes are the single quotes (which match, of course).

> (define (foo) '(a b c))
> (eq (foo) (foo))		--> #t,

define foo() as
    #< ['a', 'b', 'c'] >#
enddefine

> (define (bar) (list 'a 'b 'c))
> (eq (bar) (bar))		--> #f.

define bar() as
    ['a', 'b', 'c']
enddefine

Neither of these looks as cute as the original.  There are two reasons why this
is so, reasons which are designed into the outlined syntax.  Firstly, compile
time constants that are mutable are potential bugs.  Secondly, quoting words
explicitly is relatively uncommon and often poor practice.  The syntactic
overhead of quoting them is tolerable and in-line with the syntax of all other
denotable values.

> [why not locally define fold?]

It's soooo useful.  Otherwise, local definition would be better style.

> Apart from the left-to-right assignment, I would surely take a look at Clisp.

Will it run on HP9000/300 series ?-)  More seriously, thanks for pointing
it out.  I'll try.

Steve Knight
HP Labs, Bristol, UK