On Sat, Oct 17, 2015 at 9:08 PM, Taylan Ulrich Bayırlı/Kammer <xxxxxx@gmail.com> wrote:

Alex Shinn <xxxxxx@gmail.com> writes:

> OK, by that argument, my proposal can, as stated many times,
> be trivially and portably implemented in pure R7RS Scheme on
> top of either SRFI 69 or R6RS hash tables.
>
> Your proposal, on the other hand, requires weak tables, which
> many Schemes may never implement, and requires changes to
> the core reader and writer, which implementors are generally
> reluctant to do.
>
> So by your own argument my proposal is clearly better.

That's apples to oranges. Whether we change hash function signatures is
orthogonal to the other features you mention. Besides, they're optional
precisely for that reason. Even a mature implementation like Guile
lacks ephemeral tables, and so what its sample implementation does is
just leaving them out (signaling an error on attempt to use them).

I'm not talking about ephemerons, I'm talking about any weak pairs.

And you're ignoring the changes to the core reader. You simply

cannot write a portable version of your proposal.

I'm starting to think it's more of a bikeshedding issue than anything,
since I'm starting to think it has neither significant advantages nor
significant disadvantages.

Improved consistency and ease of use is not bikeshedding.

Moreover my proposal allows greater implementation flexibility

and more features. There are many data structures and algorithms

which depend not on hash functions but families of hash functions,

and being able to use the same hash functions for all of these is

a nice unification.

> The difficulty lies in modifying the Snow packaging specification
> to provide a set of environment variables which must be set in
> running the tests. In general, _any_ tool will need some out-of-
> band information on these variables. You can't simply set the
> env vars from Scheme within the tests themselves, because by
> that time the hash-table library has already been loaded, and
> the default hash functions already constructed.

How about always setting SRFI_126_HASH_SEED before running tests?

Where and how is the value specified? As I just said, the test

suite itself cannot do this, the Makefile or other tooling infrastructure

must do so. And you need to find some standard place to store it,

or duplicate the logic for every tool you want to be able to run the

tests with.

And I *still* don't know how your proposed change helps with this. :-)

Because (as I said before) you can pass a fixed seed explicitly and

avoid the whole issue:

(test <expected> (hash <obj> <test-seed> <bound>))

Passing a seed to the hash function is one of the more elegant

ideas I've seen in a long time, since it does so much so simply.

I'm sorry you can't see this, but I'm too busy to continue repeating

myself. Good luck with the SRFI.

Alex