Path: utzoo!mnetor!uunet!mcvax!ukc!its63b!csnjr From: csnjr@its63b.ed.ac.uk (Nick Rothwell) Newsgroups: comp.lang.misc Subject: Re: sml info [imperative aspects] Message-ID: <794@its63b.ed.ac.uk> Date: 30 Nov 87 12:19:29 GMT References: <16560@gatech.edu> <170500008@uiucdcsb> <736@its63b.ed.ac.uk> Reply-To: nick%ed.lfcs@uk.ac.ucl.cs.nss (Nick Rothwell) Organization: LFCS, University of Edinburgh Lines: 35 Keywords: instructions, values, types Summary: Exceptions really screw things up? In article <347@sequent.cs.qmc.ac.uk> keithc@qmc.ac.uk (Keith Clarke) writes: > >Michael Schmidt writes (neulich shrieb): >> there is no concept of rewrites in ML > >Correct. But there is a large sublanguage of ML that does >have a rewrite semantics. >One can apply equational reasoning to programs written in the >sublanguage. (I'm ignoring the problem of partial functions, >like most people who work with strict functional languages). Forgive my mathematical ignorance here - but, by "partial" do you mean nonterminating, or undefined for some arguments? You can't have exceptions and maintain the applicative property of your sublanguage, since you've lost referential transparency - for example, fun f() = raise F fun g() = raise G val x = f() + g() handle F => 1 || G => 2 The evaluation order becomes important. If you omit exceptions, then you've got to define some behaviour for "head(nil)" - or is this what you mean by partial? You *can* have exceptions in a pure functional language, if you treat exceptions as special values - I did this for the language described in my thesis, precisely for this reason. There's an implementation overhead, and you have to program some things slightly differently, but it works... -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick%lfcs.ed.ac.uk@nss.cs.ucl.ac.uk!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ "Nothing's forgotten. Nothing is ever forgotten." - Herne