caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Glen Mével" <glen.mevel@crans.org>
To: caml-list@inria.fr
Cc: Stefan Monnier <monnier@iro.umontreal.ca>
Subject: Re: [Caml-list] overflow checks on `int` operations
Date: Thu, 11 Jul 2019 01:05:04 +0200	[thread overview]
Message-ID: <10c67553-1e80-6dea-9ef8-13486746672d@crans.org> (raw)
In-Reply-To: <jwvlfx5k4xt.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org>


[-- Attachment #1.1: Type: text/plain, Size: 2043 bytes --]

Stefan Monnier wrote (2019-07-10 22:36):
> What's the "standard" way to perform arithmetic operations on `int`
> with overflow checking (e.g. returning an `Option` or signaling an
> exception on overflow)?
I don’t know whether there is a “standard” for integers specifically,
but the rationale for option vs. exception is the following: exceptions
are used for behaviours that are not meant to happen, (ie. program
errors), whereas options are used for the normal course of a program.
For instance, depending on your application, the fact that an element is
unbound in a hash table may be an expected fact that should be dealt with.

In this case, I would advocate for exceptions, because an overflow is
clearly a failure of the program: the bounds on native integers are only
related to the internals of the OCaml runtime, thus it is very unlikely
to have any meaning in your application. It is also likely that you may
not work around an overflow, except by running the same computation with
zarith. If you expect overflows with int, maybe you should use zarith.

Throwing an exception allows you to interrupt your program and track
precisely where the overflow occurred (with the stack trace), either by
wrapping your whole computation in a single exception handler, or by
letting the runtime handle the exception.

With options, by contrast, either you would write an option handler
around each problematic operation, or you would propagate the option,
which implies (1) rewriting your whole computation in a monadic style
and (2) losing the provenance of a None. And you would pay a penalty for
boxing your integers.

> Currently I do the checks by hand but it occurred to me that maybe I'm
> not the first one to want that.

You’re not indeed. For my own needs, I wrote carefully overflowing
versions of some usual arithmetic functions[1]. But more serious
projects may be available, I guess.

[1]: https://gitlab.crans.org/mevel/project-euler-lib/blob/master/Arith.mli

-- 
Glen Mével


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-07-10 23:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-10 20:36 Stefan Monnier
2019-07-10 23:05 ` Glen Mével [this message]
2019-07-11  6:44   ` Gabriel Scherer
2019-07-12 17:44     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=10c67553-1e80-6dea-9ef8-13486746672d@crans.org \
    --to=glen.mevel@crans.org \
    --cc=caml-list@inria.fr \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).