From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=5.0 tests=AWL,DNS_FROM_RFC_POST, HTML_MESSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 6DBB3BBAF for ; Fri, 9 Oct 2009 18:52:41 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4DAKEGz0rRVdSskWdsb2JhbACCJi+Mfop0PwEBAQEJCwoHE65ZCoEyhnKIaAEDAwWEJwSICg X-IronPort-AV: E=Sophos;i="4.44,533,1249250400"; d="scan'208";a="36026804" Received: from mail-vw0-f172.google.com ([209.85.212.172]) by mail3-smtp-sop.national.inria.fr with ESMTP; 09 Oct 2009 18:52:40 +0200 Received: by vws2 with SMTP id 2so618456vws.15 for ; Fri, 09 Oct 2009 09:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=LBAsIvfISWStgOGCxX8InsqjHilGhCYDbc1Hfa0JSuU=; b=E+xCgtgKZYW4LQdxmuz2oUe3P3hmCa6U65yaBDPi7qsVt9GIUo1Ad2guhzyRvBMa2S n40/+cDvfUxqCW7tmBAIAprAsPPmvfIqCdkdqPJeg6d+/jBVabdXyJffPlbmaU0CmScB SvUGKzC1S6bnKWnZSRrHqC1IfjknmYLdKiSQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=RgpR7bySHOe85x+V6DRduV2VnmRwbGV+NshvWp5VEGWU1fk5beujfocfJMDLANHsjf KPsxLVhurESBEtaFWLTxfW3r41aZU6ZssZZiw3oVYe4EfNIPxZlyOMkgvhpRi26F0uyU N8ZUvDEIFRsqxl8zIcOsFaRZp75RebLU12eEc= MIME-Version: 1.0 Received: by 10.220.89.93 with SMTP id d29mr4406288vcm.26.1255107158770; Fri, 09 Oct 2009 09:52:38 -0700 (PDT) Reply-To: yminsky@gmail.com In-Reply-To: <200910091618143281094@orange.fr> References: <891bd3390910081840p37e8c786g60b2c15d2c06ae60@mail.gmail.com> <7d8707de0910090033q4a14a108w62f13d7735994923@mail.gmail.com> <891bd3390910090258l61aa7947p67a10c4adcc3312a@mail.gmail.com> <200910091618143281094@orange.fr> Date: Fri, 9 Oct 2009 12:52:38 -0400 Message-ID: <891bd3390910090952l5112fe46ue01c8f2c66bc6583@mail.gmail.com> Subject: Re: [Caml-list] Improving OCaml's choice of type to display From: Yaron Minsky To: Damien Guichard Cc: "caml-list@yquem.inria.fr" Content-Type: multipart/alternative; boundary=0016362852c05a855c04758368df X-Spam: no; 0.00; ocaml's:01 yaron:01 minsky:01 yminsky:01 compiler:01 compiler:01 functors:01 ocaml's:01 functors:01 argues:01 syntax:01 damien:01 guichard:01 yaron:01 ocaml:01 --0016362852c05a855c04758368df Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 fo= r 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 nam= e 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 wrot= e: > > 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 =3D int > > let black : color =3D 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 w= ith > 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 an= d > 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=E9ponse au message* > *de :* Yaron Minsky > *du :* 2009-10-09 11:58:11 > *=C0 :* 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 (whic= h > 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 wro= te: > >> On Fri, Oct 9, 2009 at 3:40 AM, Yaron Minsky 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 > > --0016362852c05a855c04758368df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 co= mpiler).=A0 Signatures, modules and functors are an important part of the l= anguage, and if you want to use them in a significant way, then you will en= d up having multiple paths to get to the same type.=A0 OCaml's algorith= m for choosing the type to display is somewhat unfortunate in this regard.<= br>
If you have a design approach that simultaneously makes good use of fun= ctors, modules and signatures and makes OCaml's type-to-display-selecto= r happy, I'd be very interested in hearing it.

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

To be clear, some of this stuff can be made better by using signature f= unctors, but that has its own problems in terms of messiness and boilerplat= e.=A0 That said, I have half a mind to write a syntax extension to clean th= at up, and switch over to signature functors, for this and other reasons.= =A0 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&g= t; wrote:
=A0
Hi Yaron,
=A0
I think you better think twice about= the problem=20 in general (rather than the particular needs of Core) before proposing=20 some=A0controversial type display improvement.
=A0
Imagine my code is:
=A0
=A0 type color =3D int
=A0
=A0 let b= lack : color=20 =3D 0=A0
=A0
Then, following your proposition, ev= aluating=20 black=A0should give me an int rather than a color=20 because int is shorter and therefore nicer.
=A0
So, now, what's the point in the= color=20 type declaration ?
There is none, type aliasing becomes useless because you can't exp= ose it.
Call me crazy=A0but i whish i can us= e more=20 than 3 characters as a=A0type name.=A0
=A0
So you want it to be displayed as=20 an=A0Int.t rather than an=A0Int.comparable=20 ?
Then just declare it as Int.t= rather=20 than Int.comparable, or choose another=A0shorter name, it's not = an=20 OCaml issue, its' a Core issue.
(obviously it would really help if n= o english=20 word would be more than 6 characters but Ocaml can't be blamed for=20 that)
=A0
I mean,=A0when designing an=20 elaborate=A0software library, you have to make choices, and often, no matte= r=20 how good=A0OCaml is, some choices will be compromises. You have to pick the= =20 lesser between several evils and live with it.
=A0
I have learned that when programming= Ocaml-Idaho,=20 suddenly module names become longer, module types become more composited, d= ata=20 types become more subtle, and so on and so on...
=A0
Blaming OCaml is a too easy path.
=A0
At=A0one certain=A0point you have to= face=20 the verbosity you have created and decide whether the additionnal=20 expressivity worths the price.
If you think it does then it's o= k, if not then=20 just amend, if amending doesn't help then consider refactoring.<= /div>
Seek the best expressiveness/verbosi= ty ratio=20 without sacrifying too much functionality.
That's your job as a library=20 designer.
=A0
=A0
-=20 damien
=A0
=A0
En r=E9ponse au message=
de=20 : Yaron Minsky
du :=20 2009-10-09=A011:58:11
=C0 : Andrej=20 Bauer
Sujet : Re: [Caml-list]= =20 Improving OCaml's choice of type to display
=A0
Well, if we're picking heuristic= s, the fewest=20 number of characters wouldn't be crazy either.=A0 Given the choice betw= een=20 Int.t and Int.comparable (which are aliases for the same type), I'd pre= fer to=20 see Int.t.

y

On Fri, Oct 9, 2009 at 3:33 AM, Andrej Bauer <andrej.bauer@andrej.com>=20 wrote:
On=20 Fri, Oct 9, 2009 at 3:40 AM, Yaron Minsky <yminsky@gmail.com> wrote:
>=20 Choosing shorter names.

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

Andrej
<= br>

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.in= ria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


--0016362852c05a855c04758368df--