CLISP has got my interest - and I would like to know a few things.
How 'portable' (say, from Win95/NT to Linux to MAC) is CLISP? I take it
ANSI is to imply portability like this?
Is there a GNU or free/lowcost CLISP which is 100% (or 99.99%) ANSI?
Where can I find the names of some developers & commercial programs which
are 100% CLISP? Or, is that information not available because no one
(commercially) develops with it?
I would like to develop using a very high level language << which is also
portable across several platforms and OSes >>. Failing finding a high
level language which can accomplish this, I am willing to use something
like 'c' if that is required :(
I value any URLs, tips, inforamtion, or leads you can provide. Thanx.
Brett
Raymond Toy <···@rtp.ericsson.se> writes:
>Erik Naggum <····@naggum.no> writes:
>>
>> [Mark Pedersen]
>>
>> | CMU Common Lisp is ANSI, and now available for Linux.
>>
>> CMUCL 17f was not ANSI. have the Linux porters moved CMUCL up to ANSI?
>If it wasn't ANSI, then it's probably still not ANSI. The porting
>effort has been to get it running better on FreeBSD and Linux, with
>some bug fixes and small enhancements.
I don't think that is true. The porters have done a lot of non-porting
enhangments and fixes and now that the port is done they obviously
seek for a new challenge :-)
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@wavehh.hanse.de> http://www.bik-gmbh.de/~cracauer
"As far as I'm concerned, if something is so complicated that you can't ex-"
"plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
In article <····················@wavehh.hanse.de>, ········@wavehh.hanse.de
(Martin Cracauer) wrote:
> Raymond Toy <···@rtp.ericsson.se> writes:
>
> >Erik Naggum <····@naggum.no> writes:
>
> >>
> >> [Mark Pedersen]
> >>
> >> | CMU Common Lisp is ANSI, and now available for Linux.
> >>
> >> CMUCL 17f was not ANSI. have the Linux porters moved CMUCL up to ANSI?
>
> >If it wasn't ANSI, then it's probably still not ANSI. The porting
> >effort has been to get it running better on FreeBSD and Linux, with
> >some bug fixes and small enhancements.
>
> I don't think that is true. The porters have done a lot of non-porting
> enhangments and fixes and now that the port is done they obviously
> seek for a new challenge :-)
How about adding multi-threading?
Rainer Joswig
······@lavielle.com (Rainer Joswig) writes:
>In article <····················@wavehh.hanse.de>, ········@wavehh.hanse.de
>(Martin Cracauer) wrote:
>> Raymond Toy <···@rtp.ericsson.se> writes:
>>
>> >Erik Naggum <····@naggum.no> writes:
>>
>> >>
>> >> [Mark Pedersen]
>> >>
>> >> | CMU Common Lisp is ANSI, and now available for Linux.
>> >>
>> >> CMUCL 17f was not ANSI. have the Linux porters moved CMUCL up to ANSI?
>>
>> >If it wasn't ANSI, then it's probably still not ANSI. The porting
>> >effort has been to get it running better on FreeBSD and Linux, with
>> >some bug fixes and small enhancements.
>>
>> I don't think that is true. The porters have done a lot of non-porting
>> enhangments and fixes and now that the port is done they obviously
>> seek for a new challenge :-)
>How about adding multi-threading?
That's what I'd like most (for obvious reasons, given my
network-centered work today :-), but I already did too much
"triggering" and too less own work, so I don't complain and hope for
some "magic" suggestion to our CMUCL wizards...
When the GC is rewritten anyway, it is at a turning point, however.
What's all that talk about being ANSI or not, BTW? Useful work will
always use some amount of extensions, so a bit more system-dependency
or not will not matter that much. Given that the differences are
small, which is the case at least for CMUCL.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@wavehh.hanse.de> http://www.bik-gmbh.de/~cracauer
"As far as I'm concerned, if something is so complicated that you can't ex-"
"plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
From: Raymond Toy
Subject: Re: Any free/GPL/low-cost (linux) fully *ANSI* CLISP pkgs ?
Date:
Message-ID: <4nk9syh6di.fsf@rtp.ericsson.se>
········@wavehh.hanse.de (Martin Cracauer) writes:
>
> Raymond Toy <···@rtp.ericsson.se> writes:
>
> >Erik Naggum <····@naggum.no> writes:
>
> >>
> >> [Mark Pedersen]
> >>
> >> | CMU Common Lisp is ANSI, and now available for Linux.
> >>
> >> CMUCL 17f was not ANSI. have the Linux porters moved CMUCL up to ANSI?
>
> >If it wasn't ANSI, then it's probably still not ANSI. The porting
> >effort has been to get it running better on FreeBSD and Linux, with
> >some bug fixes and small enhancements.
>
> I don't think that is true. The porters have done a lot of non-porting
> enhangments and fixes and now that the port is done they obviously
> seek for a new challenge :-)
I think "small enhancements" may be an understatement. The porters
are working pretty hard (in their spare time) to make the x86 version
leaner and meaner. The calls to external C routines are being sped up
(upto 25% in some cases), the compiler is a bit smarter with floating
point, a generational GC is being worked on, and general bug fixing is
proceeding. I don't think anyone is actively making CMUCL fully ANSI,
but it seems pretty close to ANSI to me.
I think that's quite a bit of challenge already! :-)
Ray
From: Mark Pedersen
Subject: Re: Any free/GPL/low-cost (linux) fully *ANSI* CLISP pkgs ?
Date:
Message-ID: <53kgg8$kcc@miso.cs.uq.edu.au>
In <··········@Godzilla.cs.nwu.edu> ·····@cs.nwu.edu (Seth Tisue) writes:
>In article <··········@miso.cs.uq.edu.au>,
>Mark Pedersen <·····@cs.uq.edu.au> wrote:
>>I don't have a wide experience of different lisps, but there tends
>>to be variation between implementations on certain (you guessed it)
>>implementation-dependent functionality. Just like how there are a number
>>of PROLOGs that implement the Edinburgh standard but are still not
>>cleanly portable, the same applies to Common Lisp.
>This is much too pessimistic. The Common Lisp standard is an very
>extensive and complete standard. Of course, there are minor
>variations between Lisp implementations, within the guidelines set by
>the standard. But Common Lisp is extremely portable by any measure.
>It was designed from the beginning with the explicit goal of
>supporting portable code. I've frequently moved code between
>Macintosh, PC, and several different Unix Lisps with only the most
>trivial changes needed.
Well, all I can say is YMMV. In my experience of trying to compile
a large package that was developed under Lucid, I woulnd't say that
the changes necessary were trivial. Admittedly, the CLs I've had at
my disposal have been CLISP, gcl and CMU-CL - there have be various
levels of success with each of these. Colleagues of mine finally got the
thing to partially work under Allegro after 2 weeks of hard slog. Now
this is my only experience of porting a Common Lisp package, and I was
surprised at how Un-Common the various implementations appeared to
be. Perhaps this is the fault of the authors of the package, not the
fault of the Common Lisp standard, or even the developers of the various
CL implementations.
So, I guess that you can write code yourself that might be trivially
portable because it actually *is* Common Lisp, but you can't depend on
something claiming to be Common Lisp to work straight out of the box, or
even with minor tinkering.
Mark
--
-----------------------------------------------------------------------------
Mark Pedersen | email : ·····@cs.uq.oz.au | http://student.uq.edu.au/~s303080
"When freedom destroys order, the yearning for order will destroy freedom."
In article <··········@miso.cs.uq.edu.au>,
Mark Pedersen <·····@cs.uq.edu.au> wrote:
>Well, all I can say is YMMV. In my experience of trying to compile
>a large package that was developed under Lucid, I woulnd't say that
>the changes necessary were trivial. Admittedly, the CLs I've had at
>my disposal have been CLISP, gcl and CMU-CL - there have be various
>levels of success with each of these. Colleagues of mine finally got the
>thing to partially work under Allegro after 2 weeks of hard slog.
Interesting. What sorts of changes were needed?
>So, I guess that you can write code yourself that might be trivially
>portable because it actually *is* Common Lisp, but you can't depend on
>something claiming to be Common Lisp to work straight out of the box, or
>even with minor tinkering.
True. It is always possible to write non-portable code which happens
to work on a particular implementation.
--
== Seth Tisue <·······@nwu.edu> http://www.cs.nwu.edu/~tisue/
From: Mark Pedersen
Subject: Re: Any free/GPL/low-cost (linux) fully *ANSI* CLISP pkgs ?
Date:
Message-ID: <53vd3e$k0i@miso.cs.uq.edu.au>
In <··········@Godzilla.cs.nwu.edu> ·····@cs.nwu.edu (Seth Tisue) writes:
>In article <··········@miso.cs.uq.edu.au>,
>Mark Pedersen <·····@cs.uq.edu.au> wrote:
>>Well, all I can say is YMMV. In my experience of trying to compile
>>a large package that was developed under Lucid, I woulnd't say that
>>the changes necessary were trivial. Admittedly, the CLs I've had at
>>my disposal have been CLISP, gcl and CMU-CL - there have be various
>>levels of success with each of these. Colleagues of mine finally got the
>>thing to partially work under Allegro after 2 weeks of hard slog.
>Interesting. What sorts of changes were needed?
Can't fill you in on that one, as I wasn't involved in the port. I
think at least part of the problem had to do with the logical pathnames
mechanism. That at least seems to differ from implementation to
implementation.
Mark
--
-----------------------------------------------------------------------------
Mark Pedersen | email : ·····@cs.uq.oz.au | http://student.uq.edu.au/~s303080
"When freedom destroys order, the yearning for order will destroy freedom."
From: Mark Pedersen
Subject: Re: Any free/GPL/low-cost (linux) fully *ANSI* CLISP pkgs ?
Date:
Message-ID: <53kfde$k7q@miso.cs.uq.edu.au>
In <··············@rtp.ericsson.se> Raymond Toy <···@rtp.ericsson.se> writes:
>Erik Naggum <····@naggum.no> writes:
>>
>> [Mark Pedersen]
>>
>> | CMU Common Lisp is ANSI, and now available for Linux.
>>
>> CMUCL 17f was not ANSI. have the Linux porters moved CMUCL up to ANSI?
>If it wasn't ANSI, then it's probably still not ANSI. The porting
>effort has been to get it running better on FreeBSD and Linux, with
>some bug fixes and small enhancements.
>However, of the free Lisps that I have used (gcl, clisp), it is
>probably closest to ANSI, followed by clisp, and then gcl.
OK - this is more what I meant when claiming CMU-CL to be ANSI : it is
the closest to ANSI. Thanks for the qualification, Ray.
mark
--
-----------------------------------------------------------------------------
Mark Pedersen | email : ·····@cs.uq.oz.au | http://student.uq.edu.au/~s303080
"When freedom destroys order, the yearning for order will destroy freedom."
From: Raymond Toy
Subject: Re: Any free/GPL/low-cost (linux) fully *ANSI* CLISP pkgs ?
Date:
Message-ID: <4niv8hh42w.fsf@rtp.ericsson.se>
······@lavielle.com (Rainer Joswig) writes:
>
> In article <····················@wavehh.hanse.de>, ········@wavehh.hanse.de
> (Martin Cracauer) wrote:
>
> > Raymond Toy <···@rtp.ericsson.se> writes:
> >
> > >Erik Naggum <····@naggum.no> writes:
> >
> > >>
> > >> [Mark Pedersen]
> > >>
> > >> | CMU Common Lisp is ANSI, and now available for Linux.
> > >>
> > >> CMUCL 17f was not ANSI. have the Linux porters moved CMUCL up to ANSI?
> >
> > >If it wasn't ANSI, then it's probably still not ANSI. The porting
> > >effort has been to get it running better on FreeBSD and Linux, with
> > >some bug fixes and small enhancements.
> >
> > I don't think that is true. The porters have done a lot of non-porting
> > enhangments and fixes and now that the port is done they obviously
> > seek for a new challenge :-)
>
> How about adding multi-threading?
What about it? When will you have it done? :-)
But seriously, there are only about 3 people that I know of working on
it and it's all in their spare time. I don't think anyone is working
on threading. But if someone wants to do it, I'm sure no one will
refuse the contribution. :-)
Ray
In article <··············@rtp.ericsson.se>, Raymond Toy
<···@rtp.ericsson.se> wrote:
> > How about adding multi-threading?
>
> What about it? When will you have it done? :-)
Sorry, neither do I use CMU CL nor do I have the time and
knowledge of CMU CL and Unix to implement threads.
But while people are hacking
around with the CMU CL implementation, it could be
a nice thing to add, since it would enable the use
of Common Lisp software that needs multiple threads
(such as CL-HTTP).
> But seriously, there are only about 3 people that I know of working on
> it and it's all in their spare time. I don't think anyone is working
> on threading.
Sigh.
> But if someone wants to do it, I'm sure no one will
> refuse the contribution. :-)
Rainer Joswig
In article <··········@miso.cs.uq.edu.au> ·····@cs.uq.edu.au (Mark Pedersen) writes:
Can't fill you in on that one, as I wasn't involved in the port. I
think at least part of the problem had to do with the logical pathnames
mechanism. That at least seems to differ from implementation to
implementation.
I think it's mainly a Lucid problem.
As far as I can remember, Lucid used to have a not-quite-correct
implementation of the logical pathname mechanism. My first own
attempt at making a small completely portable CL program (in 1988)
had to have lots of #-LUCID's around the pathname-handling stuff,
and I later heard that there were still problems with Lucid,
though I didn't use it myself anymore.
Another thing that I've seen make people frustrated, is the package
mechanism. I think the main problem is that some implemenations are
too liberal when it comes to redefinition of packages, thus leading
programmers to producing non-standard code which may be very cumbersome
to clean up afterwards (i can't remember who's the "sinner" here, but
it wasn't Lucid).
Espen Vestre