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 EAA07162; Wed, 22 Sep 2004 04:26:16 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id EAA07325 for ; Wed, 22 Sep 2004 04:26:10 +0200 (MET DST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i8M2Q7J2019143 for ; Wed, 22 Sep 2004 04:26:09 +0200 Received: from [192.168.1.200] (ppp202-133.lns1.syd3.internode.on.net [203.122.202.133]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i8M2Q5OU055143 for ; Wed, 22 Sep 2004 11:56:05 +0930 (CST) Subject: Re: [Caml-list] Re: OCAML Downcasting? From: skaller Reply-To: skaller@users.sourceforge.net To: caml-list In-Reply-To: <87isa76z7g.fsf@qrnik.zagroda> References: <87isa76z7g.fsf@qrnik.zagroda> Content-Type: text/plain Message-Id: <1095819964.2580.1016.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 22 Sep 2004 12:26:04 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4150E2BF.000 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 sourceforge:01 2004:99 marcin:01 'qrczak':01 kowalczyk:01 downcasts:01 downcast:01 downcasting:01 downcasts:01 interscript:01 python:01 intentional:01 ignoring:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, 2004-09-22 at 08:20, Marcin 'Qrczak' Kowalczyk wrote: > 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. > > Downcasting is a sign you're doing something wrong. > > I disagree. It may be, or not. Just that OCaml doesn't support > something doesn't imply that it must be evil. The unstated assumption is that you want early error detection and efficiency which static typing promises. If you are willing to forgo these benefits -- and have slow unreliable programs -- then you can use downcasts, RTTI, or even code in Assmebler. My typesetting tool Interscript uses Python for dynamic message dispatch -- a certain class of errors lead to exceptions being thrown which are just ignored. This is intentional. The result is sometimes bad output, so you have to actually proofread the generated document to be sure you got what you expected. The reason is that (a) usually ignoring a request to use a LaTeX feature in HTML is reasonable, or vice versa. (b) termination of processing with a weird error makes finding the problem harder than generating bad output where you can actually examine the consequences visually. I.e. what I'm doing is even 'worse' than run time error diagnosis -- I'm checking, and then ignoring the fault :) > Of course something is necessary to determine at runtime whether it's > safe. I don't advocate unsafe constructs. In the static typing world, 'safe' means errors are always detected at compile time. Clearly this is impossible in general, so safe is a relative term. I consider Ocaml *unsafe* because array bounds aren't checked at compile time. Catching the error at run time is better than not catching it -- but it still means the program is unsafe. Generally, we'd like to make programs safer where possible. The problem with downcasting as a general technique is that it bypasses static safety where it is in fact desired and is available. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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