Re: Seeking computer-programming job (Sunnyvale, CA)

[Series Expansion]

So, it is your opinion that there is exactly one model for object
orientation? Fascinating.

So, it is your opinion that putting words in your opponent's mouth is
an acceptable and valid debating strategy? Fascinating.

 

[Series Expansion]

Not that it really matters for your argumentation - it is still
perfectly valid.

No, Thomas's argumentation is not "perfectly valid". Argumentum ad
hominem has been recognized as a fallacy for thousands of years.

 

[Series Expansion]

Based on his IP address then Series Expansion is twisted alias
Paul Derbyshire.

No, I am not. Furthermore, my identity is irrelevant to the questions
raised regarding Lisp macros, and the personal attacks posted by Larry
also fail to make any kind of a case for Lisp over Java.

 

[Series Expansion]

Emacs has been running on X for 20 years (give or take a few).

I'm sure it's been running on X for as long as there've been xterms to
run it in.

Wrong

[snip]

Fascinating. Arne appears to believe that Unicode is a subset of
ASCII. This is unusual and will require further investigation.

 

[Series Expansion]

Bill Joy was part of early vi.

 

[Series Expansion]

Because there have been xterms for 20 years (give or take a few).

Forget it.  Series McShameUs has been down this road before.

Please spell my name correctly. Thank you.

 The facts have never convinced him, and they never will.

These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew".

El Stupido

These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew".

Arne bravely attempted to correct the misconceptions with

These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew".

Arne "bravely" did nothing; he launched a personal attack on an
innocent target from behind a veil of online anonymity. Such an act is
ordinarily considered one of cowardice.

Wrong

I'm pretty convinced that Series Expansion, being a shameful liar, [rest
deleted]

These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew" and Arne.

Every couple of years he pops out with this crap

This remark is as illogical as it is incorrect. How can someone who
has only been present for a few weeks possibly be known to do
something "every couple of years"? It is speculation in a vacuum,
devoid of any significant probability of turning out to be accurate.

[a very large volume of nonsense]
Series ExPaulsion

Please spell my name correctly. Thank you.

is just a troll, and not even a good one at that.

These tiresome personal attacks do not constitute rational arguments
in favor of either emacs or Eclipse, "Lew".

 

[Series Expansion]

Absolutely not.

But I am. Unless you have run statistical studies on Java programmers,
you cannot logically refute it, and to assert otherwise anyway is
therefore illogical. Moreover, it is tantamount to calling me a liar,
which is as extraordinarily rude as it is unprovoked.

Typical Java programmer are a lot better at listening and learning.

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne.

Maybe not according to birth certificate, but ...

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Arne and "Lew".

 

[Series Expansion]

Your comment is off-topic for a any newsgroup.

Lew, you did better before...

Where? I have not seen it.

 

[Adlai]

That's it. I've had enough of being insulted every time I open my mouth.

**** you!

Please don't split my sentances like that.

Now, what would you want me to say, if after reading something you
said, I concluded that you weren't fully aware of the facts?

Earlier in this discussion I said something that was just plain
incorrect (re: lists in Java). I was corrected, and I accepted that as
part of a discussion -- the part where you learn things you didn't
know before.

I'm glad when somebody corrects me. Of course, I wouldn't be happy if
the corrections themselves were false -- but I can check that out
easily on various sources (Java spec, Lisp spec, etc), and confirm for
myself whether something is right or not. If I said something that was
factually wrong, and somebody pointed that out and said what was
correct, I would be thankful to them for doing so.

So, my sincere question to you is: If I think that your knowledge
about some fact is incorrect, how would you want me to tell you that?

Surely there has to be some way of doing so in any discussion where
participants hope to learn.

The truly egregious thing here is that I quite clearly know a LOT more
about Java than you do, and you even attack me for my statements about Java.

I wasn't criticising your statement about Java -- I was criticising
your sentiment that because CL packages only have symbols, then there
are collisions between similarly-named variables, types, classes,
methods, etc.

I don't think you're here to debate Lisp anymore. You're here to flame
people and be generally boorish in public. The only question is: why?

It makes me sad that you think that. I'll admit it, some things that
have been said in this thread have made me laugh; however, this last
paragraph just makes me sad that you think that. Did you read the
section I wrote about what a symbol could mean in various contexts? Do
you remember my posts explaining various features of CL? Yes, I've had
some less-genteel posts, but you can't judge somebody by the worst of
their behaviour; if you did that, everybody in this thread would be a
"drive-by flamer".

It does not matter. I deserve to be treated with a modicum of respect.
People will stop criticizing me and confine their discussions to the
programming languages under discussion here. The subject "Seamus MacRae"
is off-topic. Got it?

Of course you deserve to be treated with respect; however, I don't
think it's disrespecting you to say that you have some facts
backwards. That's all I was saying. I wasn't saying "this guy doesn't
know his shit", which has been some of what other people have said. I
was trying to help you understand an aspect of the language, so that
maybe some other people won't think you as clueless as they seem to.

That's a laugh.


No, it's another pack of vicious lies. What is the MATTER with you? Have
you gone off the deep end? Are you physically incapable of carrying out
a discussion without having to either agree with each other person or
else flame him/her? Does disagreeing *without* acrimony simply not
compute for you, or what?

If anything displays a lack of respect, it's mincing somebody's words
like that. I really do hope you read what I wrote before you replied
to it, because the sentiment expressed by your "remix" of what I said
is not at all like that of my original post.

You're not making much sense. I see a method with a list of two
arguments here. Java would have "int foo, float bar" or the like, but
Lisp functions lack argument types so that would just become "foo, bar"
and Lisp list items are space-separated instead of comma-separated so
that would just become "(foo bar)".

The method-definition syntax equivalent to Java's (int foo, float bar)
is ((int foo) (float bar)). (btw, this is something that I had wrong
earlier in the thread, and somebody corrected me about it very
bluntly, but who cares? I was wrong)

If you look at that method definition, you'll see: ((transaction-
manager picture-library:jpeg-picture))
The outside parentheses are the entire argument list; the inner
parentheses denote one argument.

But if you confuse your personal preference with objective
truth, and write that "truth" in public, I - we - feel the need to
correct your claims.
That statement makes several insulting and false insinuations about me.
I'm sorry, but I genuinely think [repeats insults]
Think what you want, but please restrain the urge to blurt out uncivil
things in public. Weren't you taught any manners as a child?
I don't think
That needs rectifying right away, then.

You complained earlier about people mincing up your messages before
replying to them. Don't do that to others. Weren't YOU ever taught the
Golden Rule as a child?

Yes, but I was also taught game theory, and "tit for tat" tends to be a
winning strategy. You do it to me enough times, I do it once to you as a
little reminder.

Now kindly return to the subject of Java and Lisp and stop discussing me
or your opinions of me in public. It is not on-topic in either
comp.lang.lisp or comp.lang.java.programmer and in fact so far as I am
aware there is no alt.fan.seamus-macrae newsgroup, so it's off-topic
everywhere.

Let it drop.

I'm just asking you to not chop up what people wrote, when you answer
them. I think that I'm allowed to request that as part of the
standards for a "reasonable discussion".
(I'm actually not sure whether it's technically a read-macro, although
it does change the way the reader interprets the symbol, so I'm
guessing it's some form of read-macro)

With syntax like that, who needs enemies?


Not really. A statement separator is pretty obvious. Lisp just uses
spaces as separators, so the #: prefix (not used much of anywhere else)
remains mysterious.

Well it's not exactly the same. However, it is a bit of syntax, which
does get used in GENSYMs, which crop up all over the place when you're
doing macros, so it's an important bit of syntax.

The condition ? exp1 : exp2; syntax isn't as common as ; or . in Java,
but it's also worth being familiar with because it's a tidy bit of
syntax when it is used.

Compared to most other languages, Lisp has no syntax in the core
language, and just a handful of abbreviations (such as ' and #' and
the backquote syntax). However, that syntax is just as important as
any other feature of CL, for understanding code.


- Adlai

 

[Series Expansion]

Series, this is a brief attempt to explain to you how Lisp macros CAN
do what you say is impossible for a macro to do

Why spend a lot of time writing an elaborate work of fiction and
posting it where it is so certain to go unappreciated?

Firstly, a Lisp macro can run code, just like any function, which it
uses to produce its expansion code. Thus, the output of a Lisp macro
is not limited to just the characters you type in -- it can create
unique symbols, and thus avoid the variable capture/multiple
evaluation problems.

However, it can only compute functions of its arguments. It cannot,
from those alone, compute a variable name that will collide with none
from any larger enclosing scope unless there exists no larger
enclosing scope. This could only occur if it was, to use a colorful
phrase, "the macro that ate Manhattan".

[elaborate discussion of Lisp equivalent of "new" operator]
Irrelevant.

The macro creates however many new symbols it needs using gensym,
storing the reference to these symbols under various human-friendly
names. These names will never appear in the expansion code, however,
the macro will use them to insert references to the gensymmed symbols
into the expansion code.

These references must be variable names that are legal Lisp
identifiers, however, if the result of the expansion is to be
compilable Lisp code. The storage location of the object is
irrelevant. It is the collision of variable names that is of concern
here. When the compiler compiles the code containing the expanded
macro and its surroundings, the resolution of variable names will
still encounter the problems previously described.

It is as if you argued that if you took this Java code:

t = object1;
t = object2;

with the latter line expanded from a macro and changed that expansion
to:

t = new Object();

instead, that this would somehow cause that assignment to no longer
clobber the previous t = object1 assignment.

Yet the code has still (after expansion) got two assignments with the
same variable name on the left hand side. When the compiler then turns
it into bytecodes it will make the pointer for t point first to
object1 and then to the new (gensymmed) storage location, where
previously it would have pointed first to object1 and then to object2.
Of course, object2 was really "whatever the macro ends up assigning to
t", so, in effect, all that has been accomplished is to move object2
around in memory, and possibly to waste some memory.

That the new Object() address is unknown to any of the other code, and
cannot be discovered, is also true in the Java case and is also
irrelevant. It would matter if the problem we were concerned with was
aliasing:

x = object1;
t = object2; t.setFoo(true);

where we would not wish the setFoo(true) call to alter object1.
Ensuring that object2 is separate and unknown to the rest of the
program does indeed prevent such an unwanted side effect. But it does
not prevent the local variable being overwritten if the name is the
same. If the compiler sees t = object1; t = object2; it will resolve
both "t"s to the same stack position and the second assignment will
overwrite the first. There is no avoiding this unless the compiler
resolves the same name in the same scope to a pointer in an
inconsistent way, and that way lies madness.

If the macro wants to evaluate an arg only once but use the value more
than once, it stores the result from evaluating it into a gensymmed
symbol, and then simply uses that symbol again where it needs to.

The manner in which storage for the variable's referent is allocated
is irrelevant to the concern at issue here. The issue is that for the
result of expanding the macro to refer to the stored value at all, it
must do so using a name, and the macro cannot compute from its
arguments alone such a name that can be guaranteed not to collide with
any name in any enclosing scope.

This is the inescapable trap. No diversionary tactics such as trying
to change the subject to memory allocation from variable names is
going to do more than delay the inevitable, which is the realization
that your macros have unavoidable difficulties.

The peculiar thing is, these difficulties should be well known within
the Lisp community. There can be no logical gain in strenuously
denying that they exist when they provably do and their existence is a
matter of public record.

If you want to create a new variable to do stuff in the expansion
code, but you don't want it possible to "mess" with this from outside
the expansion code, you can use a gensym too. This is how, for
example, you can say (loop repeat 5 (do-stuff-with x y z)) -- the loop
macro would use a gensym to keep track of how many times it had
executed the loop.

That it allocates a new memory location to hold the loop counter is
hardly surprising, nor revolutionary, nor relevant. It is the variable
name used to refer to this memory location that is at issue, and if
that name happens to collide with one in an enclosing scope, there
will be trouble. That the loop counter won't overwrite something else
in memory is admirable, but the pointer TO the loop counter may still
end up doing so.

(I will refrain from commenting at length upon the inefficiency of
having indirection like this for a simple loop counter. It is
unavoidable in a system whose native integer type is a bignum, and
potentially represented either as a machine integer or as an array of
such or some other representation. Another tradeoff, among many.)

 

[Adlai]

[elaborate discussion of Lisp equivalent of "new" operator]

Irrelevant.

No, it's got all the relevance in the world. The way symbols work in
Lisp makes it possible to generate never-seen-before symbols. Also, a
symbol's printed representation is not it's entire representation --
perhaps this would be clearer if a symbol were printed as something
like
#<SYMBOL #:G321 @ 0x4f209ac42b>

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. This is not a 100% analogy, but it's like generating a
pointer to an empty reference, that can then be filled in. Also, due
to the concerns of garbage-collecting and symbolic programming, Lisp
always knows which symbol references are in use, so generating an
unused symbol is simple.

You have to understand this, to understand safe CL macros. Scheme
macros (which were mentioned a few times) work in a different way, but
they completely bar you from making "unsafe" behaviour -- CL, however,
lets you have the cake and eat it by giving you GENSYM. If you don't
understand GENSYM, then you won't understand much of what anybody says
about CL macros.


- Adlai

 

[Seamus MacRae]

Please don't split my sentances like that.

Then don't insult me.

Now, what would you want me to say, if after reading something you
said, I concluded that you weren't fully aware of the facts?

Nothing. Keep your negative opinions of others to yourself please.

Earlier in this discussion I said something that was just plain
incorrect (re: lists in Java). I was corrected, and I accepted that as
part of a discussion -- the part where you learn things you didn't
know before.

That was different: you were actually wrong.

I'm glad when somebody corrects me.

I expect that should vary depending on a few factors, including:
* Were you actually wrong? If not, then not so good.
* What tone accompanied this "correction"? If unpleasant, then not so
good.
* Was it done discreetly, or loudly in a public place? If the latter,
then not so good.
* Was the "correction" useful, mere pedantry, or outright wrong? If
the latter two, then not so good, especially if the last item.

Surely there has to be some way of doing so in any discussion where
participants hope to learn.

Is learning the objective here? The debate seems to contain five
identifiable components.

One is the original Lisp vs. Java debate. This appears to involve some
factual statements about macros, type-safety, and what-have-you, but to
ultimately be a showdown between two unprovable opinions. There is
little to learn since opinions are inherently subjective, and opinions
also tend to be entrenched. Especially once one side makes things
personal, as yours has done.

A second is the emacs vs. Eclipse and more generally text vs. GUI debate
which likewise appears to boil down to opinion rather than fact.

Third is the argument over how awful a person Seamus MacRae is. This is
clearly also opinion, and furthermore uncivilized debate and off-topic
in both newsgroups. There is certainly nothing new to be learned here.

Fourth is the argument over how awful a person Series Expansion is. This
is entirely analogous to item number three.

Last but not least has been some odd paranoid ravings by several people,
notably Arne and Lars, centered on some kind of conspiracy theory
involving myself, Series, and several named individuals all but one of
whom is absent from this thread (the remaining one only showed up AFTER
being badmouthed by Lars a time or two, for no reason apparent to me,
and evidently getting mad about this). Obviously there is little to
learn here unless one's field of study is abnormal psychology, in which
case Lars and Arne may make excellent case studies on the topic of
shared delusions.

The final three items on the list are quite unfortunate. It is worth
noting that the targets of the flamage seem to be exclusively on the
Java/Eclipse/GUI side of the first two items now. It seems a
meta-argument can be made for the Java/Eclipse/GUI side that they're
better behaved than their Lisp/emacs/text counterparts on average.

I wasn't criticising your statement about Java

Reminder time:

That's me, making statements about Java.

And that's you, clearly attacking my statements about Java.

Now please retract your lie above about not criticizing my statements
about Java.

I was criticising

Don't. I didn't come here to be criticized, I came here to explain why
Java is superior to Lisp.

It makes me sad that you think that.

If you wish me to think otherwise, then alter your behavior. What I
think about your motives is the result of inference based on the
available evidence, namely, what I've seen you doing and heard you
saying. If your behavior is leading me to believe the above (so far it
is), and you'd prefer I believe something different, then the way to
make that preferred state come about is to alter your behavior so that
different conclusions are drawn from it. Insulting me and then lying
about it is a very poor start however.

I'll admit it, some things that have been said in this thread have
made me laugh;

I've found little amusing except the "9th-dan black belt in usenet-fu"
remark found in a drive-by flame a while ago and a recent quip about xterms.

Yes, I've had
some less-genteel posts, but you can't judge somebody by the worst of
their behaviour; if you did that, everybody in this thread would be a
"drive-by flamer".

Actually, a drive-by flamer is, more or less by definition, posting one
or a handful of flames and then relurking. Most of the people flaming
here are also sticking around. Unfortunately.

Of course you deserve to be treated with respect

Then please start doing so.

however, I don't think it's disrespecting you to say that you [are
stupid]

Oh, really? I dispute that.

I wasn't saying "this guy doesn't know his shit"

Sure looked that way.

If anything displays a lack of respect, it's mincing somebody's words
like that.

They were insulting words. I don't feel a lot of respect for insults. So
I reduced it to a summary that conveys the gist.

I really do hope you read what I wrote before you replied
to it, because the sentiment expressed by your "remix" of what I said
is not at all like that of my original post.

Sure it is. It was, and remains, crystal clear. You think I don't
understand. You think I misinterpret. You also, especially
unfortunately, think your opinions of me are ironclad facts rather than
mere opinions.

The method-definition syntax equivalent to Java's (int foo, float bar)
is ((int foo) (float bar)). (btw, this is something that I had wrong
earlier in the thread, and somebody corrected me about it very
bluntly, but who cares? I was wrong)

Politeness does not count for you? It's at the "who cares" level of
importance? I suppose that would explain your own behavior.

If you look at that method definition, you'll see: ((transaction-
manager picture-library:jpeg-picture))
The outside parentheses are the entire argument list; the inner
parentheses denote one argument.

