caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Ohad Rodeh <orodeh@cs.huji.ac.il>
To: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
Cc: Caml List <caml-list@inria.fr>
Subject: Type annotations.
Date: Mon, 18 Dec 2000 10:30:17 +0200 (IST)	[thread overview]
Message-ID: <Pine.LNX.4.20_heb2.08.0012181025210.19337-100000@zigzag.cs.huji.ac.il> (raw)

Jacques,
  I'd love to see this added to the distribution, even if only 
as an optional compile time flag. Allowing polymorphic recursion, and
mitigating the record naming problem are worthy goals, 

   Ohad.

> There are a few things that work well with this approach, polymorphic
> recursion being one. But it is not as general as it seems.
> A simple scheme is to assume that you can give explicitely a type to
> an identifier, use this type to resolve ambiguities, and check
> afterwards that this type is correct.
> With such a scheme,
>      let w : t = {x=1;y=2} in w.x
> will indeed be correctly handled.
> However, this breaks as soon as an annotation is lacking:
>      let w : t = {x=1;y=2} in
>      let v = w in
>      w.x
> Similarly, pairs won't work
>      let w : t * int = ({x=1;y=2}, 3) in (fst w).x
> Indeed, while w was given a special "assumed" type, propagating such
> assumed types through definitions and function calls is much more
> subtle.
> In a paper by Didier Remy and myself [1], we designed a system that
> could do a fair amount of "assumed" type propagation. This was
> intended for providing first class polymorphism and polymorphic
> methods, and was implemented in Objective Label. This could also be
> used for typing records, while some might see it as an overkill.
> But this is much more complex than what you are calling PRIOR.
> And this is not principal in the strict meaning (due to a mischevious
> side-effect of the value only prolymorphism rule).
> 
> I am currently working on reintegrating this feature in ocaml. However
> it is not yet clear whether it can be made cheap enough to make it
> into the main stream version (type inference becomes slower).
> And then some might discuss the fact it would require people to learn
> yet another set of rules about how assumed types are propagated.
> 
> Cheers,
> 
> Jacques
> 
> [1] Extending ML with semi-explicit higher order polymorphism,
>     Information and Computation 155, december 1999, pages 134-171.




             reply	other threads:[~2000-12-18 14:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-18  8:30 Ohad Rodeh [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-12-14 14:12 Ohad Rodeh
2000-12-15  2:25 ` Jacques Garrigue

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=Pine.LNX.4.20_heb2.08.0012181025210.19337-100000@zigzag.cs.huji.ac.il \
    --to=orodeh@cs.huji.ac.il \
    --cc=caml-list@inria.fr \
    --cc=garrigue@kurims.kyoto-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).