[Axiom-developer] Re: gcl, shared libraries

[Camm Maguire]

Greetings!

C Y <address@hidden> writes:

> --- Camm Maguire <address@hidden> wrote:
> 
> > if 1) GCL is currently deficient for axiom use in some regard and 2)
> > we have difficulties addressing said deficiencies via changes to GCL.
> > If both of these are true, I would greatly appreciate you and/or
> > others letting me know the details, as it is and has been a goal of
> > mine to ensure that gcl remains optimal for axiom use.
> 
> Camm, while it cannot (yet) be said to be part of Axiom, the cl-web
> code does not work on GCL at the moment.  There are two obvious things
> I know of and probably others I don't (yet):  1)  read-sequence doesn't
> seem to be present in GCL 2) I'm using trivial-utf-8 for string->array
> and array->string functionality, and I don't know how or if that would
> work on GCL.
> 

OK, these functions are in 2.6.8pre now.  Please let me know if 2)
presents any problem.

> > I must say I'm less than enamored with the cl-foo library development
> > model. Its source level as opposed to binary, and there is no shared
> > library memory savings.  Beyond which, there really doesn't appear to
> > be much of anything available which is not provided elsewhere in
> > faster, smaller, shareable C libraries, though I haven't made any
> > exhaustive study here. 
> 
> I'm sure there are a lot of opinions on this one.  I'm not quite clear

Yes -- by no means do I suppose mine is correct :-)

> as to why the source level is objectionable (don't we simply compile it
> at build time anyway?).  I like the all-lisp solution for the simple

source is not shareable (system memory)
source pushes on the user all compilation problems and time
source presumes more user expertise, particularly rare in lisp
source leaves more work for the user and less for the provider
source consumes more total system resources
source is less well separated from user code
source is easier to provide, and tends to therefore be more changeable
       and less 'hardened'

These issues are reminiscent of gentoo vs. Debian, bash scripting
vs. C code, and even axiom's decision to ship binaries and not just
source. 

> reason that it avoids any reliance on the behavior of the C language or
> compilers, but that's just me.
> 

All that is taken care of once a binary is loaded, in principle at
least.  With source distributions, we depend on the behavior of lisp
*and* C compilers on said code before it can be used (efficiently).
And, sad as it may be, if rely we must, C is a much stabler target
than any lisp, alas.

> > The primary goal should be in fulfilling the ansi-standard and 
> > supporting applications from the past, while offering non-standard
> > interfaces to newer functionality in external shared C libraries.
> > Do we really think cl-fad has a thirty year lifetime ahead of it?
> 
> Is there any reason to suppose it does not?  If it does not, why not? 
> Can it be improved to the point where it DOES have that lifetime ahead
> of it?  Will the problem it solves go away as Lisp implementations
> improve?
> 

I think of this akin to the lifetime of my scripts, vs. the lifetime
of my portfolio optimization code.  Or Joe's sawfish code to change the
color of icons consistently on kde and gnome, vs. the Linux kernel.
In general the quicker and easier the solution, and the more possible
implementors there are, the shorter the lifetime.  It is a question of
weight.  No one will ever rewrite axiom in a similar time frame.  


> > How will we coordinate with all these cl-library developers external
> > to the axiom project when they move on to other things in life?  
> > Will we read all their source and maintain it ourselves? 
> 
> If that source is literate (in the true literate programming sense)
> this should actually be possible.  Also, if the solutions developed are
> good enought that not many changes NEED to be made, it becomes even
> more viable.
> 
> The core of TeX has not changed in any major way for a LONG time, and
> it is STILL the best tool for the problem it solves.  This is the kind
> of development I would like to see Axiom pursue - the solution of
> problems in such a fashion that there is no need or incentive to solve
> them again.

Could not agree more here.  So we should not rewrite TeX in lisp, but
rather find a way to use this excellent tool from within lisp.

> 
> There should be NO dark corners or black magic anywhere in the software
> chain.  We should be able to look up the code for any point in the
> process, and read the explanations for purpose and method wherever we
> need to.  I know this is not possible at the moment, and maybe not for
> decades, but it is still a goal I would like to work towards.
> 

Agreed.

> Anyway.  Thank you for the work you have been putting into GCL to help
> support Axiom!  My only concrete question at the moment really relates

My pleasure.  And thank you so much for your tremendous contributions
as well!  Axiom owes so much to dedicated developers like yourself.

Take care,

> to read-sequence - is this something GCL plans to add?
> 
> Cheers,
> CY
> 
> 
>  
> ____________________________________________________________________________________
> It's here! Your new message!  
> Get new email alerts with the free Yahoo! Toolbar.
> http://tools.search.yahoo.com/toolbar/features/mail/
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah