Path: utzoo!attcan!uunet!mcsun!ukc!icdoc!syma!aarons
From: aarons@syma.sussex.ac.uk (Aaron Sloman)
Newsgroups: comp.lang.lisp
Subject: Re: Virtues(?) of Lisp syntax
Summary: pros and cons of a defined internal form
Keywords: syntax words,functions
Message-ID: <3466@syma.sussex.ac.uk>
Date: 16 Sep 90 13:05:16 GMT
References: <3368@skye.ed.ac.uk> <1350030@otter.hpl.hp.com> <3408@skye.ed.ac.uk> <3450@syma.sussex.ac.uk> <3752@goanna.cs.rmit.oz.au>
Organization: School of Cognitive & Computing Sciences, Sussex Univ. UK
Lines: 80

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (14 Sep 90)
Organization: Comp Sci, RMIT, Melbourne, Australia

Richard commented on my comments on Jeff Dalton's remarks about Lisp.

(From me)
> > It wasn't till I read this remark of Jeff's that I realised that one
> > reason I don't like Lisp is that, apart from "(" and ")", Lisp
> > doesn't help one to distinguish syntax words and function names.
>
(From Richard)
> I once built a programming language which was a sort of hybrid between
> Lisp and Pop.  In RILL, one wrote e.g.
> 	$IF (> X Y) $THEN (SETQ MAX X) $ELSE (SETQ MAX Y) $FI
> Basically, I used keywords for control structures ($PROC for lambda,
> $BEGIN for let, $IF, $FOR, $WHILE, and so on) and Lisp syntax for the rest.
> The parser _was_ better able to notice typing mistakes, and I _did_ make
> far fewer parenthesis errors than I did with straight Lisp when I later
> got my hands on it.  But that was before I met Emacs.
>
> > By contrast the uniform syntax of lisp makes it not so easy to grasp
> > that car, cdr, sqrt, append, etc. are different beasts from setq,
> > cond, quote, loop,  etc. Hence the tendency to make the kind of
> > mistake that Jeff describes, i.e. talking about different kinds of
> > functions.
>
> The thing about Pop (as it was last time I used it) is that there is
> no defined internal form for code.  At one end of the spectrum we have
> "token stream" and at the other end we have "compiled code", and there
> is nothing in between.
> .....

Nowadays, at least in Poplog, there is the Poplog virtual
machine (PVM) in between, but that is still not easy for user
programs to get hold of, and in any case it is still not the sort of
thing you want.

The lack of something like a well defined internal parse tree
structure for Pop-11 is both a great weakness and a great strength.

It is a weakness because it limits the ability of programs to
analyse Pop-11 programs and makes debugging aids harder to build. It
also makes macros harder to write: you have to read in a "flat"
sequence of text items, then replace it on the input list with a new
sequence, instead of being able to reorganise a parse tree (though
pattern matching utilities of the sort described in your letter can
help).

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. You are not restricted to extensions that map onto what the
Pop-11 compiler can handle, as you would be with macros. A syntax
word can plant any code that makes sense for the PVM, which provides
a richer range of possibilities. Just to illustrate, the PVM can
support ML and Prolog as well as Pop-11 and Common Lisp. PVM
instructions get compiled to machine code. Could a compiled ML or
Prolog be defined using Lisp macros?

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. (I am assuming that any internal form that
is "high level" enough to be useful in the way you want is going to
be more restrictive than the PVM. I don't know how to prove this!)

It may be possible to have some sort of compromise: a core language
with a defined internal form, with extensions permitted that don't
have to map onto it. I have no idea how feasible this would be.

(From me)
> > But most designers of programming languages don't think about human
> > cognitive processes.
>
(From Richard)
> You should read C.J.Date's comments on SQL...

Perhaps you should post a reference and a summary???

Aaron