> > But in Scheme, a symbol has no global properties. Or rather, if you > > like, the only global property it can have are is definition in the > > top level environment. And modules solve that problem.
> Or they would if Scheme had modules. I don't expect to get the Scheme > community to agree to a module system in my lifetime.
I do. :) All existing full-size Scheme systems have some kind of module system IIRC. And, in fact, they have essentially similar features, so its easy to write a mapping from any one of them to the others.
I think that means that a generic module system will show up before too long. The real thing that holds back agreement on a common module system is agreement on a common way to turn environments into first class objects (which, I think, is really necessary for specifying how the module system works).
> So you say. Kent Pitman says that CL does *not* have hygenic macros, > but that it's not a problem in CL.
CL has hygenic macros if you feel like it. It also has non-hygenic macros. It's just that you can use the same facility to do both. In fact, you would implement hygenic macros using the non-hygenic macro facility.
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
> That said, the point was to allow T to be a local variable name in > *one* function, not to shadow it across an entire package.
Then that function needs to be defined in a package where the symbol table is what you want it to be. You seem to not understand what symbols and packages are at all...
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
"Joe Marshall" <prunesqual...@attbi.com> writes: > To contrast this with Scheme, the compiler arranges it so that the > identifier `foo' will recover the current value of foo, but this > has nothing to do with the symbol `foo'. Having the symbol `foo' > won't (in general) let you modify the value or function associated > with that name.
Indeed this is true.
In Scheme, the thing that is missing here is not some kind of first-classness of the symbol, but rather, the first-classness of the environment. (An environment, in Scheme-speak, is a mapping from symbols to bindings.)
Common Lisp has various public ways to access one special environment (the dynamic environment), and thus for special variables, there is a convenient and accessible mapping from the symbol name to its dynamic value.
Scheme indeed lacks this (in the standard). Those implementations that have first-class environments certainly do provide just this mapping, but there is controversy in the Scheme world about whether first-class environments are a Good Thing, and among those (like me) who think they are, about what the right interfaces should look like.
I'd note that Common Lisp (IIUC) does not provide access to any environments but the current dynamic environment, right? The Scheme solution would need to provide access to all of them.
This has compiler implications that are really significant. If a function has its environment captured into an environment object, then the compilation of that code needs to maintain a symbol->variable table explicitly, at some cost. So you don't want to do it for every procedure, but only those where the compiler can show that the environment has been captured.
But that's fraught with difficulty. If you can capture "the present environment" in some function, can you walk up the call chain to the next stack frame up (and thus capture its environment)? If so, then nearly any function could, in principle, have its environment captured, and so the compiler is screwed. (Or, actually, the implementation gets a *lot* hairier.)
It's not that these are impossible problems, but they are some of the reasons that there is great diversity of opinion about what the Right Thing is, and Scheme generally only moves when all the players have agreed on the Right Thing.
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes: > > That said, the point was to allow T to be a local variable name in > > *one* function, not to shadow it across an entire package.
> Then that function needs to be defined in a package where the symbol > table is what you want it to be. You seem to not understand what > symbols and packages are at all...
Instead of insulting me, why not see what I'm saying?
In Scheme, the following is allowed:
(define (foo t) (+ t 50))
In CL, the equivalent is not.
But that function is part of a jillion functions, some of which might well want to be written the normal way, with "t" meaning "canonical true value", and only this one function wanting to shadow the name.
Kent's "solution" says "make your entire package have a different name for "canonical true value". That is only a real solution if packages nest, so that I can embed the FOO function in a little package, which is still part of the bigger package that I'm writing. And even then, it's rather a lot of hair.
This is all no big deal; it was just somebody lamenting that Lisp traditionally overloads two symbol names (t and nil) in Very Special Ways.
> > So you say. Kent Pitman says that CL does *not* have hygenic macros, > > but that it's not a problem in CL.
> CL has hygenic macros if you feel like it. It also has non-hygenic > macros. It's just that you can use the same facility to do both. In > fact, you would implement hygenic macros using the non-hygenic macro > facility.
I don't think there is any way to implement hygenic macros in CL. The macro needs to know expansion context things, to detect whether it is shadowing a local, in ways that are not computable without looking at the surrounding context of the expansion. CL macros, unless they've been radically extended since the last time I studied them, do not have access to the surrounding context.
And even if you could implement a fully hygenic macro in CL, that still isn't the point; the point is that Scheme actually *has* such a facility, and CL doesn't.
But I certainly agree with Kent Pitman that given the total language context of CL, it's really much less necessary.
> > Unless you want to do something where they Just Won't. And all this > > syntactic bloat being forced for a little theoretical > > "perfection". Not a language for me, for sure.
> Huh? There is far less "syntactic bloat" in Scheme macros,
I was actually talking about other aspects of the language, but this works, too.
> which involve two concepts (a binding concept and a > what-is-a-syntax-transformation concept), in which it Just Works, > reliably, always
Sounds like a good description of CL macros. Except that syntax tranformations are a far more general concept in CL.
> ---compared to the several different levels of macro definition in > CL, and the concomitant confusion often experienced.
"Several different levels"? What on earth are you talking about?
> The CL one allows for slightly more general macros;
"Slightly"? That's like saying that complex numbers are slightly more general than natural numbers. A turing machine is far more powerful than a very simple pattern-matching engine. AFAIK, all you can do in scheme macros is destructure based on indefinitely repeated patterns.
> (However, at present, there are two reasons Scheme lacks it;
Really, there is just one: the lack of proper symbolic processing.
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
> "Joe Marshall" <prunesqual...@attbi.com> writes: > In Scheme, the thing that is missing here is not some kind of > first-classness of the symbol,
Except that there are lots of other things that having namespaces for symbols will let you do. Like symbolic processing.
> but rather, the first-classness of the environment. (An > environment, in Scheme-speak, is a mapping from symbols to > bindings.)
Yes, that's only one feature of environments in CL.
> Common Lisp has various public ways to access one special environment > (the dynamic environment), > Scheme indeed lacks this (in the standard).
Yes, scheme lacks a dynamic environment.
> I'd note that Common Lisp (IIUC) does not provide access to any > environments but the current dynamic environment, right? The Scheme > solution would need to provide access to all of them.
Scheme doesn't have a "dynamic" environment in the sense of dynamically scoped values. There are only lexical environments, which any sane language allows to be compiled away, so they should only be accessible at compile-time, as they are in CL.
> This has compiler implications that are really significant. [...] So > you don't want to do it for every procedure, but only those where > the compiler can show that the environment has been captured.
Or just forbid capturing it, and make the compilation happen at compile-time. If someone wants the actual semantics of the code to change at runtime, they have EVAL and COMPILE for just that in CL.
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
> > > That said, the point was to allow T to be a local variable name in > > > *one* function, not to shadow it across an entire package.
> > Then that function needs to be defined in a package where the symbol > > table is what you want it to be. You seem to not understand what > > symbols and packages are at all...
> Instead of insulting me, why not see what I'm saying?
Instead of taking your misunderstanding as a personal defect, why not try to correct it?
> In Scheme, the following is allowed: > (define (foo t) > (+ t 50)) > In CL, the equivalent is not.
Because CL has macros that do symbolic processing. In CL, symbols matter. If you want a specific symbol, use it.
> But that function is part of a jillion functions, some of which might > well want to be written the normal way, with "t" meaning "canonical > true value", and only this one function wanting to shadow the name.
Then you shouldn't be making a mess of your code this way. Either choose one syntax or another. It's not that hard to do.
> Kent's "solution" says "make your entire package have a different name > for "canonical true value". That is only a real solution if packages > nest, so that I can embed the FOO function in a little package, which > is still part of the bigger package that I'm writing. And even then, > it's rather a lot of hair.
Would it be better for value lookups to be locked in at read time? I think not. I'd rather be clear in what my code says and let the language retain the power I need from it.
> This is all no big deal; it was just somebody lamenting that Lisp > traditionally overloads two symbol names (t and nil) in Very Special > Ways.
Which can be changed by you very trivially if you so desire.
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
> I don't think there is any way to implement hygenic macros in CL. The > macro needs to know expansion context things, to detect whether it is > shadowing a local,
I'm puzzled as to why a hygenic macro should be creating shadowing at all. Isn't the point of hygenic macros to NOT cause any shadowing?
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
> > I don't think there is any way to implement hygenic macros in CL. The > > macro needs to know expansion context things, to detect whether it is > > shadowing a local,
> I'm puzzled as to why a hygenic macro should be creating shadowing at > all. Isn't the point of hygenic macros to NOT cause any shadowing?
The point of a hygenic macro is that the macro can use whatever variables it likes in its expansion. If the macro does not itself bind them, then they must not interact at all with the variables that exist in the surrounding code, even if they happen to share the same name.
Implementing this efficiently generally requires looking at the surrounding context to know whether a particular variable might be shadowed (and thus should be renamed by the compiler).
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes: > Instead of taking your misunderstanding as a personal defect, why not > try to correct it?
> > In Scheme, the following is allowed:
> > (define (foo t) > > (+ t 50))
> > In CL, the equivalent is not.
> Because CL has macros that do symbolic processing. In CL, symbols > matter. If you want a specific symbol, use it.
You know, macros really have nothing to do with whether "t" is a special magic symbol. Or if you think they do, maybe you could describe the connection?
> Then you shouldn't be making a mess of your code this way. Either > choose one syntax or another. It's not that hard to do.
What are the two "syntaxes" that you're talking about?
> > Kent's "solution" says "make your entire package have a different name > > for "canonical true value". That is only a real solution if packages > > nest, so that I can embed the FOO function in a little package, which > > is still part of the bigger package that I'm writing. And even then, > > it's rather a lot of hair.
> Would it be better for value lookups to be locked in at read time? I > think not. I'd rather be clear in what my code says and let the > language retain the power I need from it.
Um, no, nobody wants value lookups to be locked in at read time. Except, that is, for the one case of "t" and "nil". Those values *are* locked in at read time, by making those two symbols Very Special.
That's the problem. It's a teeny problem (and it wasn't I that brought it up), but it's a problem. It's forced upon CL by compatibility considerations, and that's a perfectly good reason for CL to maintain the historic practice. But it doesn't make the historic practice right.
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes: > > The CL one allows for slightly more general macros;
> "Slightly"? That's like saying that complex numbers are slightly more > general than natural numbers. A turing machine is far more powerful > than a very simple pattern-matching engine. AFAIK, all you can do in > scheme macros is destructure based on indefinitely repeated patterns.
By "slightly", I meant that the additional computational power is rarely used. But indeed, I think it's really nice, and it would be great if a good method of doing it were added to the Scheme standard.
> > (However, at present, there are two reasons Scheme lacks it;
> Really, there is just one: the lack of proper symbolic processing.
Huh? You're just mouthing words that others have given you, without understanding them at all. 'tis a real shame, but it's expected boosterism. Indeed, if did anything else, Erik Naggum would start shouting at you and calling you names, so I don't blame you.
In any case, that isn't any kind of response.
Frankly, I really enjoy reading Kent's messages, because
1) He knows whereof he speaks, and really understands the deep issues, 2) He isn't convinced that CL is the Only Way To Do Anything 3) I learn a lot.
But that's not true of your messages; they are just getting in the way of a conversation that I'm enjoying a great deal. Please don't snipe.
> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes: > > Because CL has macros that do symbolic processing. In CL, symbols > > matter. If you want a specific symbol, use it. > You know, macros really have nothing to do with whether "t" is a > special magic symbol. Or if you think they do, maybe you could > describe the connection?
If a macro inside the body of a function that rebinds T uses T, then it will not work as the macro writer expected. This is because CL macros, again, are symbolic in nature, and not value-oriented as it seems scheme macros must be.
> > Then you shouldn't be making a mess of your code this way. Either > > choose one syntax or another. It's not that hard to do. > What are the two "syntaxes" that you're talking about?
One with T as a variable and one with T as a symbolic constant.
> > > Kent's "solution" says "make your entire package have a > > > different name for "canonical true value". [...] And even then, > > > it's rather a lot of hair.
> > Would it be better for value lookups to be locked in at read time? I > > think not. I'd rather be clear in what my code says and let the > > language retain the power I need from it.
> Um, no, nobody wants value lookups to be locked in at read time.
How else will you get values in scheme, since symbols don't have values? Where else will the value of "t" as used in my macro come from? This is one reason why scheme _needed_ to have #t and #f, whether or not it was explicit at the time. Unfortunately, a user cannot implement such a feature.
> Except, that is, for the one case of "t" and "nil". Those values > *are* locked in at read time, by making those two symbols Very > Special.
Wrong. The values of T and NIL are locked into the SYMBOLS. Nothing says that the string "t" has a true value.
> That's the problem. It's a teeny problem (and it wasn't I that > brought it up), but it's a problem. It's forced upon CL by > compatibility considerations,
In reality, this whole difference is just a side-effect of the issue of symbolic processing.
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes: > By "slightly", I meant that the additional computational power is > rarely used. But indeed, I think it's really nice, and it would be > great if a good method of doing it were added to the Scheme standard.
It's only rarely used if all your macros have simple patterns to them. I don't know if you can you destructure a plist with scheme macros, can you?
> > > (However, at present, there are two reasons Scheme lacks it; > > Really, there is just one: the lack of proper symbolic processing. > Huh? You're just mouthing words that others have given you, without > understanding them at all.
PAIP explains symbolic processing quite well. I have a feeling much of the techniques used there would be next to impossible to do in scheme with multiple such systems operating on the same data. Norvig doesn't use packages because he already knows everything about what will be done to the data.
> 'tis a real shame, but it's expected boosterism.
Your refusal to accept that some people might actually enjoy being able to cleanly do symbolic processing and calling the features which allow that misfeatures is what I'd call boosterism. You haven't proposed any equivalent alternative, and until you do so, you have no right to imply that we are misguided for liking namespaces for symbols.
> In any case, that isn't any kind of response.
I've already explained what I mean by symbolic processing. Kent replied and elaborated on the idea in a much more precise way. If you don't understand it, please read that post again.
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
* Thomas Bushnell, BSG | In Scheme, the thing that is missing here is not some kind of | first-classness of the symbol, but rather, the first-classness of the | environment.
As seen from Common Lisp, symbols in Scheme are just like identifiers in the Algol family, but you also have a type for an interned string that has nothing to do with the identifiers. These are really two different things. Real Lisps have real symbols.
| Common Lisp has various public ways to access one special environment | (the dynamic environment), and thus for special variables, there is a | convenient and accessible mapping from the symbol name to its dynamic | value.
I wish you would at least _try_ to understand the Common Lisp way.
| It's not that these are impossible problems, but they are some of the | reasons that there is great diversity of opinion about what the Right | Thing is, and Scheme generally only moves when all the players have | agreed on the Right Thing.
But looking for The Right Thing is not a Right Thing. Part of the reason that Scheme is such an unattractive language is that it tries to say that "there is such a thing as a universal and globally unique Right Thing", and this is _such_ a ludicrous position in the first place. Sometimes, when I hear Scheme people talk, and you among them, I get the impression that there are 26 people trying to argue which is the Only Right Letter and they are _so_ in the need of someone to say "Hey, dudes! One word: _alphabet_".
/// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes: > > tb+use...@becket.net (Thomas Bushnell, BSG) writes: > > > I don't think there is any way to implement hygenic macros in CL. The > > > macro needs to know expansion context things, to detect whether it is > > > shadowing a local, > > I'm puzzled as to why a hygenic macro should be creating shadowing at > > all. Isn't the point of hygenic macros to NOT cause any shadowing? > Implementing this efficiently generally requires looking at the > surrounding context to know whether a particular variable might be > shadowed (and thus should be renamed by the compiler).
So how does GENSYM not provide this functionality? Why worry about renaming it when you can use a symbol which is guaranteed to not exist anywhere else? I thought I did this kind of stuff all the time.
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes: > How else will you get values in scheme, since symbols don't have > values? Where else will the value of "t" as used in my macro come > from? This is one reason why scheme _needed_ to have #t and #f, > whether or not it was explicit at the time. Unfortunately, a user > cannot implement such a feature.
"Symbols don't have values"? They don't in CL either, except for special variables, for which you might want to say that.
#t and #f are constants, and that's why Scheme makes them not just symbols. The issue is that symbols are *all* available for variable names. There is no more reason to have t use up a variable name than 6.
> > Except, that is, for the one case of "t" and "nil". Those values > > *are* locked in at read time, by making those two symbols Very > > Special.
> Wrong. The values of T and NIL are locked into the SYMBOLS. Nothing > says that the string "t" has a true value.
And nothing I said was about the string "t"; it was about the *symbols*, which are Very Special.
> In reality, this whole difference is just a side-effect of the issue > of symbolic processing.
Your new mantra of the day! If you knew what it meant... oh, no, you're just chanting. Ok.
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes: > > Implementing this efficiently generally requires looking at the > > surrounding context to know whether a particular variable might be > > shadowed (and thus should be renamed by the compiler).
> So how does GENSYM not provide this functionality? Why worry about > renaming it when you can use a symbol which is guaranteed to not exist > anywhere else? I thought I did this kind of stuff all the time.
Implementing it *efficiently*. I don't think you understand what the issues are with hygienic macros; maybe you should go read the papers.
* Thomas Bushnell, BSG | Huh? There is far less "syntactic bloat" in Scheme macros, which | involve two concepts (a binding concept and a | what-is-a-syntax-transformation concept), in which it Just Works, | reliably, always---compared to the several different levels of macro | definition in CL, and the concomitant confusion often experienced.
I do not think anyone disputes the usefulness of something that either Just Works or just does not apply, but Common Lisp is not about making it possible to do only the Right Thing. I had to listen to one of the worst specimens of politician on the news last night in order to catch some real news, and it is clear that this Christian Democrat-like hypocrite really has as his concept of politics to create a whole nation where all people do the Right Thing according to his demented religious views. I mean, it is the Taliban regime all over again, only with a mad Christian. Listening to this madman, I came to think of Scheme freaks. In contrast to Common Lisp, which offers people a way to do whatever they want to do, Scheme offers a way to do whatever the Scheme designers want them to do, and if you want to do something else, the message is "You don't want to to do that."
Confusion is the result of lack of knowledge, insight, and thinking, not a property of the subject matter.
| The really significant difference is not the hygene one, which CL could | have without too much trouble.
You know, you have spelled this "hygene" consistently for a while, so I think you may not know it is actually spelled "hygiene".
| The big difference is that CL thinks of macros as *functions* from forms | to forms, and Scheme has a simpler pattern transformation method.
So Common Lisp macros can implement Scheme macros, but not vice versa.
| The CL one allows for slightly more general macros; normally of course a | CL macro is just a pattern transformation, but sometimes one wants to do | more stuff, and the Scheme version doesn't permit that.
That seems to be a case of "it Just Doesn't Work".
| (However, at present, there are two reasons Scheme lacks it; one is that | the needed interactions between the hygene rules and the transformation | functions are murky.
I read this to mean "it is better left to human intelligence", and that is just what Common Lisp does.
Oh, another thing Scheme says to people when it refuses to give people the freedom do what they think is best is: "You couldn't figure out the Right Thing on your own if you tried". I can do without that attitude.
/// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes: > It's only rarely used if all your macros have simple patterns to > them. I don't know if you can you destructure a plist with scheme > macros, can you?
Some kinds of "looking inside" work just fine. For example, you can expand a LET form the following way:
((let ((var value) ...) forms ...) ((lambda (var ...) forms ...) (value ...)))
So the ((var value) ...) repetition can be destructured, and then you can look inside it with var ... and value ... and everything works just fine.
So the amount of destructuring you can do easily covers the cases people usually want (and match what is generally considered good style for both Scheme and CL types). But one might have a good reason to want something like LET, only with no extra parens, for example; something like:
(my-let (var-1 value-1 var-2 value-2 ...) forms ...)
Indeed, that's what you want for destructuring a plist. But I think it's generally thought by Lispers that it's a shame that plists and alists have different structure, and if it were to be done over again, plists would have the alist structure. So you can't destructure a plist easily, but except when actually dealing with plists, you are advised in Common Lisp to use alists instead, in general.
Incidentally, it's been shown now that it *is* possible to do arbitrary destructuring with Scheme macros, because it turns out that with letrec-syntax you can create mutually recursive macro definitions that are Turing complete. But I certainly wouldn't claim that the results are pretty or easily understandable.
> Your refusal to accept that some people might actually enjoy being > able to cleanly do symbolic processing and calling the features which > allow that misfeatures is what I'd call boosterism.
I haven't called them misfeatures at all. I've said they seem to me to be the right thing within the broader world of Common Lisp.
> You haven't proposed any equivalent alternative, and until you do > so, you have no right to imply that we are misguided for liking > namespaces for symbols.
* Thomas Bushnell, BSG | Indeed, if did anything else, Erik Naggum would start shouting at you and | calling you names, so I don't blame you.
Please quit lying about me and what I want and would do. When you repeat this crap over and over, it is a serious case of hostility on your part. You are no longer being attacked, but you choose to attack me out of the blue repeatedly. This is not a forum for your hatred and irrationality.
Thomas Bushnell, you are intellectually dishonest and an evil person. Please cease and desist, and get help from a priest or something to get over your need to blame other people for your own character deficiencies and your psychotic break.
/// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
* Thomas Bushnell, BSG | Um, no, nobody wants value lookups to be locked in at read time. Except, | that is, for the one case of "t" and "nil". Those values *are* locked in | at read time, by making those two symbols Very Special.
Hey, dude, acquire clue, _then_ talk, will you? Your ability to stop talking when your clue runs out is sorely lacking. This indicates that you talk only to score rhetorical points for yourself, not to discuss anything of value to you or any others. Please latch out of your hostile mode and start to think. You used to be able to think, I remember.
This is the real story: t and nil are declared constants, just like pi and most-positive-fixnum. t and nil happen to have themselves as their constant value, but that is quite irrelevant to the binding issue. This has nothing to do with the reader, either. The standard says: The consequences of binding and assigning a constant variable are undefined. The value of a named constant may not be changed by assignment or binding. So this has nothing to do with t or nil being special symbols, it has nothing to do with read-time, it has to do with the rules for binding and assigning constant variables.
I wonder why you are not griping about pi, too. Perhaps you are simply unaware of the idea of constant variables? Does Scheme have constant variables? No. It has #f and #t, instead. Does Scheme have a constant value for pi? No.
Now, it may illuminate the discussion to see why it is _necessary_ that constant variables not be rebound or assigned to. First, there should be no need for a run-time lookup of their value -- the compiler should be free to inline the value. Like, a test for nil-ness should be no more than a single instruction. So if you change the value of a declared constant (it can be done), you get hosed by the system. Second, to make a constant variable useful to programmers, they must know that they can rely on it. This, somewhat ironically, follows from the _integrated_ macro system in Common Lisp, and it would _not_ follow from the macro bag on the side of Scheme. How do you capture the universal (stronger than global) value of a declared constant when you can shadow the binding and perhaps even make it lexical? What would happen to macro bodies if you could change the value of t or nil? Serious lossage! To be able to rely on your Common Lisp environment, as in trust it, constants _must_ be known to have their one and only constant value. This also means that if it is at all possible that it is not a constant and that you might want to re-bind the value, do not make it a constant. Consequently, ther are few real constants around. pi and e are the mathematical ones with their arbitrary names from a different domain, and t and nil are the boolean ones with their arbitrary names from the Common Lisp domain. That is just how things are. Deal with it. Like it the way it is and spend your mental energy on solving your problems _with_ Common Lisp as a constant as far you are concerned. This part of Common Lisp is not going to be changed. However, if you really, really want to, you can do this:
so in Loserville, you may bind t, and most of the time, it will still work. If you want it to work all the time, do not move to Loserville.
The magnitude of the confusion and the absence of insight that must exist prior to making such an incredibly bogus claim as "Those values *are* locked in at read time, by making those two symbols Very Special" is just _staggering_. The cluelessness that this betrays is so fantastically destructive to your credibility that it approaches the idiocy you keep committing when you post lies about what I would do just because you need to feed your psychotic imagination. You know just about as much about Common Lisp as you do about me, and you have _no_ control over your blabbering. It is _fantastically_ annoying to have people like you around. Go away!
| That's the problem. It's a teeny problem (and it wasn't I that brought | it up), but it's a problem. It's forced upon CL by compatibility | considerations, and that's a perfectly good reason for CL to maintain the | historic practice. But it doesn't make the historic practice right.
Do you have the mental capacity to back down when you are wrong?
/// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
On 16 Mar 2002 23:30:51 -0800, Thomas Bushnell, BSG wrote:
> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes: >> > That said, the point was to allow T to be a local variable name in >> > *one* function, not to shadow it across an entire package.
>> Then that function needs to be defined in a package where the symbol >> table is what you want it to be. You seem to not understand what >> symbols and packages are at all... > Instead of insulting me, why not see what I'm saying?
Perhaps you need to be clearer about what you're saying. You do seem to be saying that you don't understand symbols. In particular, you seem not to understand that a symbol is distinct from its name. That's probably why you think that just interning the name and calling that a "symbol" is good enough.
> In Scheme, the following is allowed: > (define (foo t) > (+ t 50)) > In CL, the equivalent is not.
Huh?
(defun foo (t) (+ t 50))
is perfect legal Common Lisp -- as long as this T is not CL:T, because that's a constant, and you can't use constants as variables, obviously!
> But that function is part of a jillion functions, some of which might > well want to be written the normal way, with "t" meaning "canonical
"t" doesn't mean anything, in isolation. You're talking about the symbol named "T" in the COMMON-LISP package, which is just one symbol named "T" out of potentially millions, any others of which have no relation to the "canonical true value" whatsoever. There's nothing special about either the name "T" or the COMMON-LISP package.
> true value", and only this one function wanting to shadow the name.
So put it in a different package. You *can* even do things like
if you really want to. I don't know why you'd want to, though.
> Kent's "solution" says "make your entire package have a different name > for "canonical true value".
Not it doesn't. Kent supplied a symbol named TRUE for that value, but of course you can continue to use the old name if you prefer; CL:T and TEMPERATURE::T are independent symbols.
> That is only a real solution if packages > nest, so that I can embed the FOO function in a little package, which > is still part of the bigger package that I'm writing.
You mean like USE-PACKAGE?
> This is all no big deal; it was just somebody lamenting that Lisp > traditionally overloads two symbol names (t and nil) in Very Special > Ways.
Where's the "overloading"? And what do you mean by "Very Special Ways"? There's nothing particularly special about them; you can make any symbol a constant with DEFCONSTANT.
-- Malum est consilium quod mutari non potest -- Publilius Syrus
On 17 Mar 2002 00:03:10 -0800, Thomas Bushnell, BSG wrote:
>> > The CL one allows for slightly more general macros; > By "slightly", I meant that the additional computational power is > rarely used.
Define "rarely". Just looking at a few of my files, I count 46 macro definitions, of which 19 are simple pattern rewrites and 27 do some computation in the expander function. I doubt that's atypical.
-- Malum est consilium quod mutari non potest -- Publilius Syrus
