[GHC] #1518: Make it possible to evaluate monadic actions when assigning record fields (<-)

[Tim Chevalier]

On 7/9/07, Adde <adde at trialcode.com> wrote:
> On Mon, 2007-07-09 at 23:28 +0000, GHC wrote:
> > #1518: Make it possible to evaluate monadic actions when assigning record fields
> > (<-)
> > -----------------------------------+----------------------------------------
> >     Reporter:  adde at trialcode.com  |        Owner:
> >         Type:  feature request     |       Status:  new
> >     Priority:  normal              |    Milestone:
> >    Component:  Compiler            |      Version:  6.6.1
> >     Severity:  normal              |   Resolution:
> >     Keywords:                      |   Difficulty:  Unknown
> >           Os:  Unknown             |     Testcase:
> > Architecture:  Unknown             |
> > -----------------------------------+----------------------------------------
> > Comment (by chevalier at alum.wellesley.edu):
> >
> >  If you wrote:
> >  {{{
> >  return Bar {
> >   barFoo <- foo
> >   barQuux <- quux
> >  }
> >  }}}
> >  which do you think should be executed first -- computation foo or
> >  computation quux?
> >
> > --
> > Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1518>
> > GHC <http://www.haskell.org/ghc/>
> > The Glasgow Haskell Compiler
>
> I would expect them to be executed in the declared order, why?
>

But when? At the point when the "return Bar{...}" expression is
demanded? OK, but then you're making the Bar constructor strict when
it wouldn't be otherwise. But if you let Bar be lazy as it normally
is, then you get effectful expressions being evaluated at
unpredictable times (e.g., in my example, maybe the foo field will
never be demanded and the quux field will be), which is generally
considered harmful.

Cheers,
Tim

-- 
Tim Chevalier* catamorphism.org *Often in error, never in doubt
"I haven't got the slightest idea how to change people, but still I
keep a long list of prospective candidates just in case I should ever
figure it out."  --David Sedaris
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs at haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs