[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: "Fasload"
From: |
Camm Maguire |
Subject: |
[Gcl-devel] Re: "Fasload" |
Date: |
13 Jan 2002 11:52:39 -0500 |
address@hidden (Thomas F. Burdick) writes:
> I almost forgot to reply to this post...
>
> Camm Maguire <address@hidden> writes:
>
> > Greetings! I've taken on the task of maintaining GCL.
>
> Wonderful. Although it's kind of a funky lisp, I'd have been sad to
> see it bit rot.
>
Me too.
> > (The project is currently setup at savannah.gnu.org, for those
> > interested.) I'd like to get the code working on as many platforms
> > as possible, especially, the Linux architectures supported by
> > Debian. The only really non-portable piece, from what I can so far
> > tell, is this bit about "fasloading".
> >=20
> > I don't know the history behind the decision to use this method in the
> > Lisp community, but I am aware that this is a subject which has
> > received some controversial discussion in the context of the future
> > and evolution of the language.=20=20
>
> Two things: GCL does (actually, all Kyoto CL-derived Lisps do, because
> KCL was developed in Japan without much communication with American
> Lispers) things differently than most Lisp implementations; also, Lisp
> systems have traditionally done their own linking (rather than use the
> system linker) on Unix systems because Unix linkers have traditionally
> been toys. If you look at CLtL1 (the standard GCL implements) or the
> ANSI spec (the current standard), you can see that it was pretty much
> impossible to use the system linker in a non-weird way, until fairly
> recently.
>
Thanks for this background!
> > My current strategy is to keep this basic design, but use the bfd
> > library to try to get the elf relocations working portably. But over
> > the long term, I do wonder why it wouldn't be simpler just to compile
> > objects as PIC code, and link them in as shared objects. One will
> > have to decide how to handle the "lisp vector" traditionally appended
> > at the end of the Elf file, but this should not be insuperable.
>
> I think that's a good long-term goal. I'm currently working on a
> Common Lisp compiler that generates C++ code (its goal is tight
> integration with C++ code bases), and that's the strategy we're using.
> When you get to that point, don't hesitate to ask c.l.l, or me
> directly, for advice.
>
I'd appreciate the opportunity to consult with you at this point very
much. Likewise, if you for any reason have particular
suggestions/patches you'd like to see in gcl, please feel free to join
in. There is a website on savannah.gnu.org, and two mailing lists,
address@hidden and address@hidden
> > 1) Am I overlooking something, i.e. is there a really good reason for
> > the existing "fasloading" mechanism which would necessitate keeping
> > it indefinitely?
>
> I'd imagine the reason it's still used is that it will be a lot of
> work to change, and Bill Schelter probably had higher-priority changes
> to make. For example, I know he had begun moving GCL in the direction
> of ANSI compliance. And there's always Maxima, which was basically
> GCL's raison d'=EAtre; speaking of which, are you maintaining that also?
> Or do you know if it's going to be maintained?
>
Yes, maxima has been taken up by a similar group headed by James
Amundson (sp?), and is hosted on sourceforge. They have a very active
mailing list as well. I must confess that a large piece of my
motivation in taking this project on is to try to ensure a fast,
portable, and correct platform for maxima throughout the free software
world.
> > 2) In your experience working with Lisp (of which I have basically
> > none), do you have opinions/suggestions on how object loading
> > should best be accomplished?
>
> Yes, I do :). That's kind of too broad of a question to answer over
> e-mail, or really with anything short of a book. I'm going to be
> writing one or two papers on the topic as handled in the Lisp system
> I'm working on.
>
> I'd highly reccomend looking at the other free lisp systems
> (especially ECL, which is related to GCL, and CMUCL, which is very
> high-quality and much has been written about it), and writing code in
> Lisp on both GCL and other Lisp systems.
>
Thanks for the tips!
> Good luck with GCL, and be sure to keep the community in the know
> about what's going on (via usenet, the CLiki, ...)
>
OK, will try to cc key messages to c.l.l.
Take care,
> --=20
> /|_ .-----------------------.=20=20=20=20=20=20=20=20=20=20=
> =20=20=20=20=20=20=20=20=20=20=20=20=20=20
> ,' .\ / | No to Imperialist war |=20=20=20=20=20=20=20=20=20=20=
> =20=20=20=20=20=20=20=20=20=20=20=20=20=20
> ,--' _,' | Wage class war! |=20=20=20=20=20=20=20=20=20=20=
> =20=20=20=20=20=20=20=20=20=20=20=20=20=20
> / / `-----------------------'=20=20=20=20=20=20=20=20=20=20=
> =20=20=20=20=20=20=20=20=20=20=20=20=20=20
> ( -. |=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
> =20=20=20=20=20=20=20=20=20=20
> | ) |=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
> =20=20=20=20=20=20=20=20=20=20
> (`-. '--.)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
> =20=20=20=20=20=20=20=20=20=20
> `. )----'=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
> =20=20=20=20=20=20=20=20=20=20
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah