> From: Jim Blandy <xxxxxx@redhat.com>

    >>> 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