RE: [Axiom-developer] Lisp portability

[C Y]

--- Bill Page <address@hidden> wrote:

> On May 21, 2007 10:55 PM Waldek Hebisch wrote:
> > ...
> > currently for clisp I need cl-fad library, which I consider
> > problematic.  Namely, cl-fad does not work with gcl, so for
> > gcl we need separate code.
> 
> In general Camm Maguire (the primary developer go GCL) has
> expressed strong interest in improving GCL's support for
> ANSI common Lisp. If solving the problems of cl-fad on GCL
> would further this goal, I expect that we could count on
> his help (time available of course not withstanding).

I think we need to worry first about ANSI Lisp support and second about
continuing to work on GCL.  GCL is targeting ANSI, so eventually it
should be a moot point anyway, and in the meantime I would suggest we
target the final platform rather than worry about working on
intermediate or outdated Lisp environments.
 
> > We need only few functions from cl-fad, to work around clisp
> > weirdness (clisp makes strong distinction between paths to
> > files and paths to directories and refuses to perform file
> > operations on directories).  So my current plan is to eliminate
> > use of cl-fad and provide the needed functions directly.
> 
> Using a "standard" common lisp package seems preferrable to me
> even if has more functionaly than is currently required.

I would tend to agree.  As we expand Axiom's capabilities we may find
ourselves needing more of the functionality of these libraries.

> > Related problem is performing operations on directories --
> > to gain portability between Unix and Windows I tried to use
> > Lisp code.  But each Lisp is doing them differently (and
> > apparently some operations sometimes are missing). So I got
> > a maze of conditionals over Lisp implementations. Looking at
> > resulting code I feel that it is better to call operationg
> > system utilities and have just use conditionals to choose
> > between Unix and Windows versions of file utilities.
> 
> I hope you mean calling the operating system routines directly
> (e.g. SI:: in GCL) and not resorting to spawning a new process
> to run shell commands (e.g. as is done one in Axiom's OBEY).

Waldek, could you release the conditionalized Lisp code in question
even if we decide not to use it?  It would make an EXCELLENT argument
and case study for making some of these interfaces more uniform between
implementations.
 
> > Concerning sockets, we need Unix domain sockets and select.
> > It seems that clisp provide both, but to get Unix domain
> > sockets one needs version including rawsock module, which
> > is not included in default clisp configuration.  
> > 
> > sbcl offers sb-bsd-sockets which seem to have basic
> > functions, but I do not see select.
> > 
> > gcl documentation suggest that Unix domain sockets are
> > unsupported. Also, I see no traces of select.
> > 
> > There is "portable" cl-sockets library but the manual says
> > it supports Allegro CL, sbcl and cmucl.  The manual does not
> > say anything about Unix domain sockets or select.  The manual
> > says that cl-sockets requires UFFI, so presumably cl-sockets
> > works on top of "portable" C library.

Does http://common-lisp.net/project/usocket/ address this problem at
all?  I don't expect any of these solutions will support GCL at this
time, but hopefully that will come.

I wish we could pull together a meeting of the major implementers of
the Free lisp distributions and the major application developers (ACL2,
Maxima, Axiom...).  Perhaps we could hammer out some common ground on
these issues.  Even an IRC chat could be helpful.

I know I have advocated Lisp implementation independence in the past
and it is still an idea I favor, but if we start to rely on modern
technologies like CFFI, sockets, unicode, telent-clx, cl-pdf, etc. we
run into the problem of simple lack of support for these features in
some of the target platforms.  Looking at the ASDF source code, for
example, one or two of the features of ASDF are not operational on
Clisp due to implementation limitations (apparently.)  I would prefer
to do things the Right Way and ask the implementation if they could
provide support for the missing functionality, as that makes things
much simpler in the long run.

Perhaps we could publish some kind of "missing feature requirements"
report on potential targets for Lisp-Implementation+Operating-System
combinations, once we get a good handle on our requirements.  As people
try to port to various platforms, perhaps we could help guide the
implementers on what features are needed.

CY

P.S. - Waldek, is there a trick to building with sbcl?  I get 
make[2]: *** No rule to make target `sbcl', needed by `do_it.sbcl'. 
Stop.
Sorry if I'm missing something obvious.


       
____________________________________________________________________________________Ready
 for the edge of your seat? 
Check out tonight's top picks on Yahoo! TV. 
http://tv.yahoo.com/