From: Dave Yost
Subject: Re: C interface standardization?
Date:
Message-ID: <3jlqji$45b@Yost.com>
In article <··················@cambridge.apple.com>,
David A. Moon <····@cambridge.apple.com> wrote:
>> From: Andrew Wason <··@bae.bellcore.com>
>> Date: Thu, 02 Mar 95 10:26:58 -0500
>>
>> Also, once you provide an FFI to C, you need to worry about
>> memory management. You need hooks into the garbage collector so
>> that when a Dylan object is collected, you can free any C objects
>> it contains (if appropriate). But this GC interface also isn't
>> standardized so each Dylan will probably provide a different
>> interface.
>
>This is a good point, and since it is not dependent on the surrounding
>environment, it should be less difficult to standardize. However it
>is still dependent on the goals and implementation strategies of each
>Dylan implementation. I have been assuming that it was unrealistic to
>try to standardize on a uniform termination (sometimes called finalization)
>facility. So I haven't done any more than communicate what Apple is doing
>for this to the Dylan Partners.
At Apple ATG (West) we've been using an experimental ehnancement
to MCL that lets you proxy a C struct with a lisp object which
references a finalizer function. The finalizer is called after the
lisp object is reaped, and, of course, is used to dispose of the
struct and all that it entails. It works extremely well. With
this feature, you can "pave over" the ugliness of the netherworld
with a safe, clean lisp interface layer. Watch for it in MCL 3.0.
Frankly, I don't know how anybody manages without this facility.
I hope these capabilities can become standardized in all safe
languages which provide an interface to the netherworld.
Dave Yost
Apple ATG
(from home)
From: Scott McLoughlin
Subject: Re: C interface standardization?
Date:
Message-ID: <9D2P2c2w165w@sytex.com>
····@Yost.com (Dave Yost) writes:
[ stuff on C<->Lisp memory management issues deleted ]
> Frankly, I don't know how anybody manages without this facility.
> I hope these capabilities can become standardized in all safe
> languages which provide an interface to the netherworld.
Howdy,
I think there are all sorts of ways to deal with this issue,
and I'd generally favor the smallest, dumbest mechanism.
A very popular strategy in the PC world is "C is for
manually dealing with low level crappy issues. So the
entire burden of interfacing with the resource
management strategy of a higher level language is
born 99% by C code." Visual Basic uses this
strategy and C add ons for Visual Basic is a pretty
big market in itself. In VB any manipulation of
VB strings might move the string itself or any
other resources allocated from the same segment.
Coding can get pretty hairy. C programmers in the
PC world thrive on BS like this.
This is an ok strategy because the non-C part adds
alot of value. C becomes an "add on" to it, not
vice versa.
If MSoft had said "Well, here's another meg of code
that parses C header files and generates oodles of
stubbs and increases the disk/ram footprint by
cha cha percent, but at least it's automatic" I
think VB would have been a less successful, and
certainly a different kind of, product.
One of our LinkLisp beta testers in sum said to
us "Give me more power and flexibility, and I'll
bear the burden on the C side of the fence. It's
what I do in C anyway." Sound's emminently reasonable
to me.
What would be nice if all Lisp's could have the
_SAME_ clunky C interface.
=============================================
Scott McLoughlin
Conscious Computing
=============================================