Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!mcsun!ukc!edcastle!lfcs!nick From: nick@lfcs.ed.ac.uk (Nick Rothwell) Newsgroups: comp.object Subject: Re: object-oriented this, that, and the other thing Message-ID: <1033@castle.ed.ac.uk> Date: 9 Nov 89 12:19:27 GMT References: <1471@aber-cs.UUCP> <914@castle.ed.ac.uk> <1561@novavax.UUCP> <352@m1.cs.man.ac.uk> Reply-To: nick@lfcs.ed.ac.uk (Nick Rothwell) Organization: LFCS Enya Admiration Society Lines: 47 In-reply-to: mario@r3.cs.man.ac.uk In article <352@m1.cs.man.ac.uk>, mario@r3 writes: >1. No side effects? I defy you to show me a useful program that has > no side effects :-). More seriously, doesn't ML have a reference > type? Ok, what I said was actually inconsistent (too much typing with brain in neutral). In fact, ML allows you to build objects with state and hence functions with side-effects. In practice, the largest proportion of a program is purely functional with a few reference variables to tie things up at the top. I'm currently working on a 10000 line ML interpreter which has around a half-dozen references (one or two timestamp generators and a top-level variable to hold the environment between runs), everything else being purely applicative. Since assignment is only permitted for explicitly created reference objects (unlike a lot of LISPs), this seems a good compromise. >> (Both of these open the doors to computer-assisted reasoning >> about program correctness.) >So has Pascal. So has 6502 machine code. So what? What I should have said is something far less controversial... :-) because 99.9% of this ML program is side-effect free, it's quite easy to reason informally about what it does, since no component is holding any kind of hidden state - all the interfaces and functions can be trusted to do behave referentially transparently, and return results based only on their input values. I think that 100% applicative programs have difficulty dealing with the outside world (I/O and so on), and start to get rather contorted. >Hmm, I wonder what what these Smalltalk expressions are if not >functionals and generators ... > double := [ :f | [ :x | f value: (f value: x)]]. > someObscureCollection do: [ :each | each process ] I personally find a powerful type system (polymorphism, parameterised types, abstraction) to be pretty essential to make the most of higher-order functions, accumulating parameters, continuations and so on. I'll grant that other people (like the Scheme people) seem to have no problem programming "in the saddle", but that requires run-time debuggers and so on, and it's a different way of working. Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk !mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ Fais que ton reve soit plus long que la nuit.