From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 67C19BBAF for ; Tue, 23 Mar 2010 20:46:18 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoCAGS3qEtIDtyakGdsb2JhbACRBoITh34IFQEBAQEJCQwHEwMfrnGBY4VZLohLAQEDBYJJgi8Ejk8 X-IronPort-AV: E=Sophos;i="4.51,296,1267398000"; d="scan'208";a="47666276" Received: from fg-out-1718.google.com ([72.14.220.154]) by mail2-smtp-roc.national.inria.fr with ESMTP; 23 Mar 2010 20:46:18 +0100 Received: by fg-out-1718.google.com with SMTP id d23so1016362fga.9 for ; Tue, 23 Mar 2010 12:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=oNmAh26DyOk84NIDr0M+o7mFnQ1IzQ+Kf18jWnpkniE=; b=nIpQZHPIlKh2oNL0qJLizB8LBulD18uFMysBw2+MIv+WWdLLZ9C/9zQC/3FMLcGnlG YkmBuDarDzJe8bwyZ7axMQ7+vHyo2yyXbqce+B2rCVKXI31XxhIDsWYUr5RZnzoaDGAb 36nVthNKVo0pNlUiuiKSawJgR1AUeVtgKIo4Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=TnXiA15bNL7pPNQdsoXd6TJlJuP0jI20zx3Sn5LbKAzQbsZTpnRTWOUPbqmI4MsdGB Frs7VNrW5GTDPzTtmQda66LnmwyNp1KMiSI7nHjW4pT7fkcem7Fa6z1KH+KVyC7oxME2 h2UZzHoGuga+wTxHASsAWj3nl1BIY2NPb+L64= Received: by 10.87.68.36 with SMTP id v36mr8086683fgk.43.1269373577601; Tue, 23 Mar 2010 12:46:17 -0700 (PDT) Received: from [192.168.2.6] (77-57-172-115.dclient.hispeed.ch [77.57.172.115]) by mx.google.com with ESMTPS id g28sm8164997fkg.28.2010.03.23.12.46.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Mar 2010 12:46:17 -0700 (PDT) Subject: Re: [Caml-list] Functions over polymorphic variants Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Kaspar Rohrer In-Reply-To: <20100323.151140.125875815.garrigue@math.nagoya-u.ac.jp> Date: Tue, 23 Mar 2010 20:46:15 +0100 Cc: caml-list@inria.fr Content-Transfer-Encoding: quoted-printable Message-Id: <50CAC2F1-D72F-49A1-B314-181B4C934437@gmail.com> References: <20100323.151140.125875815.garrigue@math.nagoya-u.ac.jp> To: Jacques Garrigue X-Mailer: Apple Mail (2.1077) X-Spam: no; 0.00; variants:01 variants:01 ocaml:01 ocaml:01 linebreak:01 foreground:01 inverted:01 bool:01 linebreak:01 foreground:01 inverted:01 bool:01 mismatch:01 trivial:01 combinators:01 Thank you for your concise answer. Am I correct when I say you are the = author of the polymorphic variants and labels extension to OCaml? As I stated earlier, I'm working somewhat heavily with PVs at the = moment. One thing that bothers me is the error message for PV type = mismatches. As the PV types contain more than just a few tags, it becomes harder to = identify the missing/different tags. To come to the point: How hard would it be to patch the OCaml sources so = that PV type mismatches would identify the offending tags? To illustrate: Type declarations do not match: type input =3D [ `break | `fragment of string | `linebreak | `newline | `nop | `set_background of color | `set_context of context | `set_foreground of color | `set_intensity of intensity | `set_inverted of bool | `set_justification of justification | `set_underline of underline | `set_width of int | `space of int ] is not included in type input =3D [ `break | `fragment of string | `linebreak | `newline | `nop | `set_background of color | `set_context of context | `set_foreground of color | `set_intensity of intensity | `set_inverted of bool | `set_underline of underline | `space of int ] Maybe the common tags could be omitted in a final digest: Type mismatch: type input =3D [ ... | `set_justification of justification | `set_width of int ] is not included in type input =3D [ ... ] I guess open and closed PV types would complicate things a bit, but this = should be possible, right? Thank you ---- Kaspar Rohrer kaspar.rohrer@gmail.com On Mar 23, 2010, at 7:11 AM, Jacques Garrigue wrote: > From: Kaspar Rohrer >> I am tinkering with streams of polymorphic variants at the >> moment. One thing that I would like to do is to write a stream >> transformer (not sure this is the correct terminology) that simply >> drops certain values of an open polymorphic type, and have the type >> of the function reflect this. >=20 > Sorry, you can't. > This is a design choice with ocaml polymorphic variants, that the row > variable is kept hidden. This has the advantage of simplicity, but it > makes impossible to abstract on the row variable itself, like you want > here. >=20 >> This is trivial with a closed polymorphic type: >>=20 >> type abc =3D [`a | `b | `c] >>=20 >> let transform (stream : [< `x | abc] Stream.t) : [> abc] Stream.t =3D >> let rec fold () =3D >> match Stream.next stream with >> | `x -> Stream.slazy fold >> | #abc as x -> Stream.icons x (Stream.slazy fold) >> with >> Stream.Failure -> Stream.sempty >> in >> fold () >>=20 >> However, I fail to see how the same function could be implemented so = it accepts an open polymorphic type as it's input. >> I.e. is there a way to express something like this (which is not = valid OCaml) >>=20 >> let transform : [> `x | 'a] Stream.t -> [> 'a] Stream.t >>=20 >> Does this even make sense? >=20 > This makes sense, but would require a different type system. > With ocaml, you must keep to closed types. > This should be sufficient for concrete examples, but you cannot build > polymorphic combinators. >=20 > Note. In designing a type system where you would be able to express > such "differential" types, poinder the problem: what is the type of > transform composed with itself. >=20 > Jacques Garrigue