Re: C interface standardization?

[smcl@sytex.com (Scott McLoughlin)]

yost@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
=============================================