This is intended for small layers like socket interface, foreign function interface, etc. Not for heavy stuff like HTTP servers, even if one is included in a particular implementation for instance.
UFFI an universal foreign function interface.
CFFI, the Common Foreign Function Interface.
clocc-port contains several compatibility layers.
ACL-COMPAT is a free implementation of parts of Franz' ACL API
CL-FAD is a portable pathname library based on the book "Practical Common Lisp"
Common-Lisp-POSIX a "compatibility layer" for POSIX systems. I'm afraid it won't be small.
PortableReadtables a compatibility table to make it easier to use readtables across multiple CL implementations.
Bordeaux-Threads offers cross-platform threading.
trivial-garbage is an interface to GC-related features such as finalizers, weak hash-tables and weak pointers.
I'm not sure that the scope of this page is clear. When does something qualify as
Or to put it another way, with what is UFFI compatible?
I think the meter to use to measure these implementations is whether they work on all the ANSI CL implementations. Some measures can be devised to categorize the different "compatibility" levels of libraries and packages.
E.g. UFFI would get a very high mark in compatibility. McCLIM a lower one.
Marco Antoniotti.
OK but how to compute this mark ? Marc Battyani
My idea of a compatibility layer is a thin layer of code that provides an unified access to some existing functionality. UFFI, acl_compat and some stuff in CLOCC are in this category. They should be available separately so that somebody needing to use sockets should be able go get a socket layer and not a full library/application. Using these layers the more higher level libraries should be portable. For instance CLSQL relies on UFFI to be portable on several implementation.
I'm considering the position that there should be no thin wrapper layers, that there should only be implementations of APIs. It may just be a different label for the same thing, but I think it has an effect in terms of expected quality--an implementation for a particular lisp may in fact be a thin layer, but when I hear "thin layer" I think "incomplete implementation."
I also think when it comes down to it, applications and higher-level libraries need complete implementations of APIs.
Indeed. An ACL implementation of acl-compat is the null layer. An implementation for a CL with no bundled socket support at all would be a considerably thicker layer. The API is the same in either case no matter how many hamsters are running round in wheels underneath. --Daniel Barlow
I'm surprised to see that there are problems with the 'thin layer' term. For me a thin layer does not mean an incomplete layer (Well, I'm not a native English speaker...). A Lisp socket API is just a layer above the C socket API of the OS. AllegroServe or CL-HTTP are not. I'm open to other definitions. What kind of definition do you propose ? Maybe we could qualify them as low level instead ? Marc Battyani
Let me give another example, which might be clearer: suppose somebody wrote a library to send mail to Internet hosts, by invoking sendmail as a subprocess and feeding the mail body to it. This would by your definition be a "thin layer", I believe. It probably consists of about one line of code per supported Lisp in fact, if CLOCC PORT's RUN-PROG is anything to go by.
Now somebody else wants to port their application that uses this layer to Windows, or some other environment where sendmail is not installed. As there is no equivalent functionality to use, he writes a complete SMTP client. It has to deal with MX lookups, retries, bounces and all the rest of that stuff, and it presents the same interface as the original library. I don't think this is any longer a "thin layer" in implementation terms, but as far as the library user's concerned it does exactly the same thing.
Do you see what I'm getting at? Difficulty or size of the library implementation should not be an important criterion for the user of the library's interface.
The ALU site has a wiki section for standardization efforts in the Standard and Quasistandard.
Pages in this topic: ACL-COMPAT BORDEAUX-MP CL-FAD external-program ffa Portable-Threads PortableReadtables Toplevel trivial-features trivial-garbage
Also linked from: Common String development index thread
CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively