From ... Path: supernews.google.com!sn-xit-02!sn-xit-03!supernews.com!freenix!fr.clara.net!heighliner.fr.clara.net!news.tele.dk!148.122.208.68!news2.oke.nextra.no!nextra.com!newsfeed1.enitel.no!nntp.newmedia.no!news.funcom.com!Norway.EU.net!127.0.0.1!nobody From: Erik Naggum Newsgroups: comp.lang.lisp Subject: Re: ACL 6.0 Trial Edition ships with non ANSI reader behavior. Date: 07 Nov 2000 04:57:40 +0000 Organization: Naggum Software; vox: +47 800 35477; gsm: +47 93 256 360; fax: +47 93 270 868; http://naggum.no; http://naggum.net Lines: 297 Message-ID: <3182561860085563@naggum.net> References: <3182371042747250@naggum.net> <3A04CA75.96A92BE8@fisec.com> <3182450051259505@naggum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: oslo-nntp.eunet.no 973573161 9805 195.0.192.66 (7 Nov 2000 04:59:21 GMT) X-Complaints-To: newsmaster@eunet.no NNTP-Posting-Date: 7 Nov 2000 04:59:21 GMT Mail-Copies-To: never User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 Xref: supernews.google.com comp.lang.lisp:3373 * John Foderaro -> Lieven Marchand | Are you suggesting that we remove everything from our Lisp that isn't | part of the ANSI standard? John, please listen, now. Nobody is suggesting any such thing. Least of all I, but you know that, already. I support what you do in extra-standard work. I have argued strongly, vociferously, and fervently at times, that people _should_ use implementation-defined extensions both to the language (like the effect of threads on the binding behavior of special variables) because that moves the language _forward_. I don't support what you do to _break_ the standard, because that moves the language _backward_. | Case sensitivity is just one more variant. In fact it's far less | likely to be a porting issue than, for example, the particular | foreign function interface you use. It would be even less of a problem if you didn't break the workings of readtable-case. I have shown you, with the code to support my claim, that your choice to break that functionality is gratuitous at best, and purposefully undermining the standard because you think that particular functionality is a kludge to fix a botch at worst. Your insistence on not getting this has pissed me off for a long time, and you're doing exactly nothing to understand it now, either. | Ever since the Common Lisp definition started to gel evolution in the | Lisp language has slowed. Lisp used to be a springboard for | experimenting with language ideas, then change became a dirty word. | So yes, we have to get Lisp jumpstarted again. I think I have said so quite explicitly, but I said one more thing that you consistently omit: First we fully implement the _entire_ standard, because that works as a better springboard to really know what needs to be changed or expanded. If you jump from a broken springboard, it's just foolish to blame non-broken springboards, but that's what you keep doing, John. Because you _break_ the standard you don't like, you _blame_ the standard for not supporting what you need, and use that as an excuse to continue to dislike it, but this is fantastically counter-productive. But as I have shown you, by nuking that stupid *force-readtable-case-raw* thing, you can get what you want _within_ the standard operating parameters of the readtable and the printer control variables. Take this to heart. | > Although I like case insensitivity, and find very little value in | > your |field| vs. |Field| example from a software engineering | > aproach, | | If you look at object oriented case sensitive languages you'll | generally find this is the convention they use (Smalltalk, C++, | Java). Others have chosen a namespace-like approach. Like Common Lisp does special variables with *stars*, Dylan has classes with . I actually think this makes a helluva lot of sense, that it is quite elegant, and furthermore, the abuse of case reminds me of German. The use of underscores is clearly Too Ugly, so some fools instead went for AlternatingCapitalLetters, which I can't help snicker at -- it looks like the really want to be programming with crayons! With their keyword-rich languages and highly redundant syntaxes, exactly what kept them from using internal _whitespace_ in identifiers? If you look at the grammars of these languages, you find that there _is_ room for internal whitespace in identifiers. So why don't they? Braindamaged language designers who can't think outside of the box they live in, that's what. I don't think caving in to other language's bad choices is a good choice for doing stupid things in Common Lisp. Common Lispers are like English-speakers: used to words with several meanings depending on the context and any modifying words in the context. This is not a problem that needs solving. In languages designed by people who have never quite progressed beyond coloring the parts of speech differently when parsing sentences, hating the fact that many words exist in multiple roles, they can't have an identifier named the same as a type, or a function the same as a variable. This is so _ridiculous_! How could anyone _be_ so unintelligent as to set this kind of mess up for himself? Now, why do I want a Common Lisp with case sensitive symbols and normally all lower-case symbols? Because I want the _freedom_ of actually referring to a symbol as, say, NORDPOOL in all caps, and have it print back to me the same way it was read. That has nothing to do with what other languages have conventions for -- the fact that they _have_ those conventions _came_ from that freedom, so it's the (fundamental) freedom I want, not their (random) conventions. | That's the key point I've been making. Old code continues to work | either in ANSI mode or in Modern mode. This is just plain wrong, John. It is only true if you follow Franz Inc coding standards in ANSI mode. People don't do that. They'd have to change their ways to use a case-sensitive Lisp no matter what you think, precisely because of the nature of the change. I'm staring in disbelief at your repeated assertions that I know to be completely untrue and I wonder what the hell you're thinking. Who the hell do you think you're fooling with this useless propaganda? | That's my #1 goal for without it we require everyone to choose one | or the other and people will just stick with the old ANSI version. I have given you an alternative that you won't listen to: Switch to lower-case symbol names as a separate step from case sensitivity. That way, people will find their dependencies on case first, and when that is gone (since it's a good idea not to have that kind of dependencies, since the case of symbols is an arbitrary decision). This can only be done if you are honest about the case change, which you are not, and which it bugs me to no end that you don't realize. _When_ people have become accustomed to lower-case symbols and have stopped making assumptions about the internal case of symbols, there's a natural fall-out: case sensitivity will be much closer, and much less harmful to introduce to the Common Lisp world. If you introduce case sensitivity with lower-case symbols at the same time, you will meet with legitimate and strong resistance, because it is just too much at once. Contrary to what you think, there _is_ no migration path from a Lisp with upper-case symbols and a case-insensitive reader to a Lisp with lower-case symbols and a case-sensitive reader which you can walk, carrying all the baggage in one trip. If you have to make several trips, you need to break the migration path in two or more parts so people can make one trip per "leg" in the whole migration path, but they must also not be allowed to return. Each step must leave something behind that you _don't_ want. In the case of Common Lisp, you are asking us to leave too _much_ behind that we are supposed not to want, like your stupid (sorry, John, but that's exactly what I think it is) disdain for the standard's solution to the problem of case, and we won't move. Enticing people to make changes in their lives is hard work, but there are some things you need to do right: First, make them want to move by offering something at the other end of a journey across the migration path, but also make them want to leave something they do not want behind and make sure the two are so tightly coupled they can't have one without leaving the other. Second, make sure that you can't go back and pick up your old ways, or people will do just that. The leaving behind thing is serious business. (You seem to think that people are as disgusted with the case issue in Common Lisp that you cannot fathom that people do not want to leave readtables behind, but that's your _big_ mistake.) This wisdom actually comes from my father, who was in charge of "rationalization" at an industrial plant when I was just a kid. At the time, it was a problem that workers returned to their old ways despite what the management thought were good reasons to move to a new way of doing things. The problem wasn't that the reasons were not good enough. The problem was that they _could_ return. All the effort of the rationalization had been spent on making the move into a smooth process, like crossing a plain. But that's just wrong. You have to cross a hill or at best a mountain pass to move to a better world and _stay_ there. That's why I don't move to the U.S. -- it's easy enough for me to get the best of both worlds, not to mention some crucial developments in the politics of the U.S., what with the dire consequences of having that moron George W. Bush in the driver's seat for four to eight years and his Supreme Court justices and other key personnel in charge for the next several decades, I imagine myself wanting out of there like so many other Americans currently feel like fleeing the place before it's too late. What you are suggesting to us all, John, is that we leave behind the things in the standard that you personally hate with a passion. (Please don't try to deny this -- at first I couldn't believe the hostility towards the resolution to the case issue in Common Lisp that you harbored.) But most of us don't feel that way about these issues. On the contrary, many of us are actually happy with the way it has been decided and how it has worked out. We're not going to pick up your hatred and leave all that behind. You're not that good a cult leader, John, and if you think in cult terms (like a "Modern Cult"), you're doing it all wrong. The Common Lisp community is just that: a community, where we _respect_ a common set of rules and laws and standards. You don't. That's _your_ problem, not ours. You _must_ be thrown out if you persist in disrespecting what the rest of the community respects. Don't do that to yourself! This is a fight you can't win. You can win if you _don't_ fight, however. If you want us to do something differently, make sure we get something back for doing it that can motivate us to join you. The freedom of using and preserving case information is enough for me, for instance. The simplicity of dealing with symbols that look excatly like they are written is appealing to me. I think upper- case symbols look old and clunky and don't want to explain why we do things that way to people I'd like to use Common Lisp, not the least because I fail. Case is an arbitrary decision if you have a case insensitive reader, but like all arbitrary decisions, they have to fall down on one side, and that side invariably carries some kinds of connotations with it. Upper-case communicates "old and clunky" to a lot of people. I'd like to move away from that to a new world. But you can't lie to people if you want them to join you. That only works for idiots who run for President, and that's only because they get much power it's worth the loss of credibility to get it. You are not going to get any power just because some Lispers move from upper- to lower-case symbol names, and you have already realized that you aren't going to get the entire community with you, anyway. That code written to ANSI X3.226-1994 is going to continue to work when ou downcase the symbol names and don't even downcase in the reader, but claim that you upcase, insead, is just obviously false. I can't believe you think you can fool anyone with that hoax, John. It pisses me off that you do, too, because it's such a gross insult to people's intelligence. Common Lisp programmers are among the very smartest programmers around. You treat them like they are stupid because they don't _rebel_ against upper-case symbol names when it's _you_ who are stupid because you _rebel_ instead of work _with_ the community to make this at first an implementation-defined property of the Common Lisp implementation. The way you're going about this case issue has bugged me for years. The way you have consistently denigrated those who don't agree with you on the case issue may in fact explain why they stick to _their_ ways instead of listening to you, and why you don't budge, either. I was not there at the time, but I have a feeling from what I have read in the publicly available notes, that you went about this as irrationally and counter-productively in the committee as you do now and that you failed because you never realized that in order to get your choice, you have to make the other choice available, too. If we shall ever succeed in getting Common Lisp away from specifying that all symbol names are in upper-case and that the reader upcases, we must make it implementation-defined, forcing people to check if they need to know, and use symbols to get their names, not the other way around, meaning that the reader has the _only_ opportunity to leave _its_ decision behind in the code. This means full support for readtable-case and the printer control variables, which you hate. This means that the Franz Inc coding standards that works for both lower-case and upper-case Lisps becomes more popular, and we can get a new and better world where the internal case of symbols no longer matters. But we do this the community-friendly way, through the standards bodies, with working systems that _respect_ the work of the standards bodies and the communities behind them. You have shown us that a lower-case Lisp works just fine. That is good. I have shown you that you don't have to break readtable-case to get that lower-case Lisp. That is good, too. Now we can show people that if they write code that does not assume an arbitrary decision has been made one particular way, they will win something and write better and more robust code, too. That is a good way to go. A splinter group, a Modern Cult, an implementation broken in the way it deals with specified behavior, is a very bad, very stupid way to make a community move in your chosen direction. I am so thoroughly annoyed with you for not using your sometimes brilliant mind to get this simple picture, but continuing to do stupid things that hurts the Lisp community with your hatred for parts of the standard. You have not listened to me before, and I sort of doubt that you will listen to me now, but you're a really smart guy with a serious hangup that needs to be cured before you can get the respect your work deserves. The reason is that you don't respect those who hold opinions on the case issue different from your own and ignore their needs and their requirements, which are far more important things than whether some code "works" or not. With a standard, we build a society based on trust in common resepct for the standard, in best-effort implementations of it, and we hold implementers harmless for mistakes if they also work to fix them. With a standard, we build communities that work and communicate together with a common baseline that is not subject to violation except by malicious outsiders, criminals, and destructive forces of other kinds. With a standard, we sign contracts and pay monies for work assuming the entire contents of the standard as part of the specification for that work by reference. With a standard, we take part in a very, very long legal tradition that extends far beyond programming and contracts: That of trusting an authoritative third party to resolve our disputes, reasonable as well as unreasonable. With your standards-breaking attitude, specifically that _you_ should be that authority (no longer a trusted third party) and that whatever _you_ decide shall prevail, you throw not just some parts of this framework of trust out the window, but _all_ of it. This works for Microsoft because they have succeeding in building their own society and community around trust in their authority, such as it is. Microsoft has built their community around them. Franz Inc is a vendor that sells to a community they have not built on their own. They do not own the community and they cannot dictate the community will. Franz Inc _chose_ to implement Common Lisp instead of continuing Franz Lisp. That meant something to you once. It means something to me now, and not just because I like the way the standard does things, but because I like standards as such, because I like lawa snd organized societies that relieve me of fighting for my rights all the time so I can instead form bonds with people based on mutual trust and respect. Granted, today's political reality is a far cry from what I expect and want to live under, but my operating principle is that _I_ shall not contribute to any further destruction of society-building mechanisms as defined and reasonably well upheld. I am deeply insulted and offended when you don't give a fuck about these principles, John, and just want to go off and destroy all the work that went into building this community just because you harbor a long-standing hatred for the committee's choice of upper-case symbol names. Let's build a bigger community, not more and smaller societies. Let's find ways to make room for your lower-case needs within the important political desire not to specify arbitrary decisions so strictly that reasonable choices are no longer available. And that includes you, John: You have to make room for the upper-case needs and other people's desire to have reasonable choices, too. #:Erik -- Does anyone remember where I parked Air Force One? -- George W. Bush