[Top][All Lists]

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

Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructi

From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] conditions/clos/gcl unified build patch and instructions.
Date: Fri, 07 Jun 2002 19:36:06 +0300

John Jorgensen wrote:

> > Please don't hurry with committing. We have to sort out new
> > basic CL package and check how Maxima works with
> > renewed GCL setup.
> It looks like all of the packages (and name strings) are built in
> package.d from line 1050 to 1068 (in current CVS). For instance,
> lisp_package denotes the "LISP" package. It should be possible to make a
> couple of packages "common-lisp" and "common-lisp-user" right in C. I'm
> still unclear on a couple of the parameters to make_package right now
> though.

I also though originally about renaming LISP -> COMMON-LISP
and USER -> COMMON-LISP-USER on C level.  But it now I don't
that that it is right thing to do.  If we just rename it then it will brake
compatibility with old GCL code.  Certainly we can  make CL and LISP
to be aliases to new COMMON-LISP (former LISP) package.
But  the point is that LISP has a lot of non ANSI symbols which is
prohibited by ANSI standard.

So I suggest the following scheme:

1. Let LISP remains as it is without any modification for the sake of

2. We create new package COMMON-LISP (CL) and populate it
with all required by ANSI CL symbols importing them from LISP,

3. We rename USER to COMMON-LISP-USER with aliases CL-USER
and USER.

The only thing which is not clear to me is the contents of CL-USER.
As standard requires we must import in it all symbols from COMMON-LISP.
But probably we want to see here some other useful implementation dependent
symbols like BYE, QUIT.  On the other hand it is not wise to expose here
all GCL specific symbols like this notorious INT.

> Also in main.c, there is an example of how to use the C functions import
> and export to import nil (Cnil) and t (Ct) into a package. This should
> solve the NIL problem that you mentioned (There's nothing like working
> around a bug instead of fixing it. ;).

Yes but we certainly want that all functions import, export, use-package
work correctly on the lisp level.

> Once nil (and possibly t) are imported into the packages, the rest of cl
> and cl-user could either be populated the lisp way, or the same way that
> GCL does a lot of it (in C files).
> J*
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel

     Vadim V. Zhytnikov


reply via email to

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