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 = <fun>

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 <jun.furuse@gmail.com> 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 <yminsky@gmail.com> 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 <jun.furuse@gmail.com> 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 = <abstr>      (* 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 <yminsky@gmail.com>
> 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 <yminsky@gmail.com>
> 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 = <fun>
> >>>> # Float.of_string;;
> >>>> - : string -> Core_extended.Std.Float.stringable = <fun>
> >>>>
> >>>> I'd be much happier if this was rendered in the following equally
> >>>> correct
> >>>> and more readable form:
> >>>>
> >>>> # Int.of_string;;
> >>>> - : string -> Int.t = <fun>
> >>>> # Float.of_string;;
> >>>> - : string -> Float.t = <fun>
> >>>>
> >>>> Or even:
> >>>>
> >>>> # Int.of_string;;
> >>>> - : string -> int = <fun>
> >>>> # Float.of_string;;
> >>>> - : string -> float = <fun>
> >>>>
> >>>> 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
>