Newsgroups: comp.object,comp.lang.lisp
From: cyber_surfer@wildcard.demon.co.uk (Cyber Surfer)
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!udel!gatech!swrinde!pipex!demon!wildcard.demon.co.uk!cyber_surfer
Subject: Re: Why Commit to Eiffel?
Distribution: world
References: <DERWAY.94Aug31155314@alumni.ndc.com> <DOUG.94Sep9075752@monet.ads.com>
Organization: The Wildcard Killer Butterfly Breeding Ground
Reply-To: cyber_surfer@wildcard.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
Lines: 108
Date: Sun, 11 Sep 1994 10:06:50 +0000
Message-ID: <779278010snz@wildcard.demon.co.uk>
Sender: usenet@demon.co.uk
Xref: glinda.oz.cs.cmu.edu comp.object:20318 comp.lang.lisp:14609

In article <DOUG.94Sep9075752@monet.ads.com>
           doug@monet.ads.com "Doug Morgan" writes:

> The language definitions of C++, Eiffel, and Sather all define the
> standard way to interface to C (and perhaps other languages).

Thanks. I've yet to see any Eiffel or Sather implementations. The
languages I've used have all used non-standard interfaces. They were
Cambridge Lisp, Visual Basic, an experimental Scheme, Actor and
Smalltalk/V. Except for the first example, they used a standard
binary interface for the object code, which is part of the Windows
dynamic linking. Every Windows app has to use that.

> Most OOPLs are designed to start up only by immediately taking over a
> new process.  I think this is easy, traditional, but also limiting.
> I'm sorry to see that Lisp usually goes along with the crowd on this.

This is why I use dynamic linking. I'm not exactly sure what you by
"taking over a new process". I'd expect the C and Lisp code to share
the process. That's certainly how I've seen it done for Windows, altho
I should add that you _could_ say everything in Windows runs in the
same "process". We should really be talking about Unix and NT, as
Windows complicates things in that respect. All the Windows "tasks"
seem to share the same address space! NT fixes that.

If I've misunderstood you, then I'm sorry.

> >> 12. Often no way to effectively debug foreign loaded C/C++
> >
> >Under Windows this is done just like with any other C/C++ code. There's
> >nothing special about calling a C function.
> 
> I know nothing about Allegro CL for Windows.  In it, do stack traces,
> inspectors and whatnot work across the C stack and (if different) the
> Lisp stack?  Sounds interesting.

I don't know. I assume you mean a Lisp inspector, so I can't comment on
that. I've yet to use Allegro CL/PC. I _have_ used Actor and Smalltalk/V,
and no, the Actor inspector doesn't inspect C objects. I'm not aware that
Actor users require this, as the C code is often in a library written by
someine else, or a part of Windows itself.

> >> 20. It is often pain to interface a copying GC with C.  (A standard
> >>     way of setting up some amount of space with non-copying GC or even
> >>     manual heap management might help.)
> >
> >Why is this necessary? _Is_it_ necessary with Allegro CL for Windows?
> >I don't know, as I've yet to use it.
> 
> From Lisp, you pass by value to C a pointer to the data portion of a
> Lisp array (or whatever).  In the meantime, your C routine either
> calls back to Lisp or another Lisp thread executes.  In either case,
> Lisp kicks off a copying garbage collection and moves the referenced
> data.  C dereferences the pointer.  Oops!  Solutions involve locking

Ah, you're assuming that the C code using the same memory as the
Lisp code. My experience with systems like Actor, under Windows,
is that programmers don't always do that. It is possible, I believe,
but I'v never tried it.

I can't comment on the thread problem, as I've to use a platform
that supports threads. Win32s has the function calls, but only for
compatibility with the full Win32 system, so they only return error
codes. A Win32s application is expected to deal with it and work
without threads. That way, the same binary can be used for both
Win32s, sitting on top of Windows aka Win16, and also with Win32,
aka NT.

As far as I'm aware, threads are not a standard feature of Common
Lisp, and not supported by all implementations. I've no idea if
Allegro CL/PC supports them, for example. If it does, then it
would have to handle the switching itself.

> out Lisp execution (and therefore GC) during the use of a C pointer
> and possibly passing data that is never subject to copying GC.
> Indirect references through non-copied pointers to GC-aware pointers
> can sometimes greatly reduce the time during which copying GC must be
> locked out (consider putting a pointer to Lisp data into a C static
> variable that hangs around for the life of the process --- it's better
> to block GC just when the static variable as actually being used in a
> computation, than for the life of the program).

This sounds more like an implentation issue than a language one.
One answer could be for the C code to copy the data it needs into
some memory of its own. There could be other ways, but they would
probably depend on the implmentation.

I can understand the problem you've described, but it seems to be
a general one, and not specific to Lisp. It certainly complicates
the interface! However, imagine that the Lisp and C code have to
communicate thru sockets. That makes the communication very narrow,
but data could still be passed from one side to the other. If the
C code knows little about the Lisp side, which has been the case
when I've done this in Actor, then the interface is narrow anyway.

This makes it the responisibily of the Lisp side to format the
data in a way that the C functions can use. They'll grab the data,
do something with it, and pass it back without allocation any
Lisp data, and perhaps indirectly invoking the GC. I've seen this
done with Cambridge Lisp running under GEM. I've also seen it done
in Actor under Windows. It's possible it could be done in other
languages interfacing to other code written in C, but I can't say.

Martin Rodgers
-- 
Future generations are relying on us
It's a world we've made - Incubus	
We're living on a knife edge, looking for the ground -- Hawkwind
