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
Hey Damien
Sure, I fully understand that both types are equivalent given the rules
governing the application operator. My point was more on the usability side,
as the type display is primarily intended at helping the programmer to
quickly figure out type mismatch. So I'd think having a display
: 2009-10-09 20:14:18
À : caml-list@yquem.inria.fr
CC :
Sujet : Re: [Caml-list] Improving OCaml's choice of type to display
On Fri, Oct 9, 2009 at 3:33 AM, Andrej Bauer andrej.ba...@andrej.com wrote:
On Fri, Oct 9, 2009 at 3:40 AM, Yaron Minsky ymin...@gmail.com wrote:
Choosing shorter names
Well, if we're picking heuristics, the fewest number of characters wouldn't
be crazy either. Given the choice between Int.t and Int.comparable (which
are aliases for the same type), I'd prefer to see Int.t.
y
On Fri, Oct 9, 2009 at 3:33 AM, Andrej Bauer andrej.ba...@andrej.comwrote:
On Fri,
Can't there be a trick by playing with, e.g, ocamlmktop, which could open
Core and its main submodules by default, like it's done with Pervasives and,
IIRC, Batteries ?
On Fri, Oct 9, 2009 at 11:58 AM, Yaron Minsky ymin...@gmail.com wrote:
Well, if we're picking heuristics, the fewest number of
On Fri, Oct 9, 2009 at 6:54 AM, Alp Mestan a...@mestan.fr wrote:
Can't there be a trick by playing with, e.g, ocamlmktop, which could open
Core and its main submodules by default, like it's done with Pervasives and,
IIRC, Batteries ?
Maybe. Although to be honest my main concern is not with
Minsky
du : 2009-10-09 11:58:11
À : Andrej Bauer
CC : caml-list@yquem.inria.fr
Sujet : Re: [Caml-list] Improving OCaml's choice of type to display
Well, if we're picking heuristics, the fewest number of characters wouldn't be
crazy either. Given the choice between Int.t and Int.comparable (which
Hi,
can't you just say that you spotted a problem in the proposed solution
instead of being so aggressive?
Removing all the useless sentences of your message just leave this:
Le 9 oct. 09 à 16:18, Damien Guichard a écrit :
Imagine my code is:
type color = int
let black : color = 0
Le 9 oct. 09 à 16:18, Damien Guichard a écrit :
Imagine my code is:
type color = int
let black : color = 0
Then, following your proposition, evaluating black should give me
an int rather than a color because int is shorter and therefore nicer.
Hmm, I'd say that having OCaml
your job as a library designer.
- *damien*
--
*En réponse au message*
*de :* Yaron Minsky
*du :* 2009-10-09 11:58:11
*À :* Andrej Bauer
*CC :* caml-list@yquem.inria.fr
*Sujet :* Re: [Caml-list] Improving OCaml's choice of type to display
Well, if we're
-list@yquem.inria.fr
Sujet : Re: [Caml-list] Improving OCaml's choice of type to display
I do basically think of this as a deficiency in the compiler as opposed to a
deficiency in core (although it's hardly a major deficiency in the compiler).
Signatures, modules and functors are an important part
11 matches
Mail list logo
