Hi Gilles, The type display routine uses right-associativity of the -> operator as a rewriting rule. Thus ('a -> 'a -> float) and 'a -> ('a -> float) are the same type and are both displayed as 'a -> 'a -> float. The type 'a -> ('a -> float) means the application will be (f x) y which is actually the same as f x y because the application is left-associative. The typer system doesn't care about your actual code syntax, and rightly so because the typer system is about semantic. You intend to write (f x) y, yet the type system tells you intend to write f x y, that's quite disturbing at first encounter. Suffice to say you have to get your head around it. Mind the right-associativity of -> and the left-associativity of application. Think your code more semantically and less syntactically. In the end this type sytem makes you a better programmer. - damien En réponse au message de : Gilles Pirio du : 2009-10-11 21:57:40 À : caml-list@yquem.inria.fr CC : Sujet : Re: [Caml-list] Re: Improving OCaml's choice of type to display On the same topic, I was wondering why the type of the ampl_scalar_app function below was displayed as ('a -> 'a -> float) -> 'a -> 'a -> float rather than ('a -> 'a -> float) -> 'a -> ('a -> float). The latter would make my life easier. # let ampl_scalar_app f p = if f p p > 1. then fun x->f x p else fun x->f p x;; val ampl_scalar_app : ('a -> 'a -> float) -> 'a -> 'a -> float = PS: I can imagine this has been discussed extensively before, feel free to just send my a link to the relevant discussion if that's the case :) Giles On Sun, Oct 11, 2009 at 8:24 AM, Jun Furuse wrote: I have not tested it well but it counts dots and should try to find the minimal one. A problem I have found so far is that it prints something confusing, ex. module M = struct type t end module N = struct type t end open M open N let _ = ( 1 : M.t ) >> Error: This expression has type int but an expression was expected of type t (which t ?!?!?) If there are types M.t and N.t and the both of M and N are opened, these types are printed just "t". This can be avoided by testing the result name "t" against the current typing envrionment to see it really means the original type "M.t". This requires more coding but the weekend has ended in the far east already :-) (It's 0:24 Monday now.) Jun On Mon, Oct 12, 2009 at 12:12 AM, Yaron Minsky wrote: > Cool! That was quick. > > Does this patch also implement stephen's fewest-number-of-dots heuristic? I > was thinking one nice approach would be fewest-number-of-dots with ties > broken by length of final identifier. > > Y > > Yaron Minsky > > On Oct 11, 2009, at 10:57 AM, Jun Furuse wrote: > >> I have quickly wrote a small patch against 3.11.1 for this feature, to >> see what it would be like. >> >> http://sites.google.com/a/furuse.info/jun/hacks/other-small-ocaml-patches >> >> With this patch, path names are printed without opened modules in the >> context. It also tries heuristic data type name simplification: if a >> variant/record data type is an alias of another data type whose name >> is shorter than the original, the printer uses the latter. >> >> For example: >> >> # open Hashtbl;; >> # let tbl = Hashtbl.create 10;; >> val tbl : ('_a, '_b) t = (* not Hashtbl.t, since Hashtbl is >> open *) >> >> # type t = int;; >> type t = int >> # type long_name = int;; >> type long_name = int >> # (1 : t);; >> - : t = 1 (* t is the shorter than its original type >> int *) >> # (1 : long_name);; >> - : int = 1 (* int is shorter name for long_name. t >> is even shorter but not aliased unfortunatelly. *) >> >> I warn you that the patch is very quickly written and not tested well. >> Enjoy! >> >> Jun >> >> On Fri, Oct 9, 2009 at 10:53 AM, Yaron Minsky wrote: >>> >>> And you can compete to come up with the most innocuous code that comes up >>> with the longest type. Here's my current favorite: >>> >>> # open Option.Monad_infix;; >>> # Map.find m 3 >>| fun x -> x + 1;; >>> - : int Core.Std.Option.Monad_infix.monad = Some 4 >>> >>> Which of course could be rendered as: >>> >>> # open Option.Monad_infix;; >>> # Map.find m 3 >>| fun x -> x + 1;; >>> - : int option = Some 4 >>> >>> y >>> >>> On Thu, Oct 8, 2009 at 9:40 PM, Yaron Minsky wrote: >>>> >>>> Anyone who plays around with the Core library that Jane Street just >>>> released can see showcased a rather ugly detail of how Core's design >>>> interacts with how OCaml displays types. Witness: >>>> >>>> # Int.of_string;; >>>> - : string -> Core.Std.Int.stringable = >>>> # Float.of_string;; >>>> - : string -> Core_extended.Std.Float.stringable = >>>> >>>> I'd be much happier if this was rendered in the following equally >>>> correct >>>> and more readable form: >>>> >>>> # Int.of_string;; >>>> - : string -> Int.t = >>>> # Float.of_string;; >>>> - : string -> Float.t = >>>> >>>> Or even: >>>> >>>> # Int.of_string;; >>>> - : string -> int = >>>> # Float.of_string;; >>>> - : string -> float = >>>> >>>> And this isn't just an issue in the top-level. The compiler also >>>> displays >>>> types in the same difficult to read form. I'm wondering if anyone has >>>> some >>>> thoughts as to what we can do to make the compiler make better choices >>>> here. There are two issues to overcome: >>>> >>>> Dropping the module name. I'd love to give the compiler the hint that >>>> Core.Std. could be dropped from the prefix in a context where that >>>> module is >>>> open. This is what's done with the pervasives module already, I >>>> believe, so >>>> it seems like it should be doable here. >>>> Choosing shorter names. This one seems harder, but there are various >>>> different possibilities for what type name to print out, and a >>>> reasonable >>>> heuristic to use might be to pick the shortest one. Part of the reason >>>> these issues come up is our use of standardized interface components >>>> (that's >>>> where the "stringable" type name comes from). I suspect this one will >>>> be >>>> hard to fix, sadly. >>>> >>>> Anyway, we'd be happy with any suggestions on how to improve matters. >>>> >>>> y >>> >>> >>> _______________________________________________ >>> Caml-list mailing list. Subscription management: >>> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list >>> Archives: http://caml.inria.fr >>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >>> Bug reports: http://caml.inria.fr/bin/caml-bugs >>> >>> > _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs