In article <·····@life.ai.mit.edu> ···@rice-chex.ai.mit.edu (Robert Krajewski) writes:
>This is exactly why nobody uses the ``original'' McCarthy Lisp syntax
>anymore. People threw it out 25 years ago...
What did the ``original'' McCarthy Lisp syntax look like?
--Ulf Dahlen
Linkoping University, Sweden and Edinburgh University, Scotland
Internet: ···@ida.liu.se
From: Robert Krajewski
Subject: Re: Virtues of Lisp syntax
Date:
Message-ID: <10722@life.ai.mit.edu>
In article <····@castle.ed.ac.uk> ······@castle.ed.ac.uk (Ulf Dahlen) writes:
>What did the ``original'' McCarthy Lisp syntax look like?
Umm, actually, I can't recall exactly...
But I think it was something like:
The list (a b c) ==> (a, b, c)
(cons x y) ==> cons[x;y]
Robert P. Krajewski
Internet: ···@ai.mit.edu ; Lotus: ······················@crd.dnet.lotus.com
From: Jeff Dalton
Subject: Re: Virtues of Lisp syntax (a tangent on macros and Scheme)
Date:
Message-ID: <3453@skye.ed.ac.uk>
In article <······················@cbnewsc.att.com> ···@cbnewsc.att.com (lawrence.g.mayka) writes:
>In article <················@ai.mit.edu>, ···@ai.mit.edu (Thomas M. Breuel) writes:
>> * In a language like Scheme (as opposed to CommonLisp)
>> that provides efficient implementations of higher order
>> constructs with natural syntax, there is little need or
>> excuse for something as horrible as LOOP in the first
>> place.
I think this ritual Common Lisp bashing is becoming a bit of a bore,
don't you?
The truth is that I can easily write a named-let macro in Common Lisp
and write a large class of loops in exactly the way I would write them
in Scheme. The efficiency isn't bad either, because most CL compilers
can optimize self-tail-recursion for local functions. (Yes, I know
Scheme does better than that.)
Moreover, if I want something like the Abelson & Sussman COLLECT macro
for streams I can write it in portable Common Lisp. I would argue
that code using such macros is significantly easier to understand that
the same thing done with nested recursive loops or nested calles to
MAP-STREAM and FLATMAP.
Until Scheme has a standard way of writing macros, I can't write
such things in portable Scheme. So I am very much in favor of
having such a standard mechanism for Scheme.
Of course, if you prefer higher-order functions instead of macros,
there is already a large set of them available in Common Lisp (MAPCAR,
SOME, REDUCE, etc.) and it is easy to write more.
So (1) Scheme's advantages over Common Lisp is this area, while real
and significant, are not as great as one might suppose, and (2) there
are iteration macros that are worth having regardless of one's views
on LOOP.
>We can talk about Dick Waters' SERIES package instead, if you prefer.
Yes, let's. I don't expect Scheme folk to flock to this beastie,
but it does show one of the benefits of having macros, namely that
it enables such work to be done.
Moreover, one of the arguments for Scheme, I would think, is that
anyone doing such work in Scheme would be encouraged by the nature of
the language to look for simple, general, "deep" mechanisms rather
than the relatively broad, "shallow" mechanisms that would fit better
in a big language such as Common Lisp. (This is not to imply that the
Series package is shallow or in any way bad (or even that shallow in
this sense is bad). Anyway, I'm speaking in general here and no
longer taking Series as my example.)
-- Jeff
In article <·····················@hellgate.utah.edu> ··················@cs.utah.edu (Tim Moore) writes:
>It's not the macros that the application programmers write themselves
>that cause problems; at least the programmer knows what the expansions
>of those macros look like. Rather, it's the macros that are a part of
>the language that cause trouble. Consider how often Common Lisp
>programmers use cond, setf, dotimes, dolist, do, and do*. The
>expansions of these macros can be pretty hairy. Maintaining the
>correspondence between the internal representation of a function and
>the form that produced it is not trivial.
Here is a case in point, that actually happened to a student in my AI
Programming class. He was getting an error message about bad
variables in a let, and could not figure out what was going wrong,
since the code being executed did not have a let in it! It turns out
that in our lisp, prog is implemented as a macro that expands into a
form that involves a let. He did have a prog, and the syntax of that
prog was bad - not bad enough to prevent the macro expansion but bad
enough to cause the let it expanded into to give an error. If the
error message were in terms of a prog he would have seen his error
quite quickly. In fact he did not, and wasted time on it.
On the other hand, using the interactive debugger (and my vast
experience :-) I was able to figure it out pretty quickly. But this
does point out that any time the code as seen in the debugger / error
messages / etc. differs from the code as written by the programmer,
there is a price to pay.
--
Lou Steinberg
uucp: {pretty much any major site}!rutgers!aramis.rutgers.edu!lou
internet: ···@cs.rutgers.edu
From: Rob MacLachlan
Subject: Re: Virtues of Lisp syntax (a tangent on macros and Scheme)
Date:
Message-ID: <10606@pt.cs.cmu.edu>
You just weren't using the right compiler. foo.lisp is:
(defun test ()
(prog ((:end 42))
(print :end)))
________________________________
* (compile-file "test:foo.lisp")
Python version 0.0, VM version DECstation 3100/Mach 0.0 on 29 SEP 90 01:13:48 pm.
Compiling: /afs/cs.cmu.edu/project/clisp/new-compiler/tests/foo.lisp 29 SEP 90 01:13:19 pm
In: DEFUN TEST
(PROG ((:END 42))
(PRINT :END))
--> BLOCK
==>
(LET ((:END 42)) (TAGBODY (PRINT :END)))
Error: Name of lambda-variable is a constant: :END.
________________________________
Rob (···@cs.cmu.edu)