"Arthur A. Gleckler" <xxxxxx@speechcode.com> writes:

> On Thu, Oct 8, 2015 at 12:55 AM, Taylan Ulrich Bayırlı/Kammer
> <xxxxxx@gmail.com> wrote:
>
>     2. That environment variable is the easiest way to make hash
>     tables deterministic when running a test suite, and a 'getenv'
>     call to get its value and derive a salt from it doesn't seem like
>     a big burden to me.
>
>
> Using an environment variable is bad for a number of reasons:
>
> * It's non-portable to systems that don't support environment
>   variables.
> * It's likely to be slow.
>
> A parameter object seems like a much better way to supply this value.
> Implementations can decide how the default value for that parameter is
> set, and you could even suggest the environment variable, but it
> decouples things better.

The idea is that the value in the environment variable will be read
during initialization of the Scheme process, and a salt value generated
once from it.  So performance should not be an issue.

A Scheme interface is a good idea, but I'm not sure how to define it
most cleanly.

- We want to keep the value opaque, since different implementations
  might accept different ranges of integers.

- What happens when I use the same hashtable inside and outside of a
  (parameterize ((hash-salt ...)) ...)?  Does it crash and burn?

Reading a parameter might also be a bit slower than reading a global C
variable.

I think implementations should just provide a secondary interface of
their choice for platforms that don't have environment variables.  Since
this whole feature is only for running test programs, I don't see it as
harmful if there's some variation in how implementations do things.

Besides, it seems that MS Windows supports environment variables, and
surely all Unixes do.  The systems you have in mind must be rather
obscure then?

Taylan