From: Swaroop Sridhar <swaroop@cs.jhu.edu>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>,
caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Recursive types
Date: Wed, 16 Nov 2005 18:00:16 -0500 [thread overview]
Message-ID: <437BBA00.3090505@cs.jhu.edu> (raw)
In-Reply-To: <20051116.173802.68165704.garrigue@math.nagoya-u.ac.jp>
Jacques Garrigue wrote:
> There is a problem with your algorithm ...
> The approach in ocaml is simpler: link at each type node, so that
> already unified types will look equal.
Let me have another take at the algorithm :
Unify (first:TYPE, second: TYPE)
will return true on Unification false if not.
1. Start
2. let t1 = repr first
let t2 = repr second
3. match (t1.kind, t2.kind) with
case (Integer, Integer) ->
return true
case (Tvar, _ ) ->
t1.link = Some t2
return true
case (_, Tvar) ->
t2.link = Some t1
return true
case (Record, Record) ->
if the record lengths don't match
return false
t1.link = t2 (***** linked speculatively *****)
for each i in 0 to t1.components.size()
Unify (t1.components[i], t2.components[i])
if Unification fails,
t1.link = None
unlink all types that were linked until now
return false
endif
for each i in 0 to t1.typeArgs.size()
Unify (t1.typeArgs[i], t2.typeArgs[i])
if Unification fails,
unlink all types that were linked until now
return false
endif
return true
case (_, _) ->
return false
4. Stop
Is this correct/ similar to what Ocaml does?
> Note in this case: the definition of llist is nominal, so this type is
> only iso-recursive, which is much easier to handle.
We might have syntactic restrictions (ex: one of ML's restriction that
recursion can occur only across variant constructor boundaries, etc) so
that arbitrary recursion is disallowed. However, from an implementation
standpoint, I *think* that the above implementation of the unifier is
easier to do even in the case of iso-recursive types. Is this true?
I thought of introducing explicit fold/unfold operations into the
algorithm, but it seemed to do more work. If I am wrong, can you please
suggest modifications to the above algorithm that works (better) only
for iso-recursive types.
Thanks,
Swaroop.
next prev parent reply other threads:[~2005-11-16 23:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20050506044107.1698.70519.Mailman@yquem.inria.fr>
2005-11-15 22:44 ` Swaroop Sridhar
2005-11-15 23:40 ` [Caml-list] " Jacques Garrigue
2005-11-16 2:20 ` Keiko Nakata
2005-11-16 6:47 ` Alain Frisch
2005-11-16 7:40 ` Keiko Nakata
2005-11-16 8:55 ` Jacques Garrigue
2005-11-17 1:45 ` Keiko Nakata
2005-11-16 3:28 ` Swaroop Sridhar
2005-11-16 8:38 ` Jacques Garrigue
2005-11-16 23:00 ` Swaroop Sridhar [this message]
2005-11-16 23:56 ` Swaroop Sridhar
2008-03-24 3:16 recursive types Jacques Le Normand
2008-03-24 3:51 ` [Caml-list] " Erik de Castro Lopo
2008-03-24 3:51 ` Erik de Castro Lopo
2008-03-24 8:37 ` Jeremy Yallop
-- strict thread matches above, loose matches on Subject: below --
2004-12-13 9:44 nakata keiko
2004-12-13 9:58 ` [Caml-list] " Damien Pous
2004-12-13 12:31 ` skaller
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=437BBA00.3090505@cs.jhu.edu \
--to=swaroop@cs.jhu.edu \
--cc=caml-list@yquem.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