Subject: Re: Legal ANSI comment form? From: Erik Naggum <erik@naggum.no> Date: 28 Aug 2002 01:14:05 +0000 Newsgroups: comp.lang.lisp Message-ID: <3239486045052686@naggum.no> * 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 up your mind long before understanding set in that this was unreadable. Such judgmentality is really harmful to achieving useful results. Mind you, I paid no attention to #+ignore /until/ I thought about it and saw how awfully stupid it is. It was "acceptable" because I ignored the actual meaning of #+ and looked only at the word "ignore". This also caused me to misread feature expressions that were more complex. From what you say, you do exactly the same thing: You do not find #+(or) readable /because/ you think #+ignore should make sense when it clearly does not. | > 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. You failed. You keep imputing positions to me that I do not hold. I hate it when people lack the willingness or perhaps ability to distinguish between what they think somebody must have meant and what they have heard them say. Like, today, I learned that Fraunhofer and Thomson want a small license fee (USD 0.75) for every MP3 decoder (not just the encoders), and a rather naïve friend of mine was outraged -- not because of the facts he had just learned himself, but because he had to invent some motives for this when he could not accept the position emotionally, and then got all worked about these motives that he had imputed to the license holders. | The short form is this: 1. We need a form-scope comment syntax. "Form-scope"? | 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). I think #; is a really good idea. I have embellished it with a count, using the usual infix numeric argument to skip that many expressions. This may not be a great idea, but it is conveniently available. (defun sharp-semi (stream char count) (declare (ignore char)) (let ((*read-suppress* t)) (dotimes (exprs (or count 1)) (read stream nil nil t))) (values)) (set-dispatch-macro-character #\# #\; 'sharp-semi) 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. | 3. #+(or) etc. is too cryptic. This is an emotional argument from ignorance, and consequently has no weight at all. | 4. So define a less cryptic false feature expression. So learn the language and use it to its fullest extent. Shying away from certain forms of expression because some people might not get it, is wrong. That is how bad programming languages develop for bad programmers. -- 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.