caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Aaron Bohannon <bohannon@cis.upenn.edu>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] annotations and type-checking
Date: Wed, 29 Jul 2009 12:50:24 -0400	[thread overview]
Message-ID: <c413fcb70907290950w1aa7ac96ue1b0547dcccc6778@mail.gmail.com> (raw)
In-Reply-To: <20090729.233928.59476910.garrigue@math.nagoya-u.ac.jp>

Yes, I was completely wrong.  Type variables do prevent me from writing

let f (x : 'a -> 'a) : 'a = x;;

and

let f (x : 'a) (y : 'a) : int = 3 in f true "true";;

So they are certainly not meaningless.  But I use annotations
primarily to get better, more accurately located error messages from
the type-checker, and apparently annotating functions that are
(intended to be) polymorphic is never useful for this purpose.  And it
boggles my mind that annotations with type variables *prevent*
generalization.

But at least by now, I guess anyone following this discussion should
know whether this program type-checks... ;)

let f (x : 'a -> unit) : unit = () in
f print_string;
let g (y : 'a -> unit) : unit = () in
g print_float ;;

 - Aaron

On Wed, Jul 29, 2009 at 10:39 AM, Jacques
Garrigue<garrigue@math.nagoya-u.ac.jp> wrote:
> From: Aaron Bohannon <bohannon@cis.upenn.edu>
>> Thank you for that link.  To boil it down, it seems (1) type variables
>> annotating top-level declarations are ignored, and (2) type variables
>> annotating local bindings are treated existentially (as if one had
>> written '_a, although that name itself is considered syntactically
>> ill-formed).
>
> Point (1) is wrong. They are not ignored, they act as constraints.
> Actually, their behaviour is uniform: they are always bound and
> generalized at toplevel. This is true both for normal functions an
> classes. The only exception is with modules, but it is not surprising
> as modules work on a different level.
>
> I can see only one really buggy behaviour in Alain's mail, the fact
> that local modules did flush type variables. Fortunately, this has
> been corrected.
>
>> So if OCaml cannot do anything better than this, then why are type
>> variables even syntactically legal in annotations?  If backwards
>> compatibility is the issue, could it not at the very very least give a
>> compiler warning when they are used?
>
> Because it is useful to be able to have type annotations sharing type
> variables in different places in a term (for instance for different
> arguments).
>
> Jacques Garrigue
>
>> On Wed, Jul 29, 2009 at 3:40 AM, Mark
>> Shinwell<mshinwell@janestcapital.com> wrote:
>>> On Tue, Jul 28, 2009 at 05:47:25PM -0400, Aaron Bohannon wrote:
>>>> Why do the first two programs type-check but the thrid one does not?
>>>
>>> Dark corners of the type system.
>>>
>>>> let f (x : 'a) : 'a = x in (f true, f 3);;
>>>
>>> Explicit type variables in this situation are considered "global".  They are
>>> not generalized until the type of the whole toplevel declaration has been
>>> determined.  Consequentially, during type-checking of the body of your
>>> let expression, 'a is not a generalized variable.
>>>
>>> There is more detail on similar situations here:
>>>
>>> http://caml.inria.fr/pub/ml-archives/caml-list/2002/06/a03da53be62c12671a891708c51e85f9.en.html
>>>
>>> Mark
>


  reply	other threads:[~2009-07-29 16:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-28 21:47 Aaron Bohannon
2009-07-28 23:28 ` [Caml-list] " Jon Harrop
2009-07-28 23:04   ` Philippe
2009-07-29  5:38     ` Johannes Kanig
2009-07-29  7:40 ` Mark Shinwell
2009-07-29 13:41   ` Aaron Bohannon
2009-07-29 14:39     ` Jacques Garrigue
2009-07-29 16:50       ` Aaron Bohannon [this message]
2009-07-29 19:01       ` Jon Harrop

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=c413fcb70907290950w1aa7ac96ue1b0547dcccc6778@mail.gmail.com \
    --to=bohannon@cis.upenn.edu \
    --cc=caml-list@inria.fr \
    --cc=garrigue@math.nagoya-u.ac.jp \
    /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).