This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
> 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.
-t