Kenny Tilton wrote:
> scav50 wrote:
>> ...the impotence of lisp to handle its own defmacro problems.
>
> That's not a problem, that's a feature. I have had great success with
> macros that captured variables deliberately.
>
and i suppose you do not debug your software, you defeature it? bums
like you think they are successful if 51% of their users do not find
any bugs in 51% of their function and macro definitions. the problem
with defmacro is that bugs are frequent, yet they manifest themselves
when you least expect it, that's why testing against these kinds of
bugs is often useless. but that wasn't the point of my argument. the
point, which was obviously beyond you, was that if new languages are
easily created on lisp, as is often alleged, then surely lisp ought to
be able to fix its own problems with defmacro variable capture and
inadvertent multiple evaluations, so that these and other pitfalls of
programming on lisp could be avoided by requiring variable capture,
for example, to be *explicit*. explicitness could look something like
this:
(safe-defmacro aif (predicate &rest body)
`(capture ((it ,predicate)) (if it ,@body)))
some of the brain-dead lisp aficiados might argue: "sure, i will just
define a new macro
(defmacro safe-defmacro (name args &rest body)
"safe version of defmacro"
;;
;; definition
;;
)
have the `definition' actually analize `body' instead of the usual
splicing, insert the necessary calls to `gensym' and commas."
BULLSHIT, i says. such a `definition' is possible in theory (due to
the openness of the language: accessibility of the symbol table, etc)
but it would have to be about as huge as the compiler itself to work
CORRECTLY. why? - the short answer to that is "because lisp is a
poorly designed piece of shit".
at least java, c++ and friends are usually humble and realistic in
their claims. btw, posting critiques of lisp to just a lisp newsgroup
is like asking the police department to investigate itself - nothing
good can come out of it. redirected replies will be ignored. i noticed
that egocentric asswipes like lynbech add "followup-to: poster" to
their messages so they can "have the last word".
p.s. hey vladimir, go hatch some more little lenins if you can't add
anything of value to the discussion.
······@yahoo.com (scav50) wrote:
> ....but that wasn't the point of my argument. the
> point, which was obviously beyond you, was that if new languages are
> easily created on lisp, as is often alleged, then surely lisp ought to
> be able to fix its own problems with defmacro variable capture and
> inadvertent multiple evaluations, so that these and other pitfalls of
> programming on lisp could be avoided by requiring variable capture,
> for example, to be *explicit*....
Been there, done that:
William D Clinger and Jonathan Rees. Macros that work. In
Proceedings of the 1991 ACM Conference on Principles of Programming
Languages, pages 155-162. Online at
ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/prop/macros_that_work.tex.gz
Eugene Kohlbecker did it first, of course.
> BULLSHIT, i says. such a `definition' is possible in theory (due to
> the openness of the language: accessibility of the symbol table, etc)
Tens of thousands of programmers are using it in practice.
> but it would have to be about as huge as the compiler itself to work
> CORRECTLY.
Nope. I have written both hygienic macro expanders and compilers.
The macro expanders are considerably smaller.
> why? - the short answer to that is "because lisp is a
> poorly designed piece of shit".
The more obvious explanation is that you don't know what you're
flaming about.
Will
······@qnci.net (William D Clinger) wrote in message news:<····························@posting.google.com>...
> ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/prop/macros_that_work.tex.gz
>
will, will, will...
first of all, let me clarify a few things after you (or for you):
scheme macros aren't macros. but i don't even want to discuss them,
that's like beating an animal that was run over by a truck, drowned,
electrocuted, cooked and then eaten. but if you insist on calling
those .... hmmm .... constructs "macros", do us all a big favor and
make it clear.
you used some ingenious quoting to make it look like your shameless
self-promoting plug was remotely relevant here. (or are you being
genuinely obtuse? i hope not) i wasn't talking about no goddamn toy
language or a language subset. i was talking about defining safe
defmacro replacement *in* common lisp (the issue being discussed is
the [lack of] power of lisp macros, not some other compiler written
for some other sublanguage).
to formalize the requirements, perhaps (i thought these were clear to
any human being, but you proved me wrong):
a) pick any standard lisp (cltl2, ansi - i don't care)
b) define "safe-defmacro" IN IT
c) make sure it's *completely* backwards compatible with all of the
original defmacro functionality (sans variable capture and multiple
evals, of course) - i don't want to hear any 'proof-of-concept'
blabbering!
d) make sure "safe-defmacro" is, in fact, safe - among other things,
all of the verbatim textbook examples of "programmer errors" involving
variable capture and multiple evals should work without modifications,
but correctly.
e) provide mechanisms for explicit intensional variable capture
f) show that your definition of "safe-defmacro" is substantially
smaller than the source (not using 'eval') for a whole lisp compiler
would have to be. - this was a crucial point
your escapades so far have been irrelevant at best
p.s. again, there are others who offer me well-known clumsy
workarounds to be used with defmacro. to them i say: don't pee on my
leg and tell me it's raining. i'm aware of the workarounds, they suck,
but it's not the issue - the issue is the myth of the programmable
programming language. lisp can not possibly be called that, given its
impotence in this regard.
I suspect that following up tp you is a bad idea, but what the heck,
it's just usenet...
······@yahoo.com (scav50) writes:
> ······@qnci.net (William D Clinger) wrote:
> > ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/prop/macros_that_work.tex.gz
> will, will, will...
>
> first of all, let me clarify a few things after you (or for you):
> scheme macros aren't macros.
We think they are. Of course there are at least three (possibly four)
flavors of macros that could contextually satisfy the definition of
`scheme macros'.
> but i don't even want to discuss them,
sounds like you don't want to discuss much, actually.
> to formalize the requirements, perhaps (i thought these were clear to
> any human being, but you proved me wrong):
>
> a) pick any standard lisp (cltl2, ansi - i don't care)
I suppose you are in the Naggum-esque `Scheme is not a Lisp' camp? Well
the principles embodied in Schee hygienic macro systems still apply...
> b) define "safe-defmacro" IN IT
> c) make sure it's *completely* backwards compatible with all of the
> original defmacro functionality (sans variable capture and multiple
> evals, of course) - i don't want to hear any 'proof-of-concept'
> blabbering!
> d) make sure "safe-defmacro" is, in fact, safe...
> e) provide mechanisms for explicit intensional variable capture
> f) show that your definition of "safe-defmacro" is substantially
> smaller than the source ...
Have you looked at syntax-case (as opposed to syntax-rules)? I believe
that it would pretty much satisfy your requirements. W/rt requirement
F, implementations of eval are typically *much* smaller than an
entire compiler. so I find you restriction there to be somewhat
irrational. If you want a Turing-complete language, you've got to have
an implementation of it somewhere.
david rush
--
Censorship may be useful for preservation of morality, but can never
be so for its restoration.
-- Jean-Jacques Rousseau
"scav50" <······@yahoo.com> wrote in message
·································@posting.google.com...
> ······@qnci.net (William D Clinger) wrote in message
news:<····························@posting.google.com>...
>
{about chaning Lisp}
Could you change C++ for me? Make it so if I misuse a pointer, or jump
table--the compiler kindly points out where I made a mistake instead of
crashing because of a invalid memory reference.
Or if I mismanage memory--it will GC for me instead of leaking memory. :)
Or if I reference an array out of bounds it extends the array for me so I do
not trash memory.
Could you also make the compiler not so strict about types--so if I pass a
long int to a function that requires an int it will still work-or, if the
function returns a long int instead of an int it will still return.
Could you also fix C++/Java so I can change my program interactivly while
the program is running. OR, so I can pass a function as an argument
easily--or pass an anonymous function as an argument to an other function.
& then add a linked-list structure that I can interactivly use in C/C++/Java
without writing the equiv. of a Lisp compiler in C :)
>>>>> "Franz" == Franz Kafka <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
Franz> Could you also fix C++/Java so I can change my program
Franz> interactivly while the program is running. OR, so I can pass
Franz> a function as an argument easily--or pass an anonymous
Franz> function as an argument to an other function.
Some of the java IDE's enable you to change functions interactively,
although there is no do direct support for it in Java per se. I am
sure that you are aware that "functions" are not first class in Java,
but objects are, so you can do the last two.
Franz> & then add a linked-list structure that I can interactivly
Franz> use in C/C++/Java
Franz> without writing the equiv. of a Lisp compiler in C :)
You need to write a Java interpreter to do this in Java, although as
the beanshell has been around for 4 year, using that might be an
easier alternative.
Language advocacy can be tedious. I like lisp, I like Java. Obviously
some things are more convenient in some languages. Using the write
language for the right job is half of the solution.
Phil
Phillip Lord wrote:
> Some of the java IDE's enable you to change functions interactively,
> although there is no do direct support for it in Java per se.
Since JDK 1.4.x you can. See
http://java.sun.com/j2se/1.4.1/docs/guide/jpda/enhancements.html#hotswap
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
In comp.lang.scheme Phillip Lord <······@russet.org.uk> wrote:
>>>>>> "Franz" == Franz Kafka <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
>
> Franz> Could you also fix C++/Java so I can change my program
> Franz> interactivly while the program is running. OR, so I can pass
> Franz> a function as an argument easily--or pass an anonymous
> Franz> function as an argument to an other function.
>
> Some of the java IDE's enable you to change functions interactively,
> although there is no do direct support for it in Java per se. I am
> sure that you are aware that "functions" are not first class in Java,
> but objects are, so you can do the last two.
There are also C++ IDE-s that allow this during debugging. Doing so is not
exactly magic, once you get your head around things like memory being made
pages of virtual memory...
>
> Phil
>
--
Sander
+++ Out of cheese error +++
> Could you change C++ for me? Make it so if I misuse a pointer, or jump
> table--the compiler kindly points out where I made a mistake instead of
> crashing because of a invalid memory reference.
So don't use bare pointers and jump-tables. There's nothing stoping
you except inertia.
>
> Or if I mismanage memory--it will GC for me instead of leaking memory. :)
Use smart pointers. Again, nothing but inertia.
>
> Or if I reference an array out of bounds it extends the array for me so I do
> not trash memory.
Use std::vector::at() instead of C-style arrays, or just use a safe
array class.
>
> Could you also make the compiler not so strict about types--so if I pass a
> long int to a function that requires an int it will still work-or, if the
> function returns a long int instead of an int it will still return.
>
Could you make it so dynamically typed languages detect at compile
time when I'm passing an incorrect type to a function, instead of
giving me a runtime error?
> Could you also fix C++/Java so I can change my program interactivly while
> the program is running.
Lisp has a very real advantage, yes. There are C/C++ interpreters
available, but they don't support the complete language, and aren't
amenable to runtime editing.
> OR, so I can pass a function as an argument
It's called Boost.Function, look it up.
> easily--or pass an anonymous function as an argument to an other function.
Again, a real advantage of Lisp --- true support for anonymous
functions. The Phoenix library has some very good lambda support, but
it still painful to use because of poor compiler error messages.
I think these language debates have some use. There are lots of things
the different programming communities can learn from each other. I,
for one, am happy that C++ is finally picking up some functional
features. But there is no point in having these discussions if you're
unwilling to use each language according to best practices. Bitching
about C++ memory management is a red-herring, just like "too many
parentheses" is for Lisp.
"Rayiner Hashem" <·······@mindspring.com> wrote in message
·································@posting.google.com...
>
>
> I think these language debates have some use. There are lots of things
> the different programming communities can learn from each other. I,
> for one, am happy that C++ is finally picking up some functional
> features. But there is no point in having these discussions if you're
> unwilling to use each language according to best practices. Bitching
> about C++ memory management is a red-herring, just like "too many
> parentheses" is for Lisp.
>
>
I'm just trying to bate scav50 not trying to complain about
C/C++/Java but scav50 probably cuts & pastes the "morons"
code and is up-set because when the other people switch to
Lisp. He's going to have to learn a whole new way to cut &
paste code ;)
come on scav50 take the bate, and make C/C++/Java
able to change code at runtime & you might get some
of us Lispers, but than again you might not :)
I use Lisp, C, C++, Java, VisualBasic.
Here's some commands.
trolls[scav50] -= 1; /* C/C++ */
(decf scav50_troll) ;; Lisp
trolls.scav50 -= 1; /* C/C++ */
scav50.troll = scav50.troll - 1 'VB
"David Rush" <·····@aol.net> wrote in message
·················@pixie.nscp.aoltw.net...
> ·······@mindspring.com (Rayiner Hashem) writes:
> > > Could you also make the compiler not so strict about types--so if I
pass a
> > > long int to a function that requires an int it will still work-or, if
the
> > > function returns a long int instead of an int it will still return.
> > >
> > Could you make it so dynamically typed languages detect at compile
> > time when I'm passing an incorrect type to a function, instead of
> > giving me a runtime error?
>
> The Stalin Scheme compiler and PLT's MrSpidey both do this.
>
> > Bitching
> > about C++ memory management is a red-herring, just like "too many
> > parentheses" is for Lisp.
>
> No. There is a significant difference. Memory management is a semantic
> issue in C++, and there are too many different ways of doing
> it. Straight C is far better. The best quote I ever heard on the
> subject is that 'C++ has several lovely small languages inside of it',
> the context being that the language taken as a whole is a bloated,
> ugly, programmer's nightmare.
>
> And I've been paid to program in C++ for 14 years now.
>
> david rush
> --
> As I've gained more experience with Perl it strikes me that it resembles
> Lisp in many ways, albeit Lisp as channeled by an awk script on acid.
> -- Tim Moore (on comp.lang.lisp)
Now if only scav50 could under stand what David Rush is saying.
But, scav50 is a cut&paste script kiddie who could not program
his way out of a paper bag.
(define *retared-troll* 'scav50)
or
(defvar *retarded-troll* 'scav50)
you decide.
(not (good-programmer-? 'scav50)) ;; returns #f in Scheme.
(not (good-programmer-p 'scav50)) ;; returns t in Lisp.
BTW, scav50 should learn to write in English before attempting
to learn to write in VisualBasic, C, C++, Java, Scheme, or Lisp.
Try to get a copy of Strunk & White's "The Elements of Style." From your
posts you look like you need it. :)
Or finish grade school? they may teach you programming in High school?
Of course you might be up set because the gifted kids get to use Scheme ;)
while your still learning Dick and Jane.
"See Dick Come.
See Dick dick Jane.
See Jane Come.
Hear her moan.
Hear her groan."
from Dick & Jane explore the "Facts of Life" series ;)
but since your an idiot who'll never understand Lisp/Scheme you feel like
making fun of people who do.
"scav50" <······@yahoo.com> wrote in message
·································@posting.google.com...
> ······@qnci.net (William D Clinger) wrote in message
news:<····························@posting.google.com>...
>
talks endlessly
{about chaning Lisp Macros.}
Could you change C++ for me? Make it so if I misuse a pointer, or jump
table--the compiler kindly points out where I made a mistake instead of
crashing because of a invalid memory reference.
Or if I mismanage memory--it will GC for me instead of leaking memory. :)
Or if I reference an array out of bounds it extends the array for me so I do
not trash memory.
Could you also make the compiler not so strict about types--so if I pass a
long int to a function that requires an int it will still work-or, if the
function returns a long int instead of an int it will still return.
Could you also fix C++/Java so I can change my program interactivly while
the program is running. OR, so I can pass a function as an argument
easily--or pass an anonymous function as an argument to an other function.
& then add a linked-list structure that I can interactivly use in C/C++/Java
without writing the equiv. of a Lisp compiler in C :)
······@yahoo.com (scav50) wrote:
> to formalize the requirements, perhaps (i thought these were clear to
> any human being, but you proved me wrong):
>
> a) pick any standard lisp (cltl2, ansi - i don't care)
> b) define "safe-defmacro" IN IT
> c) make sure it's *completely* backwards compatible with all of the
> original defmacro functionality (sans variable capture and multiple
> evals, of course) - i don't want to hear any 'proof-of-concept'
> blabbering!
> d) make sure "safe-defmacro" is, in fact, safe - among other things,
> all of the verbatim textbook examples of "programmer errors" involving
> variable capture and multiple evals should work without modifications,
> but correctly.
> e) provide mechanisms for explicit intensional variable capture
> f) show that your definition of "safe-defmacro" is substantially
> smaller than the source (not using 'eval') for a whole lisp compiler
> would have to be. - this was a crucial point
Kohlbecker did all of the above long ago, except for the part of
(d) that cannot be done without reading the programmer's mind.
(Sometimes the programmer wants multiple evaluation, and sometimes
the programmer doesn't.) But I wouldn't expect you to know that.
Or anything else.
Will
William D Clinger wrote:
> ······@yahoo.com (scav50) wrote:
> > to formalize the requirements, perhaps (i thought these were clear to
> > any human being, but you proved me wrong):
> >
> > a) pick any standard lisp (cltl2, ansi - i don't care)
> > b) define "safe-defmacro" IN IT
> > c) make sure it's *completely* backwards compatible with all of the
> > original defmacro functionality (sans variable capture and multiple
> > evals, of course) - i don't want to hear any 'proof-of-concept'
> > blabbering!
> > d) make sure "safe-defmacro" is, in fact, safe - among other things,
> > all of the verbatim textbook examples of "programmer errors" involving
> > variable capture and multiple evals should work without modifications,
> > but correctly.
> > e) provide mechanisms for explicit intensional variable capture
> > f) show that your definition of "safe-defmacro" is substantially
> > smaller than the source (not using 'eval') for a whole lisp compiler
> > would have to be. - this was a crucial point
>
> Kohlbecker did all of the above long ago, except for the part of
> (d) that cannot be done without reading the programmer's mind.
> (Sometimes the programmer wants multiple evaluation, and sometimes
> the programmer doesn't.)
i thought i said "don't pee on my leg and tell me it's raining". just
implement the safe behavior and let the programmer request multiple
evaluations *explicitly* , when he or she desires them. how hard is
this to understand?
btw kohlbecker didn't do anything remotely close to what was specified
earlier.
> But I wouldn't expect you to know that.
> Or anything else.
> ....
> Both Common Lisp and Scheme are ANSI standards.
oh-oh, why do you keep humiliating yourself like this? everyone knows
scheme was disowned by the standards committee. apparently, scheme
didn't live up to the hype it created.
David Rush wrote:
> Have you looked at syntax-case (as opposed to syntax-rules)?
are y'all pathological liars? there is no syntax-case in r5rs. keep
lying and i will call you on that again and again until i make an
honest person out of ya.
p.s. while it's obvious that at the present time, scheme is even worse
than lisp, lisp is basically a dead-end because of the huge obsolete
baggage it has to carry. that's why if scheme develops real macros and
stops obsessing about being an untyped lambda calculus interpreter, it
might actually come out ahead of lisp in a few years.
Incredibly, ······@yahoo.com (scav50) wrote:
> btw kohlbecker didn't do anything remotely close to what was specified
> earlier.
Yes he did. I have read and understood his papers, including his
entire PhD thesis. Indeed, if I recall correctly, I was on his PhD
committee. You probably hadn't ever heard his name until I mentioned
it to you a couple of days ago.
> > But I wouldn't expect you to know that.
> > Or anything else.
> > ....
> > Both Common Lisp and Scheme are ANSI standards.
>
> oh-oh, why do you keep humiliating yourself like this? everyone knows
> scheme was disowned by the standards committee. apparently, scheme
> didn't live up to the hype it created.
:)
For me to list all the things you clearly don't know would tax the
patience of the four newsgroups you have been trolling, so I will
list instead the things you clearly know:
<ul>
</ul>
Will
"scav50" <······@yahoo.com> wrote in message
·································@posting.google.com...
>don't pee on my leg and tell me it's raining.
How about if I pee in your mouth, and tell you
that C++-style pointers smell more like shit
to me that Lisp-style macros.
A macro never fucked my OS so hard that
I needed to reinstall it :)
MicroShitty WinDoz Crap Edition is written in C/C++/Java;
this is enough proof that Lisp is better that C/C++/Java.
I'd rather smell dog shit--that give up my Lispm--and
use Windows.
Drink my piss--it's brain food for you.
#include <stdio.h>
#define crash_this_os 0x0001 /* I think this code is in Windows :) */
// C/C++ is easy to use, and understand ;) :)
void main()
{
(void *) pointless_pointer = 0x0;
*pointless_pointer = &crash_this_os << pointless_pointer; /* :) */
for(i = 0; i == 1000; i++) {
i = pointless_pointer & crash_this_os | new(coredump); /* ;) */
}
printf("C and C++ are easy to use, and never crash./n");
}
// I can deal /w variable capture, and multiple
// evaluations
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com>
wrote in message ·······················@news01.roc.ny.frontiernet.net...
>
> "scav50" <······@yahoo.com> wrote in message
> ·································@posting.google.com...
>
> >don't pee on my leg and tell me it's raining.
>
> How about if I pee in your mouth, and tell you
> that C++-style pointers smell more like shit
> to me that Lisp-style macros.
>
> A macro never fucked my OS so hard that
> I needed to reinstall it :)
>
> MicroShitty WinDoz Crap Edition is written in C/C++/Java;
> this is enough proof that Lisp is better that C/C++/Java.
>
> I'd rather smell dog shit--that give up my Lispm--and
> use Windows.
>
> Drink my piss--it's brain food for you.
>
> #include <stdio.h>
>
> #define crash_this_os 0x0001 /* I think this code is in Windows :) */
>
> // C/C++ is easy to use, and understand ;) :)
> void main()
> {
> (void *) pointless_pointer = 0x0;
>
> *pointless_pointer = &crash_this_os << pointless_pointer; /* :) */
> for(i = 0; i == 1000; i++) {
> i = pointless_pointer & crash_this_os | new(coredump); /* ;) */
> }
> printf("C and C++ are easy to use, and never crash./n");
> }
>
> // I can deal /w variable capture, and multiple
> // evaluations
>
Is there some reason that you need to act like a 13-year-old here? How
about taking this meaningless (and obnoxious) discussion off-line? Oh, and
be sure to express your opinions about Windows explicitly like that next
time you go on a job interview...it's SURE to get you a great position...as
a dishwasher!
*PLONK*
"Howard" <·······@hotmail.com> wrote in message
···············@dispatch.concentric.net...
>
> Is there some reason that you need to act like a 13-year-old here? How
> about taking this meaningless (and obnoxious) discussion off-line? Oh,
and
> be sure to express your opinions about Windows explicitly like that next
> time you go on a job interview...it's SURE to get you a great
position...as
> a dishwasher!
>
> *PLONK*
>
Howard this was not ment in general it was a challange to
scav50.
He's claiming that his lang. is better than Lisp because Lisp
has macros that are hard to use--he wants us to fix them.
I challange him to fix c/c++ style pointers, and memory
managment issues to be easy to use.
The point of the challange is to:
a.) Enrage scav50 so much that he wimpers away.
b.) discurage scav50 to ever cross post to
comp.lang.lisp or comp.lang.scheme again
unless he has something important to say.
c.) to stoop to his level to see how he likes it :)
d.) to point out the other languages besides Lisp/Scheme
have issues that other people might not like
C/C++ (pointers, memory allocation, typecasting.)
the Basics (too many to list--no structured programming,
no recursion, etc.)
e.) to piss scav50 off ;) so he stops starting threads like this.
f.) to piss others off so they'll take scav50 to task.
& lastly
g.) to diss. any other idiots who want to start language wars--
I'll rip you a new ..... --one.
I appologize to any Basic/C++/C/Java/etc. programmer who
does not engage in cross-posting language wars. I'm only
dissing dumb fuckfaces like scav50 who prob. learned how
to program from a guide they found in a cracker jack box. :)
······@yahoo.com (scav50) writes:
> David Rush wrote:
>
> > Have you looked at syntax-case (as opposed to syntax-rules)?
>
> are y'all pathological liars?
No. Ad-hominem argument only shows how badly you are arguing your case.
> there is no syntax-case in r5rs.
I never said there was. Nevertheless, syntax-case is a well-known and
well-documented macro system that is available for Scheme
implementations. There is also a growing consensus that syntax-case
is the best road forward for macro systems in Scheme.
So have you looked at syntax-case or not?
> keep lying
I only asked you a question which you haven't answered. I never
asserted anything beyond the existence of the syntax-case macro
system.
> and i will call you on that again and again until i make
> an honest person out of ya.
I am already a more honest disputant than you appear to be.
david rush
--
Christianity has not been tried and found wanting; it has been found
difficult and not tried.
-- G.K. Chesterton
······@yahoo.com (scav50) wrote in message news:<····························@posting.google.com>...
> to formalize the requirements, perhaps (i thought these were clear to
> any human being, but you proved me wrong):
>
> a) pick any standard lisp (cltl2, ansi - i don't care)
> b) define "safe-defmacro" IN IT
> c) make sure it's *completely* backwards compatible with all of the
> original defmacro functionality (sans variable capture and multiple
> evals, of course) - i don't want to hear any 'proof-of-concept'
> blabbering!
> d) make sure "safe-defmacro" is, in fact, safe - among other things,
> all of the verbatim textbook examples of "programmer errors" involving
> variable capture and multiple evals should work without modifications,
> but correctly.
Incidentally, I've never run into such programmer errors outside of a
Lisp textbook.
> e) provide mechanisms for explicit intensional variable capture
> f) show that your definition of "safe-defmacro" is substantially
> smaller than the source (not using 'eval') for a whole lisp compiler
> would have to be. - this was a crucial point
I believe that meeting these requirements requires a code walker: a
program which analyzes an expression, determines where symbols are
being used to denote variables, and replaces them with generated
symbols---except instances which are specially annotated to allow
capture, as per your requirement (e). A code walker is *far* from
being an entire compiler.
But do you really think think that your puerile posturing will trick
someone into doing your coursework for free?
I'd be more than happy to take this on as contract work. Money talks;
bullshit walks.
> your escapades so far have been irrelevant at best
Nothing could possibly be less relevant than your idiotic trolling.
> p.s. again, there are others who offer me well-known clumsy
> workarounds to be used with defmacro. to them i say: don't pee on my
> leg and tell me it's raining. i'm aware of the workarounds, they suck,
> but it's not the issue - the issue is the myth of the programmable
> programming language. lisp can not possibly be called that, given its
> impotence in this regard.
I've never run into problems with defmacro. Allocating a few gensyms
and using backquote to place them into the form is indeed a chore that
adds extra syntax and detracts slightly from the clarity of the macro.
But it's a very minor chore and a very well localized one. It's not
the kind of extra work that causes ripples of dependent changes
through an entire program. Moreover, it's a chore that, when carried
out properly, provides a complete, correct solution that never breaks.
(Note: followups trimmed because this is about lisp, and I don't read
any of the other newsgroups anyway.)
> (defmacro safe-defmacro (name args &rest body)
> "safe version of defmacro"
> ;;
> ;; definition
> ;;
> )
>
> have the `definition' actually analize `body' instead of the usual
> splicing, insert the necessary calls to `gensym' and commas."
> BULLSHIT, i says. such a `definition' is possible in theory (due to
> the openness of the language: accessibility of the symbol table,
> etc) but it would have to be about as huge as the compiler itself to
> work CORRECTLY. why? - the short answer to that is "because lisp is
> a poorly designed piece of shit".
This is completely impossible to take seriously. Someone who is
worried about variable name capture can use any of a number of simple
techniques to avoid it.
It would be as if someone said,
One time I put = instead of == in a C program. This is a really
stupid design. Many people make this error and I can hardly see
how anyone could write a piece of error-free C code. The entire
C standard ought to be changed so that you cannot use = in the
same context where == can be used because this design is just so
stupid and bad.
Personally I think the above is more reasonable than the case for
trying to eliminate variable name capture in Lisp. Both have a use
--- sometimes you want the = instead of the ==, and sometimes you want
the variable name capture. But, as I said, it's really easy to avoid
variable name capture once you are aware that it can happen.
As far as the multiple evaluation problem, there's also a simple way
around that, using a couple Lisp macros. These are by Howard Stearns.
(defmacro WITH-UNIQUE-NAMES (vars &body body)
`(let ,(loop for var in vars
collect `(,var (make-symbol ,(symbol-name var))))
,@body))
(defmacro REBINDING (vars &body body)
(loop for var in vars
for name = (make-symbol (symbol-name var))
collect `(,name ,var) into renames
collect ``(,,var ,,name) into temps
finally (return `(let ,renames
(with-unique-names ,vars
`(let (,,@temps)
,,@body))))))
WITH-UNIQUE-NAMES is a convenience macro to allow you to avoid
variable capture. REBINDING ensures that the variable arguments to
macros aren't evaluated more than once. The example I have for using
this is as follows, by Kent Pitman:
> Incidentally, harlequin uses something called REBINDING which the
> Lisp Machine had a similar variation called ONCE-ONLY. This is a
> case where the LispM screwed up, I think, and made its solution
> overly complicated (and I have always assumed it was because the
> Lisp Machine compiler had a bias toward not liking extra lambda
> bindings to be created; the compiler for Harlequin is pretty good
> about folding out gratuitous lambda bindings, so it's fine for
> macros to introduce them--once again an argument for letting the
> market sort out tiny details like this). Anyway, what is normally
> written by people as:
>
> (defmacro foo (var1 var2)
> (let ((v1 (gensym "VAR1"))
> (v2 (gensym "VAR2")))
> `(let ((,v1 ,var1)
> (,v2 ,var2))
> (+ (* ,v1 ,v1) (* ,v2 ,v2)))))
>
> would be written using REBINDING as follows:
>
> (defmacro foo (var1 var2 &body forms)
> (rebinding (var1 var2)
> `(+ (* ,var1 ,var1) (* ,var2 ,var2))))
though the implementations are not those of harlequin (aka Xanalys).
So if you wanted to do
(defmacro square (x)
`(* ,x ,x))
you would do
(defmacro square (x)
(rebinding (x)
`(* ,x ,x)))
and you'd be sure not to evaluate the expression passed in as x more
than once.
This is not a big deal.
--
Fred Gilham ······@csl.sri.com
"I'm an expert at installing free software. I've installed software
packages that had 412 steps, the first two of which were 'Remove small
children and animals from the premises' and 'Don protective gloves and
mask'. If you made a mistake you had to go back to the very
beginning, including getting the kids and pets back in the house."
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> wrote in message news:<···················@news01.roc.ny.frontiernet.net>...
> We need Erik back to set some people in line ;)
No thank you.
scav50 wrote:
> Kenny Tilton wrote:
>
>
>>scav50 wrote:
>>
>>>...the impotence of lisp to handle its own defmacro problems.
>>
>>That's not a problem, that's a feature. I have had great success with
>>macros that captured variables deliberately.
>>
>
>
> and i suppose you do not debug your software, you defeature it? bums
> like you think they are successful if 51% of their users do not find
> any bugs in 51% of their function and macro definitions. the problem
> with defmacro is that bugs are frequent, yet they manifest themselves
> when you least expect it, that's why testing against these kinds of
> bugs is often useless. but that wasn't the point of my argument. the
> point, which was obviously beyond you, was that if new languages are
> easily created on lisp, as is often alleged, then surely lisp ought to
> be able to fix its own problems with defmacro variable capture and
> inadvertent multiple evaluations, so that these and other pitfalls of
> programming on lisp could be avoided by requiring variable capture,
> for example, to be *explicit*. explicitness could look something like
> this:
>
> (safe-defmacro aif (predicate &rest body)
> `(capture ((it ,predicate)) (if it ,@body)))
>
> some of the brain-dead lisp aficiados might argue: "sure, i will just
> define a new macro
>
> (defmacro safe-defmacro (name args &rest body)
> "safe version of defmacro"
> ;;
> ;; definition
> ;;
> )
>
> have the `definition' actually analize `body' instead of the usual
> splicing, insert the necessary calls to `gensym' and commas."
> BULLSHIT, i says. such a `definition' is possible in theory (due to
> the openness of the language: accessibility of the symbol table, etc)
> but it would have to be about as huge as the compiler itself to work
> CORRECTLY. why? - the short answer to that is "because lisp is a
> poorly designed piece of shit".
>
> at least java, c++ and friends are usually humble and realistic in
> their claims. btw, posting critiques of lisp to just a lisp newsgroup
> is like asking the police department to investigate itself - nothing
> good can come out of it. redirected replies will be ignored. i noticed
> that egocentric asswipes like lynbech add "followup-to: poster" to
> their messages so they can "have the last word".
>
> p.s. hey vladimir, go hatch some more little lenins if you can't add
> anything of value to the discussion.
Way to break your own thread. Or is Mozilla acting up on me?
--
--Bowen--
First of all, it really is a delight this comedy act you have, and i
feel badly for anyone taking it seriously and missing out on all the fun.
scav50 wrote:
> Kenny Tilton wrote:
>
>
>>scav50 wrote:
>>
>>>...the impotence of lisp to handle its own defmacro problems.
>>
>>That's not a problem, that's a feature. I have had great success with
>>macros that captured variables deliberately.
>>
>
>
> surely lisp ought to
> be able to fix its own problems with defmacro variable capture ...
oh. your only point is "let's see you write defhygienic"? can't i just
point out gensym and copy-symbol? that would be a lot easier.
so you are one of those people who think language design should target
the ignorant? you think ignorant programmer support is the way out of
the programming problem. great idea!!! silly me, i had these crazy ideas
about empowering good programmers.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
······@yahoo.com (scav50) wrote in message news:<····························@posting.google.com>...
> easily created on lisp, as is often alleged, then surely lisp ought to
> be able to fix its own problems with defmacro variable capture and
The problems you're concerned about are not the obstacle you think
they are. By analogy a jumbo airliner could be considered unhygienic
because it needs too much fuel and too much maintenance and might
crash. But if you have a ticket to ride in one, those problems are
beneath the surface where you shouldn't be bothered by them. From
your point of view, your ride is safe enough and clean enough that you
don't have to do anything to improve it. Therefore you're good to go.
Likewise, when using Lisp macros, which can considerably improve the
power and focus of the language for specific types of applications,
you only have to be concerned about whether the macros were written by
competent programmers. Using the macros is like having a ticket for
an airline ride.
Saying Lisp should be able to fix those problems is like saying the
airline industry should be able to reduce its fuel consumption and
maintenance, and you refuse to travel by airline till those problems
are fixed.