Re: [Caml-list] Heterogeneous dictionary

[Martin Jambon <martin.jambon@ens-lyon.org>]

Here is an old trick, which is not necessarily useful but fun nonetheless:

(* mixtbl.mli *)

type 'a t
   (** A hash table containing values of different types.
       The type parameter ['a] represents the type of the keys. *)

val create : int -> 'a t
   (** [create n] creates a hash table of initial size [n]. *)

val access : unit -> ('a t -> 'a -> 'b option) * ('a t -> 'a -> 'b -> unit)
   (**
      Return a pair (get, set) that works for a given type of values.
      This function is normally called once for each type of value.
      Several getter/setter pairs may be created for the same type,
      but a value set with a given setter can only be retrieved with
      the matching getter.
      The same getters and setters may be reused across multiple tables.
   *)


(* mixtbl.ml *)

type 'a t = ('a, (unit -> unit)) Hashtbl.t

let create n = Hashtbl.create n

let access () =
   let r = ref None in
   let get tbl k =
     try
       (Hashtbl.find tbl k) ();
       let result = !r in
       r := None;
       result
     with Not_found -> None
   in
   let set tbl k v =
     let v_opt = Some v in
     Hashtbl.replace tbl k (fun () -> r := v_opt)
   in
   get, set


I put it all on Github:

   https://github.com/mjambon/mixtbl



On 04/03/2013 05:45 PM, Anthony Tavener wrote:
> I think I might be up against a brick wall. But maybe there's a door I don't
> see, without Obj.magicing myself through the wall. (I haven't had to use
> magic
> for anything yet!) :)
>
> I want to stash values under a key, and retrieve them by that key. All
> values
> bound to a given key are of the same type, but the type will differ between
> keys. Basically like a hashtable you'd find in a dynamic language.
>
>    (* modifier-additions like this would be scattered across the
> code-base *)
>    contribute `RecoveryRoll (fun (a,b) -> a+3,b)
>    contribute `RecoveryRoll (fun (a,b) -> a,b-1)
>    contribute `ResistPain (fun a -> a+1)
>    contribute `MagicResistance (fun a -> match a with None -> None |
> Some x -> Some(x+3))
>    contribute `MagicResistance (fun a -> match a with None -> Some 7 |
> Some x -> Some(x+7))
>
>    (* example of applying modifiers... *)
>    let modified = fold `RecoveryRoll (4,1) in
>    ...
>
> (There are details I've left out here, like the need for 'contribute'
> returning an id
> by which to remove a modifier, as well as control over
> order-of-application.)
>
> Now I think the type signature of these functions would be:
>
>    val contribute: a'. 'a key -> ('a -> 'a) -> unit
>    val fold: 'a. 'a key -> 'a -> 'a
>
> And the thorn in my side would be that the key must be "keyed" to the
> type, or
> is there an escape? At one point I tried a universal type to "hide" the
> signature of the function-list, but I also stashed the inj/proj under
> the key
> -- well, of course the inj/proj functions had different types per entry in a
> hashtable, so that worked as well as not having a universal type
> involved. :)
>
> If I provide the inj/proj functions at each invocation then I need to
> pre-create these and house them somewhere (which could create a
> bottleneck of
> type-dependencies) -- Imagine several hundred modifiers like `RecoveryRoll;
> some might use types that only need visibility in one module. Trying to
> place
> each modifier in suitable modules also seems a mess... a lot of them
> conceptually exist "in the spaces between modules".
>
> So I keep trying to create an airy light-weight "implied" association to
> connect modifiers to use-sites... but to satisfy typing it seems I need
> to be
> explicit at some point.
>
> Does anyone have any ideas? I'm often surprised at the gymnastics OCaml's
> type-system can accomplish under the guidance of some smart folks. If
> anyone's
> made a heterogenous dictionary/hashtable that doesn't need types explicity
> declared, that would probably be what I'm looking for.
>
>
> Note that I've had this problem surface several times and managed to find
> solutions that suited the specific problem, but each problem can have it's
> subtle details. In this case, the large number of keys and functions,
> combined with their spread across codebase and the sparse nature of their
> use (a game-entity might have a few dozen modifiers out of hundreds)...
> really
> seems to push for association-by-name-only. At least that's all my brain
> gravitates toward.
>
> -Tony
>