Sam Steingold wrote:
> Similarly, I want DEF-CALL-OUT with many options, some of which may be
> required, instead of DEF-C-CALL-OUT, DEF-LIB-CALL-OUT,
> DEF-LIB-C-CALL-OUT, DEF-LIB-STDCALL-CALL-OUT &c.
Can you live with
(:library *zlib*) ; This and only this option gets evaluated...
I can come up with that (implementing *FOREIGN-LIBRARIES* list, somewhat different from the list the Amiga has) in the future. Then the library name can be a string (nickname), like with Amiga's DEF-LIB-CALL-OUT. With strings, nobody will care whether this is evaluated or not.
It's more work. This is not ready yet.
> I thought that the DLL FFI will make the current module facility DLL
> based too, i.e., while now modules create their own lisp.run by linking
> lisp.a with their *.o files, the new modules will compile to *.so
> (*.dll) and load them from the lisp code.
This might work on UNIX only.
I believe that what you describe is already there for UNIX systems: SYS::DYNLOAD-MODULES is in pathname.d. It's not documented for whatever reason.
On other systems, a .dll is its own binary, may have an own process space and whatever. It is not an incomplete object which needs to be linked against something to come to life. It's not an .so.
Modules are a portable way to write extensions to CLISP in C. It works on any platform which can build CLISP.
Building a .so or .dll is not portable. The C code becomes cluttered with lots of [WINAPI] __export _SYSCALL _CDECL I don't know about. It might not be available on any platform that CLISP supports.
Current modules are as distinct from shared libraries as libtool modules from shared libraries. Like CLISP modules, they have a special structure and some special identifiers not found in any other arbitrary .so.
There are other differences.
Module's functions are reactivated when a Lisp session is resumed. FFI objects are dead.
Modules can access Lisp objects. The FFI cannot.
Modules present an API based on CLISP's "object model", shared libraries one based on the C model.
Could you describe how regexp could be turned into a .so on UNIX? Maybe the UNIX link-kit script could provide the choice to create an .so instead of a .o?
Probably somebody there has already done that? E.g. whoever wrote dynload-modules (Eric Marsden?)
Is there a ready-made regexp.so found on e.g. Linux distributions? (Isn't regexp part of the Linux libc.a?)
> is this the only place where #+CYGWIN is useful?
> then it's not worth it!
I have no opinion on that.
I realized UFFI has an interesting FIND-FOREIGN-LIBRARY which might work in all cases:
I believe it will look for a mix of a given set of names (e.g. "zlib" "cygz" "libz") and a given set of types (e.g. "so" "dll") and take the first it finds.
Today, I recommended something like this on the UFFI mailing list:
'( #+(and CLISP WIN32) "dll"
#+(and CLISP UNIX) "so"
#+(and CLISP UNIX) "dll" ; for cygwin
#+(and CLISP UNIX) xyz ; for HP-UX
... for whatever 30 systems CLISP runs on.
#+(and CLISP AMIGA) "library"
> I abhor the "many names" approach.
I tend to dislike too much polymorphism as exhibited in UNIX' ioctl() or setsockopt(). Some people find it cool that open/close/read/write/ioctl is all you need on UNIX. I don't. It is appealing, though.