Then it doesn't make sense the way you interpreted it -- it then looks
like one has named a transaction-manager typed variable jpeg-picture. It
also has other problems, such as a scope on the parameter name. How can
a parameter name be scoped? It's automatically a local variable of the
method. Last but not least though, how can that variable have a type at
all? Variables don't have types in Lisp. Data sometimes seems to, but
not variables.

I'm just asking you

I said, let it drop.

I think that I'm allowed to request that as part of the
standards for a "reasonable discussion".

You first.

Well it's not exactly the same.

Told you.

The condition ? exp1 : exp2; syntax isn't as common as ; or . in Java,
but it's also worth being familiar with because it's a tidy bit of
syntax when it is used.

Actually it originated with C, and is in C++ as well. And it's maybe not
very self explanatory, but it's not encountered within the first five
minutes of running into C code, either. That #: shit, on the other hand,
is on just about every import statement.

Compared to most other languages, Lisp has no syntax in the core
language, and just a handful of abbreviations (such as ' and #' and
the backquote syntax).

I know this. But it was #: that was at issue, not #'.

However, that syntax is just as important as
any other feature of CL, for understanding code.

I expect it would be. Too bad it appears to ultimately be hairier than
Java's. Java's ?: is tame compared to #:. It's simple to explain, the
expression evaluates to the second argument if the first is true, else
the third argument. No rocket science involving "read macro" and other
compiler-theory type stuff needed. Java doesn't force you to get your
hands that dirty unless you're implementing parts of a Java toolchain,
monkeying with bytecode, or tinkering with ClassLoader.

 

