Re: [Gcl-devel] General GCL quesions

[Camm Maguire]

Greetings!

Eric Merritt <address@hidden> writes:

> > With that said, I have for some reason been
> > particulary drawn to GCL,
> > even after having read a *lot* of the (historical)
> > posts on c.l.lisp
> > where GCL is discussed. 
> 
>  In my experience the comments about GCL on c.l.l are
> almost always negative. I am not really sure why. Sure
> gcl has its problems, but no more or less then any
> other FOSS implementation.
> 

I'm not really sure why this is either.  But I suspect that at least
some component stems from the general attitude among lisp developers
that public domain stuff is better than GNU-like licensed software.
My opinion is that while the former may be in some commercially minded
developers' best short term interest, the latter is definitely more in
the best interest of the users and the long term viability of the
project as a whole.  I also think that this apparent bias towards
closed source lisp has nearly (or actually, only time will tell)
killed the language, with all the resultant implementation fracturing,
etc.  Am hoping that GCL can be to lisp what GCC has been to C.

> > To be honest, my attraction
> > to GCL is against
> > my better judgement - if I were to emphasize
> > practicality, I think I
> > would have to settle on CMUCL - 
> 
>  CMUCL has at least one critical problem that forces
> me not to use it. It doesn't run on windows.
> Personally I hate windows and use linux 99% of the
> time, however, many of the people who use my projects
> run windows exclusivly and can't or wont use linux. 
>  
>  GCL has at least two major pluses that interest me.
> It has a really excellent C-FFI and its very cross
> platform. These make it worth using in my book. The
> fact that its nativly compiled is just icing on the
> cake.
> 
> > And
> > if it weren't for GCL's stated intention of gaining
> > ANSI compliance,
> 
>  its not just an intention, camm and the guys have
> been working very hard to get GCL complient. Right now
> GCL passes the vast majority of the tests in the ansi
> test suite.
> 
> > I'd be in a real pickle since CLISP - the only other
> > 'free as in
> > speech' lisp of which I am aware - doesn't compile
> > to native code,
> > which is a 'must' for me.
> 
>  I have a problem with this too.
> 
> > So - to my questions:
> > 
> > * Is there no GCL users' newsgroup/mailing list?  I
> > couldn't find one.
> >   It seems such a group or list is de rigeur, so I'm
> > curious about
> >   this.  Is there a MAXIMA group where people
> > discuss GCL?
> 
> Hmm, good question. I have never seen one, but it
> makes sense that there should be. 
>  

Just tried to add one now on savannah, and apparently this facility is
temporarily disabled.  Please remind me in a bit and I'll try again. 

> 
> > * How may one determine the status of ANSI
> > compliance, for example for
> >   version 2.5.0+cvs, the current Debian stable
> > version?  This would be
> >   *extremely* useful in determining debugging
> > strategies when trying
> >   to load generally available packages.
> 
>  Once again 2.5.0 is old. I don't have a clue as to
> its level of complience.
>   
> > 
> > * How much of GCL is written in lisp?  Would it be
> > worth it for me to
> >   get the lisp sources?
> 
>  I think a good portion, if not the majority of gcl is
> in lisp.
>   
> > * Is GCL meant to be a niche product - MAXIMA/ACL2
> > support + Tcl/Tk?
> >   If so, shouldn't that be stated somewhere?  Or are
> > the GCL
> >   developers intending on making GCL more broadly
> > usable?  What is
> >   being done in this respect?
> 
>  MAXIMA/ACL2 seem to be gcl's primary customer and
> hence get allot of attention, but gcl is a full blown,
> well implemented lisp. So I don't think its a niche
> product.

Just wanted to add axiom to this list.

>  
> > * What lisp would the GCL developers recommend for
> > Debian users who
> >   would like to write web apps (at *least* to access
> > postgres
> >   databases) in a truly free lisp?  Please keep in
> > mind that this, for
> >   me at least, requires some sort of
> > multi-processing - I'm fine with
> >   select-based stuff for the web side, in fact I
> > prefer it, but
> >   databases usually require full-on threads - and
> > AFAIK, neither GCL
> >   or CLISP seems to do either type of
> > multi-processing.
> 
>  At the moment gcl doesn't have any multitasking at
> all. I don't the devs have any plans for it anytime
> soon, though it has been discussed.
> 

I think it is a question of priorities.  Most would rather us improve
ansi compliance first, no?

> > 
> > Am I wrong in thinking that neither of the truly
> > free lisps is going
> > to be really suitable for such common tasks any time
> > soon?  Or are
> > people going to suggest that I write/port threading,
> > a web server and
> > postgres support?
> 
>  Threading is going to be a pain, I am not sure any
> newb is capable of implementing true preemtive
> threading in gcl. I have been playing with a
> cooperative multi-tasking library, but that wont fit
> your needs at all becuase blocking io will still block
> everything. 
> 
>  That said, python's twisted matrix has managed to
> implement database multiple io in a single thread
> (including database io) perhaps it would be possible
> to port this. 

This should be possible with select.  I've actually written a C
library that can multiplex web page sockets, and might integrate this
into GCL at some point if there is interest.

> 
>  There is no  need to port a webserver, gcl has really
> excellent integration with C. I would suspect that you
> could interface with apache's mod_c very easily if
> mod_lisp didn't work.
> 
>  I am not aware of any current libs for postgresql
> support in gcl. This sucks I know, but it would
> probably be no more then a few ours work to integrate
> with the postgresql client libs. The C support in gcl
> is really quite good. 

Agreed.  I actually have a rudimentary C lib interface via libpq which
could be linked in too.  the main issue is that GCL is a compiler, and
can't possibly explicitly include hooks into every popular external
library.  What we should focus on is making it very easy to write such
interfaces from information in the C manpages, hopefully as easy or
easier than writing the code in C itself.

Take care,

> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - File online by April 15th
> http://taxes.yahoo.com/filing.html
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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