Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion whither operational semantics?
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Adrian Hey  
View profile  
 More options Sep 24 2009, 5:45 am
Newsgroups: comp.lang.haskell
From: Adrian Hey <a...@NoSpicedHam.iee.org>
Date: Thu, 24 Sep 2009 10:45:44 +0100
Local: Thurs, Sep 24 2009 5:45 am
Subject: Re: whither operational semantics?
Hello Raould

raould wrote:
>> Hmm - you've piqued my curiosity - is there something specific about
>> Haskell's semantics that bothers you?

> i'm not clueful enough to give a concrete example, but have seen
> discussions here and in comp.lang.functional where some folks have
> said what i paraphrased (hopefully w/out changing the message too
> much). i hazard that it generally has to do with space leaks due to
> laziness.

I think the problem with ambiguity wrt space behaviour of Haskell
programs isn't so much with laziness. If all Haskell implementations
were truely lazy then they should all use the same fully determined
reduction order (normal order reduction). Laziness induced space leaks
could be nailed using explicit seqs in the program source.

The problem is that normal order reduction can be inefficient, so
compilers can change the reduction order provided this does not affect
the termination properties. They may use strictness analysis to decide
when this is safe, but this is not mandated nor is the algorithm used
standardised. As strictness analysis is AFAICS effectively the halting
problem in disguise, it has no general solution. Some compilers may well
do a better job than others, hence they won't all use same reduction
order or exhibit same space behaviour for the same source program. In
fact even with the same compiler you may get completely different space
behaviour for the same program, depending on optimisation settings.

Regards
--
Adrian Hey


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.