(general agreement)

Tom Lord <xxxxxx@emf.net> writes:
> I don't mean to be gratuitously argumentative.   I don't see any
> advantage to the call-lifetime hack other than that it is slightly
> more tolerant of sloppy code that we'd want to discourage anyway.
> Your revised assq implementation is an example.

Knowing my limitations, I'd rather be tolerated than discouraged any
day.  :) Of course, being corrected would be my first choice.  I think
external lint programs could help in either style.

> Just as a point of interest: I remember back in the early days of
> Guile the syntax issues of C code were something we worried quite a
> lot about.  Some of the discussions concluded, for example, that
> conservative GC was imperative because we figured that anything else
> would be too hard for "average C programmers" to use and it seemed
> (incorrectly) at the time that conservative GC let us write Scheme
> expressions in C in a very direct style without having to think about
> it too hard.

Yes, that's how I remember it, too.

Discovering the need for scm_remember was a horrible disappointment,
because it meant we really did need to detect pointers into string and
array bodies, which would have ruined the beauty of Aubrey's
collector.

> Two things happened in the years following: (a) GC
> became much more widely accepted (thank you, James Gosling) and so
> what the "average C programmer" can be counted on for has expanded;

I think the general spread of open source software has introduced more
people to plausible coding standards than previously, too.  I know
things are way more strict these days than they were ten years ago.

> (b) it turns out that conservative GC is a sham in the sense that if
> you use it without a deep understanding of permissable C optimizations
> and eternal vigilance about what they might effect -- you're going to
> lose by writing subtly incorrect code.

To be honest, I'm not quite ready to call conservative GC a sham; it
works well enough for gcj.  It just irks me at some fundamental level,
so I just say I have a religious objection to it, and tolerate people
thinking me irrational.  But, I agree with your general sentiment.

> Scheme expressions aren't (in a simple way) C expressions and that's
> all there is too it -- trying to hide that fact in the manner of JNI
> doesn't help anyone (anymore).  I think there's an analogy between
> the interactions of conservative GC and C optimizations on the one
> hand and on the other hand the interactions between JNI/Minor-style
> conventions and semantics and call lifetimes on the other.

I'm in strong agreement regarding the "C is C, and Scheme is Scheme"
attitude.  I've tried to present the Minor API in a way that respects
that; I say:

- You get references to Scheme values, not Scheme values.
- References must be explicitly freed.  This is your job.
- We will free some for you, at well-defined times.

and I hope I haven't said, "You can write C code that looks just like
Scheme code, and it works!!!  Oh, by the way, there are some
wrinkles..."