Alex Shinn <xxxxxx@gmail.com> writes:

> Your primary argument against SRFI-69 is the exposure of the
> eq?/eqv? hash functions, which has been addressed by SRFI-125.

Indeed, even if a merge doesn't happen I could make SRFI-126 based on
SRFI-69 as well.

I think there's other advantages in taking R6RS as a base though.

I find thunk arguments pretty weird.  Continuation passing style is
great and all but it's not how we want to write our code, is it?
Returning multiple values is simpler.  The feature has been there since
R5RS and I don't think we're making nearly enough use of it.

Hash-table-ref/default is a very long name for what is probably one of
the most common use-cases.

It would definitely pain me to ignore the improvements R6RS made there,
like R7RS has done too many times already.

> I would rather leave weak references to an "advanced" hash tables
> SRFI. If you want to keep it, you should research how easy it is to
> implement in existing Schemes. Optional ephemeron semantics
> makes me nervous.

What's the advantage of splitting it to a different SRFI in this case?

As I see it, we have these few options:

- don't specify weak/ephemeral tables at all, making all idioms
  expressible with them impossible to express in standard Scheme,

- mandate weak/ephemeral tables (be it in the same SRFI or another),
  pissing off any implementation that can't easily support them, making
  the RnRS get further ignored,

- specify them but make them optional (be it in the same SRFI or
  another), making simple portable programs possible for all
  implementations, and still having a standard form for more complex
  programs which might not yet run on all implementations.

So I don't see why splitting it should make a difference in this case.

Unless you think that the currently specified semantics need more
thought put into them?  I believe I got them right but someone might
want to double-check.  (They're notoriously complicated in that the
semantics of ephemeral storage pairs can *not* be explained in terms of
traditional strong and weak references.)

> I don't want the bimaps in SRFI-125, but otherwise many of the
> functions you omit in SRFI-126 are useful. You should have a
> -fold operation, and -push! and -inc! are quite useful. Neither
> API provides cursors, which are useful for loop macros.

Fold is called sum here since it's unordered.  Pop! does not behave like
the SRFI-125 pop!, and a push! equivalent for this pop! makes no sense
(it's just set!).  Inc!/dec! are pretty much just:

    (hashtable-update! ht k inc 0)
    (hashtable-update! ht k dec 1)

if you want automatic starting at 0 on increment and capping at 0 on
decrement; you can also provide #f on dec to error instead, and so on.
Are you sure these are worth specifying?

I say "pretty much" because I just noticed that update! returns an
unspecified value.  I will make it return the value that was written
into the hash table.

Some hash table APIs provide "handle" objects with which you can quickly
access and mutate the association for a key once the association has
been looked up.  I didn't want to take the risk of specifying that the
wrong way so I made sure that lookup, intern!, update!, etc. cover the
most common cases.

A full cursor API for hash tables I have yet to see in any Scheme
implementation I looked at.  It's unclear to me how the cursor would
deal with rehashes.

> Drop the external representation. We can handle this uniformaly
> in something like SRFI-10.

Hmm, how does SRFI-10 interoperate with quasiquote?

I'd really like hash tables to be first class (in the lay sense of the
term) so I think I'd prefer to have an independent read syntax for them,
but feel free to convince me otherwise.

> I prefer SRFI-69 "hash-table" to R6RS "hashtable".

Since that's a total bikeshedding issue, I let it have zero effect on my
decision of whether to base the new API on SRFI-69 or R6RS, then go with
the result.  I suggest everyone pretty please do the same.

That being said, "hashtable" has its nice sides too, for instance it's
in line with "bytevector," and makes the name of the data type one word.
It also saves one character!  (These are what I use to make my
subconscious shut up about really preferring "hash-table". :-P)

> Neither SRFI addresses my concerns regarding the signature
> of the hash functions themselves. I feel the signature should be
>
> (hash object salt bound)
>
> where bound is only a guideline. If you omit bound, the SRFI
> must specify the range of values expected by a hash function
> (e.g. positive fixnums), and make clear the repercussions
> (e.g. in practice you cannot expect to be able to create hash
> tables taking a substantial fraction of memory, or use these
> functions for large disk-based hash tables).
>
> The salt is necessary to defend against well-known security
> attacks, and also allows flexibility in hash-table implementations
> such as double or cuckoo hashing, or use of the same hash
> functions in bloom filters, etc.
>
> Note addressing either of these changes to the hash function
> signature makes it impossible to use SRFI-114.

Now that's an interesting topic.  I'll see that I add optional arguments
to the R6RS hash functions to take a salt and bound.

Let me make sure I understand the bound argument correctly: the hash
table implementation will pass the size of its bucket vector (or a value
based on it) to the hash function here, so your comment re. big hash
tables doesn't apply when one doesn't use the hash functions directly,
right?  It only applies when one uses these functions to implement
something else?

Thanks for stirring up some discussion.  I hope we'll be able to
convince each other on as many points as possible so as to reach a
consensus.

Taylan