[Series Expansion]

On May 19, 5:47 am, Series Expansion <[email protected]> wrote:

[an attribution is missing here]

I am not Einstein, yet in another post I showed you a macro that does
neither of the above.

You did not. You showed me that a repeat macro allocates memory for
its loop counter guaranteed not to already be in use. Java's new
operator also allocates memory that is not already in use. So does C+
+'s, and C's malloc() function. There's nothing fancy there. Nor
anything relevant to the issue at hand, which involved variable name
resolution at compile time, not storage allocation at run time.

Not really. See my other post.

Yes really. Your other post utterly failed to suggest anything other
than the trivial fact that at least the macro could avoid accidentally
clobbering already-used memory when dynamically allocating fresh
memory for some data-structure.

Actually intentional variable capture, or introduction of local
functions/macros which is equivalent, is a valuable technique

All I've seen demonstrated with it so far was the cute "it trick",
which amuses for a few seconds and accomplishes little else.

It may not be just more of the proverbial bathwater, but it does not
appear to be the proverbial baby, either.

A higher-order function also does not allow other common uses of
macros like introducing new syntax

It does, or rather, it allows introducing new control structures,
which suffices.

executing code at compile time

This is a decision better made by the compiler and optimizer, not by
the programmer. Inlining is capable of causing otherwise-avoidable
cache misses, and bloats up the code.

