Path: utzoo!attcan!uunet!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.lisp
Subject: Re: Virtues(?) of Lisp syntax
Keywords: syntax words,functions
Message-ID: <3786@goanna.cs.rmit.oz.au>
Date: 18 Sep 90 13:10:57 GMT
References: <3368@skye.ed.ac.uk> <1350030@otter.hpl.hp.com> <3408@skye.ed.ac.uk> <3466@syma.sussex.ac.uk>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 67

In article <3466@syma.sussex.ac.uk>, aarons@syma.sussex.ac.uk (Aaron Sloman) writes:
> It (lack of a defined internal form) is a strength because Pop-11
> (unlike older versions of Pop) provides an alternative to writing
> macros. I.e. you can define a syntactic extension by creating a
> syntax word that reads in text and then plants instructions for the
> PVM.

Was it Madcap that used to do that?

> Could a compiled ML or
> Prolog be defined using Lisp macros?

Yes.  All you have to do is provide appropriate syntactic forms for
the macros to expand into.  In Interlisp-D, for example, it would be
quite straightforward.  It's not the *top* level that's special here,
it's the *bottom* level.

> The lack of a defined internal form enhances extendability: if there
> were a defined internal form you could not create an extension that
> did not map onto that form.

But if every PVM instruction were available as a construct that could
appear in text, there would be no such extension possible.

For example, in many C compilers, there is no assembly code program
which cannot be generated by that compiler, because there is an asm()
construct which can be used to generate the instruction of your choice.
Nearer "home" (in the sense that it is more like the way suitable Lisp
compilers work) the Sun C compilers use ".il" files which let you map
what looks like a function call to the instructions of your choice, and
peephole optimisation happens after such expansion.  It's the _bottom_
level that matters here.


[Aaron Sloman]
> But most designers of programming languages don't think about human
> cognitive processes.

[Richard O'Keefe]
> You should read C.J.Date's comments on SQL...

I had in mind his "A Guide to the SQL Standard".
I think the mildest thing he has ever said is
"it has to be said that the SQL standard is not a particularly _good_ one".
Next mildest: "SQL in its present form is extremely _un_orthogonal and is
chock full of apparently arbitrary restrictions, exceptions, and special
rules."
And the relevant quote is in the Guide, which I haven't here, so from
memory "There are a lot of principles known for designing programming
languages.  Unfortunately the design of SQL respects none of them."
Of course the design principles he refers to: consistency, orthogonality,
and so on are basically cognitive principles.  In "Relational Database
writings 1985-1989" chapter 13 is "EXISTS is not 'Exists'! (Some Logical
Flaws in SQL)" whose abstract is (and I quote literally) "SQL is not sound."
His point is that the logical connectives of SQL do not behave like the
logical connectives of logic.  (Neither do and-then and or-else in Prolog,
but they are closer than SQL.)  Again: this is a cognitive point; perhaps
the operations in SQL can be justified, but can introducing such a clash
between what the user expects (because of the names) and what the user
_gets_ be justified?

To return to Lisp:  now that I have read part of CLtL-2, I have become
convinced that Scheme is the Lisp for ->me<-.  Why?  Because I think I
understand it, and I'm quite sure that I don't understand CLtL-2.

-- 
Heuer's Law:  Any feature is a bug unless it can be turned off.