Would it be worth adding an alternative to the gen:hash, gen:hasheq, and gen:hasheqv forms that doesn't require hardcoding the keys?
Motivation: One alternative use of a hashtable involves mapping from arbitrary keys to values. However, the current gen:hash implementation expects the hardcoding of keys, such that the generated hashtables all have the same keys. This current implementation is useful for generating hashtables that represent jsexprs of some constant structure but is quite limiting for the other use/purpose.
An example of this alternative use would be a mapping of string IDs to naturals (maybe representing a score of some type). However, generating something like this is cumbersome (lifting+modifying this from the examples):
Would it be worth adding an alternative to the
gen:hash
,gen:hasheq
, andgen:hasheqv
forms that doesn't require hardcoding the keys?Motivation: One alternative use of a hashtable involves mapping from arbitrary keys to values. However, the current
gen:hash
implementation expects the hardcoding of keys, such that the generated hashtables all have the same keys. This current implementation is useful for generating hashtables that represent jsexprs of some constant structure but is quite limiting for the other use/purpose.An example of this alternative use would be a mapping of string IDs to naturals (maybe representing a score of some type). However, generating something like this is cumbersome (lifting+modifying this from the examples):
Introducing such a generator for the mappings, however, would make it considerably more concise (assume
gen:hash*
represents that generator):Could this just be implemented by the users? Yes, but currently my stance is that the library itself should support this.