Taylan Ulrich Bayırlı/Kammer scripsit:

I'll try to write my own response soon.  I lost my job on Wednesday and
am trying to find a new one ASAP while catching up with a whole bunch of
deferred personal stuff.  But I wanted to make a few points in response
to your excellent document.

> - No external representation is specified.  There is brief mention of
> implementation-dependent support for weakness, but it seems like an
> afterthought.

I decided as a matter of policy not to include lexical syntax with any
of my SRFIs, even as an option, since it is very difficult on some major
Schemes (notably Larceny) to add it without major surgery to the reader.
In any case, the SRFI 126 lexical syntax is not a requirement to support
the SRFI.

> Separate from those points, there is now the strangeness about the
> arguments that should be passed to hash functions.  I don't know
> if a resolution has been reached yet, but ultimately it seems that
> specifying hash functions to simply take an object and nothing more is
> a perfectly fine option, so the alternative considerations are just
> slowing us down I think, if not doing any other harm.

I agree 100%, and the latest drafts of SRFI 125 and SRFI 128 use the
simple contract object -> non-negative exact integer for all hash
functions except those required by SRFI 69, where implementers are
required to accept a second argument but it is recommended that they
ignore it.  SRFI 69 was massively confusing on this point, and the
sample implementation provided requires all hash functions to accept and
obey the bound passed to them, which is not a requirement of the SRFI
itself.

> All that is the reflection of an ideology that might be summarized as
> "stop standard-Scheme from being a joke as soon as possible."  (In the
> eyes of people used to more mainstream languages.)  Not by entirely
> giving up the notion of elegance of course; the intent is not to make
> Scheme into Python 4.0, but to nudge it towards adopting more positive
> attributes of languages like that, while still being Scheme.

I heartily agree, but I also think backward compatibility is important.
R6RS hash tables were created by fiat with very little concern for
existing Scheme implementations.

>
>
> By the way I'd like to remind that it was John himself who originally
> encouraged me to start working on this SRFI.  I'm very thankful for
> that, and there's no personal enmity involved in the whole ordeal,

Absolutely not.

> just to make it clear to third parties.  (I sure could have mentioned
> this in the Acknowledgments.  There's *always* something you remember
> after finalization, isn't there?)

There is.  I wanted to mention the idea of having a more formalized Last
Call process, whereby Arthur (always willing to make more work for you,
Arthur!) would announce last call as widely as finalization, in hopes
that alternative implementations, typos, and other such problems would
surface just before rather than just after finalization.

> I'm also sad that we couldn't meet in the middle with Alex on hash
> functions.  It was a difficult topic and I'm basically running to the
> safe side by simply specifying Object -> Integer.  I hope it will
> prove to be a fine choice in the long term.

I think it will, and it is also what Will Clinger, who has more experience
than the three of us put together, thinks is the Right Thing.  I wish
SRFI 126 had allowed for parameterized salt, however, though I admit
I'm not thrilled with my current design (it's the only thing blocking
finalization for 128).

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
And now here I was, in a country where a right to say how the country should
be governed was restricted to six persons in each thousand of its population.
For the nine hundred and ninety-four to express dissatisfaction with the
regnant system and propose to change it, would have made the whole six
shudder as one man, it would have been so disloyal, so dishonorable, such
putrid black treason.  --Mark Twain's Connecticut Yankee