Alex Shinn <xxxxxx@gmail.com> writes:

> On Fri, Oct 16, 2015 at 10:34 PM, Taylan Ulrich Bayırlı/Kammer
> <xxxxxx@gmail.com> wrote:
>
>     I think implementation compatibility is very important, because
>     there is already a huge disappointment in the RnRS among some
>     parties, and making incompatible changes for questionable benefit
>     won't improve that case.
>
> 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).

Your proposal can indeed be implemented not just portably, but even with
the same amount of R6RS backwards compatibility as the bound argument,
so it's certainly nowhere as bad as I initially thought, which is why
I'm still thinking about the issue.

OTOH it breaks familiarity (the bound argument is at least there in
SRFI-69 and some Scheme implementations' native hash table API), means
adding a compatibility shim on top of existing hash implementations (to
pass/strip the extra argument, ignoring it) until they actually support
the new signature themselves (which might be practically never for some
because they don't see a benefit in it and don't want to break their
API/ABI), and no very clear benefit has been demonstrated so far (just
slightly cleaner code in some rare use-cases).

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.

>     The fact that pretty much no existing Scheme implementation does
>     anything like this should hint us that it's of questionable
>     benefit.
>
> This is just pointing out the fact that pretty much no existing
> Scheme implementation has secure hash tables. Except for
> Chicken, from which perspective we're just making an implicit
> value an explicit parameter. This is often a good practice.

Salting hash functions doesn't require the changes you propose.

I don't know which Scheme implementations do and don't salt their hash
functions currently, but making the change you propose will only mean
that those which don't will pass and strip some ignored salt argument
somewhere, until they actually implement salting.

SRFI_126_HASH_SEED is as much a hint for implementations to please
implement salting, as your proposed change is.  Neither force it.

We could mandate salting, but it would be orthogonal to the way in which
it's exposed in the API.

>     >> [...] An env variable is a poor way to handle this, since it
>     >> places additional restrictions on the test running framework
>     >> (e.g.  there is currently no way in Snow to specify env vars to
>     >> be set when running tests).
>
>     I see. I would say that's a limitation of Snow though, or rather
>     R7RS, since there's no 'set-environment-variable' and no
>     'system*'.
>
> Snow is just a tool, and the language it's written in supports
> both of these, and clearly it must be using something like
> `system' to run the tests for the target implementation.

Never mind, I thought Snow was written in R7RS Scheme + SRFIs.

> 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?

A test suite should probably not rely on a specific salt value, though
still, if it does then we could agree on a convention that
SRFI_126_HASH_SEED is set to e.g. "TESTING" for testing.

And I *still* don't know how your proposed change helps with this. :-)
If you mean to discuss this as a separate topic then that's fine, though
I had the feeling you're implying it's an argument for your proposal of
changing hash function signatures.

Taylan