caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Yaron Minsky <yminsky@gmail.com>
To: Damien Guichard <alphablock@orange.fr>
Cc: "caml-list@yquem.inria.fr" <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] Improving OCaml's choice of type to display
Date: Fri, 9 Oct 2009 12:52:38 -0400	[thread overview]
Message-ID: <891bd3390910090952l5112fe46ue01c8f2c66bc6583@mail.gmail.com> (raw)
In-Reply-To: <200910091618143281094@orange.fr>

[-- Attachment #1: Type: text/plain, Size: 4704 bytes --]

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 of the
language, and if you want to use them in a significant way, then you will
end up having multiple paths to get to the same type.  OCaml's algorithm for
choosing the type to display is somewhat unfortunate in this regard.

If you have a design approach that simultaneously makes good use of
functors, modules and signatures and makes OCaml's type-to-display-selector
happy, I'd be very interested in hearing it.

Finally, the specific point you make argues against the specific heuristic
(smallest type name) I proposed, but not against all other heuristics.
Another heuristic which I think has some potential is choosing the type name
with the smallest number of dots.  (also, as a matter of personal
preference, in the case that you outline, I would prefer the answer of "int"
to "color", but that is just a coincidence, of course.)

To be clear, some of this stuff can be made better by using signature
functors, but that has its own problems in terms of messiness and
boilerplate.  That said, I have half a mind to write a syntax extension to
clean that up, and switch over to signature functors, for this and other
reasons.  That said, signature functors only clean up a little bit of the
problem.

y

On Fri, Oct 9, 2009 at 10:18 AM, Damien Guichard <alphablock@orange.fr>wrote:

>
> 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<https://forge.ocamlcore.org/projects/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.bauer@andrej.com>wrote:
>
>> On Fri, Oct 9, 2009 at 3:40 AM, Yaron Minsky <yminsky@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
>
>

[-- Attachment #2: Type: text/html, Size: 8511 bytes --]

  parent reply	other threads:[~2009-10-09 16:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-09  1:40 Yaron Minsky
2009-10-09  1:53 ` Yaron Minsky
2009-10-11 14:57   ` [Caml-list] " Jun Furuse
2009-10-11 15:12     ` Yaron Minsky
2009-10-11 15:24       ` Jun Furuse
2009-10-11 19:57         ` Gilles Pirio
2009-10-11 21:17           ` [Caml-list] " Damien Guichard
2009-10-11 21:46             ` Gilles Pirio
2009-10-11 22:16               ` Lukasz Stafiniak
2009-10-09  7:33 ` Andrej Bauer
2009-10-09  9:58   ` Yaron Minsky
2009-10-09 10:54     ` Alp Mestan
2009-10-09 11:15       ` Yaron Minsky
2009-10-09 14:18     ` Damien Guichard
2009-10-09 14:44       ` Vincent Aravantinos
2009-10-09 15:27         ` David Allsopp
2009-10-09 16:52       ` Yaron Minsky [this message]
2009-10-09 18:23         ` Damien Guichard
2009-10-09 18:14   ` Stephen Weeks
2009-10-10 15:08     ` Damien Guichard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=891bd3390910090952l5112fe46ue01c8f2c66bc6583@mail.gmail.com \
    --to=yminsky@gmail.com \
    --cc=alphablock@orange.fr \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).