More JNI vs. Pika comparison
Jim Blandy
(17 Feb 2004 23:22 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:39 UTC)
|
Re: More JNI vs. Pika comparison
Matthew Dempsky
(18 Feb 2004 15:46 UTC)
|
Re: More JNI vs. Pika comparison
Tom Lord
(20 Feb 2004 17:32 UTC)
|
Re: More JNI vs. Pika comparison
Jim Blandy
(24 Feb 2004 22:13 UTC)
|
Re: More JNI vs. Pika comparison
Tom Lord
(24 Feb 2004 22:32 UTC)
|
Re: More JNI vs. Pika comparison Jim Blandy (24 Feb 2004 23:23 UTC)
|
Re: More JNI vs. Pika comparison
Tom Lord
(25 Feb 2004 00:16 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.