Re: macros (was: Seeking computer-programming job (Sunnyvale, CA))
Series Expansion
> Series Expansion <sere...@gmail.com> wrote in news:886d0118-9790-45f9-
> a812-3b915aa7c...@s16g2000vbp.googlegroups.com:
>
> > Another hand-wave. Macros are macros are macros.
>
> That's like saying tools are tools are tools.
Did you have a point?
Macros have certain features in common. So do tools. One can reason
about them without knowing more about the specific type, although with
less information one can draw fewer conclusions. For instance, if all
one knows is that an object is a tool, one cannot immediately infer
that it is heavy. One can however infer that it is useful in some
manner and probably an artifact of human civilization. Likewise with a
macro, one can infer it will be expanded in some manner, replaced with
some deterministic function of its arguments.
> And there are some situations where some tools are known to be dangerous.
> Therefore you want to disallow tools.
I don't want to disallow anything, except possibly illogical arguments
and pointless personal attacks.
Your "leap of logic" here is akin to if I had said that 400-volt 10-
amp electricity is dangerous and that that high a power level would be
unwise to employ in home wiring, and you responded by accusing me of
advocating to have electric power banned entirely.
> You should also keep in mind that when you argue with Lisp novices about
> the advantages and disadvantages of various Lisp features, you aren't
> necessarily learning as much as you think you are.
Are you, then, admitting to be novices? This explains your internal
contradictions and apparent inability to make a good impression or
present a coherent case for preferring Lisp over Java. However, it
prompts a new question: if you are novices, then why have you insisted
on playing the role of a "know-it-all" and why have you been so
certain that it is superior to Java? Your inability to back the latter
up with convincing arguments, and apparent need to resort to personal
attacks to press your points home and even to change the subject
entirely away from Lisp, to me indicates that you have no proof
whatsoever of your claim of its superiority. In which case your
starting and continuing this argument is clearly illogical.
> As I said before, it's useless for us to try to explain the advantages of
> CL macros
Perhaps, but not for the reasons you think. The apparent fact that you
are novices yourselves may have more to do with this.
> there is a powerful synergy in their advantages, such that you could
> memorize a list of their advantages and still not get it, till you have
> enough experience with them to become aware of that synergy.
This borders on an expression of religious faith. Only the initiated
can understand, we cannot or will not explain things to lay persons,
logic is irrelevant, and so forth.
I have little interest in joining your mystery cult, or any other. I
believe in the ability of thinking minds to communicate, explain, and
understand any abstract subject matter, if it is explained coherently
enough; that is, in the power of general-purpose intelligence. This is
diametrically opposed to any belief that there are things that "only
the initiated can understand", or similar statements that have been
implied by some of your assertions.
> Most of the macro fears you express here are not even significant in CL.
It is for each individual user or potential user to judge for himself
what problems are or are not "significant".
> The kinds of bugs that happen in actual practice with macros are easy to
> see and easy to fix.
Extraordinary claims require extraordinary evidence, and as yet you
have furnished nothing of the sort.
> And even if they weren't, the extra effort to fix them
> would be worth it, because CL macros are so powerful that they enable one
> programmer to do the work of dozens.
Extraordinary claims require extraordinary evidence.
> C macros don't provide any such power, which should tell you that CL
> and C macros are two different usages of the word "macro" with two
> different meanings.
Not 100% different, and my objections have been primarily based on
specific knowledge of CL macros. None have yet addressed my
observation that a variable name guaranteed to avoid capture cannot be
reliably computed by any function of a macro's arguments, except for
the case that the arguments contain the entire rest of the code base
aside from the invocation itself and the macro's definition.
Alessio Stalla
> None have yet addressed my
> observation that a variable name guaranteed to avoid capture cannot be
> reliably computed by any function of a macro's arguments, except for
> the case that the arguments contain the entire rest of the code base
> aside from the invocation itself and the macro's definition.
It can, if the variable name is not a string but a symbol. Symbols
have identity. So I can have two variables with different names
(different symbols) even if the printed representation of the symbols
(their name as a string) is equal.
(eq 'a 'a) ==> T ;same symbol
(eq '#:x '#:x) ==> NIL ;different symbols due to #: syntax
(let ((a '#:x)) (eq a a)) ==> T ;same symbol referenced twice
I can create a unique symbol, store it somewhere, and reference it
multiple times (e.g. as a variable name). The fact it's unique isn't a
function of anything; simply is a new symbol object which is not
reachable through any package, and so it can only be referenced by
holding a pointer to it.
Series Expansion
> On May 23, 9:30 pm, Series Expansion <sere...@gmail.com> wrote:
>
> > None have yet addressed my
> > observation that a variable name guaranteed to avoid capture cannot be
> > reliably computed by any function of a macro's arguments, except for
> > the case that the arguments contain the entire rest of the code base
> > aside from the invocation itself and the macro's definition.
>
> It can, if the variable name is not a string but a symbol.
It cannot. The way in which the name is constructed is irrelevant. The
only way to always construct one that did not match any existing one
in any wider scope would be to have a list of them all, in all wider
scopes. But such a list cannot, in general, be computed solely from
the macro's arguments.
> Symbols have identity. So I can have two variables with different names
> (different symbols) even if the printed representation of the symbols
> (their name as a string) is equal.
You refer to namespaces, or some similar concept. The problem is that
the lexical expansion of the macro will be contained in lexical scopes
that may declare variables the macro has no knowledge of, because they
are not referenced in its arguments. Namespaces, in any form, will not
get you around this problem.
> (eq 'a 'a) ==> T ;same symbol
>
> (eq '#:x '#:x) ==> NIL ;different symbols due to #: syntax
The result of doing this is to make the name useless. It means that if
the macro code expanded to perform:
(let ((#:x arg-value)))
...
(somefunc (#:x))
...
(otherfunc (#:x))
this would not pass arg-value to either somefunc or otherfunc, because
every occurrence of #:x is separate from every other. This completely
defeats the purpose of even having a variable name, which requires
that it can be referred to multiple times.
Thus these #:x symbols are a mere curiosity. They do not provide a
means to avoid multiple evaluation, let alone (except trivially)
variable capture.
> (let ((a '#:x)) (eq a a)) ==> T ;same symbol referenced twice
This does not get around the problem:
(let ((a '#:x)))
(let (*a arg-value))
...
(somefunc (*a))
...
(otherfunc (*a))
(I do not know how to indirect through a, so I used the C-like
notation *a above. It doesn't matter to the point I'm making.)
This may work, getting arg-value into somefunc and otherfunc, but now
if the enclosing scope also uses a variable named a, we have a new
collision.
This is precisely what I was getting at in my previous post on this
subject.
> I can create a unique symbol, store it somewhere, and reference it
> multiple times (e.g. as a variable name).
But to reference the same one multiple times, you need another
variable to refer to it, like the variable named "a" in your second
example above. THAT variable needs a name. If it is another of your
"gensyms", it too needs a variable referring to it, so we eventually
must arrive at a variable that has an ordinary name. And then that
name may become involved in a collision. We are reduced back to the
original problem, the inability of the macro to compute a collision-
safe name solely from its arguments.
> The fact it's unique isn't a function of anything; simply is a new
> symbol object which is not reachable through any package, and so
> it can only be referenced by holding a pointer to it.
A clever attempt and a fine effort, but the collision problem has
simply moved to the name of the variable holding a pointer to it.
As I said before, the introduction of a layer of indirection here does
not solve the problem.
Series Expansion
public.xdi.org/=pf) wrote:
> Series Expansion <sere...@gmail.com> writes:
> > This completely
> > defeats the purpose of even having a variable name, which requires
> > that it can be referred to multiple times.
>
> variable each time. Problem solved.
Problem not solved, as I explained further on in my post.
> >> (let ((a '#:x)) (eq a a)) ==> T ;same symbol referenced twice
>
> > This does not get around the problem:
>
> > (let ((a '#:x)))
> > (let (*a arg-value))
> > ...
> > (somefunc (*a))
> > ...
> > (otherfunc (*a))
>
> > (I do not know how to indirect through a, so I used the C-like
> > notation *a above. It doesn't matter to the point I'm making.)
>
> Try it like this:
>
> (setq code '(let ((x arg-value)) (somefunc x) (otherfunc x)))
>
> Then
>
> (setq new-code (subst '#:x 'x code))
>
> [that is, replace occurences of X (the variable) in code with #:X (a
> different, uninterned symbol...but the same one each time!)] Now
>
> new-code => (let ((#:x arg-value)) (somefunc #:x) (otherfunc #:x))
And you're back where you started. If you pasted that code into the
editor from this news-post, saved it to a file, and compiled it,
that'd be three separate #:xs there.
> > But to reference the same one multiple times, you need another
> > variable to refer to it, like the variable named "a" in your second
> > example above. THAT variable needs a name. If it is another of your
> > "gensyms", it too needs a variable referring to it,
>
> No.
Yes.
> Because macros are not just stupid code templates; they're
> functions.
Not relevant. It does not matter how the macro computes an output such
as
(let ((#:x value)))
...
(func(#:x))
all that matters is that when the compiler compiles the above source
code the #:xs will not be the same.
> So the variable that has has the name of the temporary
> variable is a variable in the macro function, not a variable in the
> expansion.
Almost clever enough to get around it, but it all falls apart when the
"#:x" symbols (perhaps the same at this point) in the macro's output
are substituted for the macro invocation in the source code. Whereupon
they simply become "#:x" occurrences in the source code. Which the
compiler will then regard as distinct.
The only way around this would be for the macro to output somehow
directly into the object code, rather than transform the source code,
and then it would not be a macro anymore by any reasonable definition
of the word. In particular, it would become false in general that
manually expanding a macro invocation in the source code would not
alter the program semantics, which would be a serious violation of the
definition, of the principle of least astonishment, and likely of
several other things.
In fact, such a thing threatens the very sanctity of the definition of
"source code" itself, by implying that Lisp source code is really a
form of rich-text and not plain ASCII and converting it to the latter
loses information. I think it should be apparent how dangerous this
could be.
It follows that if your macros don't avoid variable capture, they're
dangerous, and if they somehow do, they're even MORE dangerous.
I rest my case.
> (defmacro see-what-I-mean (&body whatever)
> (let ((safe-variable (gensym)))
> `(let ((,safe-variable some-value))
> ,@whatever)))
>
> (macroexpand '(see-what-I-mean anything-you-like-here))
>
> => (LET ((#:G1959 SOME-VALUE))
> ANYTHING-YOU-LIKE-HERE)
>
> What do you think you can put in place of ANYTHING-YOU-LIKE-HERE that
> can get access to the variable called #:G1959?
Nothing, but it's a useless example, since there's no subsequent
retrieval of some-value. That gensyms allow you to throw values across
the event horizons of black holes had already been established.
> > must arrive at a variable that has an ordinary name. And then that
> > name may become involved in a collision.
>
> The "ordinary name" in the above example is "safe-variable". But that
> doesn't appear in the macro's expansion, so you can't collide with it.
(defmacro see-what-I-mean (&body whatever)
(let ((safe-variable (gensym)))
`(let ((,safe-variable some-value))
,@whatever
func(,safe-variable)))
(macroexpand '(see-what-I-mean anything-you-like-here))
=> (LET ((#:G1959 SOME-VALUE))
ANYTHING-YOU-LIKE-HERE
FUNC(#:G1959))
and compiling the above three lines will not cause func to be invoked
on some-value, because the #:G1959s are different again.
If they were different to begin with, you're sunk. If they weren't,
and macroexpand made them different, then you're even worse off for
the reasons outlined previously, since macroexpand is now failing to
preserve semantics and macros aren't quite macros. If they weren't,
and macroexpand didn't make them different but copying its output and
pasting it back in did, then you're even worse off than THAT because
now your source code isn't even able to be copied and pasted, or
otherwise manipulated with tools that only know ASCII, without the
semantics sometimes being altered. (And then the apparently-widespread
Lisper preference for emacs over more advanced editors comes into play
in a big way.) Source code that cannot safely be handled using tools
like grep, sed, awk, normal text editors, and so forth is not source
code in my opinion.
Kaz Kylheku
>> new-code => (let ((#:x arg-value)) (somefunc #:x) (otherfunc #:x))
>
> And you're back where you started. If you pasted that code into the
> editor from this news-post, saved it to a file, and compiled it,
> that'd be three separate #:xs there.
Then you'd have to RTFM about *print-circle*.
See, you keep assuming that there isn't any more to Lisp than what you have
read so far in this Usenet thread.
>> > But to reference the same one multiple times, you need another
>> > variable to refer to it, like the variable named "a" in your second
>> > example above. THAT variable needs a name. If it is another of your
>> > "gensyms", it too needs a variable referring to it,
>>
>> No.
>
> Yes.
>
>> Because macros are not just stupid code templates; they're
>> functions.
>
> Not relevant. It does not matter how the macro computes an output such
> as
>
> (let ((#:x value)))
> ...
> (func(#:x))
(#:x) means call the function called #:x, rather than evaluate
the variable #:x.
> all that matters is that when the compiler compiles the above source
> code the #:xs will not be the same.
We don't know that. Two #:x symbols could be the same symbol or could
not. If the code is machine generated by a macro, the #:x will be the same
symbol because the macro would have done this:
(let ((x-sym (gensym)))
`(let ((,x-sym value))
(func ,x-sym)))
I.e it would allocate a single symbol and stick it into multiple places
in the generated code. When that code is printed, those will all look like
#:x.
Yes, woe to you if you try to cut and paste that code back into Lisp.
If you want that to work reliably, then you will just have to learn about the
*print-circle* variable in the Lisp printer.
Here is how you can write a Lisp list with three occurences of #:x which really
are the same object:
[1]> '(#1=#:x #1# #1#)
(#:X #:X #:X)
[2]> (eq '#1=#:x '#1#)
T
#1= OBJ means ``the notation of OBJ is to be read normally, but also
remembered by an association with the number 1''.
#1# means ``regurgitate the object that was previously associated with 1''.
And so things like circular references, and multiple occurences of homeless
symbols can be reprented at read-time.
When you enable *print-circle*, the Lisp printer will render objects into this
notation.
[1]> (setf *print-circle* t)
T
[2]> (let ((x (cons 1 2))) (setf (cdr x) x))
#1=(1 . #1#)
See, *print-circle* shows us that circular list has itself as its tail. The ##
notation is capable of backpatching. The whole object can be associated with
#1, but #1# can also occur inside that object. Here, the object is a single
cons notated with the dot notation, and the CDR slot of the cell is the
cell itself (backpointer).
Adlai
> Here is how you can write a Lisp list with three occurences of #:x which really
> are the same object:
>
> [1]> '(#1=#:x #1# #1#)
> (#:X #:X #:X)
>
> [2]> (eq '#1=#:x '#1#)
> T
>
> #1= OBJ means ``the notation of OBJ is to be read normally, but also
> remembered by an association with the number 1''.
>
> #1# means ``regurgitate the object that was previously associated with 1''.
>
> And so things like circular references, and multiple occurences of homeless
> symbols can be reprented at read-time.
>
> When you enable *print-circle*, the Lisp printer will render objects into this
> notation.
>
> [1]> (setf *print-circle* t)
> T
> [2]> (let ((x (cons 1 2))) (setf (cdr x) x))
> #1=(1 . #1#)
>
> See, *print-circle* shows us that circular list has itself as its tail. The ##
> notation is capable of backpatching.
I guess I have to thank Series "The Troll" Expansion for creating a
situation wherein I inadvertantly learned that the #1=OBJ syntax is
useful for more than just circular lists. Thank you, my dear troll.
Now go home and RTFPCL.
- Adlai
Series Expansion
public.xdi.org/=pf) wrote:
> Series Expansion <sere...@gmail.com> writes:
> > On May 24, 2:50 am, Paul Foley <s...@below.invalid> (http://
> > public.xdi.org/=pf) wrote:
> >> If each occurrence of #:x is the exact same symbol, then it's the same
> >> variable each time. Problem solved.
>
> > Problem not solved, as I explained further on in my post.
>
OK, now that that's straightened out ...
> >> Try it like this:
>
> >> (setq code '(let ((x arg-value)) (somefunc x) (otherfunc x)))
>
> >> Then
>
> >> (setq new-code (subst '#:x 'x code))
>
> >> [that is, replace occurences of X (the variable) in code with #:X (a
> >> different, uninterned symbol...but the same one each time!)] Now
>
> >> new-code => (let ((#:x arg-value)) (somefunc #:x) (otherfunc #:x))
>
> > And you're back where you started. If you pasted that code into the
> > editor from this news-post, saved it to a file, and compiled it,
> > that'd be three separate #:xs there.
>
> Yes..../if/ I pasted it into a text editor, saved it to a file, and
> compiled it, that'd be three separate #:xs there.
And of course a macro processor is supposed to have the same effect:
as though it made its substitution of the macro's output for the
macro's invocation in the source code, after which the compiler
compiles said source code.
> But I wouldn't do that -- I'd compile it in the same Lisp image I did the
> substitution in, where there's only one #:x, and then I wouldn't have a
> problem.
Incoherent. The Lisp image is something that exists once you have a
compiled program and you run it, or you run it in the interpreter to
test it.
> >> Because macros are not just stupid code templates; they're
> >> functions.
>
> > Not relevant. It does not matter how the macro computes an output such
> > as
>
> > (let ((#:x value)))
> > ...
> > (func(#:x))
>
> > all that matters is that when the compiler compiles the above source
> > code the #:xs will not be the same.
>
> Unless you're using Lisp, in which case they will.
As already explained, they won't.
> >> So the variable that has has the name of the temporary
> >> variable is a variable in the macro function, not a variable in the
> >> expansion.
>
> > Almost clever enough to get around it, but it all falls apart when the
> > "#:x" symbols (perhaps the same at this point) in the macro's output
> > are substituted for the macro invocation in the source code. Whereupon
> > they simply become "#:x" occurrences in the source code. Which the
> > compiler will then regard as distinct.
>
> It would, if the source code were text. But it isn't
But it must be. Source code MUST be text. It's not permitted to be
something else, or the sky falls, grep can't be used to search your
source tree, sed and non-Lisp-aware text editors can't safely
manipulate your sources, aliens invade, terminators come back in time
for you, Windows Indexing Service can't search into your source files,
and other such disasters.
> > In fact, such a thing threatens the very sanctity of the definition of
> > "source code" itself, by implying that Lisp source code is really a
> > form of rich-text and not plain ASCII and converting it to the latter
> > loses information.
>
> It's not "rich-text"; it's not *text* at all. It's Lisp objects:
> lists, symbols, numbers, etc. And yes, of course serializing it to
> ASCII loses information.
This is disastrous. Source code should not be that way. Rich text is
bad enough but you're implying it's actually BINARY. I'd like to know
who thought THAT was a good idea.
> >> The "ordinary name" in the above example is "safe-variable". But that
> >> doesn't appear in the macro's expansion, so you can't collide with it.
>
> > (defmacro see-what-I-mean (&body whatever)
> > (let ((safe-variable (gensym)))
> > `(let ((,safe-variable some-value))
> > ,@whatever
> > func(,safe-variable)))
> > (macroexpand '(see-what-I-mean anything-you-like-here))
>
> > => (LET ((#:G1959 SOME-VALUE))
> > ANYTHING-YOU-LIKE-HERE
> > FUNC(#:G1959))
>
> > and compiling the above three lines will not cause func to be invoked
> > on some-value, because the #:G1959s are different again.
>
> The syntax is wrong
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Paul.
> but if you fix the syntax it /will/ cause FUNC to
> be invoked on some-value because the #:G1959s /are/ the same.
No, they aren't. Try pasting that code at your REPL if you think
otherwise.
> > semantics sometimes being altered. (And then the apparently-widespread
> > Lisper preference for emacs over more advanced editors comes into play
>
> "more advanced editors"...hahah, good one!
It's been repeatedly admitted by emacs PROPONENTS that it is at least
ten years behind the times, interface-wise. (My own personal
experience suggests a value closer to 20.)
Regardless, it is a *text* editor. If, as you say, the source code for
Lisp programs is *not text*, then, without a special-purpose NON-text
editor for them, you're up the proverbial creek.
Series Expansion
> On 2009-05-24, Series Expansion <sere...@gmail.com> wrote:
>
> >> new-code => (let ((#:x arg-value)) (somefunc #:x) (otherfunc #:x))
>
> > And you're back where you started. If you pasted that code into the
> > editor from this news-post, saved it to a file, and compiled it,
> > that'd be three separate #:xs there.
>
> Then you'd have to RTFM about *print-circle*.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Kaz.
> See, you keep assuming that there isn't any more to Lisp than what you have
> read so far in this Usenet thread.
No, I just keep assuming certain baseline, safe assumptions, one of
which is that source code is vanilla ASCII or, at worst (Java),
Unicode.
> > all that matters is that when the compiler compiles the above source
> > code the #:xs will not be the same.
>
> We don't know that. Two #:x symbols could be the same symbol or could
> not.
They can inside the macro processor's brain. Once the output is
incorporated into the in-memory image of the source code and becomes
ordinary text, however, they will be separate.
Put this way: if I type
(foo #:x)
(blah #:x)
into the code and compile it, that's two #:xs.
Macros basically automate transforming pieces of code into other
pieces of code, so if you typed something like that often, you could
get a macro to do it for you, thus avoiding one of the things you
criticize Java for: boilerplate code. So, if a macro generated
(foo #:x)
(blah #:x)
into the code and I compiled it, that should also be two #:xs, since
the macro is supposed to simply be automating the effect of typing
that stuff repeatedly and saving me the bother.
> If the code is machine generated by a macro, the #:x will be the same
> symbol because the macro would have done this:
>
> (let ((x-sym (gensym)))
> `(let ((,x-sym value))
> (func ,x-sym)))
>
> I.e it would allocate a single symbol and stick it into multiple places
> in the generated code.
And when that code is fed to the compiler, it's multiple #:xs again.
Certainly, if you selected the above and pasted it in, it would be.
And certainly, manually replacing a macro invocation in your source
file with its expansion should not change the semantics of that code
(though it would invite stuff-getting-out-of-synch problems down the
line).
> Yes, woe to you if you try to cut and paste that code back into Lisp.
Cutting and pasting code from one sourcefile to another shouldn't
alter semantics!! modulo the effects of enclosing scopes and
contextual imports.
> When you enable *print-circle*, the Lisp printer will render objects into this
> notation.
>
> [1]> (setf *print-circle* t)
> T
> [2]> (let ((x (cons 1 2))) (setf (cdr x) x))
> #1=(1 . #1#)
>
> See, *print-circle* shows us that circular list has itself as its tail. The ##
> notation is capable of backpatching. The whole object can be associated with
> #1, but #1# can also occur inside that object. Here, the object is a single
> cons notated with the dot notation, and the CDR slot of the cell is the
> cell itself (backpointer).
This hasn't solved your problem. Now the #1 in the output is the
potential source of a collision!
Thomas A. Russ
> On May 25, 12:08��am, Kaz Kylheku <kkylh...@gmail.com> wrote:
> > See, you keep assuming that there isn't any more to Lisp than what you have
> > read so far in this Usenet thread.
>
> No, I just keep assuming certain baseline, safe assumptions, one of
> which is that source code is vanilla ASCII or, at worst (Java),
> Unicode.
The whole problem with this series of threads is that you keep making
assumptions about lisp that are patently incorrect. And then you base
arguments on those incorrect assumptions.
When experienced lisp programmers point out to you that your assumptions
are incorrect, you then persist in trying to defend those assumptions,
instead of either accepting the correction in assumptions.
You see, lisp really is a language that works differently. If you can't
try to learn about lisp starting from a premise that the language works
differently, then your understanding of it is doomed. And so is any
credible technical critique, because the critique will be based on
unsound premises -- namely your limited imagination about how it can be
done.
Now, oddly enough, you seem quite willing to blithely assume that the
language MUST work in ways that make it impossible for the language to
actually work the way that everyday users of the language use it. So,
you are, of course, free to continue making unwarranted assumptions
based on your ignorance of the actual workings of Common Lisp.
But you then miss some of the greatest strengths of the language, the
chief one (in this particular thread) being that macros get to operate
on the structure of the language rather than its surface text. To put
that into more Java-friendly terms, it means that macros operate on the
parse-tree of the program, rather than on the program itself. So there
are manipulations possible that are not possible using just the text.
That is a real power.
Now it so happens that lisp uses a serialization of the structure of
lisp programs (although it's not called a "serialization" in lisp) that
can be used to reconstruct the structure of the source code. It can, in
fact, recreate the structure of any readable lisp object, including
circular structures.
The real problem with a lot of the argumentation in this thread is that
the objections were problems that either never existed or for which
problems were found long ago. There are some real benefits in having a
language with 50 years of development effort behind it (I'm speaking
here of lisp in general). And it seems rather silly to claim that such
a long-lived language absolutely doesn't work, and can't work the way
that the specification says it does.
I suppose that would be quite a hoax, if the lisp folks could pull it
off. To have a language that doesn't really work, but for which we have
a wide array of talented people who seem to agree that it really does
work. And to have them agree in their description in so much technical
detail is truly astonishing.
--
Thomas A. Russ, USC/Information Sciences Institute
Kaz Kylheku
> Series Expansion <ser...@gmail.com> writes:
>
>> On May 25, 12:08��am, Kaz Kylheku <kkylh...@gmail.com> wrote:
>
>> > See, you keep assuming that there isn't any more to Lisp than what you have
>> > read so far in this Usenet thread.
>>
>> No, I just keep assuming certain baseline, safe assumptions, one of
>> which is that source code is vanilla ASCII or, at worst (Java),
>> Unicode.
>
> The whole problem with this series of threads is that you keep making
> assumptions about lisp that are patently incorrect. And then you base
> arguments on those incorrect assumptions.
A ``safe assumption'' is in fact another word for a ``fact''. All other
assumptions are mere suppositions pulled from thin air (or, in worse
cases, from someone's ass: hence ass-umption).
Series Expansion cannot tell the difference between a fact, and something
he pulled from his ass. He will dispute the former, and regard the latter
as a safe assumption.
> When experienced lisp programmers point out to you that your assumptions
> are incorrect, you then persist in trying to defend those assumptions,
> instead of either accepting the correction in assumptions.
Not really. The above is the behavior of the Seamus MacRae identity.
This one works slightly differently. It accepts those facts, but then it
augments those new facts by pulling more assumptions out of nowhere.
The game plan is obvious: treat the debate as a game of chess, in which
the only information content is the current configuration of the board,
your color, whose turn it is, and the set of legal moves.
In making your next move, heuristics is fair game. Sacrificing truth
here and there is like losing a pawn.
The basic iteration is: gather the facts from the debate, and make up new
assumptions. Present the assumptions blankly, as if they were facts. When these
are challenged, accuse the opponents of personal attack. But accept some of
the facts, and iterate.
The name Series Expansion, in fact, is deliberately chosen to represent this
behavior. What is a series expansion? It's a dull, infinite, repetitive
representation of something compact and obvious. No finite portion of the
expansion is true; there is always another term to add to make it more
complete, and that term is predictable. It's so predictable that nobody wants
to add another term after a while. They'd rather move on, or have everyone
refer to the generating closed-form expression. So you must /goad/ others into
writing the next term. You do this by writing an incorrect one, and getting
them to correct it.
How about ``Seamus Macrae''? The given name portion is cleearly a deliberate
farce, since the name means ``modest'' or ``bashful''. MacRae is probably a
play on the word macro (another reference to expansion, note).
Thus, ``Shameful Macro'' -> ``Seamus MacRae''. Wherever he appears,
approximately the same bullshit is substituted, with no possibility
of redefinition.
Raffael Cavallaro
> The name Series Expansion, in fact, is deliberately chosen to represent this
> behavior. What is a series expansion? It's a dull, infinite, repetitive
> representation of something compact and obvious. No finite portion of the
> expansion is true; there is always another term to add to make it more
> complete, and that term is predictable. It's so predictable that nobody wants
> to add another term after a while. They'd rather move on, or have everyone
> refer to the generating closed-form expression. So you must /goad/ others into
> writing the next term. You do this by writing an incorrect one, and getting
> them to correct it.
>
> How about ``Seamus Macrae''? The given name portion is cleearly a deliberate
> farce, since the name means ``modest'' or ``bashful''. MacRae is probably a
> play on the word macro (another reference to expansion, note).
> Thus, ``Shameful Macro'' -> ``Seamus MacRae''. Wherever he appears,
> approximately the same bullshit is substituted, with no possibility
> of redefinition.
Another comp.lang.lisp first - deconstructionist literary criticism of
troll posts. Brilliant!
--
Raffael Cavallaro, Ph.D.
Series Expansion
public.xdi.org/=pf) wrote:
> Series Expansion <sere...@gmail.com> writes:
> >> Yes..../if/ I pasted it into a text editor, saved it to a file, and
> >> compiled it, that'd be three separate #:xs there.
>
> > And of course a macro processor is supposed to have the same effect:
> > as though it made its substitution of the macro's output for the
> > macro's invocation in the source code, after which the compiler
> > compiles said source code.
>
> pointlessly write the expansion out to a file only to read it back in
> again, it works fine.
That does not follow. Whether the preprocessed source code is saved to
disk or is passed directly to the compiler in main memory makes no
difference. Source code is source code, and if two successive
occurrences of #:x in source code refer to two different variables,
then two successive occurrences of #:x refer to two different
variables, even if they referred to one while still inside the macro
processor's internal representation of the code. When that
representation is flattened again into source code prior to
compilation, they become distinct. Saving it to a file or not has
nothing to do with it.
> >> > all that matters is that when the compiler compiles the above source
> >> > code the #:xs will not be the same.
>
> >> Unless you're using Lisp, in which case they will.
>
> > As already explained, they won't.
>
> Odd that it seems to have been working on a daily basis for thousands
> of people for several decades.
A claim for which we have only your word, versus a freight of logic
proving otherwise.
> >> >> So the variable that has has the name of the temporary
> >> >> variable is a variable in the macro function, not a variable in the
> >> >> expansion.
>
> >> > Almost clever enough to get around it, but it all falls apart when the
> >> > "#:x" symbols (perhaps the same at this point) in the macro's output
> >> > are substituted for the macro invocation in the source code. Whereupon
> >> > they simply become "#:x" occurrences in the source code. Which the
> >> > compiler will then regard as distinct.
>
> >> It would, if the source code were text. But it isn't
>
> > But it must be. Source code MUST be text. It's not permitted to be
> > something else,
>
> "Not permitted"? Mad as a hatter, aren't you!?
No, I am not. I am merely reiterating common sense. Something that you
apparently completely lack.
> >> > semantics sometimes being altered. (And then the apparently-widespread
> >> > Lisper preference for emacs over more advanced editors comes into play
>
> >> "more advanced editors"...hahah, good one!
>
> > It's been repeatedly admitted by emacs PROPONENTS that it is at least
> > ten years behind the times, interface-wise. (My own personal
> > experience suggests a value closer to 20.)
>
> I've never seen an editor that comes close to Emacs, in terms of
> usability.
You must have "usability" confused with something else, or else
something else confused with emacs. No application that requires a
four-page cheat sheet to even begin using productively merits any
awards on the basis of usability, except perhaps for Worst Ever or
similar "awards" of negative value. Cheat sheets went out with
Wordstar, break-dancing, and Vanilla Ice.
Paul Foley
> On May 26, 3:08�am, Paul Foley <s...@below.invalid> (http://
> public.xdi.org/=pf) wrote:
>> Series Expansion <sere...@gmail.com> writes:
>> >> Yes..../if/ I pasted it into a text editor, saved it to a file, and
>> >> compiled it, that'd be three separate #:xs there.
>>
>> > And of course a macro processor is supposed to have the same effect:
>> > as though it made its substitution of the macro's output for the
>> > macro's invocation in the source code, after which the compiler
>> > compiles said source code.
>>
>> Yes...since the "macro processor" is Lisp, and it doesn't attempt to
>> pointlessly write the expansion out to a file only to read it back in
>> again, it works fine.
>
> That does not follow. Whether the preprocessed source code is saved to
> disk or is passed directly to the compiler in main memory makes no
> difference. Source code is source code, and if two successive
> occurrences of #:x in source code refer to two different variables,
> then two successive occurrences of #:x refer to two different
> variables, even if they referred to one while still inside the macro
> processor's internal representation of the code. When that
> representation is flattened again into source code prior to
> compilation, they become distinct.
It doesn't get "flattened again into source code prior to
compilation"; the "macro processor"(that is, Lisp)'s "internal
representation of the code" /is/ the source code. The compiler
operates on that very same "internal representation" (i.e., the source
code).
>> >> > all that matters is that when the compiler compiles the above source
>> >> > code the #:xs will not be the same.
>>
>> >> Unless you're using Lisp, in which case they will.
>>
>> > As already explained, they won't.
>>
>> Odd that it seems to have been working on a daily basis for thousands
>> of people for several decades.
>
> A claim for which we have only your word, versus a freight of logic
> proving otherwise.
ROTFL
"Are you accusing me of lying? These tiresome personal attacks do not
constitute rational arguments in favor of Java, 'Series'"
Series Expansion
That would be incorrect behavior, if so. The compiler, after all, by
definition of "compiler" deals in source code, so if your statement
were correct, the output of a macro would not be in a form amenable to
being compiled.
> the "macro processor"(that is, Lisp)'s "internal
> representation of the code" /is/ the source code.
This statement is incoherent. The source code, by definition, is the
contents of the source files fed to the compiler, in the case of
Common Lisp e.g. by executing compile-file on them from a REPL.
> The compiler operates on that very same "internal representation" (i.e., the
> source code).
This, too, is incoherent, for largely the same reasons. Source code
and compiler internal representations differ by definition, unless the
internal representation at issue is something trivial, such as an
ASCII buffer read from a source file.
> >> >> > all that matters is that when the compiler compiles the above source
> >> >> > code the #:xs will not be the same.
>
> >> >> Unless you're using Lisp, in which case they will.
>
> >> > As already explained, they won't.
>
> >> Odd that it seems to have been working on a daily basis for thousands
> >> of people for several decades.
>
> > A claim for which we have only your word, versus a freight of logic
> > proving otherwise.
>
> ROTFL
I do not find your incoherent arguments, random personal attacks, and
other behaviors amusing. Rather, they concern me, as they may be early
signs of any of a number of serious degenerative neurological
conditions, for which you appear to be making no effort to seek
treatment.
I have deleted your misquotation of the remainder of my post. Suffice
it to say, you are doing a poor job of proving Lisp superior to Java.
And to add to your troubles, now the Lisp version of "computed goto"
has come to light. You have, as my colleagues would put it, "your work
cut out for you".
anonymous...@gmail.com
You can think of macros as manipulating the tokens.
(It just happens that lisp is very amenable to this sort of thing).
> > the "macro processor"(that is, Lisp)'s "internal
> > representation of the code" /is/ the source code.
>
> This statement is incoherent. The source code, by definition, is the
> contents of the source files fed to the compiler, in the case of
> Common Lisp e.g. by executing compile-file on them from a REPL.
>
Right.
> > The compiler operates on that very same "internal representation" (i.e., the
> > source code).
>
> This, too, is incoherent, for largely the same reasons. Source code
> and compiler internal representations differ by definition, unless the
> internal representation at issue is something trivial, such as an
> ASCII buffer read from a source file.
>
Right, but the internal representations are isomorphic to the source
file, so with lisp the line is 'blurry'.
(Java is to JVM as lisp is to lisp.)
(Although lisp then goes through another pass to a lower level
'virtual machine' (i.e. assembler, JVM, gcc in some cases))
Series Expansion
> On May 28, 1:43 am, Series Expansion <sere...@gmail.com> wrote:
> > > Series Expansion <sere...@gmail.com> writes:
> > > > That does not follow. Whether the preprocessed source code is saved to
> > > > disk or is passed directly to the compiler in main memory makes no
> > > > difference. Source code is source code, and if two successive
> > > > occurrences of #:x in source code refer to two different variables,
> > > > then two successive occurrences of #:x refer to two different
> > > > variables, even if they referred to one while still inside the macro
> > > > processor's internal representation of the code. When that
> > > > representation is flattened again into source code prior to
> > > > compilation, they become distinct.
>
> > > It doesn't get "flattened again into source code prior to
> > > compilation"
>
> > That would be incorrect behavior, if so. The compiler, after all, by
> > definition of "compiler" deals in source code, so if your statement
> > were correct, the output of a macro would not be in a form amenable to
> > being compiled.
>
> Most compilers tokenize the source file prior to compilation.
> You can think of macros as manipulating the tokens.
That seems acceptable, but it fails to grant macros miraculous powers
of prescience.
> > > The compiler operates on that very same "internal representation" (i.e., the
> > > source code).
>
> > This, too, is incoherent, for largely the same reasons. Source code
> > and compiler internal representations differ by definition, unless the
> > internal representation at issue is something trivial, such as an
> > ASCII buffer read from a source file.
>
> Right, but the internal representations are isomorphic to the source
> file, so with lisp the line is 'blurry'.
I have proven mathematically that if the internal representations ARE
isomorphic to the source file then your asserted miraculous properties
of gensyms are physically impossible.
> (Java is to JVM as lisp is to lisp.)
>
> (Although lisp then goes through another pass to a lower level
> 'virtual machine' (i.e. assembler, JVM, gcc in some cases))
In other words, Java is really to JVM as Lisp is to assembler, JVM, or
even C code.
(Lisp on the JVM. That's gotta be a match made in hell! The JVM is
full of checks and validations, which I'm sure you Lispers would
consider as anal as Java's type safety and similar "bondage and
discipline". I can just imagine the methods needed to tie it up and
gag it into accepting Lisp-derived bytecodes without blowing up in
some manner.)
anonymous...@gmail.com
> On May 28, 2:04 am, anonymous.c.lis...@gmail.com wrote:
>
>
>
> > On May 28, 1:43 am, Series Expansion <sere...@gmail.com> wrote:
> > > On May 27, 12:52 am, Paul Foley <s...@below.invalid> (http://public.xdi.org/=pf) wrote:
> > > > Series Expansion <sere...@gmail.com> writes:
> > > > > That does not follow. Whether the preprocessed source code is saved to
> > > > > disk or is passed directly to the compiler in main memory makes no
> > > > > difference. Source code is source code, and if two successive
> > > > > occurrences of #:x in source code refer to two different variables,
> > > > > then two successive occurrences of #:x refer to two different
> > > > > variables, even if they referred to one while still inside the macro
> > > > > processor's internal representation of the code. When that
> > > > > representation is flattened again into source code prior to
> > > > > compilation, they become distinct.
>
> > > > It doesn't get "flattened again into source code prior to
> > > > compilation"
>
> > > That would be incorrect behavior, if so. The compiler, after all, by
> > > definition of "compiler" deals in source code, so if your statement
> > > were correct, the output of a macro would not be in a form amenable to
> > > being compiled.
>
> > Most compilers tokenize the source file prior to compilation.
> > You can think of macros as manipulating the tokens.
>
> That seems acceptable, but it fails to grant macros miraculous powers
> of prescience.
>
I don't think any computer language ever grant miraculous powers.
You have to recognize that for lisp, 'tokenizing' the code turns the
code into lisp objects (more or less).
> > > > The compiler operates on that very same "internal representation" (i.e., the
> > > > source code).
>
> > > This, too, is incoherent, for largely the same reasons. Source code
> > > and compiler internal representations differ by definition, unless the
> > > internal representation at issue is something trivial, such as an
> > > ASCII buffer read from a source file.
>
> > Right, but the internal representations are isomorphic to the source
> > file, so with lisp the line is 'blurry'.
>
> I have proven mathematically that if the internal representations ARE
> isomorphic to the source file then your asserted miraculous properties
> of gensyms are physically impossible.
>
Isomorphic isn't identical,
Symbols are first class objects.
I'd like to see your proof, it sounds quite impressive.
> > (Java is to JVM as lisp is to lisp.)
>
> > (Although lisp then goes through another pass to a lower level
> > 'virtual machine' (i.e. assembler, JVM, gcc in some cases))
>
> In other words, Java is really to JVM as Lisp is to assembler, JVM, or
> even C code.
I think you could say that both statements are true.
> (Lisp on the JVM. That's gotta be a match made in hell! The JVM is
> full of checks and validations, which I'm sure you Lispers would
> consider as anal as Java's type safety and similar "bondage and
> discipline". I can just imagine the methods needed to tie it up and
> gag it into accepting Lisp-derived bytecodes without blowing up in
> some manner.)
I believe you have to do all sorts of strange things with classes and
casting.
I really wouldn't know beyond the fact that it is doable.
Thomas A. Russ
> > Most compilers tokenize the source file prior to compilation.
> > You can think of macros as manipulating the tokens.
>
> That seems acceptable, but it fails to grant macros miraculous powers
> of prescience.
...
> I have proven mathematically that if the internal representations ARE
> isomorphic to the source file then your asserted miraculous properties
> of gensyms are physically impossible.
Well, something must be wrong with either your proof or the assumptions,
since GENSYMs are able to create new symbols (objects or tokens, if you
will) that can be inserted into the parse tree that is passed to the
compiler. Those symbols are guaranteed to be unique.
If you think that is incorrect, then here is a challenge. I will write
a simple macro and you can then show that is suffers from one of the
problems that you claim it must have. You won't be able to do it.
So, here is the macro and the challenge:
You are to provide the code for the body that is inserted into the
binding context of the GENSYM and be able to print the value of that
GENSYM.
(defmacro gensym-test (&body body)
(let ((var (gensym)))
`(let ((,var (random 1000000)))
,@body
,var)))
This will return the value with a random number. Your job is to print
that value with something in BODY code. If it's more to your liking,
here is an effectively equivalent version
(defmacro gensym-test (&body body)
(let ((var #:v))
`(let ((,var (random 1000000)))
,@body
,var)))
So, you get to provide the content to replace ... for a call to this
macro that can demonstrate why variable capture has to happen.
(gensym-test ...)
Alan Bawden
> ...
> So, here is the macro and the challenge:
>
> You are to provide the code for the body that is inserted into the
> binding context of the GENSYM and be able to print the value of that
> GENSYM.
>
> (defmacro gensym-test (&body body)
> (let ((var (gensym)))
> `(let ((,var (random 1000000)))
> ,@body
> ,var)))
>
> This will return the value with a random number. Your job is to print
> that value with something in BODY code. If it's more to your liking,
> here is an effectively equivalent version
>
> (defmacro gensym-test (&body body)
> (let ((var #:v))
> `(let ((,var (random 1000000)))
> ,@body
> ,var)))
>
> So, you get to provide the content to replace ... for a call to this
> macro that can demonstrate why variable capture has to happen.
>
> (gensym-test ...)
Your second challenge is flawed. Even after I fix the missing quote:
(defmacro gensym-test (&body body)
(let ((var '#:v))
`(let ((,var (random 1000000)))
,@body
,var)))
I can crack it with the following macro:
(defmacro expose-it ()
(let ((var (caddr (macroexpand-1 '(gensym-test)))))
`(format t "The value will be: ~S~%" ,var)))
You might consider calling macroexpand-1 off-limits, but setf does it all
the time, so I don't think you can rule this out.
The moral of the story is that you have to be very careful about designing
challenges like this.
anonymous...@gmail.com
I think the moral here is to be careful when 'fixing' things, as you
might break them.
1 and 2 are semantically identical.
Quoting it makes the #:v a literal constant in your version, whereas
it is in 1 and 2, it is not.
(defmacro gensym-test1 (&body body)
(let ((var (gensym)))
`(let ((,var (random 1000000)))
,@body
,var)))
(defmacro gensym-test2 (&body body)
(let ((var #:v))
`(let ((,var (random 1000000)))
,@body
,var)))
(defmacro gensym-test3 (&body body)
(let ((var '#:v))
`(let ((,var (random 1000000)))
,@body
,var)))
(defmacro expose-it (test) (let ((var (caddr (macroexpand-1 `
(,test))))) `(format T "The value will be: ~S~%" ,var)))
(defun exposure-test1 ()
(gensym-test1 (expose-it gensym-test1)))
(defun exposure-test2 ()
(gensym-test2 (expose-it gensym-test2)))
(defun exposure-test3 ()
(gensym-test3 (expose-it gensym-test3)))
Load this code and you will see that 1 & 2 will not run due to an
unbound variable, whereas 3 behaves as you claim.
anonymous...@gmail.com
I will note that you may have been confused by the style warning that
you get with #2 (in sbcl at least).
Although you may get this warning, it loads and runs exactly as #1
would have.
Series Expansion
> On May 28, 11:03 pm, Series Expansion <sere...@gmail.com> wrote:
> > On May 28, 2:04 am, anonymous.c.lis...@gmail.com wrote:
> > > Most compilers tokenize the source file prior to compilation.
> > > You can think of macros as manipulating the tokens.
>
> > That seems acceptable, but it fails to grant macros miraculous powers
> > of prescience.
>
> I don't think any computer language ever grant miraculous powers.
>
> You have to recognize that
You have to recognize that taking a condescending tone does not
encourage others to listen to you.
> for lisp, 'tokenizing' the code turns the code into lisp objects (more
> or less).
Not relevant.
> > > Right, but the internal representations are isomorphic to the source
> > > file, so with lisp the line is 'blurry'.
>
> > I have proven mathematically that if the internal representations ARE
> > isomorphic to the source file then your asserted miraculous properties
> > of gensyms are physically impossible.
>
> Isomorphic isn't identical,
> Symbols are first class objects.
The claim made regarding gensyms cannot be correct unless the program
structure in memory (your abstract syntax tree) is not actually a tree
but a directed acyclic graph with undirected cycles. Since the parse
tree of any text source file will be a bona fide tree, it follows that
if the claim regarding gensyms is true, the two representations are
NOT isomorphic; conversely, if as you have claimed the representations
ARE isomorphic the gensym claim is bogus.
> I'd like to see your proof, it sounds quite impressive.
It was in an earlier post of mine. More than one of them in fact; I
kept having to repeat it for the hard of hearing.
> > > (Java is to JVM as lisp is to lisp.)
>
> > > (Although lisp then goes through another pass to a lower level
> > > 'virtual machine' (i.e. assembler, JVM, gcc in some cases))
>
> > In other words, Java is really to JVM as Lisp is to assembler, JVM, or
> > even C code.
>
> I think you could say that both statements are true.
No.
Paul Foley
>> I'd like to see your proof, it sounds quite impressive.
>
> It was in an earlier post of mine. More than one of them in fact; I
> kept having to repeat it for the hard of hearing.
Your idea of "proof" seems to taken from Lewis Carroll: "what i tell
you three times is true"
Alan Bawden
Yes, but they get unbound variable errors for different reasons.
gensym-test2 gets an unbound variable error NO MATTER WHAT YOU PUT IN THE
BODY! They are not "semantically identical" -- gensym-test2 is just
broken. Tom pretty clearly intended gensym-test3, which can be attacked as
I demonstrated.
(And yes, my attack does not work on gensym-test1. It does get an unbound
variable error. As near as I can tell, gensym-test1 proves the point that
Tom was trying to make just fine and he should have stopped there!)
anonymous...@gmail.com
Hmm, that's wierd.
I had thought John's version of 2 was running in the repl last night,
however this morning it clearly isn't.
I must have forgotten to overwrite an old one.
Now the moral is: 'Don't disagree with Allan, God will smite your
repl'.
Apologies!
Series Expansion
public.xdi.org/=pf) wrote:
These tiresome personal attacks do not constitute rational arguments
Thomas A. Russ
> t...@sevak.isi.edu (Thomas A. Russ) writes:
> > (defmacro gensym-test (&body body)
> > (let ((var #:v))
> > `(let ((,var (random 1000000)))
> > ,@body
> > ,var)))
> >
> > So, you get to provide the content to replace ... for a call to this
> > macro that can demonstrate why variable capture has to happen.
> >
> > (gensym-test ...)
>
> Your second challenge is flawed. Even after I fix the missing quote:
Hi Alan!
Yes, you are correct that (a) it is missing a quote and (b) is subject
to the flow with using a sort of meta-programming trick to get at the
variable of the expansion.
> (defmacro gensym-test (&body body)
> (let ((var '#:v))
> `(let ((,var (random 1000000)))
> ,@body
> ,var)))
>
> I can crack it with the following macro:
>
> (defmacro expose-it ()
> (let ((var (caddr (macroexpand-1 '(gensym-test)))))
> `(format t "The value will be: ~S~%" ,var)))
>
> You might consider calling macroexpand-1 off-limits, but setf does it all
> the time, so I don't think you can rule this out.
>
> The moral of the story is that you have to be very careful about designing
> challenges like this.
How true.
It would have been quite impressive, though, if the target of that
challenge had found that solution.
I guess I'd better stick with #1....
-Tom.
Thomas A. Russ
> anonymous...@gmail.com writes:
> > (defmacro gensym-test1 (&body body)
> > (let ((var (gensym)))
> > `(let ((,var (random 1000000)))
> > ,@body
> > ,var)))
...
> > (defmacro gensym-test3 (&body body)
> > (let ((var '#:v))
> > `(let ((,var (random 1000000)))
> > ,@body
> > ,var)))
> (And yes, my attack does not work on gensym-test1. It does get an unbound
> variable error. As near as I can tell, gensym-test1 proves the point that
> Tom was trying to make just fine and he should have stopped there!)
Yes. Reconstructing my reasoning, I think I was trying to set a trap
just to demonstrate that even if you knew the SYMBOL-NAME of the
gensymed variable, it would not work. So that if one tried to do a very
naive
(gensym-test3 (print #:v))
that it would fail. But I hadn't considered the possibility of using
macroexpand to get at the actual form. So, in that sense, the power,
reflectivity and flexibilty of the lisp tools turned out to be greater
than I had anticipated.
Thomas A. Russ
> The claim made regarding gensyms cannot be correct unless the program
> structure in memory (your abstract syntax tree) is not actually a tree
> but a directed acyclic graph with undirected cycles. Since the parse
> tree of any text source file will be a bona fide tree, it follows that
> if the claim regarding gensyms is true, the two representations are
> NOT isomorphic; conversely, if as you have claimed the representations
> ARE isomorphic the gensym claim is bogus.
Well, for starters, let's clear up some more misconceptions here.
(1) There is no requirement that the "parse tree" for lisp source has to
be a true tree (as in a directed, acyclic graph). Lisp has read
(and write) syntax for circular structures that allows a source code
to not be a tree at all. But that is mostly an aside, since it
isn't the fundamental misconception.
(2) The fundamental misconception is not realizing the impact that the
ability to execute code as part of the macro-expansion has. It is
precisely this ability to execute code that gives Lisp macros the
power that Series Expansion likes to describe as "magical".
The GENSYM that is created for use as the name of a variable DOESN'T
EXIST IN THE SOURCE CODE. It is created at macro-expansion time by
the running of code in the macro-expansion function. So, it is
quite easy to create a new, unique symbol object. And by not
registering the symbol in a package, there is no way to look it up
by name.
>
> It was in an earlier post of mine. More than one of them in fact; I
> kept having to repeat it for the hard of hearing.
Except that this proof depends on assumptions that are just not true.
And as everyone knows, a proof that proceeds from false premises
establishes nothing.
Series Expansion
> I guess I have to thank Series "The Troll" Expansion
I am not a troll.
> for creating a
> situation wherein I inadvertantly learned that the #1=OBJ syntax is
> useful for more than just circular lists. Thank you, my dear troll.
> Now go home and RTFPCL.
You are being rude, incoherent, and irrational.
Series Expansion
> Series Expansion <sere...@gmail.com> writes:
> > On May 25, 12:08Ž am, Kaz Kylheku <kkylh...@gmail.com> wrote:
> > > See, you keep assuming that there isn't any more to Lisp than what you have
> > > read so far in this Usenet thread.
>
> > No, I just keep assuming certain baseline, safe assumptions, one of
> > which is that source code is vanilla ASCII or, at worst (Java),
> > Unicode.
>
I do not. You do.
By the way, nice attempt to badmouth me behind my back. It failed.
> When experienced lisp programmers [call me names], you then persist in
> trying to defend
As would any rational individual that came under attack.
> [trimmed a lot of melodrama about how I'm "doomed"]
> your limited imagination
> your ignorance
> you then miss
Argumentum ad hominem again? So tiresome.
> the objections were problems that either never existed or for which
> problems were found long ago.
Oh, yes indeedy, problems were indeed found for your earlier problems.
And those in turn were on earlier problems, and so on and so on ad
infinitum.
> I suppose that would be quite a hoax, if the lisp folks could pull it
> off. To have a language that doesn't really work, but for which we have
> a wide array of talented people who seem to agree that it really does
> work. And to have them agree in their description in so much technical
> detail is truly astonishing.
Apparently you've never gone to a Star Trek convention.
Regardless, I never claimed that it couldn't work at all. That is your
straw-man. I merely claimed that there were some difficulties that
were going to be difficult to avoid, other than by abiding by the age-
old advice, "avoid macros".
Series Expansion
> On 2009-05-26, Thomas A. Russ <t...@sevak.isi.edu> wrote:
> >> On May 25, 12:08 am, Kaz Kylheku <kkylh...@gmail.com> wrote:
> >> > See, you keep assuming that there isn't any more to Lisp than what you have
> >> > read so far in this Usenet thread.
> >> No, I just keep assuming certain baseline, safe assumptions, one of
> >> which is that source code is vanilla ASCII or, at worst (Java),
> >> Unicode.
>
I do not.
> A ``safe assumption'' is in fact another word for a ``fact''. All other
> assumptions are mere suppositions pulled from thin air (or, in worse
> cases, from someone's ass: hence ass-umption).
This vulgarity is not helping your case, or your credibility. I do not
understand why several of you are apparently incapable of disagreeing
with someone in a civil fashion, without resort to name-calling or
expletives.
> Series Expansion cannot tell the difference between a fact, and something
> he pulled from his ass.
This is incorrect.
> > When experienced lisp programmers [call me names], you then persist in
> > trying to defend
As any rational person would.
> Not really. The above is the behavior of the Seamus MacRae identity.
Why do you refer to people named X as "the X identity"? Normal human
beings will simply use the name X.
> This one works slightly differently.
Please don't tell me you are some sort of paranoid or delusional
psychotic who believes all the other people in the world are
"identities" of some single master entity constantly plotting against
you?
Because I don't think we have a cure for that one yet.
> It accepts those facts, but then it [etc.]
I am a human being, not some pod person from outer space. Please refer
to me as "he".
> The game plan is obvious: treat the debate as a game of chess, in which
> the only information content is the current configuration of the board,
> your color, whose turn it is, and the set of legal moves.
Is that what you're doing? It explains a few things, though it also
leaves much still mysterious.
> In making your next move, heuristics is fair game. Sacrificing truth
> here and there is like losing a pawn.
That would explain why you and Thomas show a penchant for lying,
especially about me.
> The name Series Expansion, in fact, is deliberately chosen to represent this
> behavior.
No, it is not. How could I possibly have anticipated your behavior
when I first created the account, years ago? I'd never heard of people
behaving like you do at that time.
> [insults]
These tiresome personal attacks do not constitute a rational argument
in favor of either Lisp or Java, Kaz.
> How about ``Seamus Macrae''?
How about him? I don't see that he's at all relevant here.
> The given name portion is cleearly a deliberate farce, since the name
> means ``modest'' or ``bashful''. MacRae is probably a play on the word
> macro (another reference to expansion, note).
Teleology now? By what mechanism are you proposing that his parents,
however many decades ago, would have anticipated this turn of events
and given him a name that resembles "macro"? Or rather, his ancestors
perhaps thousands of years back, whenever the MacRae clan got its
start in the mists of Ireland or Scotland or wherever it is that
MacRaes come from.
Doctor Who's TARDIS?
Gimme a break.
> [calls Seamus names]
Why? He isn't here, he isn't bothering you, why attack him like that?
Your behavior is truly baffling. It will take a major research efforts
by the world's top psychiatrists to figure out what makes you tick.
Series Expansion
<raffaelcavall...@pas.espam.s.il.vous.plait.mac.com> wrote:
> On 2009-05-26 15:33:19 -0400, Kaz Kylheku <kkylh...@gmail.com> said:
> >The name Series Expansion, in fact, is deliberately chosen to represent this
> > behavior.
It is not. I had no idea that you existed, let alone would exhibit
"this behavior", when I chose that name.
> > [namecalling, aimed at myself and, in absentia, at Seamus MacRae]
>
> Another comp.lang.lisp first - deconstructionist literary criticism of
> troll posts. Brilliant!
His is certainly a troll post, but I did not see any deconstructionist
literary criticism of it.
Series Expansion
> Series Expansion <sere...@gmail.com> writes:
> > isomorphic to the source file then your asserted miraculous properties
> > of gensyms are physically impossible.
>
Nice try, but I periodically check other newsgroups than
comp.lang.java.programmer so you can only forestall my rebutting a
post full of personal attacks for a short time by trying to hide it
away in a newsgroup I don't read regularly.
Series Expansion
> The moral of the story is that you have to be very careful about designing
> challenges like this.
There is no sign of morality in either of you.
Series Expansion
> > t...@sevak.isi.edu (Thomas A. Russ) writes:
> > The moral of the story is that you have to be very careful about designing
> > challenges like this.
> I think the moral here is to be careful when 'fixing' things, as you
> might break them.
I think the moral here is that it is not polite, or wise, to badmouth
someone behind his back. Doubly so if it turns out he has very good
hearing.
Series Expansion
> On May 29, 11:04 pm, anonymous.c.lis...@gmail.com wrote:
> > On May 29, 6:25 pm, Alan Bawden <a...@shaggy.csail.mit.edu> wrote:
> > > t...@sevak.isi.edu (Thomas A. Russ) writes:
> > > The moral of the story is that you have to be very careful about designing
> > > challenges like this.
> > I think the moral here is to be careful when 'fixing' things, as you
> > might break them.
> you get with #2 (in sbcl at least).
Namecalling isn't a matter for style warnings, but for etiquette
warnings, IMO.
Series Expansion
> Series Expansion <sere...@gmail.com> writes:
> > The claim made regarding gensyms cannot be correct unless the program
> > structure in memory (your abstract syntax tree) is not actually a tree
> > but a directed acyclic graph with undirected cycles. Since the parse
> > tree of any text source file will be a bona fide tree, it follows that
> > if the claim regarding gensyms is true, the two representations are
> > NOT isomorphic; conversely, if as you have claimed the representations
> > ARE isomorphic the gensym claim is bogus.
>
Let's not.
I have no interest in your ad hominem "arguments" so you might as well
quit them.
> (1) There is no requirement that the "parse tree" for lisp source has to
> be a true tree (as in a directed, acyclic graph).
Ludicrous.
> Lisp has read
> (and write) syntax for circular structures that allows a source code
> to not be a tree at all.
A source code is a linear sequence of characters (ASCII or, less
often, wide characters). There's a difference between source code and
the parse trees used internally by compilers and similar tools.
> But that is mostly an aside, since it isn't the fundamental misconception.
This insinuation that I have "misconceptions" is unwelcome and untrue.
> It is precisely this ability to execute code that gives Lisp macros the
> power that Series Expansion likes to describe as "magical".
It is rude to address someone, in their presence, in the third person.
(And the rest of what you said is pure nonsense.)
> The GENSYM that is created for use as the name of a variable DOESN'T
> EXIST IN THE SOURCE CODE. It is created at macro-expansion time by
> the running of code in the macro-expansion function. So, it is
> quite easy to create a new, unique symbol object. And by not
> registering the symbol in a package, there is no way to look it up
> by name.
Or ever use the same one twice. Kinda limits their usefulness
methinks.
> > It was in an earlier post of mine. More than one of them in fact; I
> > kept having to repeat it for the hard of hearing.
>
> Except that [calls me a liar]
No, sir, and indeed I submit that if there is a liar here it is you.
Arne Vajhøj
> On Jun 1, 2:05 pm, t...@sevak.isi.edu (Thomas A. Russ) wrote:
>
>> Lisp has read
>> (and write) syntax for circular structures that allows a source code
>> to not be a tree at all.
>
> A source code is a linear sequence of characters (ASCII or, less
> often, wide characters).
I know that Java allows for source code in other encoding than
ASCII and UTF-16 (wide chars are usually UTF-16).
I would expect Lisp to be similar.
Arne
Arne Vajhøj
> On May 26, 3:33 pm, Kaz Kylheku <kkylh...@gmail.com> wrote:
>> Not really. The above is the behavior of the Seamus MacRae identity.
>
> Why do you refer to people named X as "the X identity"?
Because you are known for using multiple identities.
Arne
Vassil Nikolov
No, rather I think only narrow characters are allowed, no more than
7.62 mm.
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
Series Expansion
> Series Expansion wrote:
> > On Jun 1, 2:05 pm, t...@sevak.isi.edu (Thomas A. Russ) wrote:
>
> >> Lisp has read
> >> (and write) syntax for circular structures that allows a source code
> >> to not be a tree at all.
>
> > A source code is a linear sequence of characters (ASCII or, less
> > often, wide characters).
>
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne.
Tim Bradshaw
> Or ever use the same one twice. Kinda limits their usefulness
> methinks.
I know you won't listen [so why am I wasting my time?] but you *really*
need to actually make some effort to understand CL (or Lisp in general)
because this kind of statement is just making you look silly.
For instance, consider this macro:
(defmacro collecting (&body forms)
(let ((ln (make-symbol "LIST"))
(ltn (make-symbol "TAIL")))
`(let ((,ln '())
(,ltn '()))
(flet ((collect (it)
(if (null ,ltn)
(setf ,ln (list it)
,ltn ,ln)
(setf (cdr ,ltn) (list it)
,ltn (cdr ,ltn)))
it))
(progn
,@forms
,ln)))))
This uses two gensyms (I've made them with MAKE-SYMBOL, so I can give
them print names which help, but they are uninterned symbols.
Now, what does the expansion of this look like?
? (macroexpand
'(collecting
(collect 1)
(collect 2)))
(let ((#:list 'nil) (#:tail 'nil))
(flet ((collect (it)
(if (null #:tail)
(setf #:list (list it) #:tail #:list)
(setf (cdr #:tail) (list it) #:tail (cdr #:tail)))
it))
(progn (collect 1) (collect 2) #:list)))
Except, of course, those uninterned symbols are actually *the same two
symbols* each time they are used, as you can see from the macro
definition. Fortunately there is a machanism of showing this: set
*PRINT-CIRCLE* to true:
? (macroexpand
'(collecting
(collect 1)
(collect 2)))
(let ((#2=#:list 'nil) (#1=#:tail 'nil))
(flet ((collect (it)
(if (null #1#)
(setf #2# (list it) #1# #2#)
(setf (cdr #1#) (list it) #1# (cdr #1#)))
it))
(progn (collect 1) (collect 2) #2#)))
Lew
> On 2009-07-11 14:30:39 +0100, Series Expansion <ser...@gmail.com> said:
>
>> Or ever use the same one twice. Kinda limits their usefulness
>> methinks.
>
> I know you won't listen [so why am I wasting my time?] but you *really*
> need to actually make some effort to understand CL (or Lisp in general)
> because this kind of statement is just making you look silly.
Wow. You guys are still arguing with the troll after all this time?
Amazing.
I'm not sure how this topic made it through my filters but I'll block it again.
--
Lew
Pascal J. Bourguignon
> This uses two gensyms (I've made them with MAKE-SYMBOL, so I can give
> them print names which help, but they are uninterned symbols.
Better use (gensym "LIST-") and (gensym "TAIL-") so you can
distinguish them when you macroexpand:
(collecting (collect (collecting (collect 1) (collect 2)))
(collect (collecting (collect 3) (collect 4))))
--
__Pascal Bourguignon__
Series Expansion
I am not.
Series Expansion
> On 2009-07-11 14:30:39 +0100, Series Expansion <sere...@gmail.com> said:
> > Or ever use the same one twice. Kinda limits their usefulness
> > methinks.
>
> I know you won't listen
To ad hominems? No.
> but you *really* need to
I do not "*really* need to" do anything on your say-so, as a matter of
fact.
> because this kind of statement is just making you look silly.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Tim.
> ? (macroexpand
> '(collecting
> (collect 1)
> (collect 2)))
> (let ((#:list 'nil) (#:tail 'nil))
> (flet ((collect (it)
> (if (null #:tail)
> (setf #:list (list it) #:tail #:list)
> (setf (cdr #:tail) (list it) #:tail (cdr #:tail)))
> it))
> (progn (collect 1) (collect 2) #:list)))
And if what you've said about "uninterned" symbols is correct, this
won't behave as advertised if read in and evaluated.
You now have two options:
1. It just plain doesn't work, and I win.
2. It somehow does work, in which case replacing a macro invocation
with its expansion does NOT work, not always having the same
semantics as leaving the macro invocation as a macro invocation,
because there's some sort of "magic" involved. In which case I win
again because then your "macros" not only aren't true macros, but
furthermore do something very weird, confusing, and therefore
evil.
Kenneth Tilton
> Tim Bradshaw wrote:
>> On 2009-07-11 14:30:39 +0100, Series Expansion <ser...@gmail.com> said:
>>
>>> Or ever use the same one twice. Kinda limits their usefulness
>>> methinks.
>>
>> I know you won't listen [so why am I wasting my time?] but you
>> *really* need to actually make some effort to understand CL (or Lisp
>> in general) because this kind of statement is just making you look silly.
>
> Wow. You guys are still arguing with the troll after all this time?
>
> Amazing.
>
Good point. Other cll suckers, sure, but Tfb the Elder? I guess the
choppers got repossessed.
kt
Series Expansion
> >> Or ever use the same one twice. Kinda limits their usefulness
> >> methinks.
>
> > I know you won't listen [so why am I wasting my time?] but you *really*
> > need to actually make some effort to understand CL (or Lisp in general)
> > because this kind of statement is just making you look silly.
> Wow. You guys are still arguing with the troll after all this time?
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Tim.
Series Expansion
> On Sat, 11 Jul 2009 14:24:57 -0400, Arne Vajhøj <a...@vajhoej.dk> said:
>
> > Series Expansion wrote:
> >> On Jun 1, 2:05 pm, t...@sevak.isi.edu (Thomas A. Russ) wrote:
>
> >>> Lisp has read
> >>> (and write) syntax for circular structures that allows a source code
> >>> to not be a tree at all.
>
> >> A source code is a linear sequence of characters (ASCII or, less
> >> often, wide characters).
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Vassil and Arne.
> No, rather I think only narrow characters are allowed, no more than
> 7.62 mm.
Most illogical.
Series Expansion
> >>> Or ever use the same one twice. Kinda limits their usefulness
> >>> methinks.
> >> I know you won't listen [so why am I wasting my time?] but you
> >> *really* need to actually make some effort to understand CL (or Lisp
> >> in general) because this kind of statement is just making you look silly.
> > Wow. You guys are still arguing with the troll after all this time?
> choppers got repossessed.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Kenneth, "Lew", and Tim.
Series Expansion
> > The claim made regarding gensyms cannot be correct unless the program
> > structure in memory (your abstract syntax tree) is not actually a tree
> > but a directed acyclic graph with undirected cycles. Since the parse
> > tree of any text source file will be a bona fide tree, it follows that
> > if the claim regarding gensyms is true, the two representations are
> > NOT isomorphic; conversely, if as you have claimed the representations
> > ARE isomorphic the gensym claim is bogus.
>
> Well, for starters, let's clear up some more misconceptions
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Thomas.
> (1) There is no requirement that the "parse tree" for lisp source has to
> be a true tree
Sure there is. It's even stated right there in the very name "parse
tree".
> (2) The fundamental misconception is not realizing the impact that the
> ability to execute code as part of the macro-expansion has.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Thomas.
> The GENSYM that is created for use as the name of a variable DOESN'T
> EXIST IN THE SOURCE CODE.
Did I claim otherwise?
The point is, we have flat ASCII text. Then we have a parse tree (note
"tree"). Then a transformation is apparently made upon this parse tree
(note "tree"). Then you make a bunch of claims that are impossible to
reconcile with the tree-ness of this tree.
> > It was in an earlier post of mine. More than one of them in fact; I
> > kept having to repeat it for the hard of hearing.
>
> Except that this proof depends on [lies] [rest deleted]
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Thomas.
Tim Bradshaw
> Good point. Other cll suckers, sure, but Tfb the Elder? I guess the
> choppers got repossessed.
I'm not an elder as far as I know. We have had certain, um, problems
with the helicopters, it's true. Fixing the banks turned out to
require a whole lot more operational hours than we expected, and parts
availability has become a serious issue (sand gets everywhere). I'd
been assuming that Mr Expansion was actually one of your tentacles
though? If not I'll have to check it's not one of ours: we've had some
problems with some of the more independent subsystems recently.
Tim Bradshaw
Bourguignon) said:
> Better use (gensym "LIST-") and (gensym "TAIL-") so you can
> distinguish them when you macroexpand:
Yes, probably.
Tim Bradshaw
> And if what you've said about "uninterned" symbols is correct, this
> won't behave as advertised if read in and evaluated.
That's correct. But only because the printer, with default settings,
does not attempt to detect all the sharing in structures it prints.
Since, in this code, there is sharing, the printed form does not
properly represent the code. As I said, if you set *PRINT-CIRCLE*
true, then the printer *does* try and detect sharing, and will print
something which can be read in and will work (this is not always the
case, since not all structures can be printed readably at all, but it
is true here). Of course none of this affects the macro's behaviour at
all because it does not rely on the printer or reader.
Arne Vajhøj
> On Jul 11, 2:24 pm, Arne Vajh�j <a...@vajhoej.dk> wrote:
>> Series Expansion wrote:
>>> On Jun 1, 2:05 pm, t...@sevak.isi.edu (Thomas A. Russ) wrote:
>>>> Lisp has read
>>>> (and write) syntax for circular structures that allows a source code
>>>> to not be a tree at all.
>>> A source code is a linear sequence of characters (ASCII or, less
>>> often, wide characters).
>> ASCII and UTF-16 (wide chars are usually UTF-16).
>>
>> I would expect Lisp to be similar.
>
> in favor of either Lisp or Java, Arne.
No.
But it prevents readers from thinking that source code can only
be ASCII and UTF-16, which is not the case.
Arne
Series Expansion
> On 2009-07-12 19:35:59 +0100, Series Expansion <sere...@gmail.com> said:
> > And if what you've said about "uninterned" symbols is correct, this
> > won't behave as advertised if read in and evaluated.
>
> That's correct.
Then why are you still arguing?
Series Expansion
> >> Series Expansion wrote:
> >>> On Jun 1, 2:05 pm, t...@sevak.isi.edu (Thomas A. Russ) wrote:
> >>>> Lisp has read
> >>>> (and write) syntax for circular structures that allows a source code
> >>>> to not be a tree at all.
> >>> A source code is a linear sequence of characters (ASCII or, less
> >>> often, wide characters).
> >> I know that Java allows for source code in other encoding than
> >> ASCII and UTF-16 (wide chars are usually UTF-16).
>
> >> I would expect Lisp to be similar.
>
> > These tiresome personal attacks do not constitute rational arguments
> > in favor of either Lisp or Java, Arne.
>
> No.
>
Tim Bradshaw
> Then why are you still arguing?
I don't need to: the macro works, and does the arguing for me.
Series Expansion
> On 2009-07-12 19:37:08 +0100, Kenneth Tilton <kentil...@gmail.com> said:
>
> > Good point. Other cll suckers, sure, but Tfb the Elder? I guess the
> > choppers got repossessed.
These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Tim and Thomas.
> I'm not an elder as far as I know. We have had certain, um, problems
> with the helicopters, it's true. Fixing the banks turned out to
> require a whole lot more operational hours than we expected [etc etc]
Seek help.
Series Expansion
> On 2009-07-13 15:35:47 +0100, Series Expansion <sere...@gmail.com> said:
>
> > Then why are you still arguing?
>
> I don't need to
Then stop already.