[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Axiom-developer] Lisp portability

From: Bill Page
Subject: RE: [Axiom-developer] Lisp portability
Date: Mon, 21 May 2007 23:19:03 -0400

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

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

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

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

Again I believe both cl-sockets and UFFI have been discussed
as possible targets for GCL. I am not sure how close to reality
such support might be. Camm?
> In short my finding is that portable Lisp sockets are a myth:
> all implementations provide different interface and frequently
> miss some essential services.  People who want portablity
> between Lisp implementations interface to C. 
> Given that it seems that most reasonable way for Axiom is to
> use existiong C code.  There is are drawbacks: we need to
> interface to C and typical Lisp implementation can only
> interface to shared libraries via dlopen.  So we need to
> handle issues related to making shared library.
> But AFAICS we will need C interface anyway, so we need to
> resolve problems of C interface and shared libraries.

+1 Yes, this is very important.

Bill Page.

reply via email to

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