Alex Shinn <xxxxxx@gmail.com> writes:

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

They're all optional.  Only strong tables are mandatory.

> And you're ignoring the changes to the core reader. You simply
> cannot write a portable version of your proposal.

Again, optional.

Maybe I should further clarify my strategy towards what I do and don't
think should be standardized, standardized how, and made optional or
not:

RnRS/SRFIs should specify what cannot be simply implemented as a
portable library.

E.g. SRFI-113 is unnecessary; just make it a library implemented via
hash tables (once we have those).

OTOH a hash table API is important because you can't implement it in
portable Scheme in terms of a more fundamental feature.  (One could be
an extremist and try to specify some even more fundamental feature on
top of which hash tables could be implemented as a library, but that's
where I intuitively draw a line.  It would probably leave us in a
situation like we had with call/cc, which can supposedly implement all
control constructs, but after all can't do so very well.)

However, being able to implement such an API in terms of existing
fundamental features in implementations is important.  It doesn't mean
the API can be implemented as a portable library, but it means it can be
implemented relatively easily by individual Scheme implementations.
(And again one could follow the "just make it a library" idea to an
extreme and suggest to implement a portable hash table library via tons
and tons of 'cond-expand', but again that would be anti-pragmatic.)

Features that are fundamental (can't be implemented portably) but also
don't already exist in every Scheme implementation in some way (can't
easily be implemented by individual Scheme implementations either) are
thus best specified but made optional.  It means that there will be a
subset of conformant-at-all Scheme implementations which are conformant
to a (figurative) more strict variant of the SRFI --one with more
features mandatory-- and I can write my code targeting that.  In more
concrete words, I could write code using SRFI-126 with weak tables and
it would work on say Chibi, Guile, and Racket, but not FooScheme.
That's much better than not being able to write portable code using weak
tables at all.

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

"Improved consistency and ease of use" sounds great when simply put like
that, but as I explained before I don't see any significant improvement
in consistency or ease of use in your proposal.  Likewise with the
hypothetical flexibility and more features.

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

The logic of setting an environment variable is trivial and duplicating
it among tools doesn't seem like a big deal.  Note that this is really a
pathological case; in most cases we will hopefully find a cleaner way to
do it.

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

That doesn't cover uses of hash tables themselves.  Of course one should
not rely on the order of entries in a table or any such thing, but
having full determinism in a test suite is still preferable.

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

I'm also tired of the repetition.  I guess we disagree on a more
fundamental level.  In particular, I'm wary against elegance that
doesn't demonstrably carry over to practice.

Taylan