caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: caml-list@inria.fr
Subject: unification of alternatives
Date: Mon, 13 Mar 2006 19:47:00 +1100	[thread overview]
Message-ID: <1142239620.8419.314.camel@budgie.wigram> (raw)

I have an interesting problem with unification algorithm.
The problem is basically that given two terms,
either that unify, they don't unify, or *NEW* they don't
unify yet but might later.

Does anyone know how to modify the algorithm to account
for this?

It's hard for me to give a formal description, so I'll
illustrate with an example. I have a term

	typematch t with
	| t1 => t1'
	| t2 => t2'
	..
	endmatch

The reduction rule for this term is:

(a) if t is t1, return t1'
(b) if t cannot unify with t1, return

	reduce (typematch t with | t2 => t2' .. endmatch)

In other words throw out the first branch and try again.

(c) Otherwise return the whole term.
 
The indeterminism arises whenever there are type variables
present which may be replaced later on. Since we don't
know what substitutions will occur yet, we have no choice
but to delay reduction. Whilst this is probably not as
general as one may like it is actually very useful:


typedef fast_sints = typesetof (tiny, short, int, long, vlong);
...

// C integer promotion rule
typedef fun integral_promotion: TYPE -> TYPE =
  | tiny => int
  | utiny => int
  | short => int
  ...

typedef fun arithmax(l: TYPE, r: TYPE): TYPE =>
  typematch integral_promotion l, integral_promotion r with
  | vlong,vlong => vlong 
  ...

  fun add[t1:fast_ints, t2:fast_ints]: t1 * t2 -> arithmax(t1,t1)="$1
+$2";

The last rule here allows mixed mode arithmetic in Felix
to model the usual C rules .. without allowing any implicit
conversions. The typesetof operator converts a type tuple
into a set of types. The notation:

	t1:fast_ints

is constrained genericity. Basically, the overload resolution
algorithm uses unification to find the type variables,
then then constraints are checked. Unfortunately that
isn't good enough. Consider this case:

fun g[t,u:ptr[t]]: u -> t = "*$1";
var x = 1;
var px:ptr[int] = addr x;
print$ g[int] px; endl;

This actually works, but this one does not:

print$ g px; endl;

because it isn't possible to deduce t from the argument.
I have modified the algorithm so  that this now does work,
by adding the type constraint into the set of equations
to be unified.

Ok -- sorry it took so long -- so here is the problem.
The above works fine with 'regular types'. But if the
constraint is a typeset, it doesn't work.

The obvious way to make it work is to consider each
member of the typeset in turn.. however that just
isn't tractable (combinatorial explosion).

However the regular solution WILL work in many cases
if we simply delay reduction of any typesets, in particular,
just leave any typeset constraints out of the unification
step, and just check the constraint afterwards (as before).

Of course this is a real hack, since the rule isn't recursive.
The 'proper' way to do it is to throw everything at a modified
unification algorithm. The problem is to stop the algorithm
aborting prematurely with a failure. In particular in the
original example:

fun add[t1:fast_ints, t2:fast_ints]: t1 * t2

we don't want the algorithm to fail unification, when in
fact it works just fine *without* the constraints being
thrown in.

-- 
John Skaller <skaller at users dot sourceforge dot net>
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net


             reply	other threads:[~2006-03-13  8:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-13  8:47 skaller [this message]
2006-03-13 10:19 ` Stefan Monnier

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=1142239620.8419.314.camel@budgie.wigram \
    --to=skaller@users.sourceforge.net \
    --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;
as well as URLs for NNTP newsgroup(s).