Yes, they have.

Then that's the end of it. Thank you.

The fallacy here

There is no fallacy here.

is that this fact DOES NOT imply variable capture, multiple evaluation,
introduction of clashing local variables, or use of global variables.

It does not guarantee them for all macros, no, but it does guarantee
them for some, by the logic I'd previously outlined.

Suppose an argument is to be used twice. To avoid multiple evaluation,
the result of evaluating it must be stored somewhere. Regardless of
where the storage for that value is allocated, the code that replaces
the macro call must refer to it. To do so it must use a name. If that
creates a global variable, then a bad thing happens. If it does not,
then that name must name a local variable. It also must be a legal
identifier. It follows that another variable may exist in a nesting
scope that possesses the same name, which will therefore either be
captured or be hidden by the macro variable, and a bad thing happens.

That the Lisp macro can compute any function of its arguments to use
as the replacement code does not let you escape the trap. The names of
all existing variables in all enclosing scope cannot be computed from
the arguments alone, so unless the macro is the entire computer
program, it is possible for it to pick a variable name that is already
in use in an enclosing scope.

In Lisp symbols are first-class
objects and there are ways to create a symbol and locally bind it
(introducing a local variable) having GUARANTEED that the generated
symbol is UNIQUE

This is all entirely irrelevant. The issue is that the local variable
you bind may share its name with another, and rebinding it will
therefore rebind the other.

You are focusing on the equivalent of "if I have t = new Foo(); and u
= new Foo(); and call t.setQuux(42); and u.setQuux(17); it won't
change the 42 in the Foo pointed to by t to 17", when the real issue
at hand is "if I have t = new Foo(); and t = new Foo(); then call
t.setQuux(42); and t.setQuux(17); it will change the 42 in the Foo
pointed to by t to 17". It may be true that the first Foo allocated
with new Foo(); still does not get its quux clobbered, but it is also
irrelevant -- the local variable t has ended up rebound, pointing to
the wrong Foo object, and this will cause logic errors in subsequent
program execution.

This is what you fail to understand.

I fail at nothing. As demonstrated, I understand perfectly, whereas
you seem to be confused between issues of name resolution (at compile
time!) and issues of storage allocation/aliasing (at run time!).

 

[Series Expansion]

You are treading in trollish waters, "Frank".

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew".

 

[Series Expansion]

If you want to do something, then do it.  If you don't want it, then
just don't do it.  That's what we call not being dumb.
Einstein could not write certain macros to simultaneously avoid all
four of multiple evaluation,variablecapture,variablehiding, and
use of global variables, independently of the names of the local
variables in scope at the call site.

[enormous volumes of unused quoted material discarded]
Yes, they have. The fallacy here is ... This is what
you fail to understand.

Plonk this thread.

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, "Lew" and Alessio.

I have explained in a direct followup to Alessio why there is no
failure on my part and no fallacy in my reasoning.

 

[Series Expansion]

I disagree being in "trollish waters".

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Frank and "Lew".

Besides: This is Usenet. So, in the end, there's just our own countries'
laws that mark a border we can't cross - and this is true for all of
us. So, as long as our two friends are not breaking any laws in their
country, we of course simply have to be patient and have to wait until
they are loosing interest.

This implies my presence here is undesirable, and thus yet another
personal attack. Have you not yet grasped that such attacks do not
advance your goals in any discernible manner?

Openly discussing a desire to get rid of me is rude, unwise, and
potentially illegal, if interpreted as implying a threat.

 

[Series Expansion]

Nope.  Just filter them out, and they don't exist any more.

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, Tamas and Frank.

I do not need "filtering out" and I resent the implication that I do.

