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

[Series Expansion]

You cut off what Joost was saying in the middle of a sentance.

Because he was obviously flying off onto an unproductive and pointless
tangent that I had neither the time nor the inclination to pursue.

that's more rude than ...

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

Please confine your remarks to the subjects of Lisp and Java, and keep
your negative opinions of me to yourself. Publishing the latter can
serve no constructive purpose.

No, you made another assumption -- it is as follows:

It is possible for the compiler to generate code referring to a symbol
named by code given to the compiler.

This follows logically from the fact that it is possible for the
compiler to generate arbitrary code, which in turn follows from Turing-
completeness of the language.

The rest of your post was incoherent, so I see little point in either
quoting or further commenting upon it.

 

[Paul Foley]

(a) would require that the integer can be proved to be, and remain,
small by static analysis. And then Java's compiler could do the same,

Yes. So?

in principle, with BigInteger, and you have again failed to prove Lisp
intrinsically superior to Java.

Since I'm not /trying/ to prove Lisp is intrinsically superior to
Java, that's no great shock.

[Of course, "Java's compiler could do the same, in principle" is not
the same actually /doing/ it]

(b) would of course require that Lisp not by dynamically typed.

You mean (b) would require the option to add type declarations.
And guess what: you can do that in Lisp!

 

[Series Expansion]

This is what you get for insisting that names are the same as the
thing they name.

I have done nothing of the sort.

#:G622 is not interned, so another occurrence of #:G622 is a
completely different symbol that has the same name.

That has an equally useless consequence: if the macro generates an
assignment of an argument's evaluation to #:G622, followed by a
function call using #:G622 as a parameter, the function call won't
receive the result of the argument's evaluation because its parameter
was a different #:G622.

The only way around it is to maintain some kind of pointer to the
first #:G622, but then you need someplace to store that pointer and a
name for THAT. It's an infinite regress that cannot solve the problem
posed.

If you create a variable with the name #:G622 in the
calling scope, that will be an entirely different variable than the
one in the macro, so there's no problem.

There's a different problem, rather than no problem. The macro output
itself won't be able to refer to the same #:G622 twice. Except by
using some non-#repended name to refer, directly or indirectly, to
it, and then that name becomes the potential source of a collision.

Of course it isn't.  Macros can alter variables (for state in the
current image) and read and write files (for state that outlasts the
image), just like any other function.

It was impossible within the constraints of solving the posed problem,
which included "no global variables".

Furthermore, macros cannot alter variables at run-time, and if they
can alter files on disk, this seems useless and dangerous. Perhaps you
meant the code that is output by the macro evaluation, and which later
is compiled and run as part of the program, rather than the macro's
own body? The code generated by the macro can obviously alter run-time
state and disk files, but for the macro's various expansion-instances
to maintain shared, persistent state in this manner would violate the
no-global-variables constraint.

Except that, you know, you can't get the name of that variable.

See above. If that were completely true, the variable would be
useless, since you could not both store into it and then subsequently
retrieve from it. So there must be a way to refer to it repeatedly,
but whatever that mechanism is, it will recreate the original problem
of variable capture, since the context of the macro invocation, or one
of the macro's own arguments, could contain, by chance, a construct
that likewise refers to it.

Put more simply, if the macro's expansion can only refer to something
once, then it cannot be useful for avoiding multiple evaluation. If,
on the other hand, the macro's expansion can refer to a thing
repeatedly, there must be some particular piece of code that, within
some lexical scope, has the effect of referring to that same thing at
each place in that scope where that piece of code occurs. It follows
that that same piece of code, appearing elsewhere in the call site's
context, can end up having that same effect there, outside of the
macro's expansion, and then capture has occurred. Furthermore,
although the macro can compute that piece of code in some more complex
way than by its being a fixed, literal string in the source code, it
can only compute functions of its arguments, and therefore cannot
determine a "safe" such piece of code in full generality since it
cannot know of usages outside the macro invocation's arguments but
inside the immediately-enclosing scope.

 

[Seamus MacRae]

Yes. So?

I was getting to that:

Since I'm not /trying/ to prove Lisp is intrinsically superior to
Java, that's no great shock.

This entire thread has largely been your efforts to prove Lisp superior
to Java. If you have now given up on that goal, why are you still
posting to it?

You mean (b) would require

that Lisp not be dynamically typed.

 

[Jerry Gerrone]

Since it is normal human nature, it would be unless you were from Pluto
or something.

Arne referred to your [insult deleted]. He is familiar with that from
previous encounters with your other aliases (Twisted, Jerry Gerrone,
etc, etc, [implied insult deleted]). Your behaviour is [implied insult
deleted].

No. Seamus is not me and none of the nasty things that you have said
or implied about me are at all true.

 

[Paul Foley]

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.

That would be correct.

This completely
defeats the purpose of even having a variable name, which requires
that it can be referred to multiple times.

Except that Lisp source code is /structure/, not /text/. If each
occurrence of #:x is the exact same symbol (which is possible because
the source is NOT TEXT), then it's the same variable each time.
Problem solved.

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

(second (third new-code)) => #:x
(second (fourth new-code)) => #:x

