On May 19, 5:47 am, Series Expansion <sere...@gmail.com> wrote:
[snip]
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.
I am not Einstein, yet in another post I showed you a macro that does
neither of the above.
The use of a long and obscure name on a macro-internal localvariable,
combined with nesting its use within an enclosing local scope within
the macro, affords the maximum mitigation; multiple evaluation,variablecapture, and global variables are all completely avoided butvariablehiding, though rendered unlikely, remains possible.
That is the absolute best that can be done.
Not really. See my other post.
A function with closure-valued arguments can do everything you've done
with macros, so far, except for the "it trick", and additionally can
easily be made to avoid all four of multiple evaluation,variablecapture,variablehiding, and global variables simultaneously and with
100% reliability.Einsteinnot required; a reasonably competent
Smalltalk programmer in particular can do it.
Which means the only things Lisp macros apparently get you are:
a) Compile time expansion, i.e. basically automatic inlining, and an
optimizing compiler can inline a function that takes closures; and
b) Macros that deliberately usevariablecapture.
The latter, so far, seem to be clever tricks that slightly simplify
some sorts of code, but nothing crucial; the "it trick" in particular
amounts to syntactic sugar.
Actually intentional variable capture, or introduction of local
functions/macros which is equivalent, is a valuable technique: it
allows, among other things, macros which establish a dynamic context
by locally rebinding variables; for example, the macro with-standard-
io-syntax that is built-in in the CL standard.
A higher-order function also does not allow other common uses of
macros like introducing new syntax, executing code at compile time,
etc.
Closure-taking functions get you:
a) Optional inlining instead of mandatory; not inlining in some cases
might reduce cache misses; and
b) The ability for the closure itself, not just the variables used in
it, to vary at run-time; and
c) The ability to simultaneously reliably avoid all four of multiple
evaluation,variablecapture,variablehiding, and global
variables.
Right now closure-taking functions seem to be coming out ahead.
Why would you do something that you wouldn't want?
Because you couldn't avoid it?
Are you dumb?
No.
[large volume of Lisp code deleted]
None of this is relevant to the issues described above. Those issues
are inherent in the very definition of a macro as lexically replacing
its call and having its actual parameters lexically replace its formal
parameters, as has been proven repeatedly.
This again causes an encapsulation failure: merely changing the names
of variables internally used in the macro, without altering anything
else, may cause it to behave very differently at some call sites.
Yes. So why would you do that if that's not what you want to do?
Because the only alternatives, sometimes, are multiple evaluation of
arguments that may have side effects and use of global variables.
And all of the above is extrapolated from the definition of "macro"
without reference to any particular language, implementation, or
anything.
Oh! How dumb!
No, it is not.
We were discussing Lisp macros
Not relevant.
These issues are inherent in the very definition of a macro as
lexically replacing its call and having its actual parameters
lexically replace its formal parameters, as has been proven
repeatedly.
If Lisp macros have the property of lexically replacing their calls
and having their actual parameters lexically replace their formal
parameters, then Lisp macros inevitably succumb to the tradeoffs
described above (and, repeatedly, in previous posts).
If Lisp macros lack the property of lexically replacing their calls
and having their actual parameters lexically replace their formal
parameters, then Lisp macros are not actually macros at all and you,
and your associates, have perpetrated a colossal hoax here and should
be ashamed of yourselves.
Dog, Hot-Dog?
Non-sequitur. Unless this seemingly irrelevant sentence fragment is
meant to imply that Lisp macros are not truly macros, in which case
you and your fellow hoaxers have a great deal to apologize for,
starting with a massive trolling of comp.lang.java.programmer.
It is advisable that this be cleared up once and for all, so I will
directly ask:
Do Lisp macros possess the property of lexically replacing their calls
and having their actual parameters lexically replace their formal
parameters?
Yes or no.
The only way for the above not to happen is for the "macro"
involved to violate in some manner the generic, language-independent
definition of a macro, i.e. for it not to be a macro at all but rather
something else, such as a plain-Jane function call.
Ok.
Assembler macros where invented in the 1950's.
Irrelevant.
Lisp macros were invented in the early 1960's.
Irrelevant.
C macros where invented in the 1970's.
Irrelevant.
All the above can be done as well in good macro assemblers, this has
already been mentionned in this thread.
Irrelevant.
We have priority on the terminology here.
Non-sequitur.
Do Lisp macros possess the property of lexically replacing their calls
and having their actual parameters lexically replace their formal
parameters?
Yes or no.
Yes, they have. The fallacy here is that this fact DOES NOT imply
variable capture, multiple evaluation, introduction of clashing local
variables, or use of global variables. 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 and thus it can not clash with anything. This is what
you fail to understand.