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 91A747EE5B for ; Sat, 13 Apr 2013 19:14:51 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.214.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.214.47 as permitted sender) identity=mailfrom; client-ip=209.85.214.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.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@mail-bk0-f47.google.com) identity=helo; client-ip=209.85.214.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-bk0-f47.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8CAC+SaVHRVdYvjmdsb2JhbABQgzzBTXwIFg4BAQEBBw0JCRIGJIIfAQEEAScZARsdAQMBCwYFCw0uIQEBEQEFARwGE4gBAQMJBgycdYwvgnuEFAoZJw1ZiH4BBQyMOIJTB4NBA5UigWOBIYpUgzoWKYQwOg X-IPAS-Result: Al8CAC+SaVHRVdYvjmdsb2JhbABQgzzBTXwIFg4BAQEBBw0JCRIGJIIfAQEEAScZARsdAQMBCwYFCw0uIQEBEQEFARwGE4gBAQMJBgycdYwvgnuEFAoZJw1ZiH4BBQyMOIJTB4NBA5UigWOBIYpUgzoWKYQwOg X-IronPort-AV: E=Sophos;i="4.87,468,1363129200"; d="scan'208";a="10847384" Received: from mail-bk0-f47.google.com ([209.85.214.47]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 13 Apr 2013 19:14:41 +0200 Received: by mail-bk0-f47.google.com with SMTP id ik5so1771602bkc.34 for ; Sat, 13 Apr 2013 10:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=CQPibR69JDQpono6LeCnyQRdhDVwcISr916RfkTgS7Q=; b=uiofMa7gVrb+kUkW1lqWevzQLa/f8ntmhAF9NcyXL/FyZcQn9DdGGnGbimnxvxNhHO 1D32tyBhgn9mppuXsh5Vshcp5YY/VLoPH3DDxbOKwnKZ/ffOgAl2qMfnYo7vEHfMdh+r 2AfK6z/64h33fWUaUrNG7gipgIIHMiNU03i6Myp3kugrMguBMCZGv3PMRc4A7ILOAO00 bHqASDSU9SD8I07C28FO+c1aLMWzOCuHKNgffVah7/5cwFwsIMEJWSOKSGQUtlVz1RhM 5nPBFBX2grD7vC0edbucDrdlhqFNCOKRqhQ0kzzru9hNR8sOeOYktKUpMnKLGQ1kGAGE r83w== X-Received: by 10.204.164.8 with SMTP id c8mr5897163bky.5.1365873281542; Sat, 13 Apr 2013 10:14:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.205.83.144 with HTTP; Sat, 13 Apr 2013 10:14:01 -0700 (PDT) In-Reply-To: References: From: Gabriel Scherer Date: Sat, 13 Apr 2013 19:14:01 +0200 Message-ID: To: Anthony Tavener Cc: Kakadu , "caml-list@inria.fr" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] Types look compatible, but they aren't? > So, 'a becomes: (< _.. > as 'a) -- I get some monomorphic... object? Just a small thing, (< .. > as 'a) is not monomorphic, it is still a polymorphic type, that may be instantiated with any object type. It is "less polymorphic" than 'a (can be instantiated with anything). On Sat, Apr 13, 2013 at 6:15 PM, Anthony Tavener wrote: > I forgot to note, that the interesting thing was how the type inferred for > Modifier.attach when it had > one argument applied did not show the < _.. > monomorphic object constraint. > Modifier.attach > is actually a: fun id -> (key -> fn -> deleter), rather than a > straightforward three-argument function. Once > the (key -> fn -> deleter) function would come into play, the "object" was > revealed. > > > On Sat, Apr 13, 2013 at 10:07 AM, Anthony Tavener > wrote: >> >> Ohhh... that is interesting. (TL;DR: problem solved, and it was from >> inappropriate Oo.id use.) >> >> Modifier.attach is actually implemented as a function of one argument >> which does some stuff, >> returning a function of two arguments, to avoid redundant lookups in the >> case of multiple "attach" >> to the same "id". >> >> When I remove the let m = ... and just inline "Modifer.attach id ..." the >> type of Modifier.attach changes to: >> >> Db.key -> int * (((< _.. > as 'a) list -> exn) * (exn -> 'a list) -> 'a >> -> Modifier.deleter >> >> So, 'a becomes: (< _.. > as 'a) -- I get some monomorphic... object? >> >> As I wrote this I had an idea and found the problem: >> >> ... >> (* return (tbl -> unit) function which deletes this specific function *) >> let del_id = Oo.id fn in >> (fun tbl -> >> let lst = List.filter (fun e -> Oo.id e <> del_id) (fn_list tbl) in >> Hashtbl.replace tbl tag (inj lst)) >> >> >> Here, "fn" is the provided function, and I want an easy way to remove such >> functions uniquely from the >> mess of Hashtbl, universal embedding, and list. I tried a trick I once >> read Alain suggest for getting a >> unique id using the object module... and I guess that brought in this <..> >> thing I was unfamiliar with. :) >> Instead of Oo.id I'm using Hashtbl.hash now, which is normally what I'd >> do... not sure why I >> half-remembered some trick with Oo.id. >> >> Thank-you for looking at this, both of you. It helped me dig in the right >> direction! >> >> >> On Sat, Apr 13, 2013 at 1:33 AM, Gabriel Scherer >> wrote: >>> >>> This looks like a value restriction issue with >>> >>> let m = Modifier.attach id >>> >>> "A function obtained through partial application is not polymorphic >>> enough" >>> http://caml.inria.fr/resources/doc/faq/core.en.html#eta-expansion >>> >>> If this is indeed the source of your error, you can regain >>> type-checking by using instead >>> >>> let m total = Modifier.attach id total >>> >>> Note that this may change the semantics of your code if >>> (Modifier.attach id) does a side-effect before getting its next >>> parameter: if would have been effected only once with your previous >>> definition, and will be effected at each call of 'm' with the new >>> definition. >>> >>> On Sat, Apr 13, 2013 at 8:56 AM, Kakadu >>> wrote: >>> > Maybe function type (int * int -> int * int) is incompatible with >>> > object >>> > type <..>? >>> > >>> > Kakadu >>> > >>> > >>> > On Sat, Apr 13, 2013 at 10:50 AM, Anthony Tavener >>> > wrote: >>> >> >>> >> File "virtue.ml", line 462, characters 12-24: >>> >> Error: This expression has type >>> >> int * ((int * int -> int * int) list -> exn) * >>> >> (exn -> (int * int -> int * int) list) >>> >> but an expression was expected of type >>> >> int * ((< .. > as 'a) list -> exn) * (exn -> 'a list) >>> >> >>> >> The code in question: >>> >> >>> >> (fun id -> >>> >> let m = Modifier.attach id in >>> >> [ m Cast.total'k (fun (v,b) -> (v, max 1 (b-3))) (* <-- line >>> >> 462 >>> >> *) >>> >> ; m Lab.total'k (fun (v,b) -> (v, max 1 (b-3))) ]) >>> >> >>> >> For reference, the signature of Modifier.attach: >>> >> Db.key -> int * ('a list -> exn) * (exn -> 'a list) -> 'a -> >>> >> Modifier.deleter >>> >> >>> >> OCaml version is 4.00.0 -- I know I should upgrade. Keep meaning to, I >>> >> guess I will if I wake up and there's no helpful soul explaining what >>> >> could >>> >> be wrong here. :) >>> >> >>> >> Thank-you for any help. My eyes are starting to bug-out looking at >>> >> this. >>> >> >>> >> -Tony >>> >> >>> >> >>> > >> >> >