From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id IAA14505; Wed, 22 Sep 2004 08:31:56 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id IAA08983 for ; Wed, 22 Sep 2004 08:31:55 +0200 (MET DST) Received: from qrnik.knm.org.pl (paf87.warszawa.sdi.tpnet.pl [217.96.225.87]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id i8M6VlAJ015238 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 22 Sep 2004 08:31:54 +0200 Received: from qrczak by qrnik.knm.org.pl with local (Exim 3.36 #1) id 1CA0fD-0003Rv-00; Wed, 22 Sep 2004 08:31:39 +0200 To: skaller@users.sourceforge.net Cc: caml-list Subject: Re: [Caml-list] Re: OCAML Downcasting? X-Face: T0C?'>x8&TymF@` Ej6~H&|Uc2j{~CS,tTn|&?jC^xp+,k-6\@io3>5H5.L4GBdPptQ:pN`QJL$~2! References: <87isa76z7g.fsf@qrnik.zagroda> <1095819964.2580.1016.camel@pelican.wigram> From: "Marcin 'Qrczak' Kowalczyk" Mail-Followup-To: skaller@users.sourceforge.net, caml-list Date: Wed, 22 Sep 2004 08:31:38 +0200 In-Reply-To: <1095819964.2580.1016.camel@pelican.wigram> (skaller@users.sourceforge.net's message of "22 Sep 2004 12:26:04 +1000") Message-ID: <87d60eizlh.fsf@qrnik.zagroda> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at nez-perce with ID 41511C53.003 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 downcasting:01 marcin:01 'qrczak':01 kowalczyk:01 qrczak:01 sourceforge:01 downcasts:01 downcast:01 statically:01 checker:01 statically:01 checkers:01 error-prone:01 downcasting:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk skaller 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