From mboxrd@z Thu Jan 1 00:00:00 1970 X-Sympa-To: caml-list@inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q3CEGal5007388 for ; Thu, 12 Apr 2012 16:16:36 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQBAJzihk/RVdQ2kGdsb2JhbABDuWsIIgEBAQEJCQ0HFAQjggkBAQEDARICLAEbHQEDDAYFBAcHNCIBEQEFAQ4OBjWHXQEDBgWgJwqMIIJyhRwKGScNV4EOAQULkXMElWyOVj2EDA X-IronPort-AV: E=Sophos;i="4.75,410,1330902000"; d="scan'208";a="139991580" Received: from mail-vb0-f54.google.com ([209.85.212.54]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 12 Apr 2012 16:16:30 +0200 Received: by vbmv11 with SMTP id v11so2685157vbm.27 for ; Thu, 12 Apr 2012 07:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TJZLkBQBB76GDHsDy3ca/BHLwNVBQJZOvNVGPym6aZI=; b=I4hP3+JzKsX+SNFjy4zIpjDWBdWVzsULgmaOFHAsO0k7zJjGqww729C5bI2dEa79Wg TGDq6h7AJRqo+YuFV8Ag84ipQXYn37w52hKdPGnIonYPmx22pb1BIA2WEcC2sduM5J8M Nnq6ePBC4CWe8k9rXoGQWrxwEMljZafZEa6NpKQzKq0CY/8D3m0q+lT6MIs+Gl2NaTdV +sC98aiKj4VeSLafO75Sxqvb+6M1IhZEQn9sEAV8iaXdgmwhQIih0MiKZLdp8WYlHWUc gxi4WRNLazNy1y2wmvyhVT1VEvCQqXSdlCtM8v67JfUkL1zb8y2ohfgcCfB7he85vfUY uVxQ== Received: by 10.52.178.129 with SMTP id cy1mr1104381vdc.8.1334240189704; Thu, 12 Apr 2012 07:16:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.31.136 with HTTP; Thu, 12 Apr 2012 07:16:09 -0700 (PDT) In-Reply-To: <4F86E0C0.8020003@frisch.fr> References: <4F86E0C0.8020003@frisch.fr> From: Philippe Veber Date: Thu, 12 Apr 2012 16:16:09 +0200 Message-ID: To: Alain Frisch Cc: Gabriel Scherer , Leo P White , caml Content-Type: multipart/alternative; boundary=bcaec5196a598d6b8c04bd7c00af X-Validation-by: philippe.veber@gmail.com Subject: Re: [Caml-list] [ANN] ocamlopen 1.0.2 --bcaec5196a598d6b8c04bd7c00af Content-Type: text/plain; charset=ISO-8859-1 > > 4. When would you say that one should use polymorphic variants rather >> than your open datatypes? (I know how to argue in the other direction: >> unique constructors make for better error messages.) >> > > I've wanted such open datatypes several times. One example is a message > bus across an application: some components can yield messages to be > dispatched to all registered components. Messages can hold data, and the > set of possible messages (with the type of their associated data) is > extensible (say, because components can be loaded dynamically, or just to > make the application's architecture more modular). It makes sense to use > an extensible datatype to represent messages. Components can react to > messages with pattern-matching and two components can interact if their > share a common constructor definition. This is simpler than encoding open > datatypes with a "universal" type (with injections/projections). Of > course, one can use the existing "exn" type, but then we don't distinguish > between exceptions and messages at all. > Isn't this a good use case for polymorphic variants too ? Compared to open datatypes, you could suffer from the weaker type checks though: if two components are supposed to communicate through a constructor, which is mispelled in one of the component, the error would not be noticed by the compiler. my own 2 cent ... philippe. --bcaec5196a598d6b8c04bd7c00af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

4. When would you say that one should use polymorphic variants rather
than your open datatypes? (I know how to argue in the other direction:
unique constructors make for better error messages.)

I've wanted such open datatypes several times. =A0One example is a mess= age bus across an application: some components can yield messages to be dis= patched to all registered components. =A0Messages can hold data, and the se= t of possible messages (with the type of their associated data) is extensib= le (say, because components can be loaded dynamically, or just to make the = application's architecture more modular). =A0It makes sense to use an e= xtensible datatype to represent messages. =A0Components can react to messag= es with pattern-matching and two components can interact if their share a c= ommon constructor definition. =A0This is simpler than encoding open datatyp= es with a "universal" type (with injections/projections). =A0Of c= ourse, one can use the existing "exn" type, but then we don't= distinguish between exceptions and messages at all.=

Isn't this a good use case for pol= ymorphic variants too ? Compared to open datatypes, you could suffer from t= he weaker type checks though: if two components are supposed to communicate= through a constructor, which is mispelled in one of the component, the err= or would not be noticed by the compiler.

my own 2 cent ...
philippe.

--bcaec5196a598d6b8c04bd7c00af--