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 RAA03212; Tue, 18 Nov 2003 17:50:04 +0100 (MET) 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 RAA02551 for ; Tue, 18 Nov 2003 17:50:02 +0100 (MET) Received: from mail.dcs.qmul.ac.uk (vicar.dcs.qmul.ac.uk [138.37.88.163]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hAIGo2122090 for ; Tue, 18 Nov 2003 17:50:02 +0100 (MET) Received: from xenografia.plus.com ([212.159.85.26] helo=dcs.qmul.ac.uk) by mail.dcs.qmul.ac.uk with asmtp (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.24) id 1AM939-00063k-7h; Tue, 18 Nov 2003 16:49:59 +0000 Message-ID: <3FBA4D97.9060309@dcs.qmul.ac.uk> Date: Tue, 18 Nov 2003 16:49:27 +0000 From: Martin Berger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031009 X-Accept-Language: en-us, en MIME-Version: 1.0 To: skaller@ozemail.com.au CC: Caml Mailing List Subject: Re: [Caml-list] GC and file descriptors References: <1069168323.18363.83.camel@pelican> In-Reply-To: <1069168323.18363.83.camel@pelican> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Auth-User: martinb X-DCS-Spam-Score: -1.5 X-clamav-result: clean (1AM939-00063k-7h) X-uvscan-result: clean (1AM939-00063k-7h) X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 'const':01 gotos:01 expressive:01 subtyping:01 descriptors:01 behaviour:01 concise:01 exception:02 exception:02 typing:03 types:03 types:03 exceptions:04 exceptions:04 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > What alternatives are there? > > One is to have exception specifications on functions, > but that is known not to work very well. The first > difficulty is that once you have them, they must > become part of the type system. They then 'snowball' > through the whole program (in the same way 'const' > does to C programs). but isn't this snowballing exactly what you want? you can think of exceptions and normal function returns as well- behaved value-passing gotos. but nobody wants to ignore intermediate types in function chaining. so why should only the functional but not the exception behaviour be constraint by types? the only difference between exceptions and function types is that * for exceptions, the normal case is that we ignore the exception, i.e., all we do is pass it on, without touching it. * for functions, the normal case is to take the returned value and do something with it. i always wonder if problem would simply disappear with more expressive typing systems that allow concise specification of the normal case for exceptions -- where an piece of code is just a conduit for exceptions -- and appropriate grouping of exceptions, for example by subtyping. martin ------------------- 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