Subject: Re: Allegro compilation warnings
From: Erik Naggum <>
Date: 14 Oct 2000 01:18:44 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* Marco Antoniotti <>
| 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,

  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.

  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?

  I agree with everything you say, but I would
  attack to death your right to say it.
				-- Tom Stoppard