Email list hosting service & mailing list manager


Re: SRFI naming sperber@xxxxxx 20 Aug 2002 07:20 UTC

>>>>> "Alfa" == Alfa Male Petrofsky <xxxxxx@petrofsky.org> writes:

>> From: xxxxxx@informatik.uni-tuebingen.de (Michael Sperber [Mr.  Preprocessor])

>> This effectively amounts to assigning a keyword to a SRFI document,
>> right?

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

Keywords (in the sense I was referring to) are just some words
attached to a document to help classify it.  They do not uniquely
identify a document.

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

I'm confused.  You said that

> Presumably, most SRFI authors will choose a unique name on their
> own, but if two of them really want just plain "foo", then they can
> both have it.

... so your proposal just won't cut it.  (I see numbers attached to
the names.  What are they?)  I still don't see the problem in this
context: why don't you say

"This implementation supports SRFIs 11 ('Syntax for receiving multiple
values'), 16 ('Syntax for procedures of variable arity'), and 57
('PL/I syntax for Scheme')"

?

Sure, there's nothing particularly *forcing* people to be non-obscure,
but then again, I haven't seen any measure (technical, social,
economical, or political) that reliably prevents obscurity.

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

I'm not suggesting anything at this point.  It just occurred to me
that, since a single keywords probably won't be unique in the future,
people could just specify a set of keywords to help a unique
identification.  If you go with keywords.

But the fundamental question remains: I *still* fail to see what
problems you folks are expecting to solve substantially better than
the status quo does it.  If you want names to refer to SRFIs
programmatically, write a document specifying those names.  (Write a
library proposal, that is.)  I'd say submit it as a SRFI.

I'd also say wait until there's a critical mass of fundamental SRFIs
(or, better yet, help reach that critical mass), and wait until some
of the issues of the ones present now (especially some of the more
popular ones) have surfaced and resolved.

I know this takes time, and everybody is impatient because of the evil
empires in the Perl, Python, Ruby and whatnot camps.  But that's just
the way it is.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla