From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 A51087EE51 for ; Sat, 13 Apr 2013 19:26:17 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of anthony.tavener@gmail.com) identity=pra; client-ip=74.125.83.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of anthony.tavener@gmail.com designates 74.125.83.48 as permitted sender) identity=mailfrom; client-ip=74.125.83.48; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ee0-f48.google.com) identity=helo; client-ip=74.125.83.48; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="postmaster@mail-ee0-f48.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMCAFmUaVFKfVMwk2dsb2JhbABQgzy5FwGINXwIFg4BAQEBBwsLCRQEJIIfAQEFJxkBGx0BAwELBgULDS4hAQERAQUBHAYTiAEBAw8MnHeML4J7hBUKGScNWYh+AQUMjDiCUweDQQOJBYwdgWOBIYpUgzoWKYRNHQ X-IPAS-Result: AnMCAFmUaVFKfVMwk2dsb2JhbABQgzy5FwGINXwIFg4BAQEBBwsLCRQEJIIfAQEFJxkBGx0BAwELBgULDS4hAQERAQUBHAYTiAEBAw8MnHeML4J7hBUKGScNWYh+AQUMjDiCUweDQQOJBYwdgWOBIYpUgzoWKYRNHQ X-IronPort-AV: E=Sophos;i="4.87,468,1363129200"; d="scan'208";a="10847773" Received: from mail-ee0-f48.google.com ([74.125.83.48]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 13 Apr 2013 19:25:46 +0200 Received: by mail-ee0-f48.google.com with SMTP id b15so1639283eek.7 for ; Sat, 13 Apr 2013 10:25:45 -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=ifSiHk/EMeQXUvk5j0AaqxoVfzhNeI2XfedPkkZsoL8=; b=rUI+eloVjAyVFZUs2GOIsmfOdvpwB6frLb8zjfopvGJ6uUuYKXRBHVvX5OpMrL+xv+ Bd0m7EWu2hV44oVwjuWTr5aNg6Sugr4ooG0J1B9swI0bBbGXqRryQoyWPIlk4EcmQ5BT VWTG2F2jiqkcvHh/AtyI2OsRO8vWIohPcxat49keV5cUA6gDh0AYNytw0O0Ifl2319cF 5/AsL+qtNohhs3+mrKjxpkzHjZyP1yXpCgYDuKmEmSMc6rhm9o3g6Hb/I5yXGsjhn9rJ wWr5sRO+lqAtraPgLYHraVKP2mo7K3I1Pcg1GiUOEeRVedfonlvQhgML0AqkMnokBSma 3bDw== MIME-Version: 1.0 X-Received: by 10.14.104.6 with SMTP id h6mr41652912eeg.5.1365873945615; Sat, 13 Apr 2013 10:25:45 -0700 (PDT) Received: by 10.14.7.4 with HTTP; Sat, 13 Apr 2013 10:25:45 -0700 (PDT) In-Reply-To: References: Date: Sat, 13 Apr 2013 11:25:45 -0600 Message-ID: From: Anthony Tavener To: Gabriel Scherer Cc: Kakadu , "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=001a11c28e8e5641e604da414fab Subject: Re: [Caml-list] Types look compatible, but they aren't? --001a11c28e8e5641e604da414fab Content-Type: text/plain; charset=ISO-8859-1 In this instance it aquired a _ though, or does that have some other meaning here? I was getting < .. > at first, but when I called Modifer.attach with three arguments the inference changed to < _.. >. As a side note, I didn't know what to make of < .. > until Kakadu mentioned objects. I was thinking "what is that, some kind of abstract type"? That's what I get for rarely using objects! On Sat, Apr 13, 2013 at 11:14 AM, Gabriel Scherer wrote: > > 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 > >>> >> > >>> >> > >>> > > >> > >> > > > --001a11c28e8e5641e604da414fab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In this instance it aquired a _ though, or does that have = some other meaning here?

I was getting < .. >= ; at first, but when I called Modifer.attach with three arguments the infer= ence
changed to < _.. >.

A= s a side note, I didn't know what to make of < .. > until Kakadu = mentioned objects. I was thinking "what is that, some kind of abstract= type"? That's what I get for rarely using objects!


On Sat,= Apr 13, 2013 at 11:14 AM, Gabriel Scherer <gabriel.scherer@gmail.= com> wrote:
> So, 'a becomes: (= < _.. > as 'a) -- I get some monomorphic... object?

