caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
To: orodeh@cs.huji.ac.il
Cc: caml-list@inria.fr
Subject: Re: Type annotations
Date: Fri, 15 Dec 2000 11:25:23 +0900	[thread overview]
Message-ID: <20001215112523T.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: <Pine.LNX.4.20_heb2.08.0012141610480.1456-100000@zigzag.cs.huji.ac.il>

> > There has been already various proposals for allowing types to be taken
> > into account when typing record labels. The difficulty is that as soon
> > as you make it into something useful, you loose the principal type
> > property, and that some theoreticians working on ocaml wouldn't like
> > it.
> 
> The loss of the pricipal type theorem has also recently been discussed in
> comp.lang.ml and comp.lang.functional. Using type-annotation by the
> compiler prior (call this the PRIOR approach) to unification can help
> typing expression that cannot be typed otherwise. For example, cases of
> polymoriphic recursion. In fact, this is the way this is handled in
> Haskell (this topic has also appeared in this list previously). 
> Although I wouldn't go running to implement all my code in Haskell :-), I
> do think that using PRIOR could be an improvement. 
> 
> Is there a problem with PRIOR? 

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.

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>



  reply	other threads:[~2000-12-15 12:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-14 14:12 Ohad Rodeh
2000-12-15  2:25 ` Jacques Garrigue [this message]
2000-12-21 12:50 ` Ref syntax Ohad Rodeh
2000-12-22  3:29   ` Jacques Garrigue
2000-12-22  8:45     ` Sven LUTHER
2000-12-23  0:30       ` John Prevost
2000-12-22  9:07     ` Pierre Weis
2000-12-22  9:30       ` Jacques Garrigue
2000-12-22 14:22         ` Pierre Weis
2000-12-22 19:24       ` Marcin 'Qrczak' Kowalczyk
2000-12-22  9:17     ` Pascal Brisset
2000-12-23  0:37       ` John Prevost
2000-12-22 16:40   ` Marcin 'Qrczak' Kowalczyk
2000-12-23  0:39     ` John Prevost
2000-12-25 21:58       ` Pierre Weis
2000-12-18  8:30 Type annotations Ohad Rodeh

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=20001215112523T.garrigue@kurims.kyoto-u.ac.jp \
    --to=garrigue@kurims.kyoto-u.ac.jp \
    --cc=caml-list@inria.fr \
    --cc=orodeh@cs.huji.ac.il \
    /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).