seeds Alex Shinn 08 Oct 2015 05:03 UTC
Re: seeds taylanbayirli@xxxxxx 08 Oct 2015 07:55 UTC
Re: seeds Arthur A. Gleckler 08 Oct 2015 17:46 UTC
Re: seeds taylanbayirli@xxxxxx 08 Oct 2015 19:38 UTC
Re: seeds Arthur A. Gleckler 08 Oct 2015 21:47 UTC
Re: seeds taylanbayirli@xxxxxx 09 Oct 2015 08:09 UTC
Re: seeds Kevin Wortman 09 Oct 2015 17:18 UTC
Re: seeds taylanbayirli@xxxxxx 09 Oct 2015 18:33 UTC
Re: seeds Kevin Wortman 13 Oct 2015 17:36 UTC
Re: seeds taylanbayirli@xxxxxx 13 Oct 2015 18:28 UTC
Re: seeds Alex Shinn 14 Oct 2015 01:59 UTC
Re: seeds taylanbayirli@xxxxxx 14 Oct 2015 09:09 UTC
Re: seeds taylanbayirli@xxxxxx 14 Oct 2015 10:06 UTC
Re: seeds Alex Shinn 16 Oct 2015 01:23 UTC
Re: seeds taylanbayirli@xxxxxx 16 Oct 2015 13:34 UTC
Re: seeds Alex Shinn 16 Oct 2015 23:48 UTC
Re: seeds taylanbayirli@xxxxxx 17 Oct 2015 12:08 UTC
Re: seeds Alex Shinn 17 Oct 2015 13:12 UTC
Re: seeds taylanbayirli@xxxxxx 17 Oct 2015 14:09 UTC
What SRFIs are for John Cowan 17 Oct 2015 14:41 UTC
Re: What SRFIs are for taylanbayirli@xxxxxx 17 Oct 2015 15:56 UTC
Re: What SRFIs are for John Cowan 17 Oct 2015 16:55 UTC
Re: What SRFIs are for taylanbayirli@xxxxxx 17 Oct 2015 18:08 UTC
Re: What SRFIs are for John Cowan 17 Oct 2015 18:51 UTC
Re: seeds John Cowan 15 Oct 2015 17:49 UTC
Re: seeds Alex Shinn 09 Oct 2015 02:54 UTC
Re: seeds taylanbayirli@xxxxxx 09 Oct 2015 07:59 UTC
Re: seeds John Cowan 15 Oct 2015 17:51 UTC
Re: seeds taylanbayirli@xxxxxx 15 Oct 2015 23:08 UTC
Re: seeds John Cowan 16 Oct 2015 13:09 UTC
Re: seeds taylanbayirli@xxxxxx 16 Oct 2015 14:01 UTC

Re: seeds taylanbayirli@xxxxxx 13 Oct 2015 18:28 UTC

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