caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Infer least upper bound for arguments to functions in rows
Date: Thu, 31 Mar 2016 12:41:15 +0200	[thread overview]
Message-ID: <20160331104114.GB17174@frosties> (raw)
In-Reply-To: <56FBAA37.5080403@tu-berlin.de>

On Wed, Mar 30, 2016 at 12:28:07PM +0200, Christoph Höger wrote:
> Dear experts,
> 
> is there a way to infer a compatible type for the argument to t#x in the
> function:
> 
> let a t = ignore (t#x t) ; t#x (object end) ;;
> 
> I can easily provide a compatible t, e.g.:
> 
> let t = object method x _ = 23 end
> 
> I can also use a coercion:
> 
> let a t = ignore (t#x (t :> < >)) ; t#x (object end) ;;
> 
> Since < > is the common supertype of both arguments.
> 
> My problem is that in general < > won't suffice for the common type, and
> finding it is a rather complicated process.

I found that this is often a huge problem, esspecially for methods.
You can't always coerce the type and type inference won't infere
polymorphic methods (like t#x above). I've spend hours trying
different ways to not run into "self type may not escape it's class"
or "'a is unbound" errors. In the end I found a quite simple way:

  For each class (type) define a method as_<name> that returns
  (self :> name).

That way you function or method does not take a supertype of some long
winded, complex and possibly recursive class type but a simple
supertype of a class having the as_<name> method and nothing else, e.g.

  method add_widget : 'a . (<as_widget : OWidget.oWidget; ..> as 'a) -> unit

Coming up with the right as_<name> is straight forward and the type
never gets longer than this no matter how complex classes are.

> So I wonder if there is some
> clever rewriting of the function that makes ocamlc infer that type for me?
> 
> Is there any expression that for two (expressions with) different input
> types yields (an expression of) the largest common supertype?
> 
> regards,
> 
> Christoph

I don't think there is any way to get type inference to magically do
the right thing here. The inferecne of polymorphic methods simply
doesn't work that way.

MfG
	Goswin

      reply	other threads:[~2016-03-31 10:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-30 10:28 Christoph Höger
2016-03-31 10:41 ` Goswin von Brederlow [this message]

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=20160331104114.GB17174@frosties \
    --to=goswin-v-b@web.de \
    --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).