That's what I did with Lew too when he started spitting out one-liner
posts.

Lew posted nothing of value to this thread; filtering him out is quite
rational, unlike, say, filtering me out.

 

[Series Expansion]

Series, did you see my post explaining gensyms?

Yes. It failed to prove anything except that Lisp macros could
allocate data that would not collide in memory with preexisting data.
This was irrelevant. The issue is variable name resolution to
referents, at compile time, not whether the referents themselves
collide in main memory at runtime.

You focused on:

t = object1;
u = object1;

being avoided in favor of

t = object1;
u = object2;

The thing that poses a problem is instead

t = object1;
t = object2;

in which two distinct objects, with distinct memory storage, are
created, but a local variable that should remain referring to the
first ends up referring to the second.

By the way, Series, I'm under legal drinking age.

As I suspected.

If I can make a clear explanation, does my age matter?

A clear explanation of something unrelated to the problem actually
under discussion is of little value.

Or, for that matter, if I just rant and rave and ignore what people
say -- does my age matter?

Emulating "Lew" would not be a recommended course of action, Adlai. I
suggest you emulate someone else instead, perhaps me.

Those are rhetorical questions. Just please read the post about using
GENSYM in Lisp macros.

I already have.

 

[Series Expansion]

Clearly he didn't.
Incorrect.

He is still reading posts from 2 days ago now, and
you have just written yours. The last post he replied is from 1pm two
days ago, and he is replying all of them in order, even the flammatory
pointless one-liners. It will take him at least a week until he
finally reaches your post.

Also incorrect. As can be seen from the post headers of his post and
this post I am currently writing, it took less than half that.

And even when he reads it, I believe he
will give you more excuses like always (What about non-moderate users,
will they know how to do this? What about Lisp data types? Namespace?
Classpaths? Bla bla bla bla...).

That, too, was incorrect. Instead, I discovered Adlai's post to be
about macros being able to allocate storage away from existing
objects, hardly a revolutionary feature. A hypothetical macro
preprocessor for Java could do this, by having the macro expand to
code containing the "new" keyword. What neither could do is devise a
local variable name guaranteed not to be in use in any enclosing
scope, which the compiler would subsequently be guaranteed to resolve
to a unique stack offset.

He will drive you nuts, he will make you explain to him every single
detail about Common Lisp and Emacs while still refusing to learn

These tiresome personal attacks do not constitute rational arguments
in favor of either Lisp or Java, nor in favor of either emacs or
Eclipse, gugamilare.

he clearly didn't understand any single of those yet.
Incorrect.

Whenever he sees that he is wrong about something

That has not happened thus far in this thread, so you have no data
from which you could draw any inferences about what my behavior would
be in the event of such an unlikely occurrence.

excuse on something else he clearly don't have a clue about

Personal attack.

he won't accept a simple "Didn't you realize you don't have enough

Personal attack.

he will say that you are making "personal attacks".

So long as you continue to mistake statements of unflattering personal
opinions about me for valid arguments against Java or for Lisp, I will
continue to point out that they are not.

Not to mention the possibility that he
already knows about the language and that he is wasting our time on
purpose (as Lew suggested).

Further accusations and personal attacks, unsubstantiated, as always,
by any evidence, and irrelevant, as always, to the issue of Lisp macro
behavior.

I'm sorry if I am insisting on this subject, but just let it go. It
doesn't matter anyway. If he doesn't like Lisp it's his problem.

The suggestion that I dislike Lisp is in error. That I criticize it
indicates no such thing. I also have been known to criticize Java, but
I do not dislike Java; rather, I wish to see it improved.

The suggestion that dislike of Lisp constitutes a problem is a more
grievous error. This type of error has led, throughout history, to
many of the worst instances of war, repression, and persecution on
record. Freedom of opinion is an important right in a just and
civilized society.

 

[Paul Foley]

I never said that it was "bad" that CLOS could be hacked up
independently. I said that it was incompatible with type checking and
some kinds of compiler optimizations that would be possible if the
compiler could make stronger assumptions about the object system the
way Java's can.

But what makes you think real Lisp compilers can't do those things?
CLOS is part of Common Lisp.