caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl>
To: skaller@users.sourceforge.net
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Re: OCAML Downcasting?
Date: Wed, 22 Sep 2004 08:31:38 +0200	[thread overview]
Message-ID: <87d60eizlh.fsf@qrnik.zagroda> (raw)
In-Reply-To: <1095819964.2580.1016.camel@pelican.wigram> (skaller@users.sourceforge.net's message of "22 Sep 2004 12:26:04 +1000")

skaller <skaller@users.sourceforge.net> writes:

>> Attempts to avoid downcasts are often unmodular, they require to
>> specify all possible variants in one place.
>
> It makes no difference. You have do specify them all anyhow,
> downcast or not.

It makes a difference because specifying them at the type definition
would introduce a dependency loop between modules. And it would be
unmodular: it would require changing some base module whenever a far
client module is added.

Apply this reasoning to the exn type. Why don't you define all exn
constructors in one place?

> The unstated assumption is that you want early error detection
> and efficiency which static typing promises.

It's impossible in general. Only some errors are detectable statically
in practice.

> In the static typing world, 'safe' means errors are always
> detected at compile time.

No practical language is safe according to this definition, so this
definition is useless.

> Generally, we'd like to make programs safer where possible.

This is the catch: "where possible". I would add: "where practical";
sometimes the cost outweights the benefits. For example static
detection of possible division by 0 would be impractical. You would
have to either embed a proof checker in the language in order to be
able to convince the compiler that the number can't be 0, or not use
exceptions at all and have all partial functions return a result in
"option" type or similar, with manual propagation of errors.

And guess what? No language I know checks division by 0 statically
(except proof checkers, but they are not suitable for writing big
programs - too much work). Because it would make programs less robust,
not more. Because you would not use exceptions, and manual propagation
of errors is more error-prone than using exceptions, and it causes
more problems when the set of possible exceptions raised in a given
part of code is changed.

> The problem with downcasting as a general technique is that it
> bypasses static safety where it is in fact desired and is available.

It's not available because it can't express what downcasts provide:
the ability to add "constructors" to a type in a modular way.

According to your beliefs, you should advocate removing exceptions
from OCaml. Because they make the type independent from the set of
ways in which a program can fail, and thus remove the ability to
statically check whether all possible errors are caught. You should
always use explicit algebraic types to encode the outcome, no?

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


  reply	other threads:[~2004-09-22  6:31 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ci7tcf$qqf$1@wolfberry.srv.cs.cmu.edu>
     [not found] ` <ci9ggm$i6p$1@wolfberry.srv.cs.cmu.edu>
2004-09-21  8:03   ` Jacques GARRIGUE
2004-09-21  8:43     ` Damien Pous
2004-09-21  9:15       ` Jacques GARRIGUE
2004-09-21  9:29         ` skaller
2004-09-21  9:49           ` Jacques GARRIGUE
2004-09-21  9:34         ` Stefano Zacchiroli
2004-09-21  9:56           ` Jacques GARRIGUE
2004-09-21 19:27     ` Michael Vanier
2004-09-21 21:38       ` Brian Hurt
2004-09-21 22:06         ` Michael Vanier
2004-09-21 22:32           ` Brian Hurt
2004-09-22  1:04           ` skaller
2004-09-21 22:20         ` Marcin 'Qrczak' Kowalczyk
2004-09-22  2:26           ` skaller
2004-09-22  6:31             ` Marcin 'Qrczak' Kowalczyk [this message]
2004-09-22  9:03               ` sejourne_kevin
2004-09-22 10:29               ` Richard Jones
2004-09-22 18:39                 ` Brian Hurt
2004-09-22 10:50               ` skaller
2004-09-22 12:03               ` Alain Frisch
2004-09-22 12:50               ` Cláudio Valente
2004-09-22 13:15                 ` Marcin 'Qrczak' Kowalczyk
2004-09-22 15:50                   ` skaller
2004-09-22 18:42               ` Brian Hurt
2004-09-22 18:44                 ` Marcin 'Qrczak' Kowalczyk
2004-09-22 19:18                   ` Brian Hurt
2004-09-22  0:50         ` skaller
2004-09-22  1:30       ` Jacques GARRIGUE
2004-09-22  2:59         ` skaller

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=87d60eizlh.fsf@qrnik.zagroda \
    --to=qrczak@knm.org.pl \
    --cc=caml-list@inria.fr \
    --cc=skaller@users.sourceforge.net \
    /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).