On Sun, Oct 11, 2009 at 2:17 PM, Damien Guichard= <alphablock@o= range.fr> wrote:

=A0

Hi Gilles,

=A0

The type display routine uses right-= associativity=20 of the -> operator as a rewriting rule.

Thus ('a -> 'a -> f= loat) and=20 'a -> ('a -> float) are the same type and are both=A0displayed as=A0'a -> '= ;a ->=20 float.

=A0

The type=A0'a -> ('a -= > float)=20 means=A0the application=A0will be (f x) y which is actually the=20 same as=A0f x y because the application is=20 left-associative.

The typer system doesn't care ab= out your actual=20 code syntax, and rightly so because=A0the typer system is about=20 semantic.

You intend to write=A0(f x) y, yet=20 the type system tells you intend to write=A0f x y, that's quite= =20 disturbing at first encounter.

=A0

Suffice to say you have to get your = head around=20 it.

Mind the right-associativity of ->= ; and the=20 left-associativity of application.

Think your code more semantically an= d less=20 syntactically.
In the end=A0this type sytem makes you a better= =20 programmer.

=A0

- damien

=A0

=A0

En r=E9ponse au message=
de=20 : Gilles Pirio

du :=20 2009-10-11=A021:57:40

=C0 :=20 caml-list@yqu= em.inria.fr

CC :
Sujet : Re: [Caml= -list]=20 Re: Improving OCaml's choice of type to display

=A0

