Subject: Re: Allegro compilation warnings From: Erik Naggum <erik@naggum.net> Date: 14 Oct 2000 01:18:44 +0000 Newsgroups: comp.lang.lisp Message-ID: <3180475124104589@naggum.net> * Marco Antoniotti <marcoxa@cs.nyu.edu> | Come on Erik! Just _fix_ your attitude problem, Marco. Unless, of course, the _intent_ of your messages is to piss me off. | You very well that if I write an ACL DEFSYSTEM spec it simply won't | run on CMUCL. Unless somebody "ported" ACL DEFSYSTEM (or LispWorks, | or MCL DEFSYSTEM) to CMUCL. The most interesting property of a language is whether it has been specified so that it may be implemented independently. If it can't, don't ever use it. Portable code is red herring when it comes to sharing information that uses code as its vehicle of transportation and existence. Portable code has in fact led to serious problems when languages only exist as a single implementation that runs "everywhere". I'm not sure whether your "If only X were in the standard" recently was meant as a strong opinion that people should not use that which is not in the standard, but the Standard you allude to is a document ath allows people everywhere to implement the language and places requirements on the implementation. | In the current state of affairs: MK-DEFSYSTEM runs (more or less) on all | platforms. This is not necessarily a good thing. This means that there will be only one implementation of it because other implementations are not worth writing. This leads to cancer of the language it implements. | I'd rather "write things once" if I can. Writing with ACL DEFSYSTEM | will make me write things at least twice. You _could_ implement the language used by Allegro CL's defsystem. | You can always write things in Scheme and then port your Scheme | program from implementation X to implementation Y by rewriting the | code that does "records" or "multi-dimensional arrays". The semantics | is pretty much the same. The syntax as well. Why are you not getting it? You're so favorable to XML, yet you don't even seem to grasp that the idea behind XML is that it's a syntax standard that people implement in order for their data to be at least parseable from implementation to implementation. You don't want "A portable XML parser". You want "portable XML data". | As per the way I work. I organize my code in such a way that it is | easily structured using MK-DEFSYSTEM. Languages tend to shape the way we think. | And in my reply I said you are right in this respect. However, XML | somewhat frees C/C++/Perl/Java/Python/Ada95/Intercal/Kwikkalkul | users from the burden of writing an AST constructor for their | documents. Which is what you get for free when using CL. *IMHO*, | this has an immense pragmatic effect and a potential for speedup in | the day-to-day life of programmers. I may be wrong on this. _Why_ does it have that potential? Is it because there is a common standard that many people _implement_ and conform to, or is it because there is code that is portable from C to C++ to Perl to Java to Python to Ada 95 to Intercal to Kwikkalkul or whatever? I'm not interested in what a program does with my data when I choose to use a syntax like XML (or SGML). I'm interested in making sure that I can write a new application according to a specification that will be able to read and process it without having access to the (probably portable, too) code that processed it initially. | Erik. I really do not understand this. I am missing the use of | "build rule" that you make. The information you write down in your defsystem rules are intended to help you build the system, right? Like a makefile builds stuff. Of course, "building" in Common Lisp also means loading it into a Lisp system and perhaps dumping a new image, but the whole idea is that you have a bunch of sources, a bunch of build rules, and if you apply the build rules to the sources, you end up with a product. Those relationships are important to preserve and describe accurately. That's why a _common_ defsystem is important. That's why a portable defsystem is probably not a good thing, because there will never be anyone who argues for or against features in it, no arguments over the implementation or the precise semantics, only "does it work or not"-style questions, which are anathema to the value of the described relationships. | If I can say something in my defense (which may imply an | interpretation of what you just wrote which may be incorrect), I | wrote CL-CONFIGURATION to address this sort of issues. With | CL-CONFIGURATION you can :REQUIRE-SYSTEM which has been written in a | number of different and incompatible DEFSYSes. In this way you | don't have to translate. I don't expect CL-CONFIGURATION to be | perfect, but I find it useful. Bad solution to the wrong problem. If you had written this utility to read the language used by the various defsystems and produced some common form that could build with your system, we might be getting somewhere, but as long as you only identify the interpreter of the descriptions, you help kill the information, i.e., making it _more_ dependent on the specific interpreter of its representation. | > Methinks you've been had, big time, by the XML hype and have | > missed the opportunity to think about information representation | > entirely, instead confused into thinking that some irrelevant | > piece of the puzzle needs to be "portable" (the syntax or the | > implementation), and that that's it, we can all relax now and | > ignore the cost of conversion, irritation with subtle | > differences, and the mysterious bugs that crop up because we | > poor humans remember too well. | | That's why I wrote CL-CONFIGURATION and CL-ENVIRONMENT. I haven't looked at them, but from what you describe, they fall in the category of "stop-gap solutions that block real progress", like a huge number of other software "solutions" to fundamental problems. People will appreciate it, of course, and it does solve a problem that people actually have, but they have it for a bad reason, and it should not be solved for another bad reason. That way lies Perl. | It also *runs* on Lispworks, MCL, CMUCL, CLisp, ACL, and -- I hope | -- Corman Lisp, EClipse and -- maybe -- GCL, ECoLisp and ECLS. This is good if you go for the monopoly control situation where you want everybody to use your _implementation_, but the more you keep telling me it runs everywhere, the more important it is to make sure the language it interpretes is specified externally to it and actually is implemented by someeone else, too. | Fine. I wrote CL-CONFIGURATION for you. I hope that one day you will at least listen enough to what I keep telling you in more and more different ways in the hopes of one day getting through the belief that you unquestionably do the right thing that it may not be the right thing. So: No, you didn't. If anything, I want a standardized defsystem whose semantics is the object of standardization, not the code. When we have some code that gets standardized, we all lose, because the standard becomes "whatever the code does", and thousands of people will hack at the code and standard means exactly nothing. When we standardize languages, we all win, because thousands of people will have a single, authoritative source, and will fight to have people agree with them on what the specification should say. Since people put in special cases in code and exploit them to no end, but can't get away with it in specifications, the means of control over the run-away programmer is a good specification. From one data point, you can extrapolate in any direction. From one implementation, you can standardize in any direction. | BTW. I started using MK-DEFSYSTEM because I started working with | GCL and CMUCL and then I pretty much went down the road you went. Then how did we end up so astonishingly far apart? #:Erik -- I agree with everything you say, but I would attack to death your right to say it. -- Tom Stoppard