caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Ivan <ivg@ieee.org>
To: Anthony Tavener <anthony.tavener@gmail.com>
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] passing object to a function fails to compile (lablgtk2 involved)
Date: Tue, 17 Jul 2012 12:32:18 +0400	[thread overview]
Message-ID: <587471342513938@web8h.yandex.ru> (raw)
In-Reply-To: <CAN=ouMSovxwz5UG3RxQBN-Zhg2YQAmj-8YE4uM35KOSZnPc5uA@mail.gmail.com>

Thanks, Anthony!

16.07.2012, 19:29, "Anthony Tavener" <anthony.tavener@gmail.com>:

>  Are your lines calling create_model and fill_model in a different module than where the functions are defined?
>  (or called from the toplevel?) If so, it might be that the types at the module boundary are not constrained enough
>  to be compatible? (apologies if my terminology is incorrect)

Everything happens in the same file/module. It seems to me, just by some insight, that a compiler do not know about columns, stored at the model, so, when he infers his method, they remain polymorphic. I think that some constraint should help, but I'm in doubt how to spell it right. Method set (which I'm suspecting as a cause of a failure) has type, that contains type quantifier: "'a. row:Gtk.tree_iter -> column:'a column -> 'a -> unit". Right now, type quantifiers are out of my ocaml's active vocabulary. In other words I do not know, how to handle them properly. 
Moreover, I still have no insight on the variable 'b. Why do the compiler refers to some 'b, without even mentioning it in the types it inferred? It's very strange for me. 

> If these functions are in a different module than the calls to them, 
> you might need to define the module signature, using a consistent type for a "model". 
> Sometimes two types are not equal, even though they *would* 
> amount to the same underlying representation in a particular scenario. 
> So, check the inferred types of your functions... you might need to add another hint to express what you want.

Yes, It seems that refactoring this functions in a separate modules will bring additional benefits in addition to solving the problem. I'll consider looking in that direction, though the problem of constraining unusual (for me) type still remains.




  reply	other threads:[~2012-07-17  8:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-16  6:49 Ivan
2012-07-16 15:29 ` Anthony Tavener
2012-07-17  8:32   ` Ivan [this message]
2012-07-18 16:53     ` Olivier Andrieu

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=587471342513938@web8h.yandex.ru \
    --to=ivg@ieee.org \
    --cc=anthony.tavener@gmail.com \
    --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).