On the same topic, I was wonderi= ng why the=20 type of the ampl_scalar_app function below was displayed as ('a -> &= #39;a ->=20 float) -> 'a -> 'a -> float rather than ('a -> '= ;a -> float) ->=20 'a -> ('a -> float). The latter would make my life easier.
# let=20 ampl_scalar_app f p =3D if f p p > 1. then fun x->f x p else fun x-&g= t;f p=20 x;;
val ampl_scalar_app : ('a -> 'a -> float) -> 'a= -> 'a ->=20 float =3D <fun>

PS: I can imagine this has been discussed exte= nsively=20 before, feel free to just send my a link to the relevant discussion if that= 's=20 the case :)

Giles

On Sun, Oct 11, 2009 at 8:24 AM, Jun Furuse <jun.furuse@gmail.com>=20 wrote:

I=20 have not tested it well but it counts dots and should try to find
the= =20 minimal one.

A problem I have found so far is that it prints somet= hing=20 confusing, ex.

module M =3D struct type t end
module N =3D stru= ct type t=20 end
open M
open N

let _ =3D ( 1 : M.t )

>> Erro= r: This=20 expression has type int but an expression was expected of type t =A0=20 =A0(which t ?!?!?)

If there are types M.t and N.t and the both of = M=20 and N are opened,
these types are printed just "t". This can= be avoided by=20 testing the
result name "t" against the current typing envri= onment to see=20 it
really means the original type "M.t". This requires more = coding=20 but
the weekend has ended in the far east already :-) =A0 (It's 0:= 24=20 Monday
now.)

Jun

On Mon, Oct 12, 2009 at 12:12 AM, Yaron Minsky <yminsky@gmail.com> wrote:<= br>> Cool!=20 =A0That was quick.
>
> Does this patch also implement stephen= 's=20 fewest-number-of-dots heuristic? =A0I
> was thinking one nice=20 approach would be fewest-number-of-dots with ties
> broken by lengt= h of=20 final identifier.
>
> Y
>
> Yaron=20 Minsky
>
> On Oct 11, 2009, at 10:57 AM, Jun Furuse <jun.furuse@gmail.com>=20 wrote:
>
>> I have quickly wrote a small patch against 3.1= 1.1=20 for this feature, to
>> see what it would be=20 like.
>>
>> http://sites.g= oogle.com/a/furuse.info/jun/hacks/other-small-ocaml-patches
>>=
>>=20 With this patch, path names are printed without opened modules in=20 the
>> context. It also tries heuristic data type name=20 simplification: if a
>> variant/record data type is an alias of= =20 another data type whose name
>> is shorter than the original, th= e=20 printer uses the latter.
>>
>> For=20 example:
>>
>> # open Hashtbl;;
>> # let tbl = =3D=20 Hashtbl.create 10;;
>> val tbl : ('_a, '_b) t =3D <ab= str> =A0=20 =A0 =A0(* not Hashtbl.t, since Hashtbl is
>> open=20 *)
>>
>> # type t =3D int;;
>> type t =3D=20 int
>> # type long_name =3D int;;
>> type long_name =3D= =20 int
>> # (1 : t);;
>> - : t =3D 1 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0 =A0 (* t is the shorter than its=20 original type
>> int *)
>> # (1 : long_name);;
>&= gt; -=20 : int =3D 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (*=20 int is shorter name for long_name. t
>> is even shorter but not= =20 aliased unfortunatelly. *)
>>
>> I warn you that the pa= tch=20 is very quickly written and not tested well.
>>=20 Enjoy!
>>
>> Jun
>>
>> On Fri, Oct 9,= 2009=20 at 10:53 AM, Yaron Minsky <yminsky@gmail.com>=20 wrote:
>>>
>>> And you can compete to come up wit= h the=20 most innocuous code that comes up
>>> with the longest type.= =20 =A0Here's my current favorite:
>>>
>>> # open= =20 Option.Monad_infix;;
>>> # Map.find m 3 >>| fun x ->= x +=20 1;;
>>> - : int Core.Std.Option.Monad_infix.monad =3D Some=20 4
>>>
>>> Which of course could be rendered=20 as:
>>>
>>> # open=20 Option.Monad_infix;;
>>> # Map.find m 3 >>| fun x ->= x +=20 1;;
>>> - : int option =3D Some 4
>>>
>>= >=20 y
>>>
>>> On Thu, Oct 8, 2009 at 9:40 PM, Yaron M= insky=20 <yminsky@gmail.= com>=20 wrote:
>>>>
>>>> Anyone who plays around wi= th=20 the Core library that Jane Street just
>>>> released can s= ee=20 showcased a rather ugly detail of how Core's design
>>>&g= t;=20 interacts with how OCaml displays types.=20 =A0Witness:
>>>>
>>>> #=20 Int.of_string;;
>>>> - : string -> Core.Std.Int.stringa= ble =3D=20 <fun>
>>>> # Float.of_string;;
>>>> -= :=20 string -> Core_extended.Std.Float.stringable =3D=20 <fun>
>>>>
>>>> I'd be much happi= er if=20 this was rendered in the following equally
>>>>=20 correct
>>>> and more readable=20 form:
>>>>
>>>> #=20 Int.of_string;;
>>>> - : string -> Int.t =3D=20 <fun>
>>>> # Float.of_string;;
>>>> -= :=20 string -> Float.t =3D <fun>
>>>>
>>>&= gt; Or=20 even:
>>>>
>>>> #=20 Int.of_string;;
>>>> - : string -> int =3D=20 <fun>
>>>> # Float.of_string;;
>>>> -= :=20 string -> float =3D <fun>
>>>>
>>>>= ; And=20 this isn't just an issue in the top-level. The compiler=20 also
>>>> displays
>>>> types in the same= =20 difficult to read form. =A0I'm wondering if anyone has
>>>= ;>=20 some
>>>> thoughts as to what we can do to make the compil= er=20 make better choices
>>>> here. =A0There are two issues to= =20 overcome:
>>>>
>>>> Dropping the module nam= e.=20 =A0I'd love to give the compiler the hint that
>>>>=20 Core.Std. could be dropped from the prefix in a context where=20 that
>>>> module is
>>>> open. =A0This is= =20 what's done with the pervasives module already, I
>>>>= believe,=20 so
>>>> it seems like it should be doable=20 here.
>>>> Choosing shorter names. =A0This one seems harde= r,=20 but there are various
>>>> different possibilities for wha= t=20 type name to print out, and a
>>>>=20 reasonable
>>>> heuristic to use might be to pick the shor= test=20 one. =A0Part of the reason
>>>> these issues come up is ou= r=20 use of standardized interface components
>>>>=20 (that's
>>>> where the "stringable" type nam= e comes from).=20 =A0I suspect this one will
>>>> be
>>>> har= d=20 to fix, sadly.
>>>>
>>>> Anyway, we'd b= e happy=20 with any suggestions on how to improve=20 matters.
>>>>
>>>>=20 y
>>>
>>>
>>>=20 _______________________________________________
>>> Caml-list= =20 mailing list. Subscription management:
>>> http:/= /yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>>>=20 Archives: http://caml.= inria.fr
>>> Beginner's list: http://groups.yahoo.com/= group/ocaml_beginners
>>>=20 Bug reports: http://caml.inria.fr/bin/caml-bugs
>>>
>>>=
>

_______________________________________________
Caml-lis= t=20 mailing list. Subscription management:
http://yquem.inria.= fr/cgi-bin/mailman/listinfo/caml-list
Archives:=20 http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug=20 reports: http://caml.inria.fr/bin/caml-bugs
<= br>

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.in= ria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs