Something that I've worked on is a semantics for call-by-need with
parallelism (http://mcs.open.ac.uk/djk26/apset/semantics-tech-report.ps).
It's easy to specialise this semantics to the single processor case, and you
end up with a small-step semantics for call-by-need.
There are references in the above tech report to other call-by-need
semantics.
Cheers,
David.
--
David J. King
Motorola Labs, Basingstoke
Email: [EMAIL PROTECTED]
Phone: +44 1256 484148
> ----------
> From: [EMAIL PROTECTED]
> Sent: Monday, July 5, 1999 4:09 pm
> To: [EMAIL PROTECTED]
> Subject: An operational semantics for Haskell
>
> I am looking for advice or ideas on the formulation of an operational
> semantics
> for studying the behaviour of Haskell programs.
> What I have in mind is a structured semantics for the unoptimized
> evaluation of
> Core Haskell programs (my main interest is in studying space behaviour).
> By
> unoptimised I mean modelling lazy evaluation 'as it ought to be done',
> with no
> changes or implementation assumptions that could modify the time or space
> behaviour of a program.
>
> I would be grateful if anyone could point me to work in this area, or if
> anyone
> has comments or suggestions for improving existing formulations of lazy
> evaluation. I am aware of a paper by John Launchbury (20th ACM POPL,1993)
> that
> presents a lazy semantics, and would like to know if anyone who has
> studied it
> (or any similar works) have found there to be difficulties or benefits to
> using
> that presentation.
>
> I would also be very interested to hear about any optimisations to lazy
> evaluation that you think should come as standard, or, indeed, any widely
> regarded as 'safe' or 'useful' that may actually be dangerous.
>
> Thanks.
>
> Adam Bakewell.
>
