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