(eq (second (third new-code)) (second (fourth new-code))) => T

[i.e., they're the same variable], but

(eq (second (third new-code)) '#:x) => NIL

[i.e., it's not the same as any other symbol named #:x]

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. Because macros are not just stupid code templates; they're
functions. 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.

(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?

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.

 

[Paul Foley]

It was impossible within the constraints of solving the posed problem,
which included "no global variables".

Furthermore, macros cannot alter variables at run-time,

Of course they can.

and if they
can alter files on disk, this seems useless and dangerous.

Just as useless and dangerous as any other function being able to
alter files on disk.

Perhaps you
meant the code that is output by the macro evaluation, and which later
is compiled and run as part of the program, rather than the macro's
own body? The code generated by the macro can obviously alter run-time
state and disk files, but for the macro's various expansion-instances
to maintain shared, persistent state in this manner would violate the
no-global-variables constraint.

What "no-global-variables constraint"? If you /want/ the macro to
maintain shared, persistent state, a global variable is a perfectly
good way to do it!

Put more simply, if the macro's expansion can only refer to something
once, then it cannot be useful for avoiding multiple evaluation. If,
on the other hand, the macro's expansion can refer to a thing
repeatedly, there must be some particular piece of code that, within
some lexical scope, has the effect of referring to that same thing at
each place in that scope where that piece of code occurs. It follows
that that same piece of code, appearing elsewhere in the call site's
context, can end up having that same effect there, outside of the

No, that doesn't follow at all. Lisp code is not text.

 

[Lars Enderin]

Lars Enderin wrote:

Not possible. If it had been designed to do so, then it would follow
that a) it did not predate X, b) it could not be used remotely over a
terminal, and c) it used the X clipboard. However, a) it does predate X,
b) it can be used remotely over a terminal, and c) it has its own
internal clipboard. On the other hand, if it had not been designed to do
so, it could not do so now without being completely rewritten, and the
result of such a rewrite would not be emacs.

Everybody but you describes the current (GNU) Emacs. I don't know why
you are fixated on an ancient version. Of course it's completely
rewritten since RMS's first version in 1976, so what?
Emacs is completely integrated in whatever windowing system it runs
under. Its clipboard works fine with other applications.

 

[Tim X]

Fascinating that someone is so dumb [rest deleted]

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

Hand-editing UTF-8 (where it includes some double-wide characters) in
an ASCII editor is not a recommended way to edit text.

Graphics hardware, and software that acknowledges its existence, is
needed in order to display the full Unicode character set at one time.

Series, you have said on numerous occasions that your here to debate
matters and are not interested in personal attacks. Thats all good and I
hope you can accept the following as an attempt to correct your
misunderstanding [rest of personal attack, and rest of post, deleted
unread]

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

Yeh, you keep saying that whenever someone points out your errors.
Can't help but notice you cut my text just before the bit where I said
this was *not* a personal attack but rather an attempt to correct your
misunderstanding regarding emacs. I guess leaving it in would have made
your claim of a personal attack even weaker.

Pointing out that you are in error regarding your statements about
something like Emacs is NOT a personal attack. Furthermore, anyone who
wants to verify what I wrote (and others) can easily do so by going to
the Emacs website or by checking out the Emacs wiki or any of a number
of blogs that deal with Emacs. In fact, I wold recommend anyone who is
at all in doubt regarding the facts do so and after having done so,
consider which of the posters to the thread has credibility and which
does not.

It is of little importance to anyone if you wish to continue believing
in Santa, fairies at the bottom of the garden and that emacs is only
capable of ascii editing and has no support for graphics or modern
windowing environments. It may even be true that there is bliss in
ignorance, in which case, you must be a very happy and blissful person.

Tim

 

[Alessio Stalla]

For this, we have only your word, versus the overwhelming common-sense
evidence against.

Oh, of course you're right. This is actually a shot of NetBeans with
the fonts and colors changed, the text pane fully expanded, a fake
menu that explicitly mentions Emacs and a superimposed Emacs-like mode
line and minibuffer. That's the only possible rational explanation...
that doesn't go against your religious dogma that Emacs has no GUI.

Alessio

 

[Alessio Stalla]

Yeah, congrats!

You misunderstand me. I meant a function that would be called once,
with an entire source file as argument, and output an entire new
source file, something distinct from macros, which preprocess a source
file to a temporary file or within main memory prior to its
compilation.

Macros don't process files! They process Lisp code, and Lisp code IS
NOT text in any way, it's a tree-like structure made of Lisp objects
(symbols, lists, numbers, strings, ...).

 

[Series Expansion]

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.

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.

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.

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.

 

[Series Expansion]

Of course they can.

No, they cannot. The code into which a macro invocation expanded can
do so, but that is distinct from the macro itself, which is executed
at compile time.

Just as useless and dangerous as any other function being able to
alter files on disk.

We are discussing a function that executes at compile time -- not the
same thing.

What "no-global-variables constraint"?  If you /want/ the macro to
maintain shared, persistent state, a global variable is a perfectly
good way to do it!