Just a small thing, (< .. > as 'a) is not monomorphic, it i= s 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
<anthony.tavener@gmail.com<= /a>> 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 &q= uot;object" was
> revealed.
>
>
> On Sat, Apr 13, 2013 at 10:07 AM, Anthony Tavener
> <anthony.tavener@gmail= .com> wrote:
>>
>> Ohhh... that is interesting. (TL;DR: problem solved, and it was fr= om
>> inappropriate Oo.id use.)
>>
>> Modifier.attach is actually implemented as a function of one argum= ent
>> 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 =3D ... and just inline "Modifer.atta= ch id ..." the
>> type of Modifier.attach changes to:
>>
>> =A0 Db.key -> int * (((< _.. > as 'a) list -> exn)= * (exn -> 'a list) -> 'a
>> -> Modifier.deleter
>>
>> So, 'a becomes: (< _.. > as 'a) -- I get some monomo= rphic... object?
>>
>> As I wrote this I had an idea and found the problem:
>>
>> =A0 ...
>> =A0 (* return (tbl -> unit) function which deletes this specifi= c function *)
>> =A0 let del_id =3D Oo.id fn in
>> =A0 (fun tbl ->
>> =A0 =A0 let lst =3D List.filter (fun e -> Oo.id e <> del_= id) (fn_list tbl) in
>> =A0 =A0 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 t= his <..>
>> 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 th= e right
>> direction!
>>
>>
>> On Sat, Apr 13, 2013 at 1:33 AM, Gabriel Scherer
>> <gabriel.scherer@g= mail.com> wrote:
>>>
>>> This looks like a value restriction issue with
>>>
>>> =A0 let m =3D Modifier.attach id
>>>
>>> =A0 "A function obtained through partial application is n= ot polymorphic
>>> enough"
>>> =A0 http://caml.inria.fr/resources/doc/fa= q/core.en.html#eta-expansion
>>>
>>> If this is indeed the source of your error, you can regain
>>> type-checking by using instead
>>>
>>> =A0 let m total =3D 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 nex= t
>>> parameter: if would have been effected only once with your pre= vious
>>> definition, and will be effected at each call of 'm' w= ith the new
>>> definition.
>>>
>>> On Sat, Apr 13, 2013 at 8:56 AM, Kakadu <kakadu.hafanana@gmail.com>
>>> wrote:
>>> > Maybe function type (int * int -> int * int) is incomp= atible with
>>> > object
>>> > type <..>?
>>> >
>>> > Kakadu
>>> >
>>> >
>>> > On Sat, Apr 13, 2013 at 10:50 AM, Anthony Tavener
>>> > <anthony.= tavener@gmail.com> wrote:
>>> >>
>>> >> File "virtue.ml", line 462, characters 12-24:
>>> >> Error: This expression has type
>>> >> =A0 =A0 =A0 =A0 =A0int * ((int * int -> int * int)= list -> exn) *
>>> >> =A0 =A0 =A0 =A0 =A0(exn -> (int * int -> int * = int) list)
>>> >> =A0 =A0 =A0 =A0but an expression was expected of type=
>>> >> =A0 =A0 =A0 =A0 =A0int * ((< .. > as 'a) li= st -> exn) * (exn -> 'a list)
>>> >>
>>> >> The code in question:
>>> >>
>>> >> =A0 (fun id ->
>>> >> =A0 =A0 let m =3D Modifier.attach id in
>>> >> =A0 =A0 =A0 [ m Cast.total'k (fun (v,b) -> (v,= max 1 (b-3))) =A0 =A0 (* <-- line
>>> >> 462
>>> >> *)
>>> >> =A0 =A0 =A0 ; m Lab.total'k (fun (v,b) -> (v, = max 1 (b-3))) ])
>>> >>
>>> >> For reference, the signature of Modifier.attach:
>>> >> =A0 Db.key -> int * ('a list -> exn) * (exn= -> 'a list) -> 'a ->
>>> >> Modifier.deleter
>>> >>
>>> >> OCaml version is 4.00.0 -- I know I should upgrade. K= eep 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-o= ut looking at
>>> >> this.
>>> >>
>>> >> =A0-Tony
>>> >>
>>> >>
>>> >
>>
>>
>

--001a11c28e8e5641e604da414fab--