Email list hosting service & mailing list manager

More JNI vs. Pika comparison Jim Blandy (17 Feb 2004 23:21 UTC)
Re: More JNI vs. Pika comparison Matthew Dempsky (18 Feb 2004 08:09 UTC)
Re: More JNI vs. Pika comparison Jim Blandy (18 Feb 2004 08:38 UTC)
Re: More JNI vs. Pika comparison Matthew Dempsky (18 Feb 2004 15:47 UTC)
Re: More JNI vs. Pika comparison Tom Lord (20 Feb 2004 17:51 UTC)
Re: More JNI vs. Pika comparison Jim Blandy (24 Feb 2004 22:11 UTC)
Re: More JNI vs. Pika comparison Tom Lord (24 Feb 2004 22:51 UTC)
Re: More JNI vs. Pika comparison Jim Blandy (24 Feb 2004 23:21 UTC)
Re: More JNI vs. Pika comparison Tom Lord (25 Feb 2004 00:36 UTC)

Re: More JNI vs. Pika comparison Jim Blandy 24 Feb 2004 23:21 UTC

Tom Lord <xxxxxx@emf.net> writes:
>     > Where did reference counting come from?  I don't think I've ever
>     > mentioned it.
>
> My faulty memory, apparently.   I'm surprised you wouldn't have
> specified it that way in the first place.

Maybe I should have...

>     > The Minor interface doesn't include any, nor does the
>     > actual JNI, as far as I know.  Is there some use case where simply
>     > duplicating references won't work just as well?
>
> Obviously.   Anytime you want a location shared by multiple data
> structures whose lifetimes are independent of one another.

I guess I'm having a hard time imagining when that's necessary.  Minor
references aren't mutable, so there's no question of allowing one data
structure to "see" changes made by another one.  It seems like you can
replace scm_location_unref with mn_free_reference, scm_location_ref
with mn_make_local_ref, and '==' on 't_scm_word *' values with
'mn_ref_eq', and you must be done.  What am I missing?

> It's a question of locality of changes.   In my code, with the
> explicit UNREFS, if I need to add an additional use of $1 and $2 I
> just insert code before the unrefs.   In your code, with the semantics
> of "_to_cons", I need (1) change the _to_cons call to something else;
> (2) insert the new code; (3) append the explicit deallocations.

How is this different from what you have to do when you discover you
need a Pika value after the point where it's currently freed?  You
have to:

1) delete the extant scm_location_unref call,
2) add your new use of the location, and then
3) add a new scm_location_unref call at an appropriate place.

In the Minor interface, the original 'free' is harder to spot, because
it's folded into the name of a function whose primary job is something
else (consing).  In the Pika interface, the original free is easy to
spot, but it's an extra line of code that must appear whether you
actually need it to be distinct or not.

I think this is a disagreement about whether it's helpful to introduce
abbreviations that must be un-abbreviated when they no longer apply;
reasonable people's tastes can differ.  But neither proposal for this
Bison scenario escapes the need for careful reading --- explicit free
is a pain in the butt in both cases.

Regardless of whether Minor's legibility is legit or not, we agree
that explicitly-freed references, much like Minor's, are also
necessary in Pika --- that's what's important to me.