From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 8F87F7ED34 for ; Tue, 17 Jul 2012 10:33:52 +0200 (CEST) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of ivg@ieee.org) identity=pra; client-ip=84.201.186.23; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="lisp-hacker@yandex.ru"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of lisp-hacker@yandex.ru designates 84.201.186.23 as permitted sender) identity=mailfrom; client-ip=84.201.186.23; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="lisp-hacker@yandex.ru"; x-sender="lisp-hacker@yandex.ru"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@forward5h.mail.yandex.net) identity=helo; client-ip=84.201.186.23; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="lisp-hacker@yandex.ru"; x-sender="postmaster@forward5h.mail.yandex.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoCAKwiBVBUyboXlGdsb2JhbAA/BoVqhB+vWCIBAQEBBwsLCRIpgiABAQQBBBwHCwFGBQsLRiE2BhECh34DBgqpTAaJNw2JToEeiTtlJoUNgRQDiEWFIodUiwSHZjk X-IronPort-AV: E=Sophos;i="4.77,599,1336341600"; d="scan'208";a="167121871" Received: from forward5h.mail.yandex.net ([84.201.186.23]) by mail1-smtp-roc.national.inria.fr with ESMTP; 17 Jul 2012 10:33:15 +0200 Received: from web8h.yandex.ru (web8h.yandex.ru [84.201.186.37]) by forward5h.mail.yandex.net (Yandex) with ESMTP id 944DBD02AA1; Tue, 17 Jul 2012 12:32:19 +0400 (MSK) Received: from 127.0.0.1 (localhost.localdomain [127.0.0.1]) by web8h.yandex.ru (Yandex) with ESMTP id 3A03B1AD8725; Tue, 17 Jul 2012 12:32:19 +0400 (MSK) Received: from wimax-client.yota.ru (wimax-client.yota.ru [178.176.135.209]) by web8h.yandex.ru with HTTP; Tue, 17 Jul 2012 12:32:18 +0400 From: Ivan Envelope-From: lisp-hacker@yandex.ru To: Anthony Tavener Cc: "caml-list@inria.fr" In-Reply-To: References: <678391342421391@web21g.yandex.ru> MIME-Version: 1.0 Message-Id: <587471342513938@web8h.yandex.ru> Date: Tue, 17 Jul 2012 12:32:18 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Subject: Re: [Caml-list] passing object to a function fails to compile (lablgtk2 involved) Thanks, Anthony! 16.07.2012, 19:29, "Anthony Tavener" : > š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.