Email list hosting service & mailing list manager


Re: SRFI naming Alfa Male Petrofsky 17 Aug 2002 03:53 UTC

> From: xxxxxx@informatik.uni-tuebingen.de (Michael Sperber [Mr.  Preprocessor])
> >>>>> "al" == Alchemy Petrofsky <xxxxxx@petrofsky.org> writes:
>
> al> As Alex Shinn pointed out, the perl community has had success
> al> without the subnumbers by simply giving out names on a
> al> first-come-first-serve basis, with the editors occasionally
> al> rejecting requests for overly-generic names.  That sounds
> al> workable to me, but my proposal is a little easier for the
> al> editors.  Presumably, most SRFI authors will choose a unique
> al> name on their own, but if two of them really want just plain
> al> "foo", then they can both have it.
>
> This effectively amounts to assigning a keyword to a SRFI document,
> right?

I think so, but it depends on precisely what you mean by "assigning a
keyword".  I think the shortnames proposal I made in my first message
was pretty specific, so I hope that reviewing that message will enable
you to answer whether or not this is equivalent to assigning a
keyword.

> This might be made more workable by assigning sets of keywords to a
> document that, in their entirety, again uniquely identify a single
> SRFI.

I'm not sure how you think this would be better.  Perhaps you could
flesh out that idea.

With the shortnames proposal, the sentence "This implementation
supports SRFIs 11, 16, and 57" could be less obscurely written "This
implementation supports SRFIs let-values-1, case-lambda-1, and
foo-bar-baz-2".  Are you suggesting that that would become something
like "This implementation supports SRFIs {multiple-values,let-values},
{case-lambda}, and {foo,bar,baz}"?

How would you embed these sets in identifiers for things like SRFI-0?
Would there be a canonical order for each set, or would all the
different orderings have to be recognized, i.e. srfi-foo:bar:baz,
srfi-bar:baz:foo, etc.?

Are you suggesting that all unique sets of keywords be available on a
first-come-first-serve basis, or would the editors have some
discretion to reject requests for a prized simple set like {modules}?
If the editors will have to exercise discretion, how should the
guidance for this discretion be worded in the process document?

I think that in the two-paragraph shortnames proposal, all the above
issues are either adequately addressed or are non-issues (e.g., no
editorial discretion is required, and no keyword or set of keywords
can be monopolized by the early bird).  The big flaw is that many
people might mistakenly assume that SRFI let-values-2 is necessarily
an update of SRFI let-values-1, when it might actually be a competing
specification of let-values.

-al

P.S.  Regarding the cause of the apparent time warp between my
previous message and MJ Ray's reply to it half a day earlier:

> From: xxxxxx@informatik.uni-tuebingen.de (Michael Sperber [Mr.  Preprocessor])
> >>>>> "Al" == Al Petrofsky <xxxxxx@petrofsky.org> writes:

> Al> A message that passed from my server to yours yesterday is missing.

> The list manager assumed that "Alpha Mail Petrowsky" is some kind of
> daemon and therefore bounced the message to me for further approval.
> I've resent the message with one of your other aliases and kindly
> ask that you avoid this particular one in the future when posting to
> a SRFI mailing list :-)

Thanks for the explanation.  I hadn't seen that problem before.

I guess this shows that I may not be the best person to be advising
people about choosing names.  (And I guess it also shows that the SRFI
editors are already exercising the power of rejecting some names.)