In article <··········@fido.asd.sgi.com> ·······@engr.sgi.com (Mike McDonald) writes:
>In the Unix world, I can pretty much count on a Motif library being
>available for the machine, usually at a pretty "reasonable" cost. In
>the Lisp world under Unix, there is no standard GUI library. The two
>major vendors push CLIM for thousands of bucks. There is no cheap,
>compatible implementation for any of the public domain lisps. So, I'm
>back to the position, when I need to have a GUI for my code, I write
>the whole thing in C/C++. It's a pretty sad state of affairs, from my
>point of view.
Well, there is a free lisp with a full interface to Motif called
Winterp. Since it's free you can use it on any machine you care to
name.
The bigger problem here is the lack of a stardard C interface for
lisps. Until that exists, any package, such as Winterp will only run
on top of the lisp version it was built for.
--
---------------------------------------------------------------
| Chris Bitmead.....................................9690 5727 |
| ·············@Alcatel.com.au............................... |
---------------------------------------------------------------
"Simply drag your mother in law's mobile phone number from the
Address Book to the Laser Satellite icon, and the Targeting
Wizard will locate her. Then follow the onscreen prompts for
gigawattage and dispersion pattern..."
·············@Alcatel.com.au (Chris Bitmead) writes:
>In article <··········@fido.asd.sgi.com> ·······@engr.sgi.com (Mike McDonald) writes:
>>In the Unix world, I can pretty much count on a Motif library being
>>available for the machine, usually at a pretty "reasonable" cost. In
>>the Lisp world under Unix, there is no standard GUI library. The two
>>major vendors push CLIM for thousands of bucks. There is no cheap,
>>compatible implementation for any of the public domain lisps. So, I'm
>>back to the position, when I need to have a GUI for my code, I write
>>the whole thing in C/C++. It's a pretty sad state of affairs, from my
>>point of view.
>Well, there is a free lisp with a full interface to Motif called
>Winterp. Since it's free you can use it on any machine you care to
>name.
>The bigger problem here is the lack of a stardard C interface for
>lisps. Until that exists, any package, such as Winterp will only run
>on top of the lisp version it was built for.
I don't think that makes too much sense. The semantics of alien
integration for the various implmentations of Lisp are too
different. Just a few points:
- Is your Lisp runtime capable of holding alien data in Lisp data
structures, so that the alien data for arguments doesn't have to be
rebuild on every invocation on a function?
CMUCl does so using (with-alien ...) and friends
- Is the Lisp runtime capable of *using* alien data? That means,
if a Lisp variable holds an alien structure, can you access
individual fields and use that data in Lisp?
CMUCL can.
- Will you need an additional level of subroutines like the Java VM
from Sun does (and many Scheme implementations)?
Or, more general, do you need C code in addition to the alien code?
- Will memory allocated in aliens be handled by the Lisp Garbage
collector?
One example are Strings in CMUCL. In CMUCL, strings are represented as
a data structure that has a plain chain of simple characters inside
it. It always keeps a NULL at the end, although it mananges the length
of the string different for its own needs.
The result is that you can pass a string to a C alien subroutine just
by passing a pointer past the header of this Lisp object. No
conversion has to be done.
How should a portable alien interface preserve this advantage?
I think any solution for this that has a performance disadvantage is
doomed to do more harm than good, damaging Lisp performance
reputation.
There is, BTW, some kind of a "standard" alien interface. It is part
of ILU, Xerox's distributed objects system. ILU defines a Lisp macro
that describes an alien function in a portable manner. Someone how
will port ILU to a new Lisp implementation should implement this macro
so that the native alien description is generated.
But, and that is my point from above, this solution will convert data
on every call. So, for example CMUCL's abitity to hold C data in Lisp
structures so that ot can be reused over several invocations of the
alien routine is not used.
In addition, a simple Lisp macro will not be sufficient to do it for
*all* Lisp implementations. For example, the aliens of Scheme-48/scsh
need additional C code. If you generated the C code on invocation of
this Lisp macro, you would rebuild the whole C stuff on every load of
the Lisp file.
A standard alien interface that keeps the maximum performance of every
Lisp implementation will need abstract layers for:
- Describing an Alien function
- Describing alien data
- Definition of Lisp variables that hold alien data
- A mechanism to access data inside alien data hold by Lisp
variables.
An then, most important, how will you handle cases where the lisp
runtime lacks one of these features? For good performance, there is no
other way than to conditionalize code on the base of lack or suport of
features.
ILU is at
ftp://parcftp.xerox.com/pub/ilu
For more Info about CMUCL, see:
http://www.cons.org/cmucl
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"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