[clisp-list] RFE: list-external-modules

[Hoehle, Joerg-C. <Joe...@t-...>]

Sam answered one of my queries:
>>did I send a few weeks ago a RFE or e-mail or whatever
>> for either LIST-EXTERNAL-MODULES or *EXTERNAL-MODULES[-LIST]*?

>I don't remember anything like that.
>Why is this necessary?
>we have *MODULES* already.
That's for PROVIDE/REQUIRE.

I was talking about what CLISP calls external modules. CLISP could provide the list of module__fastseq__xyz things it knows as a list.

That's useful for interactive self-inspection ("how comes this #!@$% replies FFI::LOOKUP-FOREIGN-FUNCTION: no such function "foobar" to my DEF-CALL-OUT?! :(")
(LIST-EXTERNAL-MODULES) -> ("fastseq" "ffimext" "regexp" "gdi" "mtest" "hinbug" "receiver") => "Ah, I started the wrong binary.".


>you appear to indicate that when you get dlopen interface in, these
>external modules will become obsolete anyway.
I don't think so. I believe there will be less use for them. I laid out pros and cons in my article on the subject of extending CLISP via modules.
When I asked Dan Stangers on his thoughts on that topic w.r.t. gdi, IIRC he said he still considers the approach he took as best.

For instance,
o external link modules compile on any plattform where CLISP compiles on,
o while the FFI does not.
o functions of external modules are made valid again when starting from an image. There's no working concept ready yet for that with shared libraries.
o Modules provide init_functions() for further, automated customization.
o many more ...

I still see the external module system as providing the basis for user-configurable CLISP.  E.g. dirkey ought to be turned into a module.
Even sockets could have been conceived as a module, if they had been ready by then (and resolving some GC interaction problems). The FFI itself could have been a module (with a little work).

Programmers will have a choice of using either shared libraries of modules for quite a few, but not all, areas. I believe shared libraries have a smoother learning curve, but modules offer more integration into Lisp, e.g. directly (efficiently) use CLISP vectors (including for integers or strings) instead of copying data around, and much more.

More pros and cons in my article...

Maybe the following applies:
o thin-bindings & don't mind programming like C: use foreign library - if available.
o Thick bindings, integrate well into Lisp, need something special from CLISP, care about portability and user-site configuration: use module.
MS-Windows users will probably do a lot with shared libraries, since their are ubiquituous, like on the Amiga. It would be stupid IMHO to build a link module and link in kernel32.lib in order to acccess kernel32.dll.

That's why until now, I haven't had a use for FFI with Amiga-CLISP, except to test that it compiles (and that it has callbacks and many more features). The AFFI is enough to access next to any shared library on the Amiga, and that's what people there want. I believe the same will happen to MS-Windows users, for many uses.

My current design thoughts go towards a mean of loading a file containing DEF-CALL-OUT etc. which might not have to be changed whether the user has installed something as a shared library or an external module. That's a portable unified interface to both.

Regards,
	Jorg Hohle.