Email list hosting service & mailing list manager


Re: when GC is permitted Tom Lord 10 Jan 2004 18:57 UTC


    > From: Richard Kelsey <xxxxxx@s48.org>

    > I can understand wanting the first FFI SRFI being a safer, more
    > general one, perhaps based on JNI or Pika.  This SRFI isn't that
    > SRFI because that isn't the type of FFI that Mike and I needed.

In off-list conversations about SRFI-50, that paragraph has raised a
few hackles.

We all know and appreciate that the SRFI process doesn't require
authors to respond to the needs or thoughts of anyone else -- they
need only conform to the rather slim requirements of the process.

But I think we also all know that the SRFI process was designed to
encourage and facilitate the collection and application of divergent
needs and thoughts.

The SRFI process _enables_ the development of rough consensus without
trying to _enforce_ the development of rough consensus.   It's a kind
of "IETF-lite".

So I think it is an abuse -- albeit a kind of abuse the SRFI process
explicitly declines to prohibit -- when authors say (and I'm not
certain that this is what you're saying but it's sure looking that
way): "Consensus doesn't matter for this SRFI.  My goal is to have a
finalized SRFI with essentially the same content as my draft.  Your
objections are interesting but contradict my goal: I guess we just
have to agree to disagree."

Now to the specific issues that are causing friction:

1) You say that a Pika-style calling convention "isn't the type
   of FFI that Mike and I needed."

   I'm trying to interpret that statement according to the "reasonable
   person principle".  In other words, my first axiom is that it's a
   statement from a reasonable person rather than just a "Nyah, nyah
   -- you can't stop me from finalizing."

   I'm also trying to interpret it as a correct statement.   In other
   words, my second axiom is that "Hey, Mike's a smart guy.  Perhaps
   there's something important about Pika-style conventions that, if
   present in the FFI, would cause him to be unable to accomplish some
   technical goal."

   I'm so far unable to interpret the statement ("isn't the type of
   FFI...") in a way that is consistent with both axioms.

   Axiom 1, the "reasonable person principle", is my favorite.  I'll
   keep that one for now.

   So perhaps the problem is with axiom 2:  you're making an honest
   mistake, not a correct technical judgement.

   This hypothesis, that you're making a mistake, is reinforced by an
   experiment that jivera (Matthew Dempsky) carried out.  He thought:
   "Suppose I have a Scheme implementation that uses a
   Sperber/Kelsey-style FFI.  And further suppose that I now want that
   implementation to have a Pika-style FFI.  How hard is that?"  About
   2-3 pages of trivial code later, and disregarding for the moment
   the issues we haven't taken up yet about error handling and
   non-local exits, he had 95% of an implementation.  The only
   sticking point was on the exact syntax of GCPROtect-family macros:
   it would take some tweaks to reconcile those in Pika with those in
   the draft.  We would need to make a trivial addition to the Pika
   macros to complete the job.

   What about in the other direction?   I'll ask: "Suppose I have a
   bunch of code using a Kelsey/Sperber-style FFI -- but the FFI
   standard is Pika-style.  How hard is it to port that FFI-using
   code to the standard?"

   I don't have as clear an empirical an answer to that question.  On
   the other hand, I have personally made many similar kinds of global
   changes to systems in the past.   If what you have is a few 10K
   lines of code, I find it hard to believe that that would take more
   than a couple of weeks.   Emacs is a wonderful thing -- between
   grep, tags, query-replace, keyboard macros, and a tablet of paper
   -- conversions similar to this can go pretty quickly.   If the code
   in question is free software of general interest, I bet you could
   get a decent amount of help with it.

   So to sum up (1): I am having trouble imagining a respectable
   "need" for a non-Pika-conventions FFI.   Can you elaborate on the
   nature of this need?

2) Momentum is an issue.

   The phrase "Sperber and Kelsey FFI SRFI" contains four words that
   will catch people's attention and give weight to the contents of
   the document so referred to.

   The draft, while completely unacceptable for Pika (which isn't even
   done yet), _can_ be implemented in many implementations.

   My fear here is that (a) people _will_ widly adopt the draft if
   finalized;  (b) people _will_ write code against it;  (c) lack of
   support for the draft will become a major barrier-to-adoption for
   future implementations.   Therefore, in my view, the draft has a
   non-disregardable chance of limiting the future of Scheme
   implementation techniques.

   Most people, g*d willing, live in the future.  Whatever "needs"
   Kelsey and Sperber have regarding the draft, let's not forget what
   Spock says: "The needs of the many outweight the needs of the few,
   or the one."

   And, anyway, Spock aside -- it's not unselfish to want Scheme to
   evolve according to its promise.   In this case, "the needs of the
   many" are not necessarily contradictory to "the needs of the few".

3) Pika-conventions have a huge disadvantage.

   I think I've argued very well for Pika-conventions on first
   principles.

   There's one argument I can't make and that argument has the form
   "Here, look these successful systems already using them."

   There's another argument I can't make and that argument has the
   form "Here, look at this document which is easily massaged into a
   SRFI that specifies them."

   A radical proposal for reconciling the differences on this list
   might be:

   ~ perhaps some of the "rest of us" can help to revise the
     draft

   ~ perhaps some of the "rest of us" can help to implement the
     revised draft in a few implementations

   ~ perhaps some of the "rest of us" can help to strengthen the
     revised SRFI by preparing, before finalization, a few C
     libraries that use the revised interface to create bindings
     for some popular libraries

   For example: my gosh, I'd _really_ like to see SCSH running in
   several different implementations.  And isn't there now an X11
   binding for S48?  I'd like to see that get around, too.

Responses?

-t