Re: macros
Series Expansion
> On May 22, 2:39 pm, Series Expansion <sere...@gmail.com> wrote:
> > On May 19, 5:22 am, Adlai <munchk...@gmail.com> wrote:
> > > [elaborate discussion of Lisp equivalent of "new" operator]
>
> > Irrelevant.
>
> No, it's got all the relevance in the world.
It does not.
> The way symbols work in Lisp makes it possible to generate
> never-seen-before symbols.
At run-time. This does not help you much with your problems with
macros, which occur at compile time. The macro must replace
some code
macro invocation (arguments)
other code
with
some code
macro result
other code
subsequent to which the latter is compiled by the compiler. If the
macro result contains a local variable, that code must contain
something of the form "(let (name" etc. etc. (or some other form that
binds a name) and if that same name happens to occur in the "some
code" portion a collision has occurred. What is more, the names that
occur in the "some code" portion cannot in general be computed from
only the macro invocation's arguments. More generally, the list of
names to avoid cannot in general be computed from only the macro
invocation's arguments.
The "(let (name" or similar is the problem, and it cannot in general
be avoided without resort to either global variables or multiple
evaluation. Even if the macro outputs code that, at run-time later,
will create a novel symbol (using the symbol table that exists in
memory at run time to find an unused one), that same code, at compile
time, must refer to this somehow. It must create a local variable that
refers to that symbol, and that can be used elsewhere in the macro's
output to refer to it again at need, and that local variable must have
a name, and that name will then be the potential cause of a collision.
Adding one layer of indirection does not solve the problem, though it
may well impair efficiency.
> Also, a symbol's printed representation is not it's entire representation
Not relevant. The printed representation is all that is available to
the compiler at compile-time. You are apparently suggesting that it is
possible for a macro to take code like
(let (foo ... ))
(macro (argument))
and expand it to
(let (foo ... ))
((let (foo ... ))
...)
with the property that somehow the compiler will know to treat the two
foos as separate, and without variable hiding. But how can it?
More significantly, what you are saying would require as a consequence
that hand-replacing a macro invocation with its expansion could result
in different behavior at run-time than having the expansion done by
the preprocessor pass of the compiler. This would be a violation of
the broadest reasonable definition of a macro.
The nutshell is this: while your "gensym" might well be globally
unique, the code output by the macro, and later compiled by the
compiler, must reference it somehow. That reference must involve a
name, if it is to be referenced more than once. And that name cannot
be guaranteed to be unique, even if its referent can.
> GENSYM is not the equivalent of the new operator. It doesn't need to
> look at the code where a macro is being called from to do its job. All
> GENSYM needs to do is examine the Lisp image and grab an unused
> reference.
See above. This must occur at run-time. I am concerned with what
occurs at compile time.
> This is not a 100% analogy, but it's like generating a
> pointer to an empty reference, that can then be filled in.
This indirection is possible in Java and C as well.
In Java, it is as if you had
WeakReference<T> foo = new WeakReference<T>(someTInstance);
Although the T instance now has no name, and the WeakReference created
at runtime is guaranteed not to collide with any local or global
variables, the name "foo" of the reference TO that reference may
collide with or hide other variables with the name "foo" in that and
enclosing scopes. (Ignore for now the effect of WeakReference on
garbage collection.)
In C, it is as if you had
void *foo = malloc(sizeof(void *));
*foo = &my_obj;
Now, *(*foo) is my_obj and the direct pointer to my_obj is stored in
formerly unallocated space; that is a reference to my_obj that cannot
collide with any other reference in the system, barring bugs in
pointer arithmetic making malloc() stop working correctly (an
unfortunate problem sometimes in C, but a preventable one, by
debugging the pointer use that causes the corruption.)
However, the reference TO that reference again has a name, "foo",
which may collide with other names in the same scope.
Most significantly, C has macros, and one could have a C macro
generate code like the above, malloc'ing a pointer to refer to a
temporary. However, the pointer to this reference must itself be
referenced so that it can be DEreferenced and that temporary used. And
that pointer must have a name for the compiler to be able to do its
job. And a list of all potentially-colliding names in the scope could
not in general be computed as any function of the macro's arguments,
even were C macros to be like Lisp ones, able to replace themselves
with arbitrary computable functions of their arguments.
You have asserted that the Lisp macro's ability to become any function
of its arguments grants it extraordinary powers. I have demonstrated
that one particular and important power you have attributed to them
cannot possibly occur as a result of that trait, however.
java...@gmail.com
Series Expansion
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, java.oke.
java...@gmail.com
OK, Sorry for the Worry.
Now it's your turn (I'd suggest: "Sorry for Cross-Posting to c.l.l."
-- and I'm sure you meant the Clojure list --- and the "common" is
invisible in "comp.lang. .lisp").
Series Expansion
Incoherent.
java...@gmail.com
Series Expansion
Incoherent.
java...@gmail.com
> Incoherent.
Last One Wins!
Your answer:
Series Expansion
Incoherent.
java...@gmail.com
> > Your answer:
>
> Incoherent.
Kindergarten really has been a great time!!
Thanks for reminding me :)
Series Expansion
> On 29 Mag, 04:59, Series Expansion <sere...@gmail.com> wrote:
>
> > > Your answer:
>
> > Incoherent.
>
> Kindergarten really has been a great time!!
Well, now your incoherence is satisfactorily explained: you are
apparently far too young to have mastered coherence yet.
java...@gmail.com
> > Kindergarten really has been a great time!!
>
> Well, now your incoherence is satisfactorily explained: you are
> apparently far too young to have mastered coherence yet.
(To the public, other than "Too Serious of an Expansion":)
You see, if somebody is so full of himself to ignore the possibility
of self-criticism, it's simply too easy to trap them in any kind of
self-revelatory naive trap.
Anyway, thanks go to "Serious Expansion" for allowing me to
demonstrate you this kind of lesson.
-JO
Series Expansion
> On 30 Mag, 05:59, Series Expansion <sere...@gmail.com> wrote:
>
> > > Kindergarten really has been a great time!!
>
> > Well, now your incoherence is satisfactorily explained: you are
> > apparently far too young to have mastered coherence yet.
>
> off-topic post deleted unread]
Paul Donnelly
Since you're impenetrable to rational arguments, I don't see why anyone
would continue to waste time constructing them. Really, they should just
put you in their killfile, like I'm about to do.
daniel....@excite.com
-see above-
Series Expansion, I think you raise a lot of great issues that I am
learning a lot from!
The thing about GYNSYM, and I confess I am not the one to answer, is
that somehow both the lifetime of the symbol in the symbol table
(internment) and the ability to reference it are _wierd_.
And, I didn't realize it until your post pointed out the issues
surrounding representation! Thanks!
Here's wierd: this works as expected:
----
>(eval (let ((c (gensym))) `(progn (setq ,c 'test)(print ,c)(terpri))))
TEST
NIL
----
But this does not work as I expected:
----
>(progn (setq #:G1801 'test)(print #:G1801)(terpri))
Error in PROGN [or a callee]: The variable #:G1801 is unbound.
----
I know you can't read and intern a symbol like #:<name>, but somehow
it is done in the context of back-quote processing...
Anybody?
daniel....@excite.com
-see above-
Now that I think about it, the output of a macro is not text, it is a
parse tree, which then goes straight to the compiler. Same as in my
example, the `() form is never represented as text, it goes to the
EVAL as a parse tree.
For code that comes from the user, it goes through the reader to
become a parse tree, [then macro substitutions], then to the compiler.
So the macro can put in references to symbols, the names of which do
not have valid represetations in user code. I think that partitions
user symbols apart from GENSYM symbols, so that's why GENSYM symbols
used in macros cannot collide with user written code.
Basically...
Brian - qbg
read again the reader returns a different symbol. Macros work on the
list structure of the code so they can easily put the same symbol in
multiple locations, which does as one expects. Because GENSYM creates
and returns a fresh, uninterned symbol, the symbol will be different
than all of the existing symbols, and will never[1] be returned from
READ as long as it is not interned.
I'll note that you can fix your code from a previous post:
(progn (setq #1=#:G1801 'test) (print #1#) (terpri))
By using the syntax for circular structures, you can the same #:G1801
symbol appear in both locations, and it works as expected (this is
essentially what macros do).
[1]: Well, if you have a reference to the symbol you could return it
using read time evaluation, but this is a non-issue as read time
precedes macroexpansion time, so the symbol generated by the macro
doesn't exist when the macro call is read in...
Thomas A. Russ
> The thing about GYNSYM, and I confess I am not the one to answer, is
> that somehow both the lifetime of the symbol in the symbol table
> (internment) and the ability to reference it are _wierd_.
Well, the part that takes a bit of experience to understand is the
interaction between the reader and structures, since that is what your
issue here turns on.
> And, I didn't realize it until your post pointed out the issues
> surrounding representation! Thanks!
>
> Here's wierd: this works as expected:
> ----
> >(eval (let ((c (gensym))) `(progn (setq ,c 'test)(print ,c)(terpri))))
Right. That is because the LET establishes a binding of the symbol C to
the gensym. Backquote operates on objects, not surface text, so what
this is doing is inserting the actual symbol object referred to by C
into the resulting list structure. And that guarantees that the objects
introduced into backquote by ,c are the same.
> TEST
> NIL
> ----
> But this does not work as I expected:
> ----
> >(progn (setq #:G1801 'test)(print #:G1801)(terpri))
>
> Error in PROGN [or a callee]: The variable #:G1801 is unbound.
> ----
>
> I know you can't read and intern a symbol like #:<name>, but somehow
> it is done in the context of back-quote processing...
The reader handles the job of reading and interneing symbols. But the
#:<name> syntax specifically directs the reader NOT to intern the
resulting name. So each time, for example #:G1801 is encountered, you
get a new, distinct symbol. This is easily seen by comparing the
following:
(let (c #:G1801)
(eq c c))
==> T because you have the same reference.
(eq #:G1801 #:G1801)
==> NIL because two different, uninterned symbols with the symbol-name
"G1801" are created.
You can see the same effect using other operators that create new
objects as well. If you remember that gensym is really just an object
constructor, it becomes clear that you get separate objects.
(let (c (list 1 2 3))
(eq c c)) ==> T
(eq (list 1 2 3) (list 1 2 3)) ==> NIL
(defclass foo ()
(name :initarg :name))
(eq (make-instance 'foo :name "BAR") (make-instance 'foo :name "BAR"))
==> NIL
--
Thomas A. Russ, USC/Information Sciences Institute
Series Expansion
wrote:
> Series Expansion <sere...@gmail.com> writes:
> > On May 31, 9:07 am, java....@gmail.com wrote:
> >> On 30 Mag, 05:59, Series Expansion <sere...@gmail.com> wrote:
>
> >> > > Kindergarten really has been a great time!!
>
> >> > Well, now your incoherence is satisfactorily explained: you are
> >> > apparently far too young to have mastered coherence yet.
>
> >> You see, if somebody is so full of himself [rest of obviously
> >> off-topic post deleted unread]
>
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, java.oke.
>
> off-topic post deleted unread]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Paul.
Series Expansion
It can only work, though, if the parse "tree" is a directed acyclic
graph with an undirected cycle (e.g. (let (foo (gensym)) (x foo))
becomes a node with edges eventually to the (foo (gensym)) and the (x
foo) nodes, both of which have nodes to the SAME foo node, rather than
distinct-but-equal-as-strings nodes).
To get the effects the Lispers have claimed seems to require seriously
contorting the definitions of all of:
* macro (not operating on text?!)
* parse tree (contains undirected cycles?!)
* source code (not flat ASCII?!)
and possibly more.
Series Expansion
> I'll note that you can fix your code from a previous post:
> (progn (setq #1=#:G1801 'test) (print #1#) (terpri))
I'll note here that one should not ordinarily need a "syntax for
circular structures" to describe a parse *tree* (emphasis on the
"tree").
Kaz Kylheku
But the above structure above isn't circular. We use the syntax for circular
structures because this tool also also handles the simpler case of substructure
sharing, which is what is going on above. In this case we don't need
that notation to be powerful enough to handle cycles. Cycles are
expressed by the occurence of a label reference like #1# inside
the object which is introduced under that label, e.g.:
;; ``bottomless'' (1 1 1 1 1 ...) cyclic list:
#1=(1 . #1#)
No such backreference occurs above. The expresion simply introduces one object
with #1 and then refer to it later.
Syntax trees may actually be dags with shared substructure.
For instance, see the Red Dragon Book:
_Compilers: Principles, Techniques and Tools_, Aho, Sethi, Ullman.
1988, Section 5.2, ``Construction of Syntax Trees''.
I value this book as a credible authority on the subject of compilers.
The chapter of the text shows how the same syntax-directed definition can
drive the construction of either a tree or dag:
``A dag is obtained if the function constructing a node
first checks to see whether an identical node already
exists. [ ... ] When the call mkleaf(id, a) is repeated on
line 2, the node constructed by the previous call
to mlkeaf(id, a) is returned.''
What is described here is practically identical to interning in the Lisp
reader.
Thomas A. Russ
Well, so Lisp operates on parse GRAPHs and not parse TREEs. Seems like
that gives it more generality. Score one for lisp. The particular
example above is an example of a parse LATTICE, since it isn't
circular. It just has shared substructure.
Pascal J. Bourguignon
It's possible to evaluate or compile DAGs.
In some cases, it's even possible to evaluate or compile graphs with
cycle, but it's actually undefined what may happen in presence of
cycles.
--
__Pascal Bourguignon__
Series Expansion
> On 2009-06-01, Series Expansion <sere...@gmail.com> wrote:
> > I'll note here that one should not ordinarily need a "syntax for
> > circular structures" to describe a parse *tree* (emphasis on the
> > "tree").
>
> But the above structure above isn't circular.
It is, in that it contains undirected cycles. It doesn't contain
directed cycles. Regardless, it isn't a tree.
> Syntax trees may actually be dags with shared substructure.
Ordinarily that would be as an optimization, without affecting
semantics!
Series Expansion
> Series Expansion <sere...@gmail.com> writes:
> > On Jun 1, 1:04Ž pm, Brian - qbg <quickbasicg...@gmail.com> wrote:
> > > I'll note that you can fix your code from a previous post:
> > > (progn (setq #1=#:G1801 'test) (print #1#) (terpri))
> > > By using the syntax for circular structures...
>
> > I'll note here that one should not ordinarily need a "syntax for
> > circular structures" to describe a parse *tree* (emphasis on the
> > "tree").
>
> Well, so Lisp operates on parse GRAPHs and not parse TREEs.
If true, that is extremely odd.
Please stop silently redirecting followups.
fortunatus
> To get the effects the Lispers have claimed seems to require seriously
> contorting the definitions of all of:
> * macro (not operating on text?!)
> * parse tree (contains undirected cycles?!)
> * source code (not flat ASCII?!)
> and possibly more.
YES - the first one - that's the reason Lispers like the Lisp macro,
you got it exactly! Does _not_ operate on text, operates after lex
+parse phase! If you are simply trying to argue that a Lisp macro is
not what is usually called a macro - I agree with that! - then call
them L-macros.
So to get the similar benefit for C (or Pascal or whatever) type of
syntax, you'd add a new feature (maybe "C-macro" ??), not the same as
a macro pre-processor, but something that fits between the lexer
+parser and the code gen. And the C-macro usages that programmers
write would have to pass through the lexer+parser!
Try that with a new control flow structure C-macro, for instance. It
can be done, and I think some research groups are actually doing it.
But it's harder in non-Lisp like languages. In Lisp, the original
parsing system can already read "L-macro" usages.
Series Expansion
> On Jun 1, 6:06 pm, Series Expansion <sere...@gmail.com> wrote:
> > To get the effects the Lispers have claimed seems to require seriously
> > contorting the definitions of all of:
> > * macro (not operating on text?!)
> > * parse tree (contains undirected cycles?!)
> > * source code (not flat ASCII?!)
> > and possibly more.
>
> YES - the first one - that's the reason Lispers like the Lisp macro,
because it isn't one? How ridiculous. Redefining things and then
acting all shocked and flamey when people call you on it. Really now.
Alan Bawden
Lisp has been calling them "macros" since they were originally proposed in
1963. In 45 years, nobody has ever objected that Lisp wasn't entitled to
use the word. In fact, the Free On-line Dictionary of Computing's
definition of the word "macro" notes:
"Nowadays the term is most often used in connection with the C
preprocessor, Lisp, or one of several special-purpose languages built
around a macro-expansion facility (such as TeX or Unix's troff suite)."
Another example: the Wikipedia article on the computer science meaning of
the word macro includes a (not very good) section titled "Lisp macros".
Looks to me like Lisp has a pretty good claim on the word at this point.
So when you came in here, people warned you multiple times that: "Lisp
macros aren't like the macros you are used to." But you weren't interested
in learning anything new, you were here to pick a fight and prove what a
bunch of wankers we are. Now that you've lost that argument, here you are
again whining that nobody told you that these weren't the macros you were
used to! Pathetic.
Vassil Nikolov
On 25 Jun 2009 00:40:17 -0400, Alan Bawden <al...@shaggy.csail.mit.edu> said:
> Lisp has been calling them "macros" since they were originally proposed in
> 1963.
Which, by the way, is just four years after the time when the term
itself originated according to Merriam-Webster [*]. I notice that
the latter's definition is closer to Lisp macros than to cpp macros,
as it is only in for-evaluation positions that Lisp macros are
expanded by the language processor (whether compiler or
interpreter).
[*] <http://www.merriam-webster.com/dictionary/macro%5B2%5D>
---Vassil.
--
Vassil Nikolov <vnik...@pobox.com>
(1) M(Gauss);
(2) M(a) if M(b) and declared(b, M(a)),
where M(x) := "x is a mathematician".
fortunatus
> because it isn't one? How ridiculous. Redefining things and then
> acting all shocked and flamey when people call you on it. Really now.
It isn't a text preprocessing macro - yeah, you're right, the
definition is different.
Who cares that Lispers call it "macro"? As long as you can figure out
the meaning of the term in context you can join the discussion! (I
admit, though, that the difference does trip up newbies - me included,
took me a few months. It's something to learn about Lisp.)
By the way - If you could name it, Series Expansion, what would you
call it?
Series Expansion
> Series Expansion <sere...@gmail.com> writes:
> > On Jun 24, 1:51 pm, fortunatus <daniel.elia...@excite.com> wrote:
> > > YES - the first one - that's the reason Lispers like the Lisp macro,
>
> > because it isn't one? How ridiculous. Redefining things and then
> > acting all shocked and flamey when people call you on it. Really now.
>
> Lisp has been calling them "macros" since they were originally proposed in
>
> But you weren't interested in learning anything new
Not true.
> you were here to pick a fight and prove what a bunch of wankers we
> are.
Not true, but several of you *did* do a pretty nice job of proving
what a bunch of wankers they were.
> Now that you've lost that argument
I have not.
> here you are again whining
I am not.
> ... Pathetic.
I am not.
Series Expansion
> On Jun 24, 9:34 pm, Series Expansion <sere...@gmail.com> wrote:
>
> > because it isn't one? How ridiculous. Redefining things and then
> > acting all shocked and flamey when people call you on it. Really now.
>
> call it?
A "wackyfuckedupLispthing" perhaps.
ACL
I'm pretty sure lisp macros predate C macros.
Same would be true for the parse tree and source code.
(As lisp is older than c).
But anyway, maybe it would be less confusing if we called them
'compile time source-code manipulating functions'.
'Cotscmafu'.
'Macro' has had an too much of an association with excel spreadsheets
and cheating at MMOs to be really sexy anymore.
Food for thought. (maybe?)
Tim Bradshaw
> I'm pretty sure lisp macros predate C macros.
> Same would be true for the parse tree and source code.
> (As lisp is older than c).
Yes, they do, by many years.
> But anyway, maybe it would be less confusing if we called them
> 'compile time source-code manipulating functions'.
"macro" is a fine name.
Thomas F. Burdick
> On 2009-06-26 14:48:47 +0100, ACL <anonymous.c.lis...@gmail.com> said:
>
> > I'm pretty sure lisp macros predate C macros.
> > Same would be true for the parse tree and source code.
> > (As lisp is older than c).
>
> Yes, they do, by many years.
You sure about that? I thought that both C-ish macros and the Lisp
MACRO mechanism came about around 1970 or so. And in any case, the
term is clearly making reference to assembler macro-instructions,
which are much more like C macros than Lisp ones.
> > But anyway, maybe it would be less confusing if we called them
> > 'compile time source-code manipulating functions'.
>
> "macro" is a fine name.
Indeed. And when I have the need to contrast the two styles of macros,
the adjectives "textual" and "structural" work fine.
Tim Bradshaw
> You sure about that? I thought that both C-ish macros and the Lisp
> MACRO mechanism came about around 1970 or so.
The earliest reference I am aware of to Lisp macros is AIM-5, which
describes macros for Lisp 1.5 in 1963. The Lisp 1.5 manual does not
mention macros. So I'm guessing a date some time in 1963, or possibly a
little earlier.
Patricia Shanahan
The Software Preservation Group web page for Lisp history,
http://www.softwarepreservation.org/projects/LISP/ has a link to an
October 22, 1963 paper "MACRO Definition for LISP" by Timothy P. Hart,
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-057.pdf
I don't know enough about Lisp to evaluate whether what it describes is
the foundation of the current Lisp feature. Perhaps someone with the
necessary knowledge could take a look at it?
Patricia
Series Expansion
> On Jun 24, 9:34 pm, Series Expansion <sere...@gmail.com> wrote:
> > On Jun 24, 1:51 pm, fortunatus <daniel.elia...@excite.com> wrote:
> > > On Jun 1, 6:06 pm, Series Expansion <sere...@gmail.com> wrote:
> > > > To get the effects the Lispers have claimed seems to require seriously
> > > > contorting the definitions of all of:
> > > > * macro (not operating on text?!)
> > > > * parse tree (contains undirected cycles?!)
> > > > * source code (not flat ASCII?!)
> > > > and possibly more.
>
> > > YES - the first one - that's the reason Lispers like the Lisp macro,
>
> > because it isn't one? How ridiculous. Redefining things and then
> > acting all shocked and flamey when people call you on it. Really now.
>
> deleted]
>
> But anyway, maybe it would be less confusing if we called them
> 'compile time source-code manipulating functions'.
>
> 'Cotscmafu'.
>
> 'Macro' has had an too much of an association with excel spreadsheets
> and cheating at MMOs to be really sexy anymore.
Cotscmafu it is. I particularly like how it ends with "fu".
Series Expansion
> On 2009-06-26 14:48:47 +0100, ACL <anonymous.c.lis...@gmail.com> said:
>
> [irrelevancies deleted]
>
> > But anyway, maybe it would be less confusing if we called them
> > 'compile time source-code manipulating functions'.
>
> "macro" is a fine name.
Not if that's not actually what it is.
Series Expansion
Structural, schmuctural. It's apparently a macro in much the way a
3.5" floppy disk is floppy.
Kaz Kylheku
It positively, definitely describes the foundations of macros.
At the outset, an example is given for replacing an existing fexpr called
csetq by a macro.
Also, the macro STASH is defined which does almost exactly what PUSH does
today, with the same argument order:
(stash form x) ;; push value of FORM onto variable X.
expands to
(setq x (cons form x))
The modern PUSH can push onto any storage location, not only a named
variable.
The SETQ expansion is achieved by means of
MACRO ((STASH (LAMBDA (FORM)
(LIST (QUOTE SETQ)
(CADAR FORM)
(LIST (CONS (CADR FORM)
(CADAR FORM)))))))
(Indentation mine).
This is in an old-style ``eval quote'' notation in which the outer parentheses
were omitted from the toplevel form. But basically the macro would work
today, with only a minor code update.
Modern Lisp macros no longer just receive the entire macro call form as their
one and only argument, but the underlying plumbing still works that way, and
access to the whole form is still available using the &WHOLE keyword in the
macro lambda list. We don't have to use a lambda expression to define the
function, either.
So reusing the macro code in Common Lisp looks like this:
(DEFMACRO STASH (&WHOLE FORM VALUE PLACE)
(LIST (QUOTE SETQ)
(CADAR FORM)
(LIST (CONS (CADR FORM)
(CADAR FORM)))))
But now I see two bugs here. Firstly, it expects the form to have a weird shape!
Namely this:
((STASH PLACE) VALUE)
^CADAR ^CADR
Rather than
(STASH VALUE PLACE)
^CADR ^CADDR
I.e. unless this was really the representation, the paper possibly has a typo:
CADAR instead of CADDR.
Secondly, the macro is generating code, which means that certain symbols must
be quoted. But note that the CONS function is just called! That's wrong; we
need to /generate/ the code (CONS ...) not to invoke CONS at macro-expansion
time. I.e. we want
(LIST (QUOTE CONS) ...)
not:
(LIST (CONS ...))
Exactly the way the SETQ operator is quoted with (QUOTE SETQ),
the CONS operator must be quoted too.
Clearly, the paper's author didn't cut and paste his own code from
the text editor into the Lisp window of his graphics worksation
to try it out. :) :) :)
Bugfixed version:
(DEFMACRO STASH (&WHOLE FORM VALUE PLACE)
(LIST (QUOTE SETQ)
(CADDR FORM)
(LIST (QUOTE CONS)
(CADR FORM)
(CADDR FORM)))))
And now, actual test run in a Lisp session:
[1]>
(DEFMACRO STASH (&WHOLE FORM VALUE PLACE)
(LIST (QUOTE SETQ)
(CADDR FORM)
(LIST (QUOTE CONS)
(CADR FORM)
(CADDR FORM)))))
STASH
[2]> (macroexpand '(stash value place))
(SETQ PLACE (CONS VALUE PLACE)) ;
T
Our macro also has error checking. Though we don't use the VALUE and PLACE
arguments, the DEFMACRO still knows that the macro must take exactly two:
[3]> (macroexpand '(stash value place 42))
*** - The macro STASH may not be called with 3 arguments:
(STASH VALUE PLACE 42)
This error checking is absent from the 1963 version, and would have required
extra code. The 1963 STASH would simply have pulled the value and place forms
out, and ignored the superfluous 42.
The ``modern'' version (actually 1970's or 1980's modern) of the macro would
use the automatic form destructuring features of DEFMACRO, whereby the macro
lambda list (argument list to the DEFMACRO) constitutes a tree pattern
with variables, which is unified (one way) against the shape of the macro call.
Furthermore, we would use the backquote syntax to express the code generation
rather than a mess of list, quote and hard to understand ``cadavers'' like
CADAR:
(defmacro stash (value variable)
`(setq ,variable (cons ,value ,variable)))
That's it! The backquote may generate code similar to the 1963 stuff.
(Exactly how backquote works is implementation-specific). On the Lisp
implementation I'm using, the backtick is transliterated to a macro syntax,
which is then expanded, and so you can do the same thing:
[6]> (macroexpand '`(setq ,variable (cons ,value ,variable)))
(LIST 'SETQ VARIABLE (LIST 'CONS VALUE VARIABLE)) ;
T
Of course 'SETQ is a shorthand for (QUOTE SETQ), which is another
convenience not found in the original code. If we expand this notation,
we get:
(LIST (QUOTE SETQ) VARIABLE (LIST (QUOTE CONS) VALUE VARIABLE)) ;
Now, replace VALUE and VARIABLE with the expressions that compute their values,
namely (CADDR FORM) and (CADR FORM), and you get the 1963-ish code. :)
Pascal J. Bourguignon
> On 2009-06-26, Patricia Shanahan <pa...@acm.org> wrote:
>> Tim Bradshaw wrote:
>>> On 2009-06-26 19:49:35 +0100, "Thomas F. Burdick" <tbur...@gmail.com>
>>> said:
>>>
>>>> You sure about that? I thought that both C-ish macros and the Lisp
>>>> MACRO mechanism came about around 1970 or so.
>>>
>>> The earliest reference I am aware of to Lisp macros is AIM-5, which
>>> describes macros for Lisp 1.5 in 1963. The Lisp 1.5 manual does not
>>> mention macros. So I'm guessing a date some time in 1963, or possibly a
>>> little earlier.
>>>
>>
>>
>> The Software Preservation Group web page for Lisp history,
>> http://www.softwarepreservation.org/projects/LISP/ has a link to an
>> October 22, 1963 paper "MACRO Definition for LISP" by Timothy P. Hart,
>> ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-057.pdf
>>
>> I don't know enough about Lisp to evaluate whether what it describes is
>> the foundation of the current Lisp feature. Perhaps someone with the
>> necessary knowledge could take a look at it?
>
> It positively, definitely describes the foundations of macros.
>
> [...]
>
> The SETQ expansion is achieved by means of
>
> MACRO ((STASH (LAMBDA (FORM)
> (LIST (QUOTE SETQ)
> (CADAR FORM)
> (LIST (CONS (CADR FORM)
> (CADAR FORM)))))))
>
> (Indentation mine).
>
> This is in an old-style ``eval quote'' notation in which the outer parentheses
> were omitted from the toplevel form. But basically the macro would work
> today, with only a minor code update.
In http://www.informatimago.com/develop/lisp/small-cl-pgms/wang.html
you have a prefix that allow you to run directly these punch cards...
You just use (driver "stash.job") instead of (load "stash.lisp").
You will have to add the definition for the MACRO operator:
;; not tested.
(define macro (definitions)
(dolist (def definitions)
(destructuring-bind (name (lambda (form) &body body)) def
(assert (eq 'lambda lambda))
(eval `(defmacro ,name (&whole ,form) ,@body)))))
> [...]
>
> Clearly, the paper's author didn't cut and paste his own code from
> the text editor into the Lisp window of his graphics worksation
> to try it out. :) :) :)
Good luck trying to cut with scissors the top row of the punch cards
and paste it with glue on your paper... And this, if you have card
punchers able to print on the cards too.
--
__Pascal Bourguignon__
Tim Bradshaw
Tim Bradshaw
> Not if that's not actually what it is.
Who defines "what it is"? Do you have some kind of tablets handed to
you by God with a definition of the word?
Owen Jacobson
> On 2009-06-26 21:51:30 +0100, Series Expansion <sere...@gmail.com> said:
>
> > Not if that's not actually what it is.
>
> Who defines "what it is"? Do you have some kind of tablets handed to
> you by God with a definition of the word?
A user posting from Bell in Ottawa, who leaps to conclusions based on
rumour and naming and then defends those errors long past all
reason... Hmm, where have we seen this before?
-o
Vassil Nikolov
Humpty-Dumpty...
Series Expansion
>
> > Not if that's not actually what it is.
>
> Who defines "what it is"?
The dictionary.
> Do you have some kind of tablets handed to
> you by God with a definition of the word?
No, but I do have some paper handed to me by Webster's with a
definition of the word.
Series Expansion
I honestly don't know. Certainly plenty of people here have been
making all sorts of errors and jumping to all sorts of conclusions,
though I'm not one of them. A number of them have apparently been
leaping to conclusions about me, though.
Series Expansion
> On Sat, 27 Jun 2009 13:55:30 +0100, Tim Bradshaw <t...@tfeb.org> said:
>
> > Who defines "what it is"?
>
> Humpty-Dumpty...
No, the dictionary.
Tim Bradshaw
> No, but I do have some paper handed to me by Webster's with a
> definition of the word.
Webster's , of course, being the preferred source for any kind of
computing term.
But, actually:
macro |ˈmakrəʊ|
noun ( pl. -ros)
1 (also macro instruction) Computing a single instruction that expands
automatically into a set of instructions to perform a particular task.
That looks to me like a fine definition of Lisp-style macros.
Alan Bawden
> On Jun 25, 12:40�am, Alan Bawden <a...@shaggy.csail.mit.edu> wrote:
> > Series Expansion <sere...@gmail.com> writes:
> > > On Jun 24, 1:51�pm, fortunatus <daniel.elia...@excite.com> wrote:
> > > > YES - the first one - that's the reason Lispers like the Lisp macro,
> >
> > > because it isn't one? How ridiculous. Redefining things and then
> > > acting all shocked and flamey when people call you on it. Really now.
Here, Mr. Expansion accuses us of "redefining" the word "macro".
> >
> > Lisp has been calling them "macros" since they were originally proposed in
> > 1963. [rest of irrelevant digression deleted]
But here he has deleted my evidence that the way Lisp uses the word is an
acceped meaning among computer scientists in 2009. He calls my evidence an
"irrelevant digression", and chooses to reply to the rest of my messsage in
the following manner:
> > Now that you've lost that argument
>
> I have not.
>
> > here you are again whining
>
> I am not.
>
> > ... Pathetic.
>
> I am not.
This is not even effective trolling any more. Mr. Expansion is now flying
randomly around the room like a rapidly deflating balloon. He'll
eventually come to rest behind the sofa, where we'll find him when cleaning
house next fall. "What the heck is this?", someone will say, holding up
the scrap of limp shriveled rubber he has become. "Oh", someone else will
answer, "that's what's left of Series Expansion. He wasn't fun for very
long. Just throw it out."
Thomas F. Burdick
> > On 2009-06-26 19:49:35 +0100, "Thomas F. Burdick" <tburd...@gmail.com>
> > said:
>
> >> You sure about that? I thought that both C-ish macros and the Lisp
> >> MACRO mechanism came about around 1970 or so.
>
> > The earliest reference I am aware of to Lisp macros is AIM-5, which
> > describes macros for Lisp 1.5 in 1963. The Lisp 1.5 manual does not
> > mention macros. So I'm guessing a date some time in 1963, or possibly a
> > little earlier.
Wow, I stand corrected (and by a decade, no less!).
On Jun 26, 10:35 pm, Patricia Shanahan <p...@acm.org> wrote:
> The Software Preservation Group web page for Lisp history,http://www.softwarepreservation.org/projects/LISP/has a link to an
> October 22, 1963 paper "MACRO Definition for LISP" by Timothy P. Hart,ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-057.pdf
>
> I don't know enough about Lisp to evaluate whether what it describes is
> the foundation of the current Lisp feature. Perhaps someone with the
> necessary knowledge could take a look at it?
Interesting, thanks for the link.
Tim Bradshaw
> This is not even effective trolling any more. Mr. Expansion is now flying
> randomly around the room like a rapidly deflating balloon. He'll
> eventually come to rest behind the sofa, where we'll find him when cleaning
> house next fall. "What the heck is this?", someone will say, holding up
> the scrap of limp shriveled rubber he has become. "Oh", someone else will
> answer, "that's what's left of Series Expansion. He wasn't fun for very
> long. Just throw it out."
I find this kind of article really grossly unacceptable. I am sure I
am not alone in now requiring a new keyboard as my current one is now
full of coffee. Much worse, some people may have been typing while
reading and may now have scalded their hands. It is only through long
experience of this kind of behaviour on the part of certain people that
I know always to wear my asbestos-lined gloves while reading news.
Usually, of course I also wrap my laptop in cellophane.
Please refrain from this in future. I will be invoicing you for the
keyboard by return.
Kenneth Tilton
> On 2009-06-30 03:02:12 +0100, Alan Bawden <al...@shaggy.csail.mit.edu> said:
>
>> This is not even effective trolling any more. Mr. Expansion is now
>> flying
>> randomly around the room like a rapidly deflating balloon. He'll
>> eventually come to rest behind the sofa, where we'll find him when
>> cleaning
>> house next fall. "What the heck is this?", someone will say, holding up
>> the scrap of limp shriveled rubber he has become. "Oh", someone else
>> will
>> answer, "that's what's left of Series Expansion. He wasn't fun for very
>> long. Just throw it out."
>
> I find this kind of article really grossly unacceptable. I am sure I am
> not alone in now requiring a new keyboard as my current one is now full
Really? I presume you are not referring to my hunt and peck typing
skills or you would have said reading while typing the former following
the latter for hunt and peckers. My presumption thus proved, we are left
with people writing while reading and I am concerned this suggests one
can talk while listening, the hard part there being listening in so much
as few people are capable of listening. Where was I?
hth, kt
ps. It took you dweebs this long to suss Expansion's uselessness? Our
skills are fading. k
Tim Bradshaw
> ps. It took you dweebs this long to suss Expansion's uselessness? Our
> skills are fading. k
It's true. In the golden age of CLL he would have been a gibbering
wreck in some asylum by now. (But, may be, he is, who could tell?)
fortunatus
OK, this is straight from Mirriam-Webster, since you mentioned them as
being the ultimate reference:
Main Entry: macro
Function: noun
Inflected Form(s): plural macros
Etymology: short for macroinstruction
Date: 1959
: a single computer instruction that stands for a sequence of
operations
That easily includes Lisp style macros, I think.
Series Expansion
> On 2009-06-29 04:46:05 +0100, Series Expansion <sere...@gmail.com> said:
>
> > No, but I do have some paper handed to me by Webster's with a
> > definition of the word.
>
Most illogical.
Series Expansion
> Series Expansion <sere...@gmail.com> writes:
> > On Jun 25, 12:40 am, Alan Bawden <a...@shaggy.csail.mit.edu> wrote:
> > > Series Expansion <sere...@gmail.com> writes:
> > > > On Jun 24, 1:51 pm, fortunatus <daniel.elia...@excite.com> wrote:
> > > > > YES - the first one - that's the reason Lispers like the Lisp macro,
>
> > > > because it isn't one? How ridiculous. Redefining things and then
> > > > acting all shocked and flamey when people call you on it. Really now.
>
> > > 1963. [rest of irrelevant digression deleted]
>
No, you're the liar.
> > > Now that you've lost that argument
>
> > I have not.
>
> > > here you are again whining
>
> > I am not.
>
> > > ... Pathetic.
>
> > I am not.
>
> This is not even effective trolling any more.
Of course not, because IT NEVER WAS.
> Mr. Expansion is now flying randomly around the room like a rapidly
> deflating balloon. He'll eventually come to rest behind the sofa, where
> we'll find him when cleaning house next fall.
I recommend that you consult a physician. I suspect you may have
picked some bad mushrooms.
> "What the heck is this?", someone will say, holding up
> the scrap of limp shriveled rubber he has become. "Oh", someone else will
> answer, "that's what's left of Series Expansion. He wasn't fun for very
> long. Just throw it out."
This suggests a callous disregard for your fellow human beings. I
recommend you seek counseling.
Series Expansion
> On 2009-06-30 03:02:12 +0100, Alan Bawden <a...@shaggy.csail.mit.edu> said:
>
> > This is not even effective trolling any more. Mr. Expansion is now flying
> > randomly around the room like a rapidly deflating balloon. He'll
> > eventually come to rest behind the sofa, where we'll find him when cleaning
> > house next fall. "What the heck is this?", someone will say, holding up
> > the scrap of limp shriveled rubber he has become. "Oh", someone else will
> > answer, "that's what's left of Series Expansion. He wasn't fun for very
> > long. Just throw it out."
>
> I find this kind of article really grossly unacceptable.
Yes -- it is sad when people post while stoned. He'll be embarrassed
by it later. I am mystified that people frequently seek to impair
their reasoning, judgment, and decision-making faculties by
intentionally inebriating themselves with ethanol and psychotropic
drugs, even after having embarrassing photos turn up on Facebook, or
videos on YouTube, after a previous bender.
Series Expansion
> >> This is not even effective trolling any more. Mr. Expansion is now
> >> flying
> >> randomly around the room like a rapidly deflating balloon. He'll
> >> eventually come to rest behind the sofa, where we'll find him when
> >> cleaning
> >> house next fall. "What the heck is this?", someone will say, holding up
> >> the scrap of limp shriveled rubber he has become. "Oh", someone else
> >> will
> >> answer, "that's what's left of Series Expansion. He wasn't fun for very
> >> long. Just throw it out."
>
> > I find this kind of article really grossly unacceptable.
>
Yes, Alan was indeed high on something when he wrote that. And the
White Album it isn't.
> ps. It took you dweebs this long to suss Expansion's uselessness?
I am not useless, so it's hardly surprising that people don't quickly
jump to the conclusion that I am.
Series Expansion
> On 2009-06-30 21:43:06 +0100, Kenneth Tilton <kentil...@gmail.com> said:
>
> > ps. It took you dweebs this long to suss Expansion's uselessness? Our
> > skills are fading. k
>
> It's true. In the golden age of CLL he would have been a gibbering
> wreck in some asylum by now.
Is that a threat?
Regardless, I am not useless.
> (But, may be, he is, who could tell?)
Nor am I crazy.
Series Expansion
> On Jun 28, 11:47 pm, Series Expansion <sere...@gmail.com> wrote:
>
> > On Jun 28, 8:07 pm, Vassil Nikolov <vniko...@pobox.com> wrote:
>
> > > On Sat, 27 Jun 2009 13:55:30 +0100, Tim Bradshaw <t...@tfeb.org> said:
>
> > > > Who defines "what it is"?
>
> > > Humpty-Dumpty...
>
> > No, the dictionary.
>
> operations
>
> That easily includes Lisp style macros, I think.
That one is clearly flawed. It would cover a function call, operator,
or almost anything else.
Tim Bradshaw
> Is that a threat?
No, it's an elegy
Series Expansion
How ridiculous of you.
Tim Bradshaw
>> On 2009-07-03 20:45:43 +0100, Series Expansion <sere...@gmail.com> said:
>>
>>> Is that a threat?
>>
>> [calls me a liar]
>
> How ridiculous of you.
Actually, the text you replaced above with "[calls me a liar]" was
"No, it's an elegy".
Kenneth Tilton
> On 2009-07-11 04:01:32 +0100, Series Expansion <ser...@gmail.com> said:
>
>>> On 2009-07-03 20:45:43 +0100, Series Expansion <sere...@gmail.com> said:
>>>
>>>> Is that a threat?
>>>
>>> [calls me a liar]
>>
>> How ridiculous of you.
>
>
You will be hearing from my attorneys.
kenny
Series Expansion
> On 2009-07-11 04:01:32 +0100, Series Expansion <sere...@gmail.com> said:
> >> On 2009-07-03 20:45:43 +0100, Series Expansion <sere...@gmail.com> said:
> >>> Is that a threat?
> >> [calls me a liar]
> > How ridiculous of you.
>
> Actually, the text you replaced above with "[calls me a liar]" was
Exactly.
Series Expansion
> >>> On 2009-07-03 20:45:43 +0100, Series Expansion <sere...@gmail.com> said:
> >>>> Is that a threat?
> >>> [calls me a liar]
> >> How ridiculous of you.
> You will be hearing from my attorneys.
About what? You're the one that just misquoted me.
Kenneth Tilton
Do I win?
kt
Arne Vajhøj
I would assume that it was a parody.
Arne
Vassil Nikolov
Somewhere on the lyrical-tragic-comic line anyway...
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
Arne Vajhøj
But it seems that people do !
Arne
Arne Vajhøj
> On Jun 29, 5:31 am, Tim Bradshaw <t...@tfeb.org> wrote:
>> On 2009-06-29 04:46:05 +0100, Series Expansion <sere...@gmail.com> said:
>>> No, but I do have some paper handed to me by Webster's with a
>>> definition of the word.
>>
>> But, actually:
>>
>> macro |ˈmakrəʊ|
>> noun ( pl. -ros)
>> 1 (also macro instruction) Computing a single instruction that expands automatically into a set of instructions to perform a particular task.
>>
>> That looks to me like a fine definition of Lisp-style macros.
>
Illogical to check Webster when you suggested it !?!?
Arne
Series Expansion
Yep -- the Non-Sequitur of the Month Award. Congratulations.
Series Expansion
> >>> On 2009-07-03 20:45:43 +0100, Series Expansion <sere...@gmail.com> said:
>
> >>>> Is that a threat?
>
> >>> [calls me a liar]
>
> >> How ridiculous of you.
>
> > Actually, the text you replaced above with "[calls me a liar]" was "No,
> > it's an elegy".
>
> I would assume that it was a parody.
Then you would be wrong.
Series Expansion
A few people do. Idiots, mostly.
Series Expansion
No, illogical to claim that it's a "fine definition" of "Lisp-style"
macros.
Series Expansion
> On 25 Jun 2009 00:40:17 -0400, Alan Bawden <a...@shaggy.csail.mit.edu> said:
>
> > Lisp has been calling them "macros" since they were originally proposed in
> > 1963.
>
> itself originated according to Merriam-Webster [*].
Irrelevant.
> I notice that the latter's definition is closer to Lisp macros than to
> cpp macros
Irrational.
> as it is only in for-evaluation positions that Lisp macros are
> expanded by the language processor (whether compiler or
> interpreter).
Illogical. That is not sufficient to make macros non-troublesome, so
it is not a salient difference with respect to this debate.
Series Expansion
wrote:
> It's possible to evaluate or compile DAGs.
Irrelevant. By definition, source code is text and a parse tree is a
tree.
> In some cases, it's even possible to evaluate or compile graphs with
> cycle, but it's actually undefined what may happen in presence of
> cycles.
Most illogical.
Tim Bradshaw
> Irrelevant. By definition, source code is text and a parse tree is a
> tree.
Yes. However what the lisp reader produces is not a tree, it's a
general graph.
Arne Vajhøj
Are you Kenneth Tilton?
If not then how would know that it was not a parody?
Arne
Arne Vajhøj
Hm.
My impression is that so far *all* people have.
Arne
Ron Garret
<dfa774bd-1a55-4e19...@k20g2000vbp.googlegroups.com>,
Series Expansion <ser...@gmail.com> wrote:
> On Jun 2, 2:54�pm, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
> > It's possible to evaluate or compile DAGs.
>
> Irrelevant. By definition, source code is text and a parse tree is a
> tree.
I'm coming into this a little late so I could be missing some context
(in which case I apologize for butting in), but I think it's important
to note that CL is unique among programming languages in that CL
programs are specifically *not* text, they are forms. Forms can be
produced by processing text through the reader, but they can also be
produced in other ways. So in CL, source code is not necessarily text.
rg
Series Expansion
> >> Tim Bradshaw wrote:
> >>> On 2009-07-11 04:01:32 +0100, Series Expansion <sere...@gmail.com> said:
> >>>>> On 2009-07-03 20:45:43 +0100, Series Expansion <sere...@gmail.com> said:
> >>>>>> Is that a threat?
> >>>>> [calls me a liar]
> >>>> How ridiculous of you.
> >>> Actually, the text you replaced above with "[calls me a liar]" was "No,
> >>> it's an elegy".
> >> I would assume that it was a parody.
> > Then you would be wrong.
>
> Are you Kenneth Tilton?
>
> If not then how would know that it was not a parody?
Simple. When I said "[calls me a liar]", I was not intending it as a
parody. Thus I know it was not a parody.
Series Expansion
> >> Series Expansion wrote:
> >>> On Jun 30, 4:43 pm, Kenneth Tilton <kentil...@gmail.com> wrote:
> >>>> ps. It took you dweebs this long to suss Expansion's uselessness?
> >>> I am not useless, so it's hardly surprising that people don't quickly
> >>> jump to the conclusion that I am.
> >> But it seems that people do !
>
> > A few people do. Idiots, mostly.
>
People have all kinds of impressions that don't necessarily correlate
all that strongly with reality. Particularly not when they, like you,
are idiots.
Series Expansion
> On 2009-07-12 20:12:20 +0100, Series Expansion <sere...@gmail.com> said:
> > Irrelevant. By definition, source code is text and a parse tree is a
> > tree.
>
> Yes.
You agree? Then why are you still arguing?
Series Expansion
> In article
> <dfa774bd-1a55-4e19-9eed-962aca9a8...@k20g2000vbp.googlegroups.com>,
> Series Expansion <sere...@gmail.com> wrote:
> > On Jun 2, 2:54 pm, p...@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> > > It's possible to evaluate or compile DAGs.
>
> > Irrelevant. By definition, source code is text and a parse tree is a
> > tree.
>
> I'm coming into this a little late so I could be missing some context
> (in which case I apologize for butting in), but I think it's important
> to note that CL is unique among programming languages in that CL
> programs are specifically *not* text, they are forms. Forms can be
> produced by processing text through the reader, but they can also be
> produced in other ways. So in CL, source code is not necessarily text.
It is still text. It becomes a parse tree. Much as in other languages.
Unlike in other languages, this tree is accessible to user code, but
that cannot gift it with magical powers impossible to normal trees
(say, a magical ability to contain undirected cycles).
Ron Garret
<baebd95c-a471-411e...@r34g2000vba.googlegroups.com>,
Series Expansion <ser...@gmail.com> wrote:
> On Jul 13, 2:44�am, Ron Garret <rNOSPA...@flownet.com> wrote:
> > In article
> > <dfa774bd-1a55-4e19-9eed-962aca9a8...@k20g2000vbp.googlegroups.com>,
> > �Series Expansion <sere...@gmail.com> wrote:
> > > On Jun 2, 2:54�pm, p...@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
> > > > It's possible to evaluate or compile DAGs.
> >
> > > Irrelevant. By definition, source code is text and a parse tree is a
> > > tree.
> >
> > I'm coming into this a little late so I could be missing some context
> > (in which case I apologize for butting in), but I think it's important
> > to note that CL is unique among programming languages in that CL
> > programs are specifically *not* text, they are forms. �Forms can be
> > produced by processing text through the reader, but they can also be
> > produced in other ways. �So in CL, source code is not necessarily text.
>
> It is still text. It becomes a parse tree.
Not necessarily. It is *usually* text, but it need not be. For
example, it is in principle possible to create Lisp programs graphically.
> Much as in other languages.
Much as. But not exactly as.
> Unlike in other languages, this tree is accessible to user code,
It's not just *accessible*, it's *producible* by user code *ab initio*.
> but
> that cannot gift it with magical powers impossible to normal trees
> (say, a magical ability to contain undirected cycles).
I don't know about "magical", but it's pretty frickin' cool.
rg
Tim Bradshaw
> It is still text. It becomes a parse tree.
It becomes a form...
> Much as in other languages.
> Unlike in other languages, this tree is accessible to user code, but
> that cannot gift it with magical powers impossible to normal trees
> (say, a magical ability to contain undirected cycles).
... which is not a tree but a general directed graph which may contain cycles.
Series Expansion
> Series Expansion <sere...@gmail.com> wrote:
> > On Jul 13, 2:44 am, Ron Garret <rNOSPA...@flownet.com> wrote:
> > > In article
> > > <dfa774bd-1a55-4e19-9eed-962aca9a8...@k20g2000vbp.googlegroups.com>,
> > > Series Expansion <sere...@gmail.com> wrote:
> > > > On Jun 2, 2:54 pm, p...@informatimago.com (Pascal J. Bourguignon)
> > > > wrote:
> > > > > It's possible to evaluate or compile DAGs.
>
> > > > Irrelevant. By definition, source code is text and a parse tree is a
> > > > tree.
>
> > > I'm coming into this a little late so I could be missing some context
> > > (in which case I apologize for butting in), but I think it's important
> > > to note that CL is unique among programming languages in that CL
> > > programs are specifically *not* text, they are forms. Forms can be
> > > produced by processing text through the reader, but they can also be
> > > produced in other ways. So in CL, source code is not necessarily text.
>
> > It is still text. It becomes a parse tree.
>
> No
Yes.
> > Much as in other languages.
>
> Much as.
Much as.
> > Unlike in other languages, this tree is accessible to user code,
>
> It's not just *accessible*, it's *producible*
That's part of accessibility.
> > but that cannot gift it with magical powers impossible to normal
> > trees (say, a magical ability to contain undirected cycles).
>
> I don't know about "magical", but it's pretty frickin' cool.
So you say. But "cool" doesn't add those bignums or put food on the
table, as a rule.
Series Expansion
> On 2009-07-13 15:43:36 +0100, Series Expansion <sere...@gmail.com> said:
>
> > It is still text. It becomes a parse tree.
>
> It becomes a form...
The Lispy term for a parse tree.
> > Much as in other languages.
> > Unlike in other languages, this tree is accessible to user code, but
> > that cannot gift it with magical powers impossible to normal trees
> > (say, a magical ability to contain undirected cycles).
>
> [calls me a liar]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Tim.
Tim Bradshaw
> The Lispy term for a parse tree.
So, since a form is a tree, clearly the following predicate could never
return true for any form:
(defun own-car-p (x)
(and (consp x)
(eq (car x) x)))
Because such a form could never exist, right?
? (defvar *x* '#1=(#1# . #1#)
*x*
? (own-car-p *x*_
t
So, not a tree then.