>> In article <m3wvljjbmq....@world.std.com>, >> Tom Breton <t...@world.std.com> writes: >> > ... > [misleading snippage undone. I wrote:] >> > All else being equal, it's better to make fewer transformations on >> > your code; it's less machinery to think about. IMO. Don't you agree?
>> >> the purpose of macros is to simplify your code. once the macro is >> >> written and debugged, you shouldn't have to think about it.
>> > Wow, this thread just keeps chewing at this statement for no apparent >> > reason.
>> probably because there is a good reason for it
> Now I know beyond a reasonable doubt that this thread isn't on the > level. I may not be such a gifted writer that I get my meaning across > 100% of the time, but this is ridiculous. There is nothing in my > innocuous statement that should remotely evoke this sudden > insult-hurling conga-line. 3 people so far have attacked me for the > paragraph above - or should I say, 3 user-ids have.
could you please explain in which way i attacked you? where the insult is? methinks you suffer from paranoia.
> I'm inclined to agree with the guy who suggested that we're seeing a > bunch of Naggum tentacles. Same style, same quick resort to "then > you're a bad programmer", same pattern of zealotry, same type of > conceptual blind spots.
not having seen any of your code i have no idea whether you are a good or a bad programmer, so i wouldn't make that statement.
> While obviously no-one can be 100% sure, it's done a hell of a lot of > walking like a duck and quacking like a duck; I say it's a duck named > Erik Naggum. I'm disgusted that you would stoop so low as to harrass > the newsgroup under phony names. I believe you used the phrase > "obsessed stalker" in one of your recent attacks; you may want to > apply it closer to home.
yes, paranoia. i am not erik. if you were not so paranoid you might arrive at the conclusion that the contents of your statementtriggers the "attacks".
> I will continue to use this newsgroup and ignore you, regardless your > user-id. I've already killfiled your recent tentacles, I suppose I > shall have to keep doing so for each new tentacle. I assure you, it's > far less work to add you to my killfile each time than it is to create > each "Hartmann Schaffer".
be my guest.
>> >> once the macro is written and debugged,
>> > Sure, once it's *done*.
>> i have news for you: this is one of the essential tasks when you are >> programming, esp. when you are writing code that other people have to >> use.
> Wow, you really are just trying to goad me, aren't you?
no
>> >> you shouldn't have to think about it.
>> > Sure, you *shouldn't* have to, that doesn't mean you never will.
>> fact of life.
>> btw. if you dislike macros so much, nobody forces you to use them
> Yup, just trying to goad me.
no
> Ob-liten-up-with-some-humor: The insult-hurling conga line goes like > this:
> "You're bad programm-ER! > You're bad programm-ER! > ..."
could you explain how you arrive at this conclusion?
Peaker <GNUPea...@yahoo.com> writes: > [...] The best way to contradict that would probably be to bring > some macro definitions that are simply not doable using non-macro > means. Thomas A. Russ brought a few nice examples of how macros > effectively extend the language. I brought equivalent non-macro > solutions, that show that all the specific macro functionality from > his examples can be implemented using the non-macro means.
The point of macros is not that it provides something that is otherwise _impossible_. Your counter-examples, as was pointed out by someone else, are considered to be inferior to the macro versions in every respect (like readability, flexibilty, performace). That is how you are being contradicted. You may of course say that _you_ find your non-macro solutions are more readable, that you don't care about the performance loss etc. But don't expect anyone else to care.
In article <3165947477983...@naggum.no>, Erik Naggum <e...@naggum.no> wrote:
> the people you argue against typically know dozens of languages. > Common Lisp has more than 40 years of history behind it. it's quite > amazing that you think you can beat that with arguments from > ignorance of what has been done and without making comparisons of > languages each on their _own_ merits.
And Smalltalk has about 30 years of history behind it, and manages to do just as well with objects as we do with functions and macros.
If we had a reader macro for [ that expanded [ ... | ... ] into (lambda (...) ...), we could write things like:
(with-open-file '("filename") [ s | <stuff that reads from S> ])
and implement WITH-OPEN-FILE as a function rather than as a macro, much as in Smalltalk it would be implemented as an object call.
Both approaches have their merits. As I've said about 5 times, it's mainly a stylistic choice -- there's not really anything fundamental about it. Most of the "40 years of history" is actually "40 years of forming common habits and idioms".
-- Barry Margolin, bar...@genuity.net Genuity, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
In article <3909FE18.F1CBE...@yahoo.com> posted on Friday, April 28, 2000 4:09 PM, Peaker <GNUPea...@yahoo.com> wrote:
> You do have to deal with some complexity with any > type of interface, but interfaces built of infix > operation definitions, and object models, tend to > make things simpler, and end up exporting less > complexity.
Excuse me? Infix syntax is full of ambiguity. You have to constantly consider the precedence of operators, which is a waste of time. With prefix syntax, there is never any ambiguity as to the associativity of the operations.
Object models have nothing to do with this. CL has a HIGHLY developed OO system. I personally don't know of a single one that has even equal power and flexibilty. It's not perfect, but that's why we have the MOP.
Infix exports MORE complexity and involves more complexity INTERNALLY. There really aren't many uses for it. Personally, I prefer both RPN and prefix notation to infix for almost all situations. Only when you are dealing with polynomials and have a few operators is infix preferable to the others. But we rarely program with only 3 or 4 different types of operations.
-- -> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <- -> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <- -> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <- -> -/- http://photino.sid.rice.edu/ -=- mailto:rahul-j...@usa.net -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.210020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request.
In article <3909F804.C49C5...@yahoo.com> posted on Friday, April 28, 2000 3:43 PM, Peaker <GNUPea...@yahoo.com> wrote:
> I did not say CLOS+MOP was not powerful. I think it is safe to say, > however, that the LISP syntax values simplicity over many things, and > the syntax/lang. itself is not related in any way to the object model, and > is simply not extendible in means other than macros (such as, for example, > operator overloading).
In CL the "operators" (methods) are MORE overloadable than in most other object systems.
> Which is why I also consider examples of how > macros are useful in extending the LISP syntax simply invalid to the > argument of whether or not the concept macros is useful.
Macros extend syntax (control structures), they should not be used for overloading operators.
> As powerful as CLOS+MOP may be, I would not consider it an > alternative to macros in replacing the language extendibility abilities.
Which is why it's not.
> I've not yet noticed a contradiction of that claim. The best way to contradict > that would probably be to bring some macro definitions that are simply not > doable using non-macro means. Thomas A. Russ brought a few nice > examples of how macros effectively extend the language. I brought > equivalent non-macro solutions, that show that all the specific macro > functionality from his examples can be implemented using the non-macro > means. I challange you to contradict me by bringing examples of > extensions that I simply cannot replicate using non-macro means.
How did you propose to write LOOP as a function and still have it execute at a somewhat reasonable speed? Macros are used for transforming code at _compile_ time, so that these transformations do not need to be applied at run time.
> By the concept of an 'ideal language', I obviously refer to my oppinion of > an ideal language, which is a language that has all the extendibility, but not > the macros.
Macros are what _make_ the language extensible. The alternatives you've shown have been tried and discarded.
-- -> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <- -> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <- -> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <- -> -/- http://photino.sid.rice.edu/ -=- mailto:rahul-j...@usa.net -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.210020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request.
In article <8ed2k8$73...@joe.rice.edu>, Rahul Jain <ra...@rice.edu> wrote:
>Object models have nothing to do with this. CL has a HIGHLY developed >OO system. I personally don't know of a single one that has even equal >power and flexibilty. It's not perfect, but that's why we have the MOP.
I suspect Smalltalkers would not consider our object model so highly developed, since CL is not objects all the way down like Smalltalk is. We're both certainly better than C++, though.
-- Barry Margolin, bar...@genuity.net Genuity, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
> The main point of the exercise is that of controlling the evaluation > of arguments.
> (defmacro Iff (Test Then &optional Else) > "A replacement for IF, takes 2 or 3 arguments. If the first evaluates to > non-NIL, evaluate and return the second. Otherwise evaluate and return > the third (which defaults to NIL)" > `(cond > (,Test ,Then) > (t ,Else)) )
> You couldn't do this using a function, because passing the THEN and > ELSE values to a function would mean that both would get evaluated > before being passed in.
Of course, the syntax is a little funny, but there is always the hoary trick of:
Peaker <GNUPea...@yahoo.com> writes: > Joe Marshall wrote:
> > What exactly do you mean by `unclean' or `*CLEANER*'? How are you > > measuring `cleanliness'?
> Its a complex subjective term, and I doubt I can do well defining it, but I can > say it directly relates to readability.
And you measure readability how? If `cleanliness' is some vague, ill-defined, subjective term, I doubt very much that you'll be satisfied by *any* answer in here. It would be an issue of taste and opinion, rather than a technical issue.
> > > I am criticising LISP for not providing powerful-enough alternative > > > features such as a built-in powerful object model and syntax features > > > concerning that, that can also change the ways things are evaluated, and > > > provide a CLEANER mean than macros, for the same purpose.
> > I guess if CLOS+MOP isn't powerful enough for you, you should consider > > using another language. If the ability to modify and extend the > > readtable, evaluator, and compiler isn't enough to change the way > > things are evaluated, you're SOL as far as Lisp is concerned.
> I did not say CLOS+MOP was not powerful.
Um, I'm re-reading that sentence and it still looks to me like you are.
> Which is why I also consider examples of how > macros are useful in extending the LISP syntax simply invalid to the > argument of whether or not the concept macros is useful.
Ok, so not only are you attempting to `measure' the language against against some subjective scale, you consider explicit counterexamples to be invalid.
> > > What I am trying to request there is, the contradiction of the claim that in an > > > ideal language, there is ALWAYS a cleaner way than macros, and therefore > > > macros only provide extra mess.
> > We've been contradicting you.
> I've not yet noticed a contradiction of that claim.
Read the next sentence carefully; you will see your claim contradicted.
---> `Your claim is false.' <---
> The best way to contradict > that would probably be to bring some macro definitions that are simply not > doable using non-macro means.
1. Most things done with a macro simply cannot be done in an _identical_ way by non-macro means.
2. Everything done with a macro *can* be accomplised in some non-identical way with a non-macro. At the ludicrous limit, you write an interpreter.
3. You consider examples of macros simply invalid to the argument.
> Thomas A. Russ brought a few nice > examples of how macros effectively extend the language. I brought > equivalent non-macro solutions, that show that all the specific macro > functionality from his examples can be implemented using the non-macro > means. I challange you to contradict me by bringing examples of > extensions that I simply cannot replicate using non-macro means.
LOOP, CLOS, Dick Waters' STREAMS, ....
> > > I don't see how I could have made that any more specific.
> > How about by defining cleanliness in a quantifiable way, defining what > > you mean by `ideal language'?
> Cleanliness > is subjective but some charactaristics are quite absoloute, and can roughly > measure the cleanliness of a piece of code. I would say the simplest way to > measure cleanliness, is to measure readability (probably just as problematic > as well, but probably better defined than cleanliness).
Not to me. What are these absolutes?
> By the concept of an 'ideal language', I obviously refer to my oppinion of > an ideal language, which is a language that has all the extendibility, but not > the macros.
In article <F4oO4.96$xb5.3350@burlma1-snr2>, Barry Margolin
<bar...@genuity.net> wrote: > If we had a reader macro for [ that expanded [ ... | ... ] into (lambda > (...) ...), we could write things like:
> (with-open-file '("filename") > [ s | > <stuff that reads from S> ])
One of the wonderful things about Lisp is that it doesn't take much more effort to implement such things than it does to lament about not having them. This took about five minutes:
> I suspect Smalltalkers would not consider our object model so highly > developed, since CL is not objects all the way down like Smalltalk is. > We're both certainly better than C, though.
But, having used both, I'd say that CLOS has the better MOP. Smalltalk has too much of its inheritance mechanism hardwired into its VM. Multiple inheritance is a big win over double dispatch hacks, too. Minimal differences, true, but when you're dealing with two strong contenders, minutia matter. I won't get into the macro debate too much, but when I was actively programming in Smalltalk, I found I missed them. I wanted to add a macro-like capability but, with the heavy syntactic issues involved, it was easier just to generate code specific to my needs, rather than attempting to build a generalized code generation system. Again, minimal differences, but I still choose Lisp.
> (if-fn (condition-true-p arg1) > (lambda () (format t "It's true!")) > (lambda () (format t "It's false!")))
unfortunately, that relies on COND being defined, which could be used in place of IF-FN directly. The point is that a function takes in parameters and returns a result. A macro takes in some symbols and returns code transformed into a form that is defined in terms of the language features existing before that macro was defined.
-- -> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <- -> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <- -> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <- -> -/- http://photino.sid.rice.edu/ -=- mailto:rahul-j...@usa.net -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.210020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request.
In article <uCoO4.101$xb5.3308@burlma1-snr2> posted on Friday, April 28, 2000 5:52 PM, Barry Margolin <bar...@genuity.net> wrote:
> In article <8ed2k8$73...@joe.rice.edu>, Rahul Jain <ra...@rice.edu> wrote: >>Object models have nothing to do with this. CL has a HIGHLY developed >>OO system. I personally don't know of a single one that has even equal >>power and flexibilty. It's not perfect, but that's why we have the MOP.
> I suspect Smalltalkers would not consider our object model so highly > developed, since CL is not objects all the way down like Smalltalk is. > We're both certainly better than C++, though.
I know very little Smalltalk, so I really can't be authoritative when I make comparisons to it, but it seems that what Peaker is complaining about can be achieved quite easily in CL. Unfortunately, I'm not really sure WHAT he proposes as the alternative...
-- -> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <- -> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <- -> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <- -> -/- http://photino.sid.rice.edu/ -=- mailto:rahul-j...@usa.net -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.210020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request.
Discussion subject changed to "Seems like Erik uses tentacles (Was Re: Are macros really a neccessity, or a coverup of languagedeficiencies?)" by Gareth McCaughan
Tom Breton wrote: > I'm inclined to agree with the guy who suggested that we're seeing a > bunch of Naggum tentacles. Same style, same quick resort to "then > you're a bad programmer", same pattern of zealotry, same type of > conceptual blind spots.
I think you're being ridiculous. The articles purporting to be from Hartman Schaffer aren't in remotely #\Erik's style.
> While obviously no-one can be 100% sure, it's done a hell of a lot of > walking like a duck and quacking like a duck; I say it's a duck named > Erik Naggum.
I say you're basing your accusation (which is, after all, a pretty serious one) on a *very* small amount of walking and quacking.
*
I think there's been some misunderstanding going on here. Tom wrote, way back when,
| Well, using a macro instead of a function adds one more | level of indirection, so don't use it unless it accomplishes | something extra.
and I think some have taken this as some kind of blanket attack on macros. I *think* -- and I'm sure Tom will complain if I'm wrong -- that he was just repeating the old advice: don't use macros as a hacky way of doing inline functions. And I'd guess that the adverse reaction is coming from people who wouldn't dream of using macros that way, and haven't seriously considered the possibility that Tom might be referring to doing that.
Unless Tom is saying that he objects to using macros for things like WITH-OPEN-FILE or extended LOOP, or the people arguing against him are saying that things like (defmacro square (x) `(* x x)) are better than inline functions, I think this sub-thread is an argument about nothing.
-- Gareth McCaughan Gareth.McCaug...@pobox.com sig under construction
> Barry Margolin <bar...@genuity.net> wrote in message > news:uCoO4.101$xb5.3308@burlma1-snr2... > > I suspect Smalltalkers would not consider our object model so highly > > developed, since CL is not objects all the way down like Smalltalk is. > > We're both certainly better than C, though.
> But, having used both, I'd say that CLOS has the better MOP. Smalltalk has > too much of its inheritance mechanism hardwired into its VM.
Well, I suppose. In most implementations, certainly. It's not hard to add multiple inheriance, though. Or prototypes. Given that, which parts do you think are problematically hard wired?
(I should say that one can add those alternative inheritance mechanisms without giving rise to, e.g., terrible performance problems.)
> Multiple > inheritance is a big win over double dispatch hacks, too.
Surely you mean multiple dispatch (i.e., selecting methods on the basis of several or all the arguments rather than just the first)? Otherwise, I'm confused.
Mutiple dispatch is definitely slicker from double dispatch, but I believe double dispatch is mostly confined to the arithmetic hierachy. Some pain when adding new numeric types, to be sure, but perhaps an acceptible compromise if one isn't typically feeling the need for multiple dispatch.
> Minimal > differences, true, but when you're dealing with two strong contenders, > minutia matter. I won't get into the macro debate too much, but when I was > actively programming in Smalltalk, I found I missed them. I wanted to add a > macro-like capability but, with the heavy syntactic issues involved, it was > easier just to generate code specific to my needs, rather than attempting to > build a generalized code generation system.
[snip]
I was wondering if you'd mind providing some of the details (e.g., why you wanted one, what the heavy issues were, etc.)? I have been pondering this question for some time. The major use for a macro expansion phase In Smalltalk, as I see it, is to permit more flexiblity with inlining various messages. This would make implementing *efficient* control structures much easier. (In general, using the normal dispatch mechanism for a control structure is only really useful for seldomly used structures which are not time critical. The standard control stuctures, e.g., #ifTrue:ifFalse are inlined for precisely this reason. Of course, Self didn't have to go with compiler based inlining, so perhaps this should be solved along those lines.)
> I've not yet noticed a contradiction of that claim. The best way to > contradict that would probably be to bring some macro definitions that are > simply not doable using non-macro means.
Since I doubt this is possible, it's hardly the *best* way.
Well, maybe from your perspective!
Of course, all that *really* needs to be shown, as far as I can make out, is that the macro ways are "cleaner" by some measure.
Alas, there doesn't seem to be consensus on what the measure should be. You have one, and just about everyone else has another.
Barry Margolin <bar...@genuity.net> writes: > In article <8ed2k8$73...@joe.rice.edu>, Rahul Jain <ra...@rice.edu> wrote: > >Object models have nothing to do with this. CL has a HIGHLY developed > >OO system. I personally don't know of a single one that has even equal > >power and flexibilty. It's not perfect, but that's why we have the MOP.
> I suspect Smalltalkers would not consider our object model so highly > developed, since CL is not objects all the way down like Smalltalk is. > We're both certainly better than C++, though.
One prominent Smalltalker, Alan Kay, gave a keynote at OOPSLA '97 and had some good things to say about AMOP. The tape of the talk is circulating somewhere around Franz; perhaps I can find it and quote precisely what he said. Or maybe someone else knows.
-- Duane Rettig Franz Inc. http://www.franz.com/ (www) 1995 University Ave Suite 275 Berkeley, CA 94704 Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
> > Barry Margolin <bar...@genuity.net> wrote in message > > news:uCoO4.101$xb5.3308@burlma1-snr2... > > > I suspect Smalltalkers would not consider our object model so highly > > > developed, since CL is not objects all the way down like Smalltalk is. > > > We're both certainly better than C, though.
> > But, having used both, I'd say that CLOS has the better MOP. Smalltalk has > > too much of its inheritance mechanism hardwired into its VM.
> Well, I suppose. In most implementations, certainly. It's not hard to > add multiple inheriance, though. Or prototypes. Given that, which parts > do you think are problematically hard wired?
> (I should say that one can add those alternative inheritance mechanisms > without giving rise to, e.g., terrible performance problems.)
Unless you had access to and could change the VM code, the added multiple inheritance stuff was much slower in method dispatch than the one hardwired into the VM, usually going through the exception handling system and being interpreted past there. You're correct that some Smalltalk vendors added support for the notion (V2.5 of ParcPlace's Smalltalk-80, e.g.), but rolling your own without VM support meant unacceptable performance hits.
> > Multiple > > inheritance is a big win over double dispatch hacks, too.
> Surely you mean multiple dispatch (i.e., selecting methods on the basis > of several or all the arguments rather than just the first)? Otherwise, > I'm confused.
You, of course are correct. I meant multi-methods. However, mixins are a lot slicker and convenient than message forwarding.
> Mutiple dispatch is definitely slicker from double dispatch, but I > believe double dispatch is mostly confined to the arithmetic hierachy. > Some pain when adding new numeric types, to be sure, but perhaps an > acceptible compromise if one isn't typically feeling the need for > multiple dispatch.
Not only in the arithmetic, but throughout the drawing model, as well. Shapes and screens have to send quite a few messages between each other to form a picture. It also leads to inconsistencies when it comes to drawing to a printer context rather than to a screen.
> > Minimal > > differences, true, but when you're dealing with two strong contenders, > > minutia matter. I won't get into the macro debate too much, but when I was > > actively programming in Smalltalk, I found I missed them. I wanted to add a > > macro-like capability but, with the heavy syntactic issues involved, it was > > easier just to generate code specific to my needs, rather than attempting to > > build a generalized code generation system. > [snip]
> I was wondering if you'd mind providing some of the details (e.g., why > you wanted one, what the heavy issues were, etc.)? I have been pondering > this question for some time. The major use for a macro expansion phase > In Smalltalk, as I see it, is to permit more flexiblity with inlining > various messages.
The applications I was working on had various rule-based subsystems and database interfaces that were compiled into methods on the fly for performance reasons. Generation of Smalltalk's heavier syntax was a relatively big pain, compared to generating code expansions for Lisp. Granted, either is a piece of cake compared to doing this for C++ or Java :-).
>This would make implementing *efficient* control > structures much easier. (In general, using the normal dispatch mechanism > for a control structure is only really useful for seldomly used > structures which are not time critical. The standard control stuctures, > e.g., #ifTrue:ifFalse are inlined for precisely this reason.
Absolutely. I was going to mention this point as an aside, but I thought it wasn't really salient. I didn't want to get into a discussion about built-in compile-time expansion for relatively often used message sends vs. run-of-the-mill method generation.
> Of course, > Self didn't have to go with compiler based inlining, so perhaps this > should be solved along those lines.)
It's quite possible, but most Lisp folk seem more comfortable with declarations and macro expansion and code that is directly compiled. Self's approach is more relevant if you're using a JIT'ted VM, have no declarations, depend heavily on message sends, and can take the time to make the JIT compiler more reflective. To do so in Lisp would make most of the compilers out there generate larger code without much improvement in performance.
Rahul Jain wrote: > > I've not yet noticed a contradiction of that claim. The best way to contradict > > that would probably be to bring some macro definitions that are simply not > > doable using non-macro means. Thomas A. Russ brought a few nice > > examples of how macros effectively extend the language. I brought > > equivalent non-macro solutions, that show that all the specific macro > > functionality from his examples can be implemented using the non-macro > > means. I challange you to contradict me by bringing examples of > > extensions that I simply cannot replicate using non-macro means.
> How did you propose to write LOOP as a function and still have it execute > at a somewhat reasonable speed? Macros are used for transforming code at > _compile_ time, so that these transformations do not need to be applied > at run time.
Note that the fact macros force code to be created at compile-time is a disadvantage, because function code can be inline'd and partially evaluated (equivalent to macro-expanding) OR called, while macros are always expanded. I would write a LOOP as a method on a block returning bool, that used a 'goto' construct that is merely available for the low-level functionality and implementability of such a concept.
> > By the concept of an 'ideal language', I obviously refer to my oppinion of > > an ideal language, which is a language that has all the extendibility, but not > > the macros.
> Macros are what _make_ the language extensible. The alternatives you've > shown have been tried and discarded.
Discarded by whom? Note most languages used today, are far from having macros as powerful as LISP's, or even have no macros. I would not conclude things about a language according to hope people use it and what they choose to discard.
> And you measure readability how? If `cleanliness' is some vague, > ill-defined, subjective term, I doubt very much that you'll be > satisfied by *any* answer in here. It would be an issue of taste > and opinion, rather than a technical issue.
Yes, whether or not the alternatives to macros are cleaner is mostly a matter of taste. However, even most macro-supporters agree that the alternatives are generally cleaner. Most merely state they are less powerful.
> > > > I am criticising LISP for not providing powerful-enough alternative > > > > features such as a built-in powerful object model and syntax features > > > > concerning that, that can also change the ways things are evaluated, and > > > > provide a CLEANER mean than macros, for the same purpose.
> > > I guess if CLOS+MOP isn't powerful enough for you, you should consider > > > using another language. If the ability to modify and extend the > > > readtable, evaluator, and compiler isn't enough to change the way > > > things are evaluated, you're SOL as far as Lisp is concerned.
> > I did not say CLOS+MOP was not powerful.
> Um, I'm re-reading that sentence and it still looks to me like you are.
What syntax features concerning the object model are there? Can you use the object model of CLOS to create a Query language as done with the 'retrieve' macro, and can be done with powerful enough alternative object-models?
> > Which is why I also consider examples of how > > macros are useful in extending the LISP syntax simply invalid to the > > argument of whether or not the concept macros is useful.
> Ok, so not only are you attempting to `measure' the language against > against some subjective scale, you consider explicit counterexamples > to be invalid.
You seriously misunderstood me there. That macros are not useful for _LISP_ I do not claim. What I claim is, that the fact they are useful for LISP does not mean that macros are a useful concept in general, and therefore bringing examples of how macros are useful in LISP may show that macros are useful for LISP, but not that macros are useful everywhere. What I'm trying to say is that macros are only useful in languages without the powerful alternative ways, for those who find those alternative ways cleaner. Those are most people.
> > > > What I am trying to request there is, the contradiction of the claim that in an > > > > ideal language, there is ALWAYS a cleaner way than macros, and therefore > > > > macros only provide extra mess.
> > > We've been contradicting you.
> > I've not yet noticed a contradiction of that claim.
> Read the next sentence carefully; you will see your claim contradicted.
> ---> `Your claim is false.' <---
Now I think you're doing this on purpose. You obviously understand that shooting unestablished contradicting sentences into the air is not what I mean by 'contradicting me'.
> > The best way to contradict > > that would probably be to bring some macro definitions that are simply not > > doable using non-macro means.
> 1. Most things done with a macro simply cannot be done in an > _identical_ way by non-macro means.
How identical do you want those to be? If you want the advantages of the things done with macros, you have those in the non-macro means, and if you think you don't, please bring an example to demonstrate that, that I've yet to see.
> 2. Everything done with a macro *can* be accomplised in some > non-identical way with a non-macro. At the ludicrous limit, you > write an interpreter.
If you can bring here a case in which I would have to write an interpretr to simulate a useful macro of yours, I would agree.
> 3. You consider examples of macros simply invalid to the argument.
> > Thomas A. Russ brought a few nice > > examples of how macros effectively extend the language. I brought > > equivalent non-macro solutions, that show that all the specific macro > > functionality from his examples can be implemented using the non-macro > > means. I challange you to contradict me by bringing examples of > > extensions that I simply cannot replicate using non-macro means.
> LOOP, CLOS, Dick Waters' STREAMS, ....
Loop is implement'able in non-macro means, I've shown the use of a non- macro LOOP in my reply to Russ's examples, but I've not shown the implementation. It should be easily implementable with a built-in 'goto' statement which is there for other control structures to be built with (and not be used by actual code). CLOS is impossible to implement as an extension without macros, but note the alternative I've suggested to macros IS a powerful object model, which means the features of CLOS are already BUILT-IN. I would request information, or pointers to information about 'Dick Waters' STREAMS' so I can suggest how to implement those with macro alternatives.
> > > > I don't see how I could have made that any more specific.
> > > How about by defining cleanliness in a quantifiable way, defining what > > > you mean by `ideal language'?
> > Cleanliness > > is subjective but some charactaristics are quite absoloute, and can roughly > > measure the cleanliness of a piece of code. I would say the simplest way to > > measure cleanliness, is to measure readability (probably just as problematic > > as well, but probably better defined than cleanliness).
> Not to me. What are these absolutes?
For example, the lack of noise. Or the direct link between syntax/semantics and the actual meaning. I would say, for example, that an RSA- encrypted piece of code is absoloutely less readable than the original, unencrypted piece of code.
> > By the concept of an 'ideal language', I obviously refer to my oppinion of > > an ideal language, which is a language that has all the extendibility, but not > > the macros.
> Why is this ideal?
"... my oppinion ..., which is a language that has all the extendibility, but not the macros."
Bijan Parsia wrote: > Of course, all that *really* needs to be shown, as far as I can make > out, is that the macro ways are "cleaner" by some measure.
> Alas, there doesn't seem to be consensus on what the measure should be. > You have one, and just about everyone else has another.
> Thus, you're arguing at the wrong level.
Perhaps you are right. Most of the time I was making the assumption that everyone else found non-macro means more clean. I do believe that most people really do find the non-macro means cleaner, just less powerful.
Why are you calling EVAL here? Doesn't it put the closure in the wrong lexical environment? I think just returning `(lambda ...) is the right thing. Just testing my understanding.
Duane Rettig <du...@franz.com> writes: > One prominent Smalltalker, Alan Kay, gave a keynote at OOPSLA '97 > and had some good things to say about AMOP. The tape of the talk is > circulating somewhere around Franz; perhaps I can find it and quote > precisely what he said. Or maybe someone else knows.
I can't verify this right now (offline), but apparently it quotes Alan Kay as saying "The Art of the Metaobject Protocol is the best book written in computing in ten years."
Peaker <GNUPea...@yahoo.com> writes: > > And you measure readability how? If `cleanliness' is some vague, > > ill-defined, subjective term, I doubt very much that you'll be > > satisfied by *any* answer in here. It would be an issue of taste > > and opinion, rather than a technical issue.
> Yes, whether or not the alternatives to macros are cleaner is mostly a matter > of taste. However, even most macro-supporters agree that the alternatives > are generally cleaner. Most merely state they are less powerful.
I'm not a `macro supporter' (but I play one on C.L.L), however I gave several examples before where macros are exactly the right tool. Macros are for modifying the syntax of the language to bring it in line with the problem you are addressing. Consider my hypothetical example of:
As a matter of fact, DEFINE-ALU-OPERATION could expand into either of the previous two forms. The point is that DEFINE-ALU-OPERATION is a piece of new syntax designed to make alu opcode definition clear, concise, and obvious.
The main reason macros are `unclean' are because they introduce new syntax into the language. New syntax, by definition, doesn't follow the normal rules of evaluation, and therefore imposes a burden upon the programmer. On the other hand, new syntax may allow you to express something that was cumbersome to express before, thus relieving the programmer of a different burden.
If you find *all* new syntax to be too burdensome, then you will never be satisfied with any use of it.
> > > Which is why I also consider examples of how > > > macros are useful in extending the LISP syntax simply invalid to the > > > argument of whether or not the concept macros is useful.
> > Ok, so not only are you attempting to `measure' the language against > > against some subjective scale, you consider explicit counterexamples > > to be invalid.
> You seriously misunderstood me there. That macros are not useful for > _LISP_ I do not claim. What I claim is, that the fact they are useful for LISP > does not mean that macros are a useful concept in general, and therefore > bringing examples of how macros are useful in LISP may show that > macros are useful for LISP, but not that macros are useful everywhere.
Perhaps not macros per se, but syntactic extenions may be useful in *all* languages simply because no language understands all syntax. In Lisp, syntactic extensions are done with macros, in other languages, perhaps you use FEXPRS or the equivalent. In some languages perhaps you use the object system.
> What I'm trying to say is that macros are only useful in languages without > the powerful alternative ways, for those who find those alternative ways > cleaner. Those are most people.
I disagree. Macros are perfectly clean for simple syntactic transformations.
> > > The best way to contradict > > > that would probably be to bring some macro definitions that are simply not > > > doable using non-macro means.
> > 1. Most things done with a macro simply cannot be done in an > > _identical_ way by non-macro means.
> How identical do you want those to be? If you want the advantages of the > things done with macros, you have those in the non-macro means, and if > you think you don't, please bring an example to demonstrate that, that I've > yet to see.
I mean *precisely* identical. No quotes, square brackets, #'(lambda (), make-instance, etc. And this is the main point. The macro provides a syntactic transformation *only*, and it is the precise syntax that cannot be duplicated without the macro.
Since macros only tranform syntax, the semantics must be supplied by other means. That's proof positive that everything a macro does can be done by non-macro means.
Now if you believe, as you seem to, that all syntactic transformations to the language are `unclean', then *no* syntactic transformation could be `cleaner' than the form it is transformed to, in *any* language. If so, there is nothing to discuss.
> > LOOP, CLOS, Dick Waters' STREAMS, ....
> Loop is implement'able in non-macro means.
Of course it is. It has to be. The macro is a syntactic transformation that simply rewrites LOOP into something that doesn't involve a macro.
> CLOS is impossible to implement as an extension without macros, but note > the alternative I've suggested to macros IS a powerful object model, which > means the features of CLOS are already BUILT-IN.
Actually, the bulk of CLOS *could* be implemented without macros. The nice syntax of DEFMETHOD, DEFGENERIC, and DEFCLASS, would be replaced with the uglier expansion, but you could.
But CLOS isn't generally used for syntactic transformations. Not that you couldn't do this in lisp, its that very few syntactic transformations need the full CLOS object model behind them to accomplish the transformation.
> > > > > I don't see how I could have made that any more specific.
> > > > How about by defining cleanliness in a quantifiable way, defining what > > > > you mean by `ideal language'?
> > > Cleanliness > > > is subjective but some charactaristics are quite absoloute, and can roughly > > > measure the cleanliness of a piece of code. I would say the simplest way to > > > measure cleanliness, is to measure readability (probably just as problematic > > > as well, but probably better defined than cleanliness).
> > Not to me. What are these absolutes?
> For example, the lack of noise.
What's noise in this case?
> > > By the concept of an 'ideal language', I obviously refer to my oppinion of > > > an ideal language, which is a language that has all the extendibility, but not > > > the macros.
> > Why is this ideal?
> "... my oppinion ..., which is a language that has all the extendibility, but not > the macros."
I don't understand what you are objecting to. You want `all the extendibility', I presume that includes simple syntactic transformations, but you don't want macros, which precludes simple syntactic transformations. Make up your mind.
In article <390ACE66.E5A19...@yahoo.com>, Peaker <GNUPea...@yahoo.com> writes:
> ... > You seriously misunderstood me there. That macros are not useful for > _LISP_ I do not claim. What I claim is, that the fact they are useful for LISP > does not mean that macros are a useful concept in general, and therefore > bringing examples of how macros are useful in LISP may show that > macros are useful for LISP, but not that macros are useful everywhere. > What I'm trying to say is that macros are only useful in languages without > the powerful alternative ways, for those who find those alternative ways > cleaner. Those are most people.
did you ever wonder why macros are less useful in other languages? hint (imo): lisp programs syntax is represented by data structures built into the language, and you have the full power of the language available when you write the macros. Also, the language syntax is sufficiently simple that when writing a macro you need not worry too much about parsing the source and concentrate your attention on the macro's functionality. this makes the macrosystem powerful enough that you can even define new control structures. i don't know any other language where macros are that easy. i suggest the real reason why other languages have these features is that they must be built in because there is no way how you can implement them with their macro facilities.
