Re: [Axiom-developer] Lisp portability

[Waldek Hebisch]

CY wrote:
> --- 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.
>  

1) I need GCL support for regression testing.
2) I hope that Aldor lesson should be clear: avoid waiting on third
   party, this may take long time.  In GCL case we may count on
   goodwill of Camm, but still I do not think taht we should
   cut off our life support and hope that it will be restored 
   on time.
3) ATM core of Axiom is written in a very small subset of Lisp,
   sitting in the intersection of Cltl and Ansi.  We need conditionals
   for things going beyond Ansi or Ansi violations.  Directly
   here GCL is just one more implementation.  Indirectly, we can
   not use some Ansi features.  IMHO _that_ can wait for Ansi
   GCL.

Back to cl-fad: its use of packages is incompatible with Cltl.  If
IIRC Ansi GCL misses one or two odd functions.  But beyond that
we would have to add to cl-fad a bunch of conditionals to
cover GCL case.  That is, we would have to use forked version
of cl-fad.

> > > 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.
> 

cl-fad really provides very little functionality: the only nifty
feature is ability to recursively walk directory tree.

> > > 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).
> 

I mean spawning processes.  I know that Windows does not like this,
but is it really that bad?  As alternative I consider rolling
our own C library -- it seems that _no_ Lisp implementation
give direct access to system calls.

<rant>  People frequently wonder why Perl is more popular than Lisp.
Already 15 years ago Perl allowed you to call the 'syscall' system
call -- which means that if Perl missed some OS function (it supported
a _lot_ of them out of the box) one could roll Perl code to
work around the problem.
</rant>

> 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 did not investigate deeply, but the web page does not mention
Unix domain sockects or select...  They clearly say that UDP is
is not ready, and mention a lot of little details about things
alredy done, so they probably even have no plans for Unix domain.
 
> 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.
> 

configure --with-lisp=/full/path/to/sbcl

Current SVN should not require this.  There is good chance that
sbcl from current SVN will bootstrap algebra, but I still have to
commit many fixes.

-- 
                              Waldek Hebisch
address@hidden