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 5620A80211 for ; Fri, 20 Oct 2017 13:21:06 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=ivg@ieee.org; spf=Pass smtp.mailfrom=ivg@ieee.org; spf=None smtp.helo=postmaster@mail-yw0-f171.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of ivg@ieee.org) identity=pra; client-ip=209.85.161.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of ivg@ieee.org designates 209.85.161.171 as permitted sender) identity=mailfrom; client-ip=209.85.161.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; 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-yw0-f171.google.com) identity=helo; client-ip=209.85.161.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="postmaster@mail-yw0-f171.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3A3qx0GRYQWLK+lobLy9pPR6L/LSx+4OfEezUN459i?= =?us-ascii?q?sYplN5qZpc25bnLW6fgltlLVR4KTs6sC0LWG9f24EUU7or+/81k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i76xXcoFx7+LQt4?= =?us-ascii?q?IPjuUs6X1pzvlrOEwIDIewhDmBa6ZLpzKl328VSQ5YEqht5OI7gwxlPgpn9TfP?= =?us-ascii?q?xOjTdkP1vWmRvj/e+18YJq6DhZsPFn/MlFB/bUZaM9GJ1GBTJuHGcp49PgtRjf?= =?us-ascii?q?VkPb52UTemQbnxcOBBLKukKpFqztuzf347IukBKROtf7GPVpADk=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AADt2ulZh6uhVdFcHAEBBAEBCgEBF?= =?us-ascii?q?QEBAQECAQEBAQgBAQEBhBhuJweDc4E2mCiBeoJRk3SBIgNcChgBCoQDAYEUAoQ?= =?us-ascii?q?xB0MUAQEBAQEBAQEBAQESAQEBCA0JCCgvgjgFAR4GgjsBAQEDAQEiBBkBASwLA?= =?us-ascii?q?QQLCwsDCg0IFQICIhIBBQEKEgYTCAoIiW4DCAUIEJ0AQIsha4FtOoMIAQEFhCs?= =?us-ascii?q?Dg2MBAQEBBgEBAQEBAQEBGAgSgxyCB4FQhF41hEByEoJVgmGIOgyZG4djjQ6Cc?= =?us-ascii?q?pAqlWIUBR+BFQ8ngXyBBwhJNQaCKQmCGiofgg8kNgGJAoFVAQEB?= X-IPAS-Result: =?us-ascii?q?A0D0AADt2ulZh6uhVdFcHAEBBAEBCgEBFQEBAQECAQEBAQg?= =?us-ascii?q?BAQEBhBhuJweDc4E2mCiBeoJRk3SBIgNcChgBCoQDAYEUAoQxB0MUAQEBAQEBA?= =?us-ascii?q?QEBAQESAQEBCA0JCCgvgjgFAR4GgjsBAQEDAQEiBBkBASwLAQQLCwsDCg0IFQI?= =?us-ascii?q?CIhIBBQEKEgYTCAoIiW4DCAUIEJ0AQIsha4FtOoMIAQEFhCsDg2MBAQEBBgEBA?= =?us-ascii?q?QEBAQEBGAgSgxyCB4FQhF41hEByEoJVgmGIOgyZG4djjQ6CcpAqlWIUBR+BFQ8?= =?us-ascii?q?ngXyBBwhJNQaCKQmCGiofgg8kNgGJAoFVAQEB?= X-IronPort-AV: E=Sophos;i="5.43,405,1503352800"; d="scan'208,217";a="297152297" Received: from mail-yw0-f171.google.com ([209.85.161.171]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 20 Oct 2017 13:21:04 +0200 Received: by mail-yw0-f171.google.com with SMTP id q126so3132934ywq.10 for ; Fri, 20 Oct 2017 04:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VpGGebw0w6Dr51uuw4KBtJ9zolbdTdFm25Z388B7JRA=; b=NOhGCsCMrAooYwaEWxumETsvHVZ9p72walMDdvoCQ3ogqXsymjSlX9PFHNrneHhs1n 95bvf7L4dpiJPSol1s3KX5RrQfaAH/VV4auWbNa6Slmifq4DWFuL+f3JYugtTOYnJKuE TXzOZ6C57dGuKVdLVe2szc1OMeDMq3tmfe9M9mJ38LLCqr5vQlsj0rIKSJs1bOB9K9wK SBKz45uMPCgZzpLrt7XPCDfm9+d3XPI5ZZWtt/pWH38F5EU4ejat11lR4uBRJXFqvj7g cdKQ/5Yry0Gloop0UdmS4zstPBFUYxsIGYNd4iv/wPksoxYzU+DH6QOUk8VbUSzukUHd YxNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VpGGebw0w6Dr51uuw4KBtJ9zolbdTdFm25Z388B7JRA=; b=fqpZ8Bp+YgH3PtUKrJHJYtYMR/wdN3CvCablK1Ob4VqS9Njz9gmMYSv+Qs82YfOdyl ZgzFOJAL1cyUdfI7PEEVs2hqHzHQRsop94JUoMwVvFDq3+zMG+eDSFZ/QJkFuI2Qc3Of kqQYXQFvlAurJtR43/4tPNh+oFS50IRXuBTABQG9lXCwZICNnm9pvb1m3EZcgmmqlYJ/ PX6P/71I5aigVfHgbCma+GbqDbcrzPUetT8ziFAkZuofE9B7RW30BwUp0SwwUooAwENg ovwKcX1K9fpVd3FIFHdmxf8bbKQdlo8/VANBPCgXwMt+rL4CTjmUwFHa03taifWhAECH zb1w== X-Gm-Message-State: AMCzsaUFBNf1q22tyIZcEXUYymdH+itp8/Exq+BqyS4A/Hk/ygC6db1J oCZmLjG8hnJwt5onBwavej+HyOHBfkdCd+Ousj8iUA== X-Google-Smtp-Source: ABhQp+StC8ig8Mqi1ueuS5p9hho/nS2XT+2A9xgxSOYMlSsxQg1XMuNs13+//fLMfjjScgL51NraKsVh/oam+Rn5WKw= X-Received: by 10.129.123.135 with SMTP id w129mr2920155ywc.299.1508498462706; Fri, 20 Oct 2017 04:21:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.174.33 with HTTP; Fri, 20 Oct 2017 04:21:02 -0700 (PDT) Received: by 10.129.174.33 with HTTP; Fri, 20 Oct 2017 04:21:02 -0700 (PDT) In-Reply-To: References: <86o9p2ywgc.fsf@gmail.com> From: Ivan Gotovchits Date: Fri, 20 Oct 2017 07:21:02 -0400 Message-ID: To: David Allsopp Cc: caml-list , Malcolm Matalka Content-Type: multipart/alternative; boundary="001a114948dc03ce77055bf8abea" Subject: RE: [Caml-list] What if exn was not an open type? --001a114948dc03ce77055bf8abea Content-Type: text/plain; charset="UTF-8" It's also a question of efficiency, signaling an absence of data with an exception is usually more efficient, than signaling the presence of data by wrapping it in some data constructor, as the latter needs an allocation. Thus a function that raised an exception is more basic, than a function that returns an optional value, as the former can be translated into the latter, but not vice versa if you take an allocation into account. On Oct 20, 2017 6:55 AM, "David Allsopp" wrote: > Malcolm Matalka wrote: > > I have a question in two parts: > > > > 1. Would this be a good idea? Why? (I'll describe why I think it is) > > > > 2. If it were a good idea, is it feasible to do? > > > > Full question: > > > > Despite exceptions being a part of the language, there is a trend in > > many libraries to try to avoid using them. While I cannot find it, I > > recall someone (Daniel maybe?) saying that the standard API advice is > > that exceptions should not cross API boundaries. > > > > The short reason for why people seem to want to avoid exceptions (which > > I agree with) is that they side step the type system for helping you > > understand if your code is correct and handles all situations the code > > might experience. Since the exn type is open, it means that one can > > add any exception they want so it's not even known what exceptions you > > might get ahead of time. > > > > Another aspect of exceptions, which might be more of my personal > > experience, is that exceptions tend to be pretty useless after the > > fact. For example, forgetting to handle a Not_found exception is an > > exercise in pain. Maybe I'm just bad at this, but many exceptions just > > aren't that useful. End_of_file is another one that, IMO, makes the > > program flow pretty awkward and if you have multiple files you're > > reading from at the same time quite ugly. I tend to use wrappers that > > give me an option based API. Maybe I just bad at solving these > > problems though and I'm the problem. > > > > The consequence of this is that even though I put a lot of effort in my > > code trying to avoid exceptions, I can never actually know that I have > > succeeded unless I'm very defensive and wrap all foreign calls in some > > exception handling code. There are APIs for this, but if I mess up > > then I'm in a bad spot. > > > > My proposal is that exceptions becomes a closed type and they reflect > > what Java calls "errors", which are things your program logic should > > generally not handle but can choose to if it wants to (I think we call > > these failures in Ocaml). The two specific exceptions I can think if > > that should exist are: Assertion_failure and Out of Memory. Another > > one that I think might be nice but is open for debate is a > > Not_implemented_failure, I use something like this often while building > > a system. I'm sure there are a few more that people can think of are > > meaningful, but the point is these represent pretty bad situations that > > the program logic shouldn't handle except in special situations. > > Without wishing to open old debating wounds too much, the argument of > exceptions as errors tends to come down as to whether the thing signalled > by an exception is truly exceptional. Not_found, for example, in some > scenarios is as unexpected or impossible as Invalid_argument. Historically, > they're (ab)used for performance reasons, but some of the overhead of that > is being addressed in flambda. Note that for some arguable design mistakes > - e.g. End_of_file, you can use exception matching to get around this, e.g. > > match input_line ch with > | data -> ... > | exception End_of_file -> ... > > which means that the old pattern > > let data = try Some (input_line ch) with End_of_file -> None > > is only needed if you need to compile with OCaml < 4.02 > > If you haven't come across it, https://caml.inria.fr/pub/old_ > caml_site/ocamlexc/ocamlexc.htm is an interesting piece of older research > around dealing with handling exceptions. > > What your proposal does overlook slightly is the use of exceptions for > actual flow control. See for example, an oldish post of Alain Frisch's at > https://www.lexifi.com/blog/static-exceptions. However, uses of > exceptions like this may at some point be subsumed by Algebraic Effects > which are being worked on by various people, mostly with multicore OCaml in > mind. There's lots of links to that in https://github.com/ocamllabs/ > ocaml-multicore/wiki as well as other literature elsewhere online. > > HTH, > > > David > > -- > 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 --001a114948dc03ce77055bf8abea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's also a question of efficiency, signaling an abse= nce of data with an exception is usually more efficient, than signaling the= presence of data by wrapping it in some data constructor, as the latter ne= eds an allocation. Thus a function that raised an exception is more basic, = than a function that returns an optional value, as the former can be transl= ated into the latter, but not vice versa if you take an allocation into acc= ount.

On Oct= 20, 2017 6:55 AM, "David Allsopp" <dra-news@metastack.com> wrote:
Malcolm Matalka wrote:
> I have a question in two parts:
>
> 1. Would this be a good idea? Why? (I'll describe why I think it i= s)
>
> 2. If it were a good idea, is it feasible to do?
>
> Full question:
>
> Despite exceptions being a part of the language, there is a trend in > many libraries to try to avoid using them.=C2=A0 While I cannot find i= t, I
> recall someone (Daniel maybe?) saying that the standard API advice is<= br> > that exceptions should not cross API boundaries.
>
> The short reason for why people seem to want to avoid exceptions (whic= h
> I agree with) is that they side step the type system for helping you > understand if your code is correct and handles all situations the code=
> might experience.=C2=A0 Since the exn type is open, it means that one = can
> add any exception they want so it's not even known what exceptions= you
> might get ahead of time.
>
> Another aspect of exceptions, which might be more of my personal
> experience, is that exceptions tend to be pretty useless after the
> fact.=C2=A0 For example, forgetting to handle a Not_found exception is= an
> exercise in pain.=C2=A0 Maybe I'm just bad at this, but many excep= tions just
> aren't that useful.=C2=A0 End_of_file is another one that, IMO, ma= kes the
> program flow pretty awkward and if you have multiple files you're<= br> > reading from at the same time quite ugly.=C2=A0 I tend to use wrappers= that
> give me an option based API.=C2=A0 Maybe I just bad at solving these > problems though and I'm the problem.
>
> The consequence of this is that even though I put a lot of effort in m= y
> code trying to avoid exceptions, I can never actually know that I have=
> succeeded unless I'm very defensive and wrap all foreign calls in = some
> exception handling code.=C2=A0 There are APIs for this, but if I mess = up
> then I'm in a bad spot.
>
> My proposal is that exceptions becomes a closed type and they reflect<= br> > what Java calls "errors", which are things your program logi= c should
> generally not handle but can choose to if it wants to (I think we call=
> these failures in Ocaml).=C2=A0 The two specific exceptions I can thin= k if
> that should exist are: Assertion_failure and Out of Memory.=C2=A0 Anot= her
> one that I think might be nice but is open for debate is a
> Not_implemented_failure, I use something like this often while buildin= g
> a system.=C2=A0 I'm sure there are a few more that people can thin= k of are
> meaningful, but the point is these represent pretty bad situations tha= t
> the program logic shouldn't handle except in special situations.
Without wishing to open old debating wounds too much, the argument of excep= tions as errors tends to come down as to whether the thing signalled by an = exception is truly exceptional. Not_found, for example, in some scenarios i= s as unexpected or impossible as Invalid_argument. Historically, they'r= e (ab)used for performance reasons, but some of the overhead of that is bei= ng addressed in flambda. Note that for some arguable design mistakes - e.g.= End_of_file, you can use exception matching to get around this, e.g.

match input_line ch with
| data -> ...
| exception End_of_file -> ...

which means that the old pattern

let data =3D try Some (input_line ch) with End_of_file -> None

is only needed if you need to compile with OCaml < 4.02

If you haven't come across it, http= s://caml.inria.fr/pub/old_caml_site/ocamlexc/ocamlexc.htm is = an interesting piece of older research around dealing with handling excepti= ons.

What your proposal does overlook slightly is the use of exceptions for actu= al flow control. See for example, an oldish post of Alain Frisch's at <= a href=3D"https://www.lexifi.com/blog/static-exceptions" rel=3D"noreferrer"= target=3D"_blank">https://www.lexifi.com/blog/static-exceptions. = However, uses of exceptions like this may at some point be subsumed by Alge= braic Effects which are being worked on by various people, mostly with mult= icore OCaml in mind. There's lots of links to that in https://github.com/ocamllabs/ocaml-multicore/wiki as well a= s other literature elsewhere online.

HTH,


David

--
Caml-list mailing list.=C2=A0 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
--001a114948dc03ce77055bf8abea--