From: Paul Frederick Snively
Subject: Re: Virtues of Lisp syntax
Date:
Message-ID: <33695@cup.portal.com>
I believe Jay is referring to MLisp.
MLisp is indeed an Algol-like syntax for Lisp. The version that I have is
written in PLisp (Pattern-matching Lisp), which in turn is written in Common
Lisp.
Paul Snively
Macintosh Developer Technical Support
Apple Computer, Inc.
Hanging out at ·····@cup.portal.com
Jay is referring to RLisp. MLisp is yet another effort along the same lines.
RLisp used to be distributed with the REDUCE computer algebra package.
(Maybe it still is; I haven't used Reduce lately.) Portable Common Lisp was
originally developed to support portability of Reduce. RLisp was covered
in a chapter in the book by Organick, Forsythe, and Plummer, _Programming
Language Structures_, Academic Press (1978).
Personally I didn't find RLisp attractive. A few control statements such as
IF..THEN were in Algol syntax, but the guts of the work still had to be done
with Lisp 1.5-like functions, e.g. cons(car(a), b), so you felt like you
were switching between two different languages within the same expression!
Scheme, now, _feels_ like Algol-60 (the world's sweetest version of Fortran),
and I'd say that feel is more important than look.
-- Bert
RLISP was an Algol-like Syntax that was a translator into Portable
Standard Lisp. To those of us who implemented and subsequently used
it, there were many mixed views. Some people felt that they liked it
because they didn't like the ``ugly'' Lisp syntax. They still had
access to all of the Lisp operations, but didn't have to put up with
the parens (remember that when we were RLISP, we didn't have fancy
text editors that did paren bouncing, auto-indentation, etc -- try
writing Lisp code without the editor features, it really is much more
difficult). The others among us, felt that RLISP just got in the way,
so we used PSL. RLISP has currently diverged some what. PSL is still
be distributed (by us and others) and supports a flavor of RLISP.
That version is still in use by the Alpha_1 group here at Utah which
has a solid modelling package, which has a mode where the users can
define models in RLISP. The REDUCE algebra system (which is also
still being distributed) has a slightly different version for
supporting computer algebra (in that case, RLISP works well -- the
most common users of REDUCE are non-computer scientists who find
things like infix operators a requirement). Finally, there is
something called RLISP-88 from Rand, which has extended RLISP with
concurrency operations, an object system, and other neat features.
B.
In article <······················@hellgate.utah.edu> ·····················@cs.utah.edu (Robert R. Kessler) writes:
=>RLISP was an Algol-like Syntax that was a translator into Portable
=>Standard Lisp. To those of us who implemented and subsequently used
=>it, there were many mixed views. Some people felt that they liked it
=>because they didn't like the ``ugly'' Lisp syntax. They still had
=>access to all of the Lisp operations, but didn't have to put up with
=>the parens (remember that when we were RLISP, we didn't have fancy
=>text editors that did paren bouncing, auto-indentation, etc -- try
=>writing Lisp code without the editor features, it really is much more
=>difficult). The others among us, felt that RLISP just got in the way,
=>so we used PSL. RLISP has currently diverged some what. PSL is still
=>be distributed (by us and others) and supports a flavor of RLISP.
=>That version is still in use by the Alpha_1 group here at Utah which
=>has a solid modelling package, which has a mode where the users can
=>define models in RLISP. The REDUCE algebra system (which is also
=>still being distributed) has a slightly different version for
=>supporting computer algebra (in that case, RLISP works well -- the
=>most common users of REDUCE are non-computer scientists who find
=>things like infix operators a requirement).
In so far as extension languages are concerned, this is the most
important argument against unsugared Lisp syntax. Most people
learned mathematics with infix operators and most people are more
accustomed to communicating in a written form where keywords and
separators are the typical delimiters, obviating the need for
parenthesis or bracket matching. In fact, most users are not
persuaded by arguments that Lisp syntax is "elegant" or "easy
to learn." They are far more likely to believe that the programmer
was to lazy to build a simple parser and therefore decided, because
of the obvious intrinsic value of the product, that the user should
be willing to be the parser for an otherwise unfamiliar notation.
This attitude, at best, is not customer-oriented and, in any case,
is unproductive. Parsing technology is well developed. Extension
languages can fairly easily accommodate an ALGOL-like syntax while
still providing all the semantics of Lisp (or Scheme, for that
matter.)
=>Finally, there is
=>something called RLISP-88 from Rand, which has extended RLISP with
=>concurrency operations, an object system, and other neat features.
=>
=>B.
Ned Nowotny, MCC CAD Program, Box 200195, Austin, TX 78720 Ph: (512) 338-3715
ARPA: ···@mcc.com UUCP: ...!cs.utexas.edu!milano!cadillac!ned
-------------------------------------------------------------------------------
"We have ways to make you scream." - Intel advertisement in the June 1989 DDJ.
In article <·····@cadillac.CAD.MCC.COM> ·······@MCC.COM (Ned Nowotny) writes:
>In so far as extension languages are concerned, this is the most
>important argument against unsugared Lisp syntax. Most people
>learned mathematics with infix operators and most people are more
>accustomed to communicating in a written form where keywords and
>separators are the typical delimiters, obviating the need for
>parenthesis or bracket matching. In fact, most users are not
>persuaded by arguments that Lisp syntax is "elegant" or "easy
>to learn." They are far more likely to believe that the programmer
>was to lazy to build a simple parser and therefore decided, because
>of the obvious intrinsic value of the product, that the user should
>be willing to be the parser for an otherwise unfamiliar notation.
>This attitude, at best, is not customer-oriented and, in any case,
>is unproductive. Parsing technology is well developed. Extension
>languages can fairly easily accommodate an ALGOL-like syntax while
>still providing all the semantics of Lisp (or Scheme, for that
>matter.)
This makes a couple of assumptions that are unlikely to be true.
1) We're not doing +,-,*,/ arithmetic, we're programming. (BTW - "+"
isn't really a binary operator, neither is "*"; there are surprisingly
few true binary, or unary, operations.)
2) One consequence is that binary and unary operators are the exception;
in fact, operators with arbitrary arity are common, or at least would
be if "modern" languages were as upto date as lisp. That being
the case, infix notation doesn't work and prefix notation requires
delimiters, which brings us back to lisp-like syntaxes.
As to the development of parsing technology, the state-of the art
syntax for n-ary operators, user-defined or system defined, is:
op(<operands, possibly separated by commas>)
I don't see that that is a big improvement over lisp syntax.
-andy
--
UUCP: {arpa gateways, sun, decwrl, uunet, rutgers}!neon.stanford.edu!andy
ARPA: ····@neon.stanford.edu
BELLNET: (415) 723-3088
One thing that a lot of people seem to be ignoring is the way that all
modern lisps make it so easy to augment lisp's syntax to suit the job at
hand. When it comes to building complex mathematical expressions, prefix
notation is absolutely hopeless.
When you can add a simple operator-precedence parser and attach it to a
macro in a few minutes, there is no need to bother writing it out long-hand.
Surely the main reason lisp has survived so long is it's ability to take on
and mimic the special features of newer languages that evolve around it.
Simon
--
·······@uk.ac.ic.doc | ·······@cix.co.uk | ..!mcsun!ukc!slxsys!cix!sispero
------------------------------------------------------------------------------
The Poll Tax. | Saddam Hussein runs Lotus 123 on | DoC,IC,London SW7 2BZ
I'm Not. Are you?| Apple Macs.| I love the smell of Sarin in the morning
On 12 Sep 90 02:12:38 GMT, ····@Neon.Stanford.EDU (Andy Freeman) said:
andy> In article <·····@cadillac.CAD.MCC.COM> ·······@MCC.COM (Ned
andy> Nowotny) writes:
ned> In so far as extension languages are concerned, this is the most
ned> important argument against unsugared Lisp syntax. Most people
ned> learned mathematics with infix operators and most people are more
ned> accustomed to communicating in a written form where keywords and
ned> separators are the typical delimiters, obviating the need for
ned> parenthesis or bracket matching.
I would also like to observe that while providing users with a familiar,
mathematical like syntax, may help sales, is is actually extremely
misleading, because even if they look like mathemtical expressions, the
semantics of expressions in programs are only weakly related to those of
the mathamtical expressions they look similar to, especially for
floating point, or unsigned in C (which actually uses modular arithmetic).
andy> This makes a couple of assumptions that are unlikely to be true.
andy> 1) We're not doing +,-,*,/ arithmetic, we're programming. (BTW - "+"
andy> isn't really a binary operator, neither is "*"; there are
andy> surprisingly few true binary, or unary, operations.)
Precisely. Agreed. Even the semantics are different.
andy> 2) One consequence is that binary and unary operators are the exception;
andy> in fact, operators with arbitrary arity are common, or at least would
andy> be if "modern" languages were as upto date as lisp. That being
andy> the case, infix notation doesn't work and prefix notation requires
andy> delimiters, which brings us back to lisp-like syntaxes.
The real challenge here is that we want some syntax that says, apply
this operator symbol to these arguments and return these value_s_. Even
lisp syntax does not really allow us to easily produce multiple values.
So either we say that after all all functions take just one argument and
return one result (and they may be both structured), which may be an
appealing solution, or we are stuck; mainly because our underlying
mathematical habits do not cope well with program technology (and I am
not happy with those that would like, like the functionalists, to reduce
programming to what is compatible with *their* notion of maths).
andy> As to the development of parsing technology, the state-of the art
andy> syntax for n-ary operators, user-defined or system defined, is:
andy> op(<operands, possibly separated by commas>)
andy> I don't see that that is a big improvement over lisp syntax.
Actually, there is state of the art technology for multiple arguments to
multiple results, and it is *Forth* of all things, or maybe POP-2. A lot
of power of Forth and Pop-2 indeed comes from their functions being able
to map the top N arguments on the stack to a new top of M results. Maybe
postfix is not that bad after all. Something like
10 3 / ( 10 and 3 replaced with 1 and 3 ) quot pop rem pop
or with some sugaring like Pop-11.
Another alternative is that used in languages like CDL or ALEPH, based
on affix/2level grammar style, to junk function notation entirely, and
just use imperative prefix syntax. Something like
divide + 10 + 3 - quot - rem.
I have seen substantial programs written like this, and this notation
actually is not as verbose as it looks, and is remarkably clear. For
example, Smalltalk syntax is essentially equivalent to this, as in:
10 dividedBy: 3 quotient: quot remainder: rem!
There are many interesting alternatives...
--
Piercarlo "Peter" Grandi | ARPA: ·················@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: ···@cs.aber.ac.uk
In article <·················@odin.cs.aber.ac.uk>, ···@cs.aber.ac.uk (Piercarlo Grandi) writes:
> On 12 Sep 90 02:12:38 GMT, ····@Neon.Stanford.EDU (Andy Freeman) said:
> andy> 1) We're not doing +,-,*,/ arithmetic, we're programming. (BTW - "+"
> andy> isn't really a binary operator, neither is "*"; there are
> andy> surprisingly few true binary, or unary, operations.)
> Precisely. Agreed. Even the semantics are different.
I missed this the first time it came around.
I have some bad news for the two of you: in floating-point arithmetic
"+" _is_ a binary operation. Floating-point "+" and "*" are not
associative. If one Lisp compiler turns (+ X Y Z) into
(plus (plus X Y) Z) and another turns it into (plus X (plus Y Z))
then they are going to produce _different_ results. For integer
and rational arithmetic, there's no problem, but anyone doing floating
point calculations in Lisp has to be very wary of non-binary + and * .
--
Heuer's Law: Any feature is a bug unless it can be turned off.
On 12 Sep 90 02:12:38 GMT, ····@Neon.Stanford.EDU (Andy Freeman) said:
andy> 1) We're not doing +,-,*,/ arithmetic, we're programming. (BTW - "+"
andy> isn't really a binary operator, neither is "*"; there are
andy> surprisingly few true binary, or unary, operations.)
In article <·················@odin.cs.aber.ac.uk>, ···@cs.aber.ac.uk
(Piercarlo Grandi) writes:
pcg> Precisely. Agreed. Even the semantics are different.
On 14 Sep 90 07:45:24 GMT, ··@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
said:
ok> I missed this the first time it came around. I have some bad news
ok> for the two of you: in floating-point arithmetic "+" _is_ a binary
ok> operation. Floating-point "+" and "*" are not associative.
The semantics *are* different. Didn't I write that?
ok> If one Lisp compiler turns (+ X Y Z) into (plus (plus X Y) Z) and
ok> another turns it into (plus X (plus Y Z)) then they are going to
ok> produce _different_ results.
As long as people *know* that the semantics are different, and this is
the big problem, they can choose whether to code the things in either of
the three ways.
ok> For integer and rational arithmetic, there's no problem,
Well, this is a case in point for my argument about the pitfalls; there
is still a problem. Nobody constrains you to have only positive numbers
as the operands to n-ary fixed point +, so that
(+ -10 +32767 +10)
is not well defined on a 16 bit machine, unless you do modular
arithmetic throughout.
As we already know but sometimes forget, arithmetic on computers follows
*very* different rules from arithmetic in vanilla mathematics, and using
a notation that resembles the latter can be utterly misleading, even for
very competent people, without pausing for hard thought.
(+ a b c d e)
simply means apply repeated *computer* addition on *computer* fixed or
floating point throughout. It is the *programmer's* responsibility to
make sure this makes sense -- the unfamiliar syntax may make him pause,
at least -- and somehow maps into vanilla mathematics not too
inaccurately.
ok> but anyone doing floating point calculations in Lisp has to be very
ok> wary of non-binary + and * .
Anyone doing floating point arithmetic on *any* machine, IEEE standard
or Cray, has to be very very wary of assuming it is the same as
arithmetic on reals, and yet a lot of people do (and then complain that
two computers with different floating representations print utterly
different results to their programs!).
The real problem is that *lots* of people still believe that floating
point numbers are reals, and fixed point ones have infinite precision!
They miss out completely on the non associativity or modularity, and all
the other funny, funny properties of floating and fixed point.
My contention is not with lisp n-ary operators (that are damn useful and
safe on other domains), it is that even the simplest existing operators
on floats and fixeds have entirely non-obvious semantics, and that this
is carefully disguised by conventional, mathematics looking syntax. Ah
sales!
--
Piercarlo "Peter" Grandi | ARPA: ·················@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: ···@cs.aber.ac.uk
In article <·······@xds13.ferranti.com>, ·····@ficc.ferranti.com (Peter
da Silva) writes:
> In article <·················@odin.cs.aber.ac.uk>, ···@cs.aber.ac.uk
(Piercarlo Grandi) writes:
> > The real challenge here is that we want some syntax that says, apply
> > this operator symbol to these arguments and return these value_s_. Even
> > lisp syntax does not really allow us to easily produce multiple values.
>
> I may be being more than usually dense, here, but what's wrong with returning
> a list? What could be more natural?
> --
> Peter da Silva. `-_-'
> +1 713 274 5180. 'U`
> ·····@ferranti.com
My understanding was that the major reason is efficiency: multiple
values are returned on the stack, instead of consing a new list. The
rest is a syntactic sugar ( important in that if you are interested only
in the first value there is no additional syntax).
From: Jeff Dalton
Subject: Re: Virtues of Lisp syntax
Date:
Message-ID: <3425@skye.ed.ac.uk>
In article <·····@cadillac.CAD.MCC.COM> ·······@MCC.COM (Ned Nowotny) writes:
>In so far as extension languages are concerned, this is the most
>important argument against unsugared Lisp syntax. Most people
>learned mathematics with infix operators and most people are more
>accustomed to communicating in a written form where keywords and
>separators are the typical delimiters, obviating the need for
>parenthesis or bracket matching.
Um, when's the last time *you* wrote expressions in an infix
language. Parentheses and bracket-matching are definitely
involved. That is, the difference is, to some extent, a
mater of degree.
Of course, you're right that there are more user-friendly syntaxs that
than provided by Lisp, at least if the users are not already familiar
with Lisp. However, (1) the implementation of a Lisp-based extension
language tends to be simpler and smaller, (2) the result is a proper
programming langauge rather than something more restricted, (3) Lisp
is at least as "friendly" as some of the alternatives such as Post-
Script, (4) experience with a number of implementations of Emacs (eg,
Multics Emacs, GNU Emacs) -- and of other things -- has shown that
users, even "non-programmers", can use Lisp effectively as an
extension language and even find such use pleasant.
> In fact, most users are not
>persuaded by arguments that Lisp syntax is "elegant" or "easy
>to learn." They are far more likely to believe that the programmer
>was to lazy to build a simple parser and therefore decided, because
>of the obvious intrinsic value of the product, that the user should
>be willing to be the parser for an otherwise unfamiliar notation.
I also think you overestimate the extent to which users will be
comfortable with mathematics and the rigidities imposed by programming
languages in general. That is, many users will feel they are parsing
an unfamiliar notation regardless.
>This attitude, at best, is not customer-oriented and, in any case,
>is unproductive. Parsing technology is well developed. Extension
>languages can fairly easily accommodate an ALGOL-like syntax while
>still providing all the semantics of Lisp (or Scheme, for that
>matter.)
True.
-- JD