Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!ukc!etive!aiai!jeff
From: jeff@aiai.uucp (Jeff Dalton)
Newsgroups: comp.lang.lisp
Subject: Re: Re: Code as data (replies to comments).
Message-ID: <534@skye.ed.ac.uk>
Date: 13 Jun 89 16:49:54 GMT
References: <1057@syma.sussex.ac.uk> <1350021@otter.hpl.hp.com>
Sender: news@aiai.ed.ac.uk
Reply-To: jeff@aiai.uucp (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 152

In article <1350021@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Stephen Knight) writes:
>A few quick replies to these interesting comments followed by a longer
>exposition of my crazy ideas.

Your message is a very long one, so I don't think I can respond to
every point in it.

It is true that some people dislike Lisp syntax, and find that a
reason to avoid Lisp.  It's true that some people prefer infix
notation and "if"-"endif" bracketing.  But what still needs to be
taken into account is that some people find the Lisp syntax better and
more readable than the alternatives.  They do not regard it as an bad
compromise or even as a good compromise, trading readability for
something else that's worth more.

That other people disagree and say it is a bad compromise doesn't
mean they're right that it's bad.  People disagree about all kinds
of things for all kinds of reasons.  Some things that suffer near
universal ridicule are later proclaimed by all to be True, Right,
and Good.

You suggest that Lisp might be better off if it supported more
than one syntax.  Well, maybe that's true.  But Lisp already lets
one put additional syntax on top of Lisp.

>> It's a very important benefit of Lisp that there is no distinction
>> between "built-in operators" and "user-defined functions". 
>
>Of course.  But this does not imply prefix syntax (cf. Prolog for counter
>example.)

Most languages do not allow the uer to define new infix operators.
Prolog does, but has a more complex syntax as a result.  Sometimes it
works, so that operator declarations make the code more readable,
sometimes it doesn't.

Besides, as far as I know, there's no portable way for a Prolog
programmer to define new operators that are recognized by is/2.

>>>    Outside the Lisp
>>>    community, the syntax is widely considered to be a laughing matter.  
>> 
>> It's gratifying to see that this conversation is being kept on a
>> rational, intellectual plane.
>
>Maybe you feel the remark was tactless but that's life as I see it,
>sorry.  I *promise* that I was not trying to create a slanging match.  I
>was only trying to show by dramatic contrast that Lispers are very insular
>in their views on the weaknesses of Lisp.

No, we are quite aware that some people dislike Lisp's syntax.
But it does not follow from that that those people are right
and those who prefer Lisp's syntax are wrong.

>The fact that people scoff at Lisp's syntax signifies that a real
>compromise of readability has taken place.

No it doesn't.  People scoff at lots of things.  Sometimes they
have good reasons, other times they don't.  Sometimes they have good
reasons but still turn out to be wrong, or bad reasons but turn out
to be right.

>I appeal to your honesty.  Haven't you noticed people scoffing
>at Lisp purely because of its syntax?  I think that's a silly reason to
>reject a most interesting language.  I want to accept it as a valid criticism
>and propose a route to a better language.

So is it a "silly reason" or a "valid criticism"?

[various things omitted]

>>>    Why are atoms quoted with a single quote at the start?
>> 
>> Everything is quoted with a single quote at the start, not only
>> "atoms".  There's no need for a close quote; it would be entirely
>> redundant.
>
>At the risk of seeming ludicrous for discussing trivia in depth, there is
>a quite serious point lurking here.
>
>It should be clear that there is an implicit closer for an open quote --
>namely the token boundary.

That's the end of the token, not the end of the quote.  There's no
need to think of it as some kind of end of quote.

>If the atom being quoted contains a token boundary in its text it needs
>quoting in a more conventional manner with string-like quotes.  

No it doesn't.  There are two conventions for this sort of thing (not
just in Lisp): quotes and escape characters.  Besides, in Lisp the two
so-called quotes are for two different purposes.  That's why you may
have to write:

   '|this is an atom|

If this is explained as (1) the syntax of symbols and (2) literal
verses expression, there's no need for confusion.

>As this is only an occasional requirement, Lisp has a second quoting
>convention rather than only one.  (It has at least three, of course.)

If you call enough things "quoting conventions", you can have any
number of them I suppose.

>The absurdity is that a quote is chosen for the implicit close convention and
>a vertical bar for the open-close convention.  The point here is that, for a
>beginner, Lisp is dominated by bracket-pairs which must be matched exactly.
>But almost immediately, the beginner is confronted with a quote (a close
>quote, in fact) that doesn't need opening.  The impression of arbitrary rules
>and poor choices is established almost immediately.

What is the close quote that doesn't need opening?  Do you just mean
that the character "'" is a close quote?

Besides, beginners don't need to know about vertical bar at all.

>Rather than raising any more hackles, I'd like to propose my 'vision'
>of Lisp with Pascal-like syntax, and an introduction route that hopefully
>wouldn't have too many Lisp hackers hanging themselves in the morning.  

There's nothing wrong with your syntax, for those who like that
sort of thing.  Why don't you try implementing it and see if lots
of people like it.  I'd certainly be interested in trying it out.

>The next example is defining 'reverse'.  I'd do it like this.
>
>define fold( op, seed, list ) as
>    if list = [] then
>        seed
>    else
>        fold( op, op( list.head, seed ), list.tail )
>    endif
>enddefine
>
>define reverse( list ) as
>    fold( cons, [], list )
>enddefine

I guess I still find the following better:

     (define (fold op seed list)
       (if (null? list)
           seed
         (fold op
               (op (car list) seed)
               (cdr list))))

     (define (reverse list)
       (fold cons '() list))

-- Jeff