From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id F3F7A7EE51 for ; Thu, 4 Apr 2013 04:18:32 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anthony.tavener@gmail.com) identity=pra; client-ip=209.85.215.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of anthony.tavener@gmail.com designates 209.85.215.171 as permitted sender) identity=mailfrom; client-ip=209.85.215.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ea0-f171.google.com) identity=helo; client-ip=209.85.215.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="postmaster@mail-ea0-f171.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwCAPThXFHRVderjWdsb2JhbABDgzyubYljAYgygQQIFg4BAQEBBwsLCRIGJIIfAQEEAScZARsSCwEDAQsGBQsDCg0hIQEBEQEFAQoSBhMICgmHZgEDCQYMoiOML4J7hEEKGScDClmIfAEFDIw7gk4EB4NAA4h6iiuBZoFggR+KUYM5FimETR0 X-IPAS-Result: AjwCAPThXFHRVderjWdsb2JhbABDgzyubYljAYgygQQIFg4BAQEBBwsLCRIGJIIfAQEEAScZARsSCwEDAQsGBQsDCg0hIQEBEQEFAQoSBhMICgmHZgEDCQYMoiOML4J7hEEKGScDClmIfAEFDIw7gk4EB4NAA4h6iiuBZoFggR+KUYM5FimETR0 X-IronPort-AV: E=Sophos;i="4.87,404,1363129200"; d="scan'208";a="11690365" Received: from mail-ea0-f171.google.com ([209.85.215.171]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 04 Apr 2013 04:18:32 +0200 Received: by mail-ea0-f171.google.com with SMTP id b15so863402eae.2 for ; Wed, 03 Apr 2013 19:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oAG+3/29ch8vN9X1dCqdai+9wEcoDiGv+rKHyn9orEo=; b=rmKZnOsh/CDYXZ8x0O5mtLYOwyBOZl8vYnH6eKgDsCEajqMbf/3rX7HEtFLYjjjgwP 2wtUbccN9LoeM4vPTq1r92xCppKthDcUgVW+Bapj+keWGJ1v3XIhvBi6t4NapLh6dc8n hmqdvv9JGc6cJxQmE4CyNA04xAjOXSYAxYzzj8/nN/1ab/J8+6/Qp4X5mQTGVeDCfF+I xb1pYZvlYd+TQMgDznwMlcjF8KJCq2JueMIi5DA79hOopRs5z5J0g6C6knUv4jNZXRIH MQJmZcq8Gvwwo9AlmUkXHDPIOpPWpzv+6Rat95T44WlYLHQiHnvOzXn+oWhKp9qFlttc 2ujg== MIME-Version: 1.0 X-Received: by 10.14.200.137 with SMTP id z9mr7196938een.20.1365041911492; Wed, 03 Apr 2013 19:18:31 -0700 (PDT) Received: by 10.14.2.198 with HTTP; Wed, 3 Apr 2013 19:18:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Apr 2013 20:18:31 -0600 Message-ID: From: Anthony Tavener To: Yaron Minsky Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=047d7b343b823d162904d97f9642 Subject: Re: [Caml-list] Heterogeneous dictionary --047d7b343b823d162904d97f9642 Content-Type: text/plain; charset=ISO-8859-1 Oh, maybe I created a limitation in my own head... Would this work then (for example): module Modifier = struct let recovery = Key.create "recovery" let resist_pain = Key.create "resist_pain" let resist_magic = Key.create "resist_magic" (* a whole lot of these... *) end These would then be monomorphic? Anyway, the important thing is they didn't require knowledge of any types to create all the keys, so now having all other modules referencing Modifier wouldn't be bad at all. Then something like the following will reify the type of the Modifier.recovery key? let mods = set mods Modifier.recovery (fun (a,b) -> a+6,b) in ... I kept thinking that if I had a "grand central" of universal embeddors they'd need to be aware of the types they're embedding... thereby creating the type-dependencies I was worried about! This solution, if I'm understanding it right, is perfectly fine! Thank-you for cluing me in, Yaron! On Wed, Apr 3, 2013 at 7:29 PM, Yaron Minsky wrote: > Have you looked at Univ_map in Core? It has the same problem you're > complaining about, in that the keys do need to be tied to the type of > the data stored under that key. You then of course need to stash the > key somewhere. But I'm not sure what problem that creates. In > particular, I don't know why this creates a bottleneck of type > dependencies. Each Univ_map.Key.t is created independently, and can > be created at any point in the code. > > y > > On Wed, Apr 3, 2013 at 8: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. > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --047d7b343b823d162904d97f9642 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Oh, maybe I created a limitation in my own head...
Would this work then (for example):

<= /div>
module Modifier =3D struct
=A0 let recovery= =3D Key.create "recovery"
=A0 let resist_pain =3D Key.create "resist_pain"
=
=A0 let resist_magic =3D Key.create "resist_magic"
=A0 (* a whole lot of these... *)
end

These would then be monomorphic? Anyway, the important= thing is
they didn't require knowledge of any types to= create all the keys, so
now having all other modules refer= encing Modifier wouldn't be bad at all.

Then something like the following will reif= y the type of the
Modifier.recovery key?
=A0 let mods =3D set mods Modifier.recovery (fun (a,b) -= > a+6,b) in ...

I kept thinking that if I had a "grand= central" of universal embeddors
they'd need to be= aware of the types they're embedding... thereby
creati= ng the type-dependencies I was worried about!

This solution, if I'm understanding it = right, is perfectly fine!
Thank-you for cluing me in, Yaron= !



On Wed, Apr 3, 2013 at 7:29 PM, Yaron Minsky <yminsky@janestreet.com= > wrote:
Have you looked at Univ_map in Core? =A0It has the same problem you're<= br> complaining about, in that the keys do need to be tied to the type of
the data stored under that key. =A0You then of course need to stash the
key somewhere. =A0But I'm not sure what problem that creates. =A0In
particular, I don't know why this creates a bottleneck of type
dependencies. =A0Each Univ_map.Key.t is created independently, and can
be created at any point in the code.

y

On Wed, Apr 3, 2013 at 8:45 PM, Anthony Tavener
<anthony.tavener@gmail.com<= /a>> wrote:
> I think I might be up against a brick wall. But maybe there's a do= or 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 be= tween
> keys. Basically like a hashtable you'd find in a dynamic language.=
>
> =A0 (* modifier-additions like this would be scattered across the code= -base *)
> =A0 contribute `RecoveryRoll (fun (a,b) -> a+3,b)
> =A0 contribute `RecoveryRoll (fun (a,b) -> a,b-1)
> =A0 contribute `ResistPain (fun a -> a+1)
> =A0 contribute `MagicResistance (fun a -> match a with None -> N= one | Some x
> -> Some(x+3))
> =A0 contribute `MagicResistance (fun a -> match a with None -> S= ome 7 | Some x
> -> Some(x+7))
>
> =A0 (* example of applying modifiers... *)
> =A0 let modified =3D fold `RecoveryRoll (4,1) in
> =A0 ...
>
> (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:
>
> =A0 val contribute: a'. 'a key -> ('a -> 'a) -&g= t; unit
> =A0 val fold: 'a. 'a key -> 'a -> 'a
>
> And the thorn in my side would be that the key must be "keyed&quo= t; 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 als= o
> 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. =A0:)
>
> 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<= br> > OCaml's type-system can accomplish under the guidance of some smar= t
> 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 ke= ys
> 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)... =A0really seems to push for
> association-by-name-only. At least that's all my brain gravitates<= br> > toward.

--
Caml-list mailing list. =A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--047d7b343b823d162904d97f9642--