NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/pop/177

Internet Message Format | 1993-01-01 | 10.7 KB

From: [e-mail] (Steve Knight)
Date: Fri, 1 Jan 1993 17:00:15 GMT
Subject: Re: Syntax Misdesign
Message-ID: <[e-mail]>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!col.hp.com!news.dtc.hp.com!hpscit.sc.hp.com!hplextra!otter.hpl.hp.com!otter!sfk
Newsgroups: comp.lang.pop
References: <[e-mail]>
Lines: 255

I view this discussion as an exploration of the two syntaxs for
quotation and sequence construction in Pepper and POP-11.

Aaron argues as follows:
> 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.

This claim isn't correct in the context of the quasi-quotation solution
used in Pepper.  This is because lists and vector construction is
respected by quasi-quotation in Pepper.  And there is less mechanism in
the Pepper approach so it seems unlikely that there are more errors
due to mislearning, too.  My expectation would be that empirical tests
would show no significant difference between the two approaches in
everyday programming but the Pepper approach would be superior in
ease of learning and understanding of corner-cases.


Aaron goes on to criticise the Pepper syntax as it has been
explained so far:
> 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.

Since the Pepper syntax is a quasi-quotation mechanism it
includes an escape mechanism that forces quotation of meta-symbols.
This mechanism is illustrated a little later.

Perhaps what is less obvious is that POP-11's list and vector
syntax are quasi-quote contexts that lack an escape mechanism
for the meta-symbols '{', '}', '[', ']', '%', '^', and '^^'.  This
is a great nuisance as anyone who has tried to create lists such as
the following will agree
    [ } % ^ the cat on the mat ^^ % { ]
These get written as
    [% "}", "%", "^", % the cat on the mat % "^^", "%", "{" %]


Aaron pursues a particular example which requires a forcing-quotation
mechanism for convenience:
> At present [in POP-11] 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"]

In fact this is an incorrect understanding of the extended quote syntax.
Without an escape mechanism the only way to denote the quote-word would
be an expression evaluating to it, such as
      consword( '"' )
and therefore the example is properly written as
      lconstant quote = consword( '"' );
      [quote, "cat", quote, "->", "x"]
or more naturally
      "[ ^quote cat ^quote -> x ]"

However, Pepper introduces a single escape mechanism for forcing quotation
which is introduced by the '\' token.  The example becomes
      "[ \" cat \" -> x ]"
Although this is not as neat as the ["cat" -> x] notation it is not
particularly ugly either.  Furthermore, it tackles POP-11's awkward
cases without trouble either
      "[ \} \% \^ the cat on the mat \^^ \% \{ ]"


Aaron puts weight behind his example with the claim:
> 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.

I can't agree that this is a common case from my own experience.  But
even should it prove to be true, Pepper's syntax provides a single,
neat means of quoting all symbols inside a quasi-quotation.  POP-11
has a hotch-potch of solutions that don't cover all cases.  In effect,
POP-11 relies on not missing the common cases -- and when it does it
is irritating.  And from my experience, I find the other meta-symbols,
particularly '[', ']', and '%' occurring more frequently than I expect,
and POP-11's syntax finds them quite awkward.


Aaron then puts forward a slightly different solution:
> 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!

The crux of this solution is to distinguish two types of quotation,
quasi-quotation introduced by the '%' symbol and single-word quotation
introduced by the '"' symbol.  When designing Pepper, this solution was
rejected only because we couldn't find another quotation symbol that
wouldn't cause problems.  The suggestion of "%" is profoundly flawed,
as Aaron immediately notes.  Since we wish to employ multi-word
quotation in the context of function application, we have to delete this
particular suggestion.  (Or change the syntax for partial application
and dlocal bindings.)

However, the general idea is plainly viable.  In the design of Pepper,
we felt that once the escape mechanism was introduced it wasn't worth
adding a single-word quotation.  But note that this idea has the merit
of allowing '"' to retain its traditional meaning.

As a closing note, Chris's example below, is an instance which argues
for the need for quasi-quotation to respect list and vector syntax.
>   [
>      ["bill and ben and little weed"],
>      ["andy and teddy and looby loo"],
>      ["thomas the tank engine and friends"]
>   ]

The point of this example is that to a POP-11 programmer, having to put
quotes in all those places is irritating.  The solution adopted in Pepper
is to allow list and vector brackets inside quotes to build lists and
vectors.  This example therefore becomes ....

    "[
      [ bill and ben and little weed ]
      [ andy and teddy and looby loo ]
      [ thomas the tank engine and friends ]
    ]"


