From: Jacques GARRIGUE <garrigue@kurims.kyoto-u.ac.jp>
To: Francois.Pottier@inria.fr
Cc: caml-list@inria.fr
Subject: Re: Weird behavior with mutually recursive type definitions
Date: Mon, 16 Aug 1999 16:08:01 +0900 [thread overview]
Message-ID: <19990816160801Q.garrigue@kurims.kyoto-u.ac.jp> (raw)
In-Reply-To: Your message of "Mon, 16 Aug 1999 08:31:58 +0200" <19990816083158.52649@pauillac.inria.fr>
From: Francois Pottier <Francois.Pottier@inria.fr>
> > Why is it so? Constraints are required for the object system, and if
> > there are constraints you must expand abbreviations inside definitions
> > to check them. If recursion occurs before the abbreviation is
> > generalized, this means that all occurences of an abbreviation in the
> > same type definition will be unified, and have the same constraints.
>
> I fail to see why type abbreviations should be monomorphic while
> their declaration is being checked. Is this intended to make the
> type system safe, or to guarantee the typechecker's termination?
My explanation probably lacked clarity.
Since abbreviations may contain constraints, one must expand them when
defining types depending on them (to check that the constraints are
satisfied).
If the abbreviation has been defined earlier, no problem, you just
extract its constraints.
But if it is yet to be defined (which is the case with mutually
recursive definitions), you must keep everything monomorphic so that
constraints can be enforced later.
What we want is just to enforce constraints from the abbreviation to
other type definitions, but as a result this means also introducing
constraints the other way round (classical problem with unification).
My comment was that such a restrictive algorithm is needed if we want
to collect all constraints in one pass, but if we require that all
abbreviation definitions contain explicitely all their constraints,
the above problem can be avoided with a two-pass algorithm.
> By the way, I find O'Caml's error messages on this topic rather
> strange.
Error messages with unification are hard.
You can see here another funny behaviour with recursive definitions:
# type t = u and u = unit;;
type t = unit
type u = t
Jacques
---------------------------------------------------------------------------
Jacques Garrigue Kyoto University garrigue at kurims.kyoto-u.ac.jp
<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
next prev parent reply other threads:[~1999-08-22 19:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-08-04 13:52 Francois Pottier
1999-08-12 13:17 ` Hendrik Tews
1999-08-13 1:42 ` Jacques GARRIGUE
1999-08-16 6:31 ` Francois Pottier
1999-08-16 7:08 ` Jacques GARRIGUE [this message]
1999-08-16 7:51 ` More confusion " Francois Pottier
1999-08-16 7:57 ` Jacques GARRIGUE
1999-08-27 11:32 ` Weird behavior " Jerome Vouillon
1999-08-27 10:12 ` Jerome Vouillon
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=19990816160801Q.garrigue@kurims.kyoto-u.ac.jp \
--to=garrigue@kurims.kyoto-u.ac.jp \
--cc=Francois.Pottier@inria.fr \
--cc=caml-list@inria.fr \
/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