gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] CLtL1 (was Axiom build error)


From: Michael Koehne
Subject: Re: [Gcl-devel] CLtL1 (was Axiom build error)
Date: Mon, 28 Jun 2004 21:50:02 +0200
User-agent: Mutt/1.3.28i

Moin Camm Maguire,

> OK, I'm missing the head of the thread so far, but first off, axiom
> will not build with gcl in ANSI mode due at the very least to the
> in-package issue.

  Axiom does not build, because it does'nt build by design ;( The idea
  to requiring a source code, to patch it - could be done in a patch
  like mine - but is a shoot in the foot for any project that lasts
  longer than half a year - Axiom build is not obscure, its opaque ;)

> GCL will support both CLTL1 and ANSI modes going
> forward.  Hopefully this will be considered a strong feature of GCL
> given all the historical high quality work done under the earlier
> dialect. 

  I have to disagree here - The CLTL1/ANSI double coding is a pain in
  the ass, and should be dropped together with all those broken #ifdef
  UNIX constructs. 

  e.g. implementing pprint-dispatch was'nt that difficult - but I'm
  currently stuck, because I'm unable to raise a 'type-error form a
  ./lsp/*.lsp file, because clcs does'nt exist at this moment.

  So lets throw away the complete ./clcs/ directory and rework all
  errors to become conditions.

  Same with PCL - PCL is like a shiny hype on top of a rotten base.
  CLOS should go into the GCL kernel - perhaps with a few small *.lsp
  functions aside.

  One might use CLTL1 behavoir by pushing :CLTL1 to *features*, to
  supress ANSI only error conditions, if GCL is implemented in a way
  that its mostly ANSI with CLTL1 backward compatibility.

  e.g. my current in-package is a special - and not a macro - so its
  able to 'eat shit' and deal with the old compiler and old code - and
  also with new ANSI code from Common Lisp Controller.

  So #:foo and 'foo and "foo" are all valid as packages, and :use '(lisp)
  is still possible. But there is an ANSI only error condition, if the
  package does not yet exist. This condition wont happen, if :CLTL1 is
  in *features* - thus we would have a GCL that is able to run ANSI
  CL by default - and offers some CLTL1 backward compatibility tricks,
  if in need.

  This backward compatibility is not a big problem, e.g. I'm compiling
  and testing Maxima on regulary base. But this is impossible for Axiom.
  reason : see above !

  Axiom should become able to compile from a plain /usr/local/gcl, else
  nobody could support it. If this means, that we need to extend GCL
  to incorporate some good things from Axiom - than we should include
  those Axiom patches, or provide a way for a user to tweak some
  variables. e.g.:

  gcl-2.6.1.o.main.c.patch
  - increasing stack size should become a command line option
  gcl-2.6.1.unixport.init_gcl.lsp.in.patch
  - quite start should become a command line option
  gcl-2.6.1.cmpnew.gcl_cmp????.lsp.patch
  - is not necessary, just (setq *suppress-compiler-notes* t)
  gcl-2.6.1.h.linux.defs.patch
  gcl-2.6.1.unixport.makefile.patch
  - Axiom should use compile-link, to build its own first image,
    as long as we dont have a elf-loader using -ldl.

Bye Michael
-- 
  mailto:address@hidden             UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1'
  http://www.xml-edifact.org/           CETERUM CENSEO WINDOWS ESSE DELENDAM




reply via email to

[Prev in Thread] Current Thread [Next in Thread]