Hi Yaron,

I think you better think twice about the problem in general (rather than the 
particular needs of Core) before proposing some controversial type display 
improvement.

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.

So, now, what's the point in the color type declaration ?
There is none, type aliasing becomes useless because you can't expose it.
Call me crazy but i whish i can use more than 3 characters as a type name. 

So you want it to be displayed as an Int.t rather than an Int.comparable ?
Then just declare it as Int.t rather than Int.comparable, or choose another 
shorter name, it's not an OCaml issue, its' a Core issue.
(obviously it would really help if no english word would be more than 6 
characters but Ocaml can't be blamed for that)

I mean, when designing an elaborate software library, you have to make choices, 
and often, no matter how good OCaml is, some choices will be compromises. You 
have to pick the lesser between several evils and live with it.

I have learned that when programming Ocaml-Idaho, suddenly module names become 
longer, module types become more composited, data types become more subtle, and 
so on and so on...
 
Blaming OCaml is a too easy path.

At one certain point you have to face the verbosity you have created and decide 
whether the additionnal expressivity worths the price.
If you think it does then it's ok, if not then just amend, if amending doesn't 
help then consider refactoring.
Seek the best expressiveness/verbosity ratio without sacrifying too much 
functionality.
That's 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 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.com> wrote:

On Fri, Oct 9, 2009 at 3:40 AM, Yaron Minsky <ymin...@gmail.com> wrote:
> Choosing shorter names.

By which you probably mean "the fewest number of dots (module
projections)". It might be a bit annoying if the code that prints
doesn't know what modules are open. What do the INRIA priests say?

Andrej
_______________________________________________
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

Reply via email to