[Openmcl-devel] sockets and compatibility
jjwiseman at yahoo.com
Mon Jul 1 17:06:58 UTC 2002
Hamilton Link wrote:
> Depending on who's writing the code, this wouldn't save you from
> conditionals -- I'd be surprised if not many people want their code
> to run under both MCL and OpenMCL.
Using the acl-socket-*.lisp files that are part of portable
allegroserve and provide an ACL-compatible socket interface, I
actually am able to use the same code in openMCL, MCL, ACL, and CMUCL
without read-time conditionals (modulo the openMCL package issue).
(It looks like I could use LispWorks too, but I don't have access to
> Plus having the same package name may end up implying more identical
> functionality than is actually the case; recall good design is that
> the more identical two things look the more identically they should
> behave. I'd hate to have unported code load, only to break at run
> time due to subtle functional differences.
Yes, definitely. Though in the case of sockets I would be 100% behind
trying to converge on the compatibility of interfaces rather than live
with gratuitous incompatibilities (not that all incompatibilities are
gratuitous--but lets make sure there really is a reason for any
incompatibility). OpenMCL appears to be at least sympathetic to the
ACL API; I guess I would just hope that if it were not going to be as
compatible as is reasonably possible that there would be a good reason
for it first. I don't know of a good reason for sockets to be in CCL.
> IMHO a better bet is to conditionalize the package declaration of
> the code you're developing to have this or that symbol list imported
> from a "portable-socket" package instead of directly from the local
> socket package, whatever it's called.
This would probably be better current practice, yes, but I feel that
is due to the unfortunate state of cross-lisp socket interface
incompatibility rather than being inherently desirable.
I would much rather write code that says "to use this, your lisp must
support this socket interface." Which can work even for the lisps
that haven't been thought of yet, that I can't write read-time
In fact, that approach is even realistic, given that ACL's socket
interface seems to be becoming the de facto standard portable socket
package, based on OpenMCL's choosing to use it, along with the portable
> In systems that don't have a suitable function set, you can "roll
> your own" and import that instead, so only the portable package
> declaration and your personalized TCP wrappers change from system to
I don't know. I use four different lisps regularly, and the less work
I have to do to make my code work in all four, the happier I am.
Using personalized TCP wrappers also harshes my code-sharing buzz,
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel