From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 680F3BBAF for ; Mon, 1 Feb 2010 17:00:02 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikCABKJZkvZSMDqimdsb2JhbACBM5oTAQEBCgkMBxEFvmGERQQ X-IronPort-AV: E=Sophos;i="4.49,383,1262559600"; d="scan'208";a="55084917" Received: from fmmailgate03.web.de ([217.72.192.234]) by mail4-smtp-sop.national.inria.fr with ESMTP; 01 Feb 2010 17:00:01 +0100 Received: from smtp06.web.de (fmsmtp06.dlan.cinetic.de [172.20.5.172]) by fmmailgate03.web.de (Postfix) with ESMTP id CC02F13CF005D; Mon, 1 Feb 2010 17:00:00 +0100 (CET) Received: from [95.208.117.111] (helo=frosties.localdomain) by smtp06.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #314) id 1Nbygy-0006ho-00; Mon, 01 Feb 2010 17:00:00 +0100 Received: from mrvn by frosties.localdomain with local (Exim 4.71) (envelope-from ) id 1Nbygx-00049t-MD; Mon, 01 Feb 2010 16:59:59 +0100 From: Goswin von Brederlow To: Tiphaine Turpin Cc: Goswin von Brederlow , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Problem correlating input and output type References: <87fx5mi25n.fsf@frosties.localdomain> <4B65D9D4.4030101@irisa.fr> Date: Mon, 01 Feb 2010 16:59:59 +0100 In-Reply-To: <4B65D9D4.4030101@irisa.fr> (Tiphaine Turpin's message of "Sun, 31 Jan 2010 20:28:20 +0100") Message-ID: <87mxzt54lc.fsf@frosties.localdomain> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: goswin-v-b@web.de X-Sender: goswin-v-b@web.de X-Provags-ID: V01U2FsdGVkX1/1Z99P/NgkLMEVv4Z7dlkNb2S/eNNk1UW95bNo Y8ScMxVDrOmMrVb4t3WIFS8rsE7hEjAtAi9IC9GInlBd1c+Bfx kIMn08qS8= X-Spam: no; 0.00; irisa:01 callbacks:01 runtime:01 runtime:01 sig:01 'foo:01 val:01 val:01 foo:01 'foo:01 struct:01 foo:01 bool:01 bool:01 sig:01 Tiphaine Turpin writes: > Goswin von Brederlow a écrit : >> Hi, >> >> last night I had a crazy idea > Definitely :-). > >> [...] >> >> >> Can anyone think of a way to express this so that the type system keeps >> track of which callbacks are already connected? >> > Here is an attempt (with only two "events"). Note that : > - the imperative version cannot prevent connecting a signal more than once > - such types can only represent sets of "parallel" edges of a lattice, > i.e., this doesn't generalises to arbitrary "typestate" properties > - this is just a curiosity, and not a reasonable way of doing such > things. Runtime checking would be much easier (but still a bit hackish). But runtime checks will only show the error when the GUI object is instantiated. Some obscure dialog might not pop up in month. > Tiphaine > > module LatticeFun : sig > > type ('foo, 'bar) r > type t and f > > val make : unit -> (f, f) r > val set_foo : (f, 'bar) r -> (t, 'bar) r > val set_bar : ('foo, f) r -> ('foo, t) r > val use : (t, t) r -> unit > > end = struct > > type ('foo, 'bar) r = {foo : bool ; bar : bool} > > type t > type f = t > > let make () = {foo = false ; bar = false} > let set_foo x = {x with foo = true} > let set_bar x = {x with bar = true} > let use _ = () > > end > > module LatticeImp : sig > > type ('foo, 'bar) r > type t and f > > val make : unit -> (f, f) r > val set_foo : ('foo, 'bar) r -> (t, 'bar) r > val set_bar : ('foo, 'bar) r -> ('foo, t) r > val use : (t, t) r -> unit > > end = struct > > (* for some reason, the direct declaration causes a module type error *) > type r1 = {mutable foo : bool ; mutable bar : bool} > type ('foo, 'bar) r = r1 > > type t > type f = t > > let make () = {foo = false ; bar = false} > let set_foo x = x.foo <- true ; x > let set_bar x = x.bar <- true ; x > let use _ = () > > end Thanks. That solves the first problem. But how do you translate that into ocaml objects? type need_click type have_click class type ['click] clickable_type = object method set_click : ...? method use : ...? end I believe a method can not change the type of a class nor can it require the parametereized class to be of a certain type. And if I write helper function outside the class like let set_foo x = x#foo <- true ; x then I can't use inheritance for them. Maybe I can use inheritance for the class objects and module inclusion for the set_* helpers. But how do I write the use function so that one can not use of an inherited class? Or how do I specify method add_connected_obj : () obj The would need to be specific to the exact type of object being added. I do believe I need something that simplifies the type with each aplication of a callback so that all fully connected objects will have the same basic type, e.g. unit need_click need_drag obj => unit need_click obj => unit obj MfG Goswin