Or for an alternative set of recommendations, see cirCLe and the cirCLe Task List
Problems: As far as I can tell ACL-Compat is not intended as general purpose library -- being focused on "providing enough Allegro interfaces to make porting Allegro code easier", or something like that. UFFI is fine if you need to write portable FFI, but otherwise your implemention's native interfaces are likely to be better. If these are supposed to be recommendations, then as far as I can seem ASDF is in more maintainable state then mk-defsystem, and extensible to boot. For something more focused, please peruse the cirCLe page. --Nikodemus Siivola
Question: Having used ACL-Compat in a couple of asdf-installable libraries I've written and published I've got to ask: if I shouldn't use ACL-Compat as, in part, a portable networking interface, what should I use? What portable networking code is there that I can asdf-install right now and that someone wanting to use my code can install right now? ACL-Compat worked well for me and has allowed someone else to install and run my code, without incident, on a CL implementation and a platform I can't get at and can't test with. -- Dave Pearson
My concern is that we're again failing to distinguish interface from implementation: acl-compat is not an interface, but a partial implementation of sundry interfaces of Allegro CL. Which is to say, if you want to use the ACL networking interfaces you may well find that acl-compat implements them well enough that you can run on other implementations, but you should probably be aware that it exists primarily as "necessary glue to make portable allegroserve? work", and any bugs/gaps/infelicities in it that don't impact paserve may not be an immediate priority for its authors (for whom I am not speaking, btw).
Whether the ACL interface is a good interface (and indeed, which parts of which interfaces provided by ACL are in the scope we're talking about) is another question again. Without having looked hard at it, my impression is "good enough", which at least is an advance on CLOCC PORT. I wouldn't want it elevated to ANSI-like status, but at least it gets the job done. -- Daniel Barlow
The whole point of this page is to list "good enough" solutions, after all. I can see that someone decided against using acl-compat for networking, but I'd like the policy of adding another link if you decide that the current recommendation isn't good enough. If there *isn't* any good-enough library for networking, then write that instead.
- Svein Ove Aas
This was my impression too. When I was looking to make some of my code installable via asdf-install I went looking around here to see what was "good enough" in terms of providing a method of doing networking stuff and would just fall into place if someone did an asdf-install of my code. My impression was that this list was a pragmatic view of what's out there and available and easy to install right now, ACL-Compat seems to fit that bill. If someone has something they think is "just as good enough" or "better at being good enough" then doesn't it make more sense to list that library rather than striking out the items listed here that are known to work and are being used? Given this, doesn't it make sense to remove the strike-out, remove this discussion and get on with looking for "useful right now" libraries and listing them here? -- Dave Pearson
For what it's worth, when I originally created CLiki, it was my intention that pages about software would not only contain details of the software itself, but might include mini-reviews, useful tips, and recommendations for/against it. So although I've removed the strike-out against acl-compat, I'd really welcome it if the people responsible for the various for/against comments would move their commentary to that page. I'll do likewise for mine.
As to this page, I think the recommendations would probably carry more weight if signed, and perhaps accompanied by brief (one sentence) "reasons for nomination", because clearly there isn't the community-wide consensus on some of these choices that would make them no-brainers. -- Daniel Barlow, again
Feel free to move this to the UFFI page, but why the claim that my implementation's native FFI interface will be better? I'm willing to agree that this may be the case today, but it doesn't seem like a good situation. In the sprit of what presumably motivated this overall discussion, wouldn't it make sense for my implementation (using my liberally here, of course) to provide an UFFI-compatible interface, or at a minimum ensure that UFFI wasn't much worse than the native interface? Maybe I'm missing something here, but why should UFFI be worse in the long run? Who wouldn't want portable FFI? Are there implementation/platform specific things that would preclude a portable FFI from being "the right thing"? -- cyrus
It's simple: UFFI is essentially the lowest common nominator, being as it as an additional layer on top of native ones. Very nice as such, but not what you'd end up with if you started designing "a dream FFI": I claim that almost any implementation's native interface is closer to that then UFFI. -- Nikodemus Siivola
I don't buy it. We've got the ability to write (relatively) portable C (or other languages) code, and we have a standardized common-lisp. The bindings between a given common-lisp, on a given platform, with a given shared-library are so non-standard that it warrants having a different FFI for every LISP x platform combination? This sounds insane. I'm totally willing to believe that there are ways to optimize in platform-specific ways and would be happy to see a given CL implementation do this -- under the covers! I'm happy to be proven wrong, but it would seem that if you believe that a CL standard is a good thing and that portable C code is a good thing, you would want a standard way to link those two up. Am I missing something here? - Cyrus
I agree completly with Cyrus. What hurts Lisp a lot is lack of standard library for ffi. Just take a look at java JNI. No matter what implementation on what platform, bridge code is the same. CFFI seems closest guess because it works on widest range of implementations and platforms. Also, standard interface for socket? and threads is a must. It's 21st century. Why would anybody care about implementation specifics when coding in lisp. One should be able to write standard lisp code and don't care about implementations. Maybe it's time for CLTL3?. -- Marko Kocic
I'd really like to see a list like the above that is dynamically updated with popularity ("I use this") votes - digg type thing. Collapsed view would show just the highest rated of each library type or user could expand a lib type to see all contenders with their popularity rankings. - Cid
This page is linked from: Bindings for libraries Library
CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively