Quote: For every desired CL implementation, build the actual wrapper code from the abstract description, using the respective foreign function interface. (ffi: for CLISP, alien: for CMU-CL, ff: for Allegro CL 5 and 6, ...)
IMHO uffi would be a better sollution so you won't have to reinvent the wheel ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(disclaimer: I'm still "getting a bearing" on wxLisp, at the moment -- just heard about it, tonight) but:
this proposal sounds great, to me.
Incidentally, UFFI is already being packaged for Debian/Sid (and maybe for the 'Sarge' Debian release, and maybe others), in the regular packages repository -- so, I guess that one could say "code re-use" or somesuch, about it.
(Of course, I have no idea as to what implementaiton changes would be needed, in any particulars, for it, but patches are patches and revisions are so, heh)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Of course, not re-inventing wheels is a nice thing, but the particular wheel needed here is not yet invented for 3 reasons:
1) I only skimmed over UFFI, but it looks like it doesn't currently produce code for CLISP. Making such code would be crucial because CLISP -- although using a bytecode compiler -- produces shockingly fast numerical code, able to beat CMU LISP compiled code. (I'd guess this is due to the sqeezing work of Sam Steingold of the CLISP project group.)
2) UFFI's licence is the special Franz Allegro Somewhat-lesser-than-GNU licence, which is not legaly compatible with the BSD license which is currently in favour on the wxCL project.
3) Also, don't forget that there's a "w" at the 1st position of "wxWidgets" (the new name of "wxWindows"). Although it stands for "Windows", a certain operating system of bad reputation, it means that any true implementation of wxCL must run with at least one CL system on the operating system in question. I'm not sure if UFFI does address CLs on "Windows".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Quote: For every desired CL implementation, build the actual wrapper code from the abstract description, using the respective foreign function interface. (ffi: for CLISP, alien: for CMU-CL, ff: for Allegro CL 5 and 6, ...)
IMHO uffi would be a better sollution so you won't have to reinvent the wheel ...
(disclaimer: I'm still "getting a bearing" on wxLisp, at the moment -- just heard about it, tonight) but:
this proposal sounds great, to me.
Incidentally, UFFI is already being packaged for Debian/Sid (and maybe for the 'Sarge' Debian release, and maybe others), in the regular packages repository -- so, I guess that one could say "code re-use" or somesuch, about it.
(Of course, I have no idea as to what implementaiton changes would be needed, in any particulars, for it, but patches are patches and revisions are so, heh)
Thanks for suggesting UFFI.
Of course, not re-inventing wheels is a nice thing, but the particular wheel needed here is not yet invented for 3 reasons:
1) I only skimmed over UFFI, but it looks like it doesn't currently produce code for CLISP. Making such code would be crucial because CLISP -- although using a bytecode compiler -- produces shockingly fast numerical code, able to beat CMU LISP compiled code. (I'd guess this is due to the sqeezing work of Sam Steingold of the CLISP project group.)
2) UFFI's licence is the special Franz Allegro Somewhat-lesser-than-GNU licence, which is not legaly compatible with the BSD license which is currently in favour on the wxCL project.
3) Also, don't forget that there's a "w" at the 1st position of "wxWidgets" (the new name of "wxWindows"). Although it stands for "Windows", a certain operating system of bad reputation, it means that any true implementation of wxCL must run with at least one CL system on the operating system in question. I'm not sure if UFFI does address CLs on "Windows".