Path: utzoo!attcan!uunet!samsung!munnari.oz.au!ditmela!smart
From: smart@ditmela.oz (Robert Smart)
Newsgroups: comp.lang.functional
Subject: Re: Purity and Laziness
Message-ID: <11688@ditmela.oz>
Date: 28 May 90 03:12:57 GMT
References: <1535@sys.uea.ac.uk> <4170@castle.ed.ac.uk> <14531@dime.cs.umass.edu> <2535@skye.ed.ac.uk> <8691@cs.utexas.edu> <1990May25.024023.10616@comp.vuw.ac.nz> <1990May28.020325.18011@comp.vuw.ac.nz>
Reply-To: smart@ditmela.oz.au (Robert Smart)
Organization: CSIRO, Division of Information Technology, Australia
Lines: 21

In article <1990May28.020325.18011@comp.vuw.ac.nz> brian@comp.vuw.ac.nz (Brian Boutel) writes:
> b) to go to parallel evaluation, which is expensive to simulate on a
> sequential machine.
>
I'm a complete amateur at this, but I can't believe that parallel evaluation
would be as bad as all that in practise. It's not like an operating system
where the processes have unknown behaviour and you have to be very fair about
sharing time. All you need is for both processes to call a scheduler every
now and then. You might start with calling the scheduler every 16th time
through a particular calculation point, then move that up to every 32nd, etc.
In that way the scheduling cost would always be low in large calculations.

Also I really doubt whether there are a lot of cases where a procedure has
multiple parameters which might not terminate. Most commonly there will only
be one and the compiler should be able to figure out a reasonable heuristic
for deciding which patterns to try to match for a given function call.
To be popular a language needs to behave in a surprise free fashion. For
lazy functional languages that has to mean parallel parameter evaluation
when truly necessary.

Bob Smart