[Axiom-developer] lisp portability

[daly]

Gaby,

> the *variabilities* of existing lisp implementations

My largest and most painful C++ effort involved moving a program in
"standard" C++ under Microsoft Visual C++ to GCC. The template issue
alone nearly made me insane. Memory leaks, general protection faults,
float-to-double conversions, random APIs, pointer-conversion warnings,
include-file randomness, named pipes, std:: namespace breakage,
library linkage problems, IDE-hooks, "Microsoft standard extensions", 
typedefs of typedefs of typedefs of (void *), object cleanup, argument
initial-value list processing,....

Compared to that effort the CLtL1 and ANSI lisp compliance for various
implementations is hardly a problem. But I admit to being more fluent
in lisp than C++ so it was mostly me. One of my projects (Magnus,
<http://sourceforge.net/projects/magnus>, infinite group theory)
is in C++ and it is no more or less portable than lisp.

The claim that C++ is "standard" is as weak or strong as the claim
that ANSI is standard. No vendor complies 100% because opinions
vary. If you look at the ANSI lisp standard you'll see "comments" and
"unresolved" issues.  I haven't looked at the C++ standard but I'd bet
that the same things exist there.

I authored a fair amount of the axiom common lisp code and I tend to
use a very small subset of the lisp language so most of the code
should move from CLtL1 to ANSI trivially. I suspect that
package-defining issues and file-system issues are the likely
"breakage" points. Most of the likely problem areas already have #+
and #- conditionals due to past portings.

My point is that, yes, the various "ANSI lisps" have variabilities
but these are generally confined to areas where everybody suffers.
SBCL is struggling with raw sockets on Windows because Windows does
sockets different from Unix. Language standards never cover that.

We most likely will need C code for sockets that is platform specific
if we continue to use the current sman code.  An alternative is to use
a portable lisp socket package and recode the graphics/hyperdoc/sman
to use more portable code.

Personally, I'd go with platform-specific C code for now and then think
about a redesign.






> How do you qualify the one who refuses to listen and understand what
> people are reporting as the problem?

Well, I wasn't trying to be personal about it and "qualify the one".
I don't know but you can choose your own labels, I suppose. Did you
see Bill's comment about "the problem"? He said:

  > More seriously, this issue of Lisp (non)portability is a 
  > major problem.

so I'm not sure that you listened to that. 





and Bill,


>    ...I can not believe that there are/were people 
> on this email list that touted the portability of Lisp as
> a reason for downgrading Axiom code to that level!

Clearly insanity and irrationality reigns over some people.
Since GCL generates C code and C is known to be highly portable
(which is why the graphics and hyperdoc were moved to windows first),
we should simply compile the lisp to C, throw away the lisp, and
we're done. :-)

Bill, exactly how much common lisp have you written?
Do you have a significant common lisp program I could look at?
Are you speaking from experience?

Or are you simply trying to make the point that boot is portable
and lisp is not? If this is your point, please try to state it 
without attacking lisp. And please try to explain why file system
handling and socket handling is any more portable in boot.


t