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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id E9C9A7EE5B for ; Mon, 26 May 2014 17:25:41 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of philippe.veber@gmail.com) identity=pra; client-ip=74.125.82.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="philippe.veber@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of philippe.veber@gmail.com designates 74.125.82.171 as permitted sender) identity=mailfrom; client-ip=74.125.82.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="philippe.veber@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-we0-f171.google.com) identity=helo; client-ip=74.125.82.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="postmaster@mail-we0-f171.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8BAK5bg1NKfVKrlGdsb2JhbABZg1lYrDyMWYh8AYEKCBYOAQEBAQcLCwkSKoIlAQEBAwESLgEbEgsBAwELBgULGiEiAREBBQEKEgYlEIgLAQMJCA2jQGqNGYMNmW8KGScDCmSFNhEBBQyOQgQHhEAEhF4FlRCBPY95GCmEajs X-IPAS-Result: Ar8BAK5bg1NKfVKrlGdsb2JhbABZg1lYrDyMWYh8AYEKCBYOAQEBAQcLCwkSKoIlAQEBAwESLgEbEgsBAwELBgULGiEiAREBBQEKEgYlEIgLAQMJCA2jQGqNGYMNmW8KGScDCmSFNhEBBQyOQgQHhEAEhF4FlRCBPY95GCmEajs X-IronPort-AV: E=Sophos;i="4.98,913,1392159600"; d="scan'208";a="76447437" Received: from mail-we0-f171.google.com ([74.125.82.171]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 26 May 2014 17:25:41 +0200 Received: by mail-we0-f171.google.com with SMTP id w62so8287831wes.16 for ; Mon, 26 May 2014 08:25:41 -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=A5tP2CyVFfeK3uDpGKekblN88ZMwE3MMdVubRLQQoZg=; b=HL7csEPRH1ryg0wyG/L7aOm4Hxy/uNGY5Cycogb0i08NlPUFbQKkcCZ4APY4+69G2c ZuDFu0o8pR/hKbBBZX/FOmCI+kSTRSjDH7ho87qbkF8+ma478ZxMrtKCcYKdQyF0baTm ettL6vVxN5CSQHiKhxGk3oaQs899fJWhgi421ZI4GPEu5qMkvky7OtSquhx2ZRh7v1i4 NAMrkQgFyAozUpDLX/FH2hYxMsF1YFUYDlmglP4BRhFw9KNRP5Feaw603yJc4hEauWqr OFEehPUDAhfnfiGJ6OqZ4EgS0nVGiuDbhaob2ClNiC48/UmqKdFACO3qC+TIAnBBI5al r4PQ== X-Received: by 10.194.77.2 with SMTP id o2mr29937012wjw.68.1401117941216; Mon, 26 May 2014 08:25:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.239.100 with HTTP; Mon, 26 May 2014 08:25:21 -0700 (PDT) In-Reply-To: <53835610.9050609@inria.fr> References: <53835610.9050609@inria.fr> From: Philippe Veber Date: Mon, 26 May 2014 17:25:21 +0200 Message-ID: To: Romain Bardou Cc: caml users Content-Type: multipart/alternative; boundary=047d7bfced9c2cbd9904fa4f31d1 X-Validation-by: philippe.veber@gmail.com Subject: Re: [Caml-list] Uncaught exceptions in function type. --047d7bfced9c2cbd9904fa4f31d1 Content-Type: text/plain; charset=ISO-8859-1 Hi Romain! > Some issues: > > - One needs to separate exceptions into two groups, the ones that you > are actually interested in typing (their purpose is to kill the program, > so to speak) and the ones that you are not (they are actually used for > control flow). > I would not like such a separation, unless the user can decide the kind of each exception (did you say burdensome? ;o). This kind of separation is pretty much the reason why there are errors and exceptions in Java, IIRC. > > - I'm not sure it is easy to infer. For instance, in: > > let f g = > g 1 > > should we just assume that g raises nothing? No, we should assume g raises something, and that f raises the same. > Or should we use some kind > of row variable, like: > > let f (g: 'a raise ([< ] as 'raises): 'b raise 'raises = > g 1 > Yes more like that > > But then what about: > > let f > (g: 'a raise ([< ] as 'raises_h) > (h: 'a raise ([< ] as 'raises_g): 'b raise [ 'raises_g | 'raises_h ] = > g 1 + h 2 > > is it sound to have those abstract union types [ 'raises_g | 'raises_h ]? > I guess it is not easy because 'raises_g and 'raises_h may have incompatibilities (same constructors with different arguments). Since you worked on union of abstract polymorphic variant types, I guess you know pretty well how difficult that would be ;o). > > Do we want all functions to have these convoluted types? > Representing those types could be optional most of the time. The only place where they would be important would when catching exceptions, to have the compiler check for exhaustivity. > > -- > Romain Bardou > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --047d7bfced9c2cbd9904fa4f31d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Romain!


Some issues:

- One needs to separate exceptions into two groups, the ones that you
are actually interested in typing (their purpose is to kill the program,
so to speak) and the ones that you are not (they are actually used for
control flow).
I would not like such a separation, unl= ess the user can decide the kind of each exception (did you say burdensome?= ;o). This kind of separation is pretty much the reason why there are error= s and exceptions in Java, IIRC.
=A0

- I'm not sure it is easy to infer. For instance, in:

let f g =3D
=A0 g 1

should we just assume that g raises nothing?
No, we shoul= d assume g raises something, and that f raises the same.
=A0
Or should we use some kind
of row variable, like:

let f (g: 'a raise ([< ] as 'raises): 'b raise 'raises = =3D
=A0 g 1

Yes more like that
=A0

But then what about:

let f
=A0 =A0 (g: 'a raise ([< ] as 'raises_h)
=A0 =A0 (h: 'a raise ([< ] as 'raises_g): 'b raise [ 'ra= ises_g | 'raises_h ] =3D
=A0 g 1 + h 2

is it sound to have those abstract union types [ 'raises_g | 'raise= s_h ]?

I guess it is not easy because 'raises_= g and 'raises_h may have incompatibilities (same constructors with diff= erent arguments). Since you worked on union of abstract polymorphic variant= types, I guess you know pretty well how difficult that would be ;o).
=A0

Do we want all functions to have these convoluted types?
Representing those types could be optional most of the time. The only pl= ace where they would be important would when catching exceptions, to have t= he compiler check for exhaustivity.
=A0

--
Romain Bardou

--
Caml-list mailing list. =A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--047d7bfced9c2cbd9904fa4f31d1--