The problem is that it was your proposed scheme for avoiding all four
of multiple evaluation, variable capture, variable hiding, and global
variable use that that ended up involving, perhaps in disguise, global
variables.

No, that doesn't follow at all.

Yes, it does.

 Lisp code is not text.

If that is true then a) it does not alter the above, where the term
"piece of code" is used agnostically as to how precisely it is
constructed -- it could be a machine-meaningful jpeg image and what I
said above would remain true -- and meanwhile b) you are in trouble on
a whole new front, as it becomes unsafe to manipulate Lisp code in
normal text editors and with tools like sed and awk, tools that are
commonplace in software developers' tool-kits. This was elaborated
upon in a prior post of mine.

 

[Series Expansion]

Series, you have said on numerous occasions that your here to debate
matters and are not interested in personal attacks. Thats all good and I
hope you can accept the following as an attempt to correct your
misunderstanding [rest of personal attack, and rest of post, deleted
unread]

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

Yeh, you keep saying that whenever someone points out your errors.

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

Can't help but notice you cut my text just before the bit where I said
this was *not* a personal attack

That was a lie. I have little interest in reading lies. If I ever do
develop an inexplicable urge to read lies, I will visit whitehouse.gov
or a similar politician-run site.

[remaining personal attacks and other nonsense deleted unread]

 

[Series Expansion]

Oh, of course you're right.

 

[Series Expansion]

Macros don't process files! They process Lisp code,

which resides in files, if you know what's good for you and don't want
to have to type in the whole program again every time the power fails,
Windows crashes, or Microsoft releases another update.

Lisp code IS NOT text in any way, it's a tree-like structure made of
Lisp objects (symbols, lists, numbers, strings, ...).

Even were this true, it would still need to resolve in files to
survive across sessions. Furthermore, if that were true, there would
be a serious violation of a fundamental standard of language design,
that program source code be susceptible of manipulation as text using
text-oriented tools that lack any particular awareness of the language
in question. This is elaborated upon in another recent post of mine.

 

[Seamus MacRae]

Everybody but you describes the current (GNU) Emacs.

Whereas I, above, described a generic application in an agnostic manner.
"It" could be any software for which it was true that a) it predated X,
b) it had been observed to be used remotely over a terminal, and c) it
had its own internal clipboard, and the above would still hold.

Of course it's completely rewritten since RMS's first version in 1976,
so what?

If this is true, then what you are describing is not emacs. (Are you
also forgetting that GOSMACS was the first Unix emacs, and is definitely
not named for RMS?)

 

[Alessio Stalla]

which resides in files,

No, its printed representation resides in files. Actual Lisp code is
not textual, and it usually resides in memory (though of course it
could be dumped to files, but it probably wouldn't be readable by
humans). Lisp code can be thought as an abstract syntax tree closely
mirroring its printed representation.

if you know what's good for you and don't want
to have to type in the whole program again every time the power fails,
Windows crashes, or Microsoft releases another update.


Even were this true,

as it is,

it would still need to resolve in files to
survive across sessions.

No, you just need a way to automatically recreate the code across
sessions. The most common way is that the programmer edits text
representing Lisp code, and then feeds this text to the Lisp
implementation, that "reads" (parses) it and produces the actual code.
The text itself of course gets saved in files.

Furthermore, if that were true, there would
be a serious violation of a fundamental standard of language design,
that program source code be susceptible of manipulation as text using
text-oriented tools that lack any particular awareness of the language
in question. This is elaborated upon in another recent post of mine.

Lisp source code instead is meant to be easily manipulated by a
programmer using Lisp itself. This is the basis for macros. The fact
humans deal to the code in its printed form is only a convenience for
them. You could edit Lisp code without ever modifying text, for
example by using a GUI application that shows the code as a tree.
However, since text is much more versatile, I believe such a GUI will
never be the preferred way of writing Lisp code.

 

[Lars Enderin]

Whereas I, above, described a generic application in an agnostic manner.
"It" could be any software for which it was true that a) it predated X,
b) it had been observed to be used remotely over a terminal, and c) it
had its own internal clipboard, and the above would still hold.

Irrelevant. The current emacs is GNU Emacs or XEmacs. The rest is history.

If this is true, then what you are describing is not emacs. (Are you
also forgetting that GOSMACS was the first Unix emacs, and is definitely
not named for RMS?)

Emacs has been upgraded since the 70's. It's still called emacs.

 

[Paul Foley]

Problem not solved, as I explained further on in my post.

Yes; all the thousands of people who have been /doing/ this every day
for several decades are wrong. You're right.

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. 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.

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.

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, so it doesn't.

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.

[Your use of "implying" indicates that you haven't already been told
this several times, which I know you have - at least twice by me]

(defmacro see-what-I-mean (&body whatever)
(let ((safe-variable (gensym)))
`(let ((,safe-variable some-value))
,@whatever
func(,safe-variable)))

You mean (func ,safe-variable) -- and yes, of course you can do that,
but that's INSIDE the macro definition, where it's what you want. You
can't access safe-variable from outside the macro definition.

(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, but if you fix the syntax it /will/ cause FUNC to
be invoked on some-value because the #:G1959s /are/ the same.

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!