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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 375F47EE51 for ; Thu, 4 Apr 2013 03:29:06 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.229 as permitted sender) identity=mailfrom; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@tot-dmz-mxout1.janestreet.com) identity=helo; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@tot-dmz-mxout1.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqABAArWXFEmacjlnGdsb2JhbABDxDqBBR4OAQEBAQEGDQkJFCiCHwEBBScZAQE3AQ8LCw0uIQESAQUBHAYTG4dnAw8Doi6Kb4Q7AQWFBw2JVQaMR4JSB4NAkyiBZoFgi3CDORYphEo X-IPAS-Result: AqABAArWXFEmacjlnGdsb2JhbABDxDqBBR4OAQEBAQEGDQkJFCiCHwEBBScZAQE3AQ8LCw0uIQESAQUBHAYTG4dnAw8Doi6Kb4Q7AQWFBw2JVQaMR4JSB4NAkyiBZoFgi3CDORYphEo X-IronPort-AV: E=Sophos;i="4.87,404,1363129200"; d="scan'208";a="9700165" Received: from mx5.janestreet.com (HELO tot-dmz-mxout1.janestreet.com) ([38.105.200.229]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2013 03:29:04 +0200 Received: from tot-oib-smtp1.delacy.com ([172.27.22.15] helo=tot-smtp) by tot-dmz-mxout1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1UNYz8-0000q7-VZ for caml-list@inria.fr; Wed, 03 Apr 2013 21:29:02 -0400 Received: from tot-dmz-mxgoog1.delacy.com ([172.27.224.14] helo=mxgoog2.janestreet.com) by tot-smtp with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UNYz8-0000aH-UN for caml-list@inria.fr; Wed, 03 Apr 2013 21:29:02 -0400 Received: from mail-wg0-f72.google.com ([74.125.82.72]) by mxgoog2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1UNYz8-00055g-QP for caml-list@inria.fr; Wed, 03 Apr 2013 21:29:02 -0400 Received: by mail-wg0-f72.google.com with SMTP id m15so3180792wgh.3 for ; Wed, 03 Apr 2013 18:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LhFs37ISJU9lxBsrnKyJifVc0rN7Wy38xdap+gFAxyM=; b=SStvsdpKdFuHbh/ZwHOE9M5/kVewwdgEfEp9hw71HmhSk0A23A6xSLJm173d6FuKwU m6rMHveaAUoDF/l6ouc9l2jxUN+reIHfOIUiU+CCcWiZoyIPc7Iq8LSJlOD3Xfaa63Qo M63WJi0scayF5yTOCaSuzDHp7MKYrKibo6qpQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=LhFs37ISJU9lxBsrnKyJifVc0rN7Wy38xdap+gFAxyM=; b=icsoNEJ7qaJ1rH5ScUcxZsYuuAForuHyi2XzIx0VMDpBvo/ck0xdaj+mzZ1qsQYgLk wte1UYqE6ip0qFgdsoeXbexOoVkIjrmznEbTIsauEnNJsZb2GCJI4+lTcLz9DoSTBVpa jpLNEeV4VZRchBUqlWB0AjCZs3K8Vv4VfOe961Iw94FPmeb20VnIop8O7o37yJij0f8g Mo9z5QhkDNTjZIcyW/mFS13qQU3GOsMEXiAdxreOQRY2L17m4vH/n17AsJW6fEmjTixc vE8YbIkE/T4Tc+jyw7H+2eciHJ1ieU1y5T3hqOXgMAe/QzTXpAescCPDPeCYep+VbI1H wxZw== X-Received: by 10.204.227.80 with SMTP id iz16mr2831202bkb.121.1365038942199; Wed, 03 Apr 2013 18:29:02 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.204.227.80 with SMTP id iz16mr2831200bkb.121.1365038942075; Wed, 03 Apr 2013 18:29:02 -0700 (PDT) Received: by 10.204.226.78 with HTTP; Wed, 3 Apr 2013 18:29:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Apr 2013 21:29:01 -0400 Message-ID: From: Yaron Minsky To: Anthony Tavener Cc: "caml-list@inria.fr" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnFrOmYQEQg7fWo7t5ZEAY7n3UZJe+Ov8qmRyDqp4PTgAHLRixvKnGQSL8+gYPmCgOtHqSrXYrWiDz7pGevJgMWOvqvdpRA9MalRTmZf0w0Ytz4sXEOkeYAHCr8K4QOoomQ/R5KrxJD6YBDpfSZpEZBsXDkjQ== Subject: Re: [Caml-list] Heterogeneous dictionary 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.