[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More JNI vs. Pika comparison
> From: Jim Blandy <jimb@xxxxxxxxxx>
>>> 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?
Surely you want a sharable, mutable location.
In implementation, aside from not being reference counted, mn_refs
with linear operators presumably provide that. I suppose that
formally, i.e. in specification, they aren't promised to.
It just seems odd -- a bit forced. You have these locations that you
want to only be used in value-like ways except that they need explicit
storage management except where they dont' because the free of the
call cleans them up except where that's lame because it results in a
storage leak. Why not, instead, just give me real locations?
>> 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.
I don't get these steps (1) and (3). Aren't I just going to be
inserting new code before the explicit free of the location? In the
worst case -- aren't I just moving the point of that free?
> 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.
Well, sure. As I said -- I didn't spec an interface for them in the
original proposal. The explicit-free/pseudo-value-locations stuff
isn't quite right for parameters and locations -- central to FFI
calling conventions -- and that's what's important to me.