gcl-devel
[Top][All Lists]
Advanced

[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



reply via email to

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