Kevin Wortman <xxxxxx@gmail.com> writes:

>     Then please propose an API based on one of those which solves our
>     problem, without having any of the mentioned issues. I haven't
>     been able to come up with a satisfactory one.
>
>
> Well, IIRC Alex Shinn has already proposed a procedure-based API and
> reiterated it several times.

If you mean the proposal of changing the signature of hash functions to
hash(object, bound, seed), I explained some issues with that in previous
mails on the list.  (Please correct me if any of my explanations was
wrong.)

> And the only complaint lodged against using a parameter object seems
> to be that referencing it costs one procedure call, which seems
> perfectly acceptable for an infrequent operation in a
> functional-leaning language.

I would currently summarize my main complaints as:

- Things will crash and burn when a hash table is operated on from two
  dynamic extents with different values for the hash salt.

- It might be an intrusive change to the C code of some implementations,
  similar to (but not as bad as) changing hash function signatures.

- Since the only real use-case is determinism for unit tests, even that
  one procedure-call seems excessive, when it could otherwise be a
  global variable in C whose value is set once at startup.

If one uses functional style, then probably one shouldn't use SRFI-126
or any traditional hash table API at all, since they are intrinsically
highly imperative.

Other than that, I won't try to make guesses on how people might use
hash tables.  For instance Alex Shinn mentioned one might want very huge
hash tables filling all of memory, or even on-disk ones, and it makes me
happy if the specified API doesn't hinder that, although I prefer to not
to make sacrifices for uncommon use-cases either so if you think point
#1 above is no problem (we could encode exactly the mentioned limitation
into the spec, saying a hash table must not cross between dynamic
extents with different salts), and if nobody sees any other issues, then
I won't clutch onto point #2.

>     I do not understand why environment variables should not be used
>     in Scheme specifications. They're a simple, ubiquitous mechanism
>     for controlling program behavior from the point of process
>     creation onward, some other alternatives being ARGV, the
>     filesystem, and standard IO ports, all of which seem inferior in
>     this case.
>
>
> The problem is that environment variables are not actually ubiquitous
> in the full sense of the word. There are Schemes that run on platforms
> where environment variables don't exist. Raw-metal embedded systems
> have already been mentioned, and there are also Scheme dialects that
> run in Javascript and the GPU.

Hmm, good point.  Especially "web browser as platform" is getting pretty
popular (however horrific it may seem in some ways) so it would probably
be good not to discriminate against that.

I'll ponder on whether it would be OK to just specify that a hash table
should not be used across dynamic extents with different values for the
salt parameter.  Let me know if you have a better idea.

Taylan