caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Pierre Weis <Pierre.Weis@inria.fr>
To: helsen@informatik.uni-tuebingen.de (Simon Helsen)
Cc: caml-list@inria.fr
Subject: Re: polymorphic recursion
Date: Tue, 22 Sep 1998 17:06:41 +0200 (MET DST)	[thread overview]
Message-ID: <199809221506.RAA17926@pauillac.inria.fr> (raw)
In-Reply-To: <Pine.A32.3.96.980922113949.2728U-100000@modas> from "Simon Helsen" at Sep 22, 98 12:00:11 pm

> This might be the case for OCaml, but note that SML97 disallows more
> general type-constraints than the type apparent in the expression without
> the constraint (cf. rule (9) and comment in the 97 Definition - p22) 

That's a good point. It's simple to state and understand.

> This makes sense in the filosophy that type constraints are only supposed
> to be programmer documentation or to help the type-inference engine to
> detect type-errors "earlier" (the latter is practical while debugging
> type-errors).

Yes, but furthermore it can be used to help the typechecker to find
types more general than it will normally find.

> Unfortunately, SML is not very consistent on this matter as well, since it
> might require type annotations to succeed its type inference (e.g. at
> top-level monomorphism and the resolution of variable record patterns) A
> SML type-constraint cannot be more general, but is allowed to be more
> specific. e.g:
> 
> - val (f : 'a -> 'a -> 'a) = fn x => fn y => y;
> val f = fn : 'a -> 'a -> 'a

This is necessary to ``constrain'' the types of programs, when you
want to obtain a type more specific than the one synthetized by
the typechecker, in order to get more precise typing
verifications. This is also useful to get rid of spurious type
unknowns at modules boundaries, since you cannot let them escape from
the module.

> And if SML "would" follow this filosophy properly, there is no room for
> polymorphic recursion in general since, as you indicate, type-inference
> for this is undecidable. 

Yes polymorphic recursion type-inference is undecidable.
No, ``exact'' type constraints do not preclude polymorphic recursion.

Starting with the ``exact'' type annotation as hypothesis, it is easy
to verify that the polymorphic recursion is sound. This is simple and
easy. The only drawback is that you have to find the type yourself,
and that you may indicate a too specific type.

> I don't know why Caml allows more general type constraints, but it might
> be a good idea to follow SML on this matter (and I am interested to know
> if there are good reasons for not doing this)

If we use it to get polymorphic recursion, there is a good reason to
do this.

Another problem is the scope of type variables in type
constraints. What's the meaning of

let f (x : 'a) (y : 'a) = y;;

We may need explicit Forall keywords to express type schemes in constraints.

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/







  reply	other threads:[~1998-09-22 15:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-09-21 16:30 Peter J Thiemann
1998-09-22  2:33 ` Jacques GARRIGUE
1998-09-22  9:22   ` Pierre Weis
1998-09-22 10:00     ` Simon Helsen
1998-09-22 15:06       ` Pierre Weis [this message]
1998-09-22 15:28         ` Simon Helsen
1998-09-22 16:33           ` Pierre Weis
1998-09-22 15:50         ` Pierre CREGUT - FT.BD/CNET/DTL/MSV
1998-09-22 17:14           ` Xavier Leroy
1998-09-28  9:51             ` Pierre Weis
1998-09-28 11:45               ` Peter Thiemann
1998-09-28 13:00                 ` Pierre Weis
1998-10-05 14:27               ` Local definitions Anton Moscal
1998-10-12 11:39                 ` Xavier Leroy
1998-10-12 17:20                   ` Adam P. Jenkins
1998-10-14 13:47                   ` Anton Moscal
1999-08-22 20:35 Polymorphic recursion Hongwei Xi
1999-08-23 12:19 ` Pierre Weis
2007-04-03 16:59 Loup Vaillant
2007-04-04 13:49 ` [Caml-list] " Roland Zumkeller
2007-04-04 15:13   ` Alain Frisch
2007-04-04 15:50     ` Stefan Monnier
2008-05-12 21:55 polymorphic recursion Jacques Le Normand

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=199809221506.RAA17926@pauillac.inria.fr \
    --to=pierre.weis@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=helsen@informatik.uni-tuebingen.de \
    /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).