> This is essentially the solution I've been using. At one point I was > naming my packages/features things like TFB.GARNET-EXTENSIONS. I > stopped when you yourself posted a reply to one of my c.l.l articles > that began the quoted text from me with "I wrote..." (because your > newsreader recognized my/your initials). Unfortunately, for > completely general-purpose things (ie, not tied to a product > associated with a shorter domain name), I end out with some > attrociously long names: eg, EDU.BERKELEY.OCF.TFB.GARNET-EXTENSIONS. > For packages, I can use nicknames, but for features, it gets ugly. > It's not just the length (I always edit code in 100-column windows), > really it's the ability to scan code and see the names. When I scan > names prefixed like this, I see the domain name part. Maybe I'll try > using / after the domain part -- it seems to emphasize the important > part better.
Well, one question is how often do you end up typing these things? I changed to long names, and I stressed about this to the extent that I looked at Franz's relative package names trick, but in practice I've never used it, because I just don't type package names very much, and the same goes for features. I think that for packages, the relative name trick might be quite useful, because I'm aware that some people prefer to type package names rather than use a whole load of random packages. And I think Franz-compatible relative names are available for at least CMUCL, ACL and LW now. For features I find it hard to imagine a case where I'd be typing them so often that I'd care, unless I was maintaining something which was densely conditionalised and thus already in hell. When code gets like that the right solution is to become a gardener...
Using package nicknames is not a solution because the nicknames can collide just as easily as the full names.
I guess for features the solution *might* be to have a notion of `current feature context' and then have #+/#- parse names beginning with `.' relative to that. But it's really a non-problem for me, so I've never worried about it.
Erik Naggum <e...@naggum.no> writes: > This discussion has changed my view on #+ignore and the like. From > not having an opinion on it to having an actual opinion on it, I > have come to think it is wrong to use /any/ non-existing feature as > a marker that some code should not be processed, and in particular > that overloading natural language semantics on formal constructs is > a form of intellectual sloppiness that should be avoided.
I think you are over-rationalizing a rather mundane concept. I can see there is an overloading of concepts going on, and to some degree this also runs counter to my aesthetic sense. But I have a bigger problem with #+(or) or similar variants like #+(and x (not x)), which--while neat in a slightly geeky way--I'd sooner associate with socially excluding, "wizard"-friendly languages, rather than the lucidness I've come to expect with Common Lisp.
Let me propose #+false as a mechanism that to a lesser extent confuses separate concepts, even if it still only works by accident. For the next Common Lisp, I'd like to see the feature language extended with a proper false (and true) expression. This as a perferrable alternative to using up another macro character to achieve form-scope comments. I actually think I'd lean towards having "ignore" be this false expression, acknowledging that feature expressions is a tool to aid programmers in system construction, not a mirror of formal mathematical logic.
* Frode Vatvedt Fjeld | I think you are over-rationalizing a rather mundane concept.
Huh?
| But I have a bigger problem with #+(or) or similar variants like #+(and x | (not x)), which--while neat in a slightly geeky way--I'd sooner associate | with socially excluding, "wizard"-friendly languages, rather than the | lucidness I've come to expect with Common Lisp.
I really wonder what you are afraid of and how you come up with this highly emotional position.
| Let me propose #+false as a mechanism that to a lesser extent confuses | separate concepts, even if it still only works by accident.
This "proposal" and the existing abuse of #+ and #- mean that we should no longer read #+feature as "process the following expression if the feature is present in the system" and #-feature as "process the following expression if feature is not present in the system", but as something entirely different. It was only when I started to /read/ the #+ and #- out loud that I found #+ignore and the like to be astonishingly counter-productive and abusive of the concepts involved.
How do you /read/ #+feature? What does it /mean/ to you?
From what you write above, I believe you do not think about what you read, but sort of go by a feeling that #+feature means "process the following when some fuzzy interpretation of feature makes intuitive sense apart from what it actually means". This is only tolerable when people are ignorant of the language or when they do not understand what they are doing. Such lack of appreciation and understanding will necessarily lead to such fantastically counter-productive attitudes as branding /actual/ understanding of the language as "geeky" and "wizard-friendly". Learn the language instead of trying to adopt some fuzzy pre-understanding intuition to what you read.
Your strong resistance to learning the nature of feature expressions is disheartening. And setting yourself up so you cannot embrace a slightly geeky, socially excluding, "wizard"-friendly language is not conducive to getting the point. You have to back down from this silly pontificated opinion because it is false, and you have just made that very much harder for yourself. Instead of moving towards a solution, you have solidified an abuse of the feature expression. If you wish to make sense and convince people that such abuse should be tolerated, you have to remove some of the emotional ties you have presented and back it up with reasoning. OK?
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <e...@naggum.no> writes: > I really wonder what you are afraid of and how you come up with this > highly emotional position.
My concern is not to push CL towards being less readable than need be.
> [...] How do you /read/ #+feature? What does it /mean/ to you?
Well, how do you read out #+(or), exactly? Feature expressions is already a language, complete with its own interpreter. My position is to mold that language into being as useful and readable as possible, rather than holding it to some measure of conceptual purity.
> From what you write above, I believe you do not think about what you > read, but sort of go by a feeling that #+feature means "process the > following when some fuzzy interpretation of feature makes intuitive > sense apart from what it actually means".
No, #+false or even #+ignore would mean "process the following when the feature that is guaranteed not to be present in any system is present". Which in the current language can be spelled out as #+(and x (not x)), which can be reduced to #+(or). By endorsing #+(or) you have clearly already made that leap from "does this feature exist?" to "evaluate this expression", so I really can't understand your complaining over this.
> This is only tolerable when people are ignorant of the language or > when they do not understand what they are doing. Such lack of > appreciation and understanding will necessarily lead to such > fantastically counter-productive attitudes as branding /actual/ > understanding of the language as "geeky" and "wizard-friendly". > Learn the language instead of trying to adopt some fuzzy > pre-understanding intuition to what you read.
I never branded anyone's understanding of this, I was describing the language/notation that would result from adopting #+(or) etc.
What do you expect the average new CL student's reaction to seeing #+(or) will be?
Fuzzy pre-understanding is a good thing, it's how everyone gets by in a complex world. Also in a learning situation it is almost essential, so long as the implied understanding follows the pre-understanding. But I believe in this case the issue is rather about something quite different, which might be called fuzzy post-understanding. After you have understood something, you keep it in your active vocabulary by means of any number of fuzzy mechanisms. I believe that's how the brain works. In my view, #+(or) provides very little for that part of the brain to work with (in other words, it's unreadable), and for no particularly good reason other than some sense of purity that, in this smallest and simplest of languages, is worthless. (Again, that's not worthless in the sense that it's a concept that is worthless to understand and appreciate, but worthless as a consideration in which notation to use.)
> If you wish to make sense and convince people that such abuse should > be tolerated, you have to remove some of the emotional ties you have > presented and back it up with reasoning. OK?
I tried to, actually. The short form is this: 1. We need a form-scope comment syntax. 2. Since we already have #+ and #-, using up another macro character might not be worth it (but if the distaste for "intellectual sloppiness" is very strong, it might be worth it after all, #; could be a strong candidate). 3. #+(or) etc. is too cryptic. 4. So define a less cryptic false feature expression.
> No, #+false or even #+ignore would mean "process the following when > the feature that is guaranteed not to be present in any system is > present".
That'd be #+cltl2, then :-)
Actually, I wonder why we don't just use #-common-lisp for ignoring forms. Not only should that feature be present in every "Common Lisp family" language, but it's also more obvious on casual inspection than #+(or)
Comments? (ahaha)
-dan, still writing code that won't run in the New Implementation of Lisp
a few lines later, someone might see `(or E1 E2)' instead of `unless', or `(and E1 E2)' instead of `when'. probably it won't be cryptic if these constructs are seen to be used in different contexts.
one could argue that the whole practice of programming is cryptic (by definition!), so when congruent usage-meaning mapping shows up like this, it is actually a way to allow the mental model to settle to a more consistent, lower-energy-requiring form. the student that sees this moves ahead quicker.
Daniel Barlow <d...@telent.net> writes: > Actually, I wonder why we don't just use #-common-lisp for ignoring > forms. Not only should that feature be present in every "Common Lisp > family" language,
Because people share code between CL and non-CL lisps.
> but it's also more obvious on casual inspection than > #+(or)
Apparently not since you either overlooked or failed to acknowledge the complete meaning of #-Common-Lisp. I'd say that included in the meaning of obvious is not only "quick" but "correct". Of the two notations #-common-lisp and #-(or) that you cited, you got only one correct, and of those the fastest was #-(or). So it WAS actually most obvious, too ... at laest of these. But that's just my opinion. ;)
Besides, obviousness if a function of time. If people used #+(or) it would become more obvious. (Sort of like the US courts once ruled that you had an expectation of privacy in certain situations that the government has, I'm told more recently argued that since people are so doubtful that the rights are protected, that there is no expectation of privacy left to violate...)
Tim Bradshaw <t...@cley.com> writes: > * Thomas F Burdick wrote: > > This is essentially the solution I've been using. At one point I was > > naming my packages/features things like TFB.GARNET-EXTENSIONS. I > > stopped when you yourself posted a reply to one of my c.l.l articles > > that began the quoted text from me with "I wrote..." (because your > > newsreader recognized my/your initials). Unfortunately, for > > completely general-purpose things (ie, not tied to a product > > associated with a shorter domain name), I end out with some > > attrociously long names: eg, EDU.BERKELEY.OCF.TFB.GARNET-EXTENSIONS. > > For packages, I can use nicknames, but for features, it gets ugly. > > It's not just the length (I always edit code in 100-column windows), > > really it's the ability to scan code and see the names. When I scan > > names prefixed like this, I see the domain name part. Maybe I'll try > > using / after the domain part -- it seems to emphasize the important > > part better.
> Well, one question is how often do you end up typing these things? I > changed to long names, and I stressed about this to the extent that I > looked at Franz's relative package names trick, but in practice I've > never used it, because I just don't type package names very much, and > the same goes for features. I think that for packages, the relative > name trick might be quite useful, because I'm aware that some people > prefer to type package names rather than use a whole load of random > packages. And I think Franz-compatible relative names are available > for at least CMUCL, ACL and LW now.
Hmm, yes, looking at the relative-package support has been on my to-do list for a while now, maybe I should check it out. At the moment I'm using MCL, CLISP, CMUCL and SBCL all pretty regularly, so I'm not sure I want to get too dependant on it, though...
> For features I find it hard to imagine a case where I'd be typing > them so often that I'd care, unless I was maintaining something > which was densely conditionalised and thus already in hell. When > code gets like that the right solution is to become a gardener...
It's not typing them that I mind, it's visually scanning through code that's the problem. I don't make heavy use of contitionalization, but often I'll write code so that if, say, garnet, or my package of garnet-related utilities, isn't loaded, significant chunks of functionality will disappear, but the rest of the code will load just fine. So depending on the program, I might have several conditionalizations in there. Using them *this* way, it doesn't make me want to go back to serving coffee.
> Using package nicknames is not a solution because the nicknames can > collide just as easily as the full names.
Well, yes, except I have a utility that manages the naming and renaming of packages for me O:-)
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
> Let me propose #+false as a mechanism that to a lesser extent confuses > separate concepts, even if it still only works by accident.
Someone who pushes :nil or :ignore or :debug onto *features* is going to know there could be trouble. On the other hand, I wouldn't think twice before using :false. This is IMO a *very* bad plan.
> For the next Common Lisp, I'd like to see the feature language > extended with a proper false (and true) expression.
Yuck. Remember, this is just a hack to allow you to comment out an s-expression. Once you're getting into always-true or always-false feature "tests", you're not really using the feature system anymore. If we're going to extend the language to support commenting out s-expressions, why not extend it to do just that. Make #; mean "discard the next s-expression". Don't standardize ugly hacks.
> This as a perferrable alternative to using up another macro > character to achieve form-scope comments.
How on earth do you figure?
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
* Frode Vatvedt Fjeld | My concern is not to push CL towards being less readable than need be.
Curiously, we have exactly the same concern. How about that?
| > [...] How do you /read/ #+feature? What does it /mean/ to you? | | Well, how do you read out #+(or), exactly?
I would appreciate an answer to my questions before you fire off counter-questions as if this was some soft of political campaign.
Since I understand how (or) works in general in Common Lisp, I find no problems reading it exactly as it stands: First, use the following expression when the feature expression holds. And second, which is never. Likewise, (and) always holds. I also think of (or x y z) as the first true value of x, y, and z and (and x y z) as the first false value of x, y, and z. Contrary to how many people read (< a b c), I read it as testing whether a, b, and c, in that order are monotonically increasing values. This is probably because I read < as "less than", I think of the symbol as indicating growth and increasing values. Color me different, but long ago, I discovered that so much of mathematics became unduly hard to grasp if I thought in terms of operations because the operations quickly became so involved that I could not efficiently abstract them away. It is crucial that one understands the relationships involved rather than the operations to compute the values if you want to think mathematically. I see that people who think in terms of operations never get very far in mathematics, too, so I think that I got this part right.
That is, when I see (+) I read "the identity under addition" not "add no numbers together". The identity under veljunction
| My position is to mold that language into being as useful and readable as | possible, rather than holding it to some measure of conceptual purity.
If there is a conflict here, you have the conceptual purity wrong. I think you are massively overreacting to something quite different from what is at hand, and I cannot determine what it is.
| No, #+false or even #+ignore would mean "process the following when the | feature that is guaranteed not to be present in any system is present".
What a silly way to think about this. My god. There is no such guarantee for any individual /feature/ -- you had to create it ex nihilo. (or) and (and), however, embody that guarantee for /feature expressions/.
| Which in the current language can be spelled out as #+(and x (not x)), which | can be reduced to #+(or).
It is nothing if not silly first to invent a convoluted form that does not follow from the premisese and then to reduce it (I am not aware of any rules that make such a reduction possible, though), but I guess this is how you think about this and why you cannot come to grips with the simplicity and elegance of (or) and (and). I see this as evidence of a lack of appreciation of the identity values of operators, which seems incongrous and unexpected. I hope you will find the time to stop warring so stupidly and tell me /why/ you invented this convoluted form and how you reduced it, in that order.
| By endorsing #+(or) you have clearly already made that leap from "does this | feature exist?" to "evaluate this expression", so I really can't understand | your complaining over this.
I have seldom seen less honest argumentation and equivocation in this newsgroup. I have not made any leap like you say I have. Damn you for imputing such stupidity to me! Just because you see things differently does not give you any right you make any claims about what other people think. Do you understand this much? What /is/ it you fight against? What possible motivation could you have to engage in such dirty politics just because you do not "like" an existing facility and have to invent your own bogosity?
The language of feature expressions does not involve evaluation. Why do you fail to understand this? Read the goddamn specification and understand what it says! I believe, however, that the reason you are so confused is that you think a stupid stunt like #+ignore is a good idea and want to abuse the feature expression for some pseudo-natural language processing without actually understanding the mechanism. You have argued for a position that is inconsistent with the actual mechanism and argue against positions that are consistent with the existing facility. Since you /invent/ "guarantees" that some some features will never be in a system without any support for such a claim from the specification, you are clearly not talking about the existing feature framework, but one where feature names "mean" something to the reader when interpreted in the reader's natural language, and you ignore the counter-argument that the vocabulary that programmers would draw from to invent "meaningful" symbols is unbounded, whereas the vocabulary of the feature expression language is well-defined. Then you have the gall to claim that others /also/ "evaluate" the feature expression and the dishonesty to put words in other people's mouth. This is clearly not a "fight" you think you can win with argumentation alone, but have to fight it out with idiotic politics and blame-throwing and imputing positions to your opposition that are far easier to refute than their real positions. I really had thought higher of you than to expect this kind of shit from you.
| I never branded anyone's understanding of this, I was describing the | language/notation that would result from adopting #+(or) etc.
It seems that you make up your mind about consequences without thinking very carefully about any arguments. I think you just "feel" that #+(or) is ugly and react emotionally and unintelligently to it without examining your own reaction. Then you blame other people for your emotional reaction and impute all sorts of evil intentions to them when nonesuch exist. Right?
That you think something bad will result from A does not mean that A is bad /until/ it is taken to the extreme, which normal people would not do. To argue that nothing but the extreme position exists is unbelievably stupid and counterproductive. The fact that /you/ think "false" will never be on the feature list and others "ignore" and "never" and perhaps "nil" or whatnot, however, is cause for concern. There is no natural restriction on the words that some people will think are never going to be used. People use symbols in their natural language, for crying out loud.
| What do you expect the average new CL student's reaction to seeing #+(or) | will be?
I expect the average new Common Lisp programmer to want to know what it means before they react emotionally like some retarded and judgmental idiot who cannot deal with the unexpected and goes screaming to mom when he has to learn to deal with it. I expect the Common Lisp programmer to be smarter than your average person who judges based on his first impression and never thinks about it again.
| Fuzzy pre-understanding is a good thing, it's how everyone gets by in a | complex world.
Sure. But programming is about real and fundamental understanding of the world you want to control and not just to "get by in a complex world". That is, unless you want to communicate lack of precision and fuzzy thinking. in which case a lot of stupid things that people do should be tolerated by their programming languages. I do not want to go down that road. I see that you have taken that road and are quite happy with it. Then you have the gall to argue that you fight against useless conceptual purity. How fucking annoying!
| Also in a learning situation it is almost essential, so long as the implied | understanding follows the pre-understanding.
It is crucial that when it does not, the student /thinks/ and does not leap to judgment based on his pre-understanding emotional responses. More often than not, the pre-understanding is faulty and needs to be updated or even entirely replaced. If you are the kind of person who judges first and never thinks, I should think programming computers would be so frustrating that at the very least you never learn Lisp.
| But I believe in this case the issue is rather about something quite | different, which might be called fuzzy post-understanding. After you have | understood something, you keep it in your active vocabulary by means of any | number of fuzzy mechanisms. I believe that's how the brain works.
I do not disagree with this in general terms, but I find it stunning that you use this theory to reject something you have clearly not thought much about. The use of a feature with a name that one hopes should communicate to other programmers a desire not use it is remarkably naïve. This would be a good argument in favor of obscenities instead of normal words.
It is only when you do not understand how feature expressions work that you can dream up something like #+ignore. If you understood how they work, you would not even /want/ to invent this, but would already understand that you could achieve it with #+(or) and #-(and). But if you first see #+ignore, it takes really good understanding to realize that what people mean is #+(or). (Thanks again, Paul.) #+ignore spreads because it looks OK to the untrained eye, not because it is linguistically sound. The idea that one should test for named features are not even going to be present is severely misguided.
| In my view, #+(or) provides very little for that part of the brain to work | with (in other words, it's unreadable), and for no particularly good reason | other than some sense of purity that, in this smallest and simplest of | languages, is worthless.
So much hostile judgment and so little desire to understand. I could cry.
You have not even tried to understand it, but have made
Erik Naggum <e...@naggum.no> writes: > * Frode Vatvedt Fjeld
> | Also in a learning situation it is almost essential, so long as the > | implied understanding follows the pre-understanding.
> It is crucial that when it does not, the student /thinks/ and does > not leap to judgment based on his pre-understanding [...]
this is to say "pre-" simply means "before", not necessarily "underlying". evolution of understanding does not preclude extinction of misunderstanding. you have to be ruthless w/ these supposedly ephemeral thoughts, sometimes.
Erik Naggum <e...@naggum.no> writes: > Contrary to how many people read (< a b c), I read it as testing > whether a, b, and c, in that order are monotonically increasing > values.
Erik Naggum <e...@naggum.no> writes: > [..] It seems that you make up your mind about consequences without > thinking very carefully about any arguments. I think you just > "feel" that #+(or) is ugly and react emotionally and unintelligently > to it without examining your own reaction.
You are obviously correct that I feel #+(or) to be ugly. I have felt that way about many things and since changed my mind. My examining this particular reaction should be almost literally in your face when you wrote this, however.
> Then you blame other people for your emotional reaction and impute > all sorts of evil intentions to them when nonesuch exist. Right?
These and similar accuasations must stem from grave misconseptions about the most basic premises of why I write what I do, and why I chose to participate in this discussion. I simply don't understand it.
> [..] The fact that /you/ think "false" will never be on the feature > list and others "ignore" and "never" and perhaps "nil" or whatnot, > however, is cause for concern. There is no natural restriction on > the words that some people will think are never going to be used. > People use symbols in their natural language, for crying out loud.
Any such proposals I made was--at least intended to be--in the context of a (hypothetical) revised standard for feature expressions (and as such CL itself). The idea was to pick one symbol that conforming CL implementations would have to ensure that #+ and #- saw like a nonexisting feature. This might not have been very clear, I admit.
Many people read (< a b c) as "a less than b less than c". I think this defeats the purpose of a function-application prefix syntax. I even find the function name "less" to be slightly misleading since the values have to /increase/ from left to right for "less" to return true. Well, anyway.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
> > This means we can write (foo bar #;zot quux) and (foo bar #2;zot quux) > > instead of (foo bar #|zot|# quux) and (foo bar #|zot quux|#), respectively.
> Cool
Yep
> Running lisp with emacs causes troubles. How I can get emacs to > understand?
Well, I'd be happy if anybody had a fix for font-lock and #| |# comments.
Cheers
-- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'.
Marco Antoniotti <marc...@cs.nyu.edu> writes: > Well, I'd be happy if anybody had a fix for font-lock and #| |# > comments.
In XEmacs, this works as expected. I haven't tested this in Emacs, but in XEmacs this is done via the syntax table entries for # and |:
# ' 58 meaning: expression-prefix, first character of comment-start sequence B, second character of comment-end sequence B | . 67 meaning: punctuation, second character of comment-start sequence B, first character of comment-end sequence B
Raymond Wiker <Raymond.Wi...@fast.no> writes: > Marco Antoniotti <marc...@cs.nyu.edu> writes:
> > Well, I'd be happy if anybody had a fix for font-lock and #| |# > > comments.
> In XEmacs, this works as expected. I haven't tested this in Emacs, > but in XEmacs this is done via the syntax table entries for # and |:
> # ' 58 meaning: expression-prefix, > first character of comment-start sequence B, > second character of comment-end sequence B > | . 67 meaning: punctuation, > second character of comment-start sequence B, > first character of comment-end sequence B
That's the easy bit.
If I remember correctly, Emacs' view of comments was that they shouldn't nest properly; this was wired quite heavily into the C engine last time I looked. Unless this has changed, I think that comments of the form #| foo #| bar |# baz |# won't be properly font-locked, and it didn't look trivial to fix.
If it is working in any emacs running on Unix, let me know, please :-)
> > > Well, I'd be happy if anybody had a fix for font-lock and #| |# > > > comments.
> > In XEmacs, this works as expected. I haven't tested this in Emacs, > > but in XEmacs this is done via the syntax table entries for # and |:
> > # ' 58 meaning: expression-prefix, > > first character of comment-start sequence B, > > second character of comment-end sequence B > > | . 67 meaning: punctuation, > > second character of comment-start sequence B, > > first character of comment-end sequence B
> That's the easy bit.
> If I remember correctly, Emacs' view of comments was that they > shouldn't nest properly; this was wired quite heavily into the C > engine last time I looked. Unless this has changed, I think that > comments of the form > #| foo #| bar |# baz |# > won't be properly font-locked, and it didn't look trivial to fix.
I do not think this is the problem. The problem is that font-lock messes up the colors on the definition *following* the #| ... |# commented region.
Any ideas why?
Cheers
-- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'.
