[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Dec 22 16:41:40 1992 
Subject:Re: Syntax Misdesign 
From:Aaron Sloman 
Volume-ID:921222.01 

Concerning whether lists should by default quote their contents or
not,

kers@hplb.hpl.hp.com (Chris Dollin) writes:

> Date: 16 Dec 92 16:27:24 GMT
> Organization: Hewlett-Packard Laboratories, Bristol, UK.

(aaron)
>    It's much easier where the default is quotation to have a single
>    pair of brackets to unquote, than when the default is evaluation and
>    lots of quotation marks are needed to quote. Of course, in Lisp you
>    don't need lots of quotation marks as a prefix quotes the whole list
>    expression.

(kers)
> In Pepper I have taken the step Steve describes: the list and vector syntax do
> *not* automatically quote. (Why should they?)

A rhetorical question is not an argument. If square brackets are
defined as quoting then they should quote, if they are not defined
as quoting they should not quote. The question is which happens more
often, which is less misleading, more likely to lead to bugs, etc.

My contention was that if the default is not to quote then more
typing errors will occur when people want to quote things. That's an
empirical claim which could well be false.

(kers)
> ....You want quotation, you quote
> things, and a natural extension to Pop word-quotation is to allow *any* number
> of items between quotes.
>
> Thus the Pop list [bill and ben the flowerpot men] becomes the Pepper list
> ["bill and ben the flowerpot men"]. This means that it is not the case that
> ``lots'' of quotation marks are needed to quote, at least in examples like
> this.

That won't do as it stands, because the double quote symbol " is
itself a word in Pop-11 and needs to be capable of occurring in a
list. At present you can create lists like ["cat" -> x] which, if
given to the compiler (previously to popval) will assign the word
"cat" to x.

On the new notation, you'd have to do
    [""", "cat", """, "->", "x"]

or
    [""", "cat", """ "-> x"]

which is horribly confusing, unless a new convention were introduced
e.g. that within a quoted context in list brackets "" refered to
""". Then you could do

    ["""cat "" -> x"]

Given the frequency with which lists containing quoted words are
created (e.g. in macros, etc.) I think this sort of thing is still
intolerable.

An alternative would be to have lists non-quoting by default, but
allow "%" to toggle quoting as it does now, except immediately
after "(" and before ")", when it would signify partial application,
as in

    maplist(% sqrt %)

So

    %cat dog mouse%

would become equivalent to

    "cat", "dog", "mouse"

Then the above example would be expressed thus

    [% "cat" -> x %]

which I think is much clearer!

(kers)
> It gets a bit more irritating in expressions like:
>
>     [
> 	["bill and ben and little weed"],
> 	["andy and teddy and looby loo"],
> 	["thomas the tank engine and friends"]
>     ]

Which could become
     [
 	[%bill and ben and little weed%],
 	[%andy and teddy and looby loo%],
 	[%thomas the tank engine and friends%]
     ]

> Now you can get irritated (and I did) by the result of separating list and
> vector syntax from quotation; sometimes, when you want to build a list that is
> a mixture of quoted and unquoted material, it is a nusiance. But this is true
> in Pop, too. And I will admit, I did spoil the purity of my position by
> extending the quotation syntax to allow lists, vectors, and unquoted material
> to appear within it. But the result -- that dropping into quotation mode is
> signalled explicitly by quotation marks, which happen to allow list and vector
> constructs within them -- is, I think, a rather nicer design.

It would be possible to allow % .... % to cause nested list and
vector expressions all to be in quote mode by default, with embedded
occurrences of % ... % to unquote.

(aaron)
>    Probably one of the most serious misdesigns is that there's no good
>    syntax for defining procedures that take different combinations of
>    arguments, like, for example, newanyarray or newarray. You have to
>    write horrible code to test what's on the top of the stack.
>
> Well ... I think the horrid code warns us about the horrid idea. I've always
> been unhappy about procedures like newarray *because* they take different
> numbers of arguments, the number being determined by the types of the ``fixed''
> arguments.

I am inclined to agree with this, having just found a bug in Poplog
common lisp due to the fact that giving newanyarray a list
(including []) as the default item (i.e. the second, optional,
argument) causes it to treat the list as the boundslist, i.e. the
first argument. I think an alternative to newanyarray should be
provided that always takes the same number of arguments, but maybe
allows false, or undef to indicate that a default should be used.

Or maybe we need a unique record called default, of type default, so
that isdefault(item) or item == default can be a test for such
items, by analogy with isundef(item), or item == termin.

Aaron
-- 
Aaron Sloman, School of Computer Science,
The University of Birmingham, B15 2TT, England
EMAIL   A.Sloman@cs.bham.ac.uk  OR A.Sloman@bham.ac.uk
Phone: +44-(0)21-414-3711       Fax:   +44-(0)21-414-4281