In summary, the design principles behind the Pepper (quasi-)quotation
syntax are
    (1) To make quotation independent of list and vector syntax.
    (2) To only have *one* quasi-quotation mechanism.
    (3) To provide a single force-quotation mechanism (\).
Our design goals were
    (4) To be easy to learn for beginners and instantly learnable by
        experienced POP-11 programmers.
    (5) To be a complete system of quotation, by which we mean being able
        to quote all words and to cleanly interact with all syntax for
        data construction (lists, vectors, and strings).

Note that the design principles (1) to (3) are not supported in POP-11 so we
knew we had to significantly depart from the existing syntax.  The solution
adopted is outlined below.  It is plain that it satisfies the principles.
We are reasonably confident that the design goals are also satisfied.
Judge for yourselves.

Steve

PS. I'm writing this without Chris Dollin's permission and, as he's
    the principal designer of Pepper, I must apologise in advance for
    any errors I may have committed in the following outline of
    Pepper's quotation syntax.



Quasi-Quotation In Pepper
-------------------------
A quasi-quotation context is introduced (and closed) by the
symbol '"'.  All symbols other than the following meta-symbols
denote a PUSHQ of themselves.

    Meta-Symbols:  [ ] { } % ^ ^^ \

The meta-symbol '\' forces the next item to be treated as a
ordinary word whether or not it is a meta-symbol or not.  If the
next item is a string it is converted to a word before being PUSHQ'd.
The next item must be a word or string or a compiler error is raised.

The meta-symbol '%' flips the context to an evaluation context up
to the next matching '%'.

The meta-symbol '^' PUSH's the next word unless it is the word '('.
If it is '(' then a single expression is evaluated up to the
next matching ')'.

The meta-symbol '^^' is similar to '^' except that it plants a call
to -explode- immediately afterwards.

The meta-symbols '[' and '{' introduce a list and vector opening
respectively.  Each must be paired with an appropriate list or
vector closing symbol ']' and '}'.  The meaning of an open/close
pair is to construct the list or vector from the items deposited
on the stack between the pair.


Learning Pepper Syntax
----------------------
It is very simple for experienced POP-11 programmers to use Pepper
syntax.  There are only a few things to remember.  Firstly, lists
and vectors don't quote their contents.  So where you might have written
    [ ^x > ^y ]            in POP-11
you might write
    [ x, ">", y ]          in Pepper

Secondly, the '"' symbol now works like the inside of POP-11's vector
syntax and can be used to put a sequence of values on the stack.  So
where you might have written
    f( "cat", "dog", [] )  in POP-11
you might would write
    f( "cat dog []" )      in Pepper.
And where you would have written
    { ^^x ^y ^^z }         in POP-11
you might write
    "{ ^^x ^y ^^z }"       in Pepper

Thirdly, the '\' symbol can be used to force the quotation of any
word or string as a word.  So where you would have written
    "%"                    in POP-11
you will write
    "\%"                   in Pepper
And where you might have written
    [% "[" %]              in POP-11
you would write
    "[ \[ ]"               in Pepper

And that's just about it.  There only thing remaining is to deal with
the issue of list tails.  In POP-11, the meta-symbol '^^' has a very
special role inside lists -- if it appears at the end of a list it
causes list sharing (store aliasing) by making its value the tail
of the newly constructed list.

In other words
    [ ^^x ^y ^^z ]          in POP-11
is different from
    "[ ^^x ^y ^^z ]"        in Pepper
since the POP-11 version forces the newly constructed list to share with
the spine of -z- and the Pepper version doesn't.

Pepper has a different syntax for denoting the tail of lists, derived
from the Prolog syntax.  In Pepper, you would write
    [ x1, x2, ..., xN | t ]
to denote a list whose first N elements were x1 to xN and whose tail was
t.  The advantage of this approach is that the notation highlights the
important semantic difference between the two approaches.

So you might write
    [ ^^x ^y ^^z ]           in POP-11
and
    "[ ^^x ^y | ^z ]"        in Pepper

Furthermore, you would write
    [ ^^x ^y % z.explode %]  in POP-11
to achieve the effect of
    [ ^^x ^y ^^z ]           in Pepper


As I hope is clear, converting from one to the other is very easy indeed.
The only complexity stems from the subtle treatment of '^^' in POP-11 that
often isn't properly understood.  Comparing the two notations is really
best done by working through a few examples.  (If you do this, please
note that the proposed Pepper matcher is quite different to the POP-11
matcher.  This is because the POP-11 matcher is geared up for its own
quotation syntax and is quite unsuitable for Pepper syntax.)