Evaluate function

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Evaluate function

Derek McLoughlin
Reading "Parallel and Concurrent Programming in Haskell", at the bottom of
page 27 the author wants to force the evaluation of a list of Strings:

evaluate ( length puzzles )

Why not just

evaluate puzzles

?

https://github.com/simonmar/parconc-examples/blob/master/sudoku4.hs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20140526/cf0ff9a3/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Evaluate function

Daniel Fischer
On Monday 26 May 2014, 10:00:33, Derek McLoughlin wrote:

> Reading "Parallel and Concurrent Programming in Haskell", at the bottom of
> page 27 the author wants to force the evaluation of a list of Strings:
>
> evaluate ( length puzzles )
>
> Why not just
>
> evaluate puzzles
>
> ?
>
> https://github.com/simonmar/parconc-examples/blob/master/sudoku4.hs

Because "evaluate" means "evaluate to weak head normal form", that is, to the
outermost constructor or lambda.

evaluate puzzles

would evaluate the list just so far that it is known whether the list is empty
or not.

To evaluate something completely, one needs to evaluate a value that depends
on the complete structure. Presumably, to determine the length of the list,
one needs to evaluate all paths completely to see whether they lead to a valid
puzzle, hence the evaluation is forced by demanding the evaluation of the
length.

Reply | Threaded
Open this post in threaded view
|

Evaluate function

Derek McLoughlin
Thanks. Reading back, this is actually explained on page 14 - sorry for
that.
On 26 May 2014 11:22, "Daniel Fischer" <daniel.is.fischer at googlemail.com>
wrote:

> On Monday 26 May 2014, 10:00:33, Derek McLoughlin wrote:
> > Reading "Parallel and Concurrent Programming in Haskell", at the bottom
> of
> > page 27 the author wants to force the evaluation of a list of Strings:
> >
> > evaluate ( length puzzles )
> >
> > Why not just
> >
> > evaluate puzzles
> >
> > ?
> >
> > https://github.com/simonmar/parconc-examples/blob/master/sudoku4.hs
>
> Because "evaluate" means "evaluate to weak head normal form", that is, to
> the
> outermost constructor or lambda.
>
> evaluate puzzles
>
> would evaluate the list just so far that it is known whether the list is
> empty
> or not.
>
> To evaluate something completely, one needs to evaluate a value that
> depends
> on the complete structure. Presumably, to determine the length of the list,
> one needs to evaluate all paths completely to see whether they lead to a
> valid
> puzzle, hence the evaluation is forced by demanding the evaluation of the
> length.
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20140526/cd850497/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Evaluate function

Kim-Ee Yeoh
Administrator
In reply to this post by Daniel Fischer
On Mon, May 26, 2014 at 5:21 PM, Daniel Fischer <
daniel.is.fischer at googlemail.com> wrote:

> To evaluate something completely, one needs to evaluate a value that
> depends
> on the complete structure. Presumably, to determine the length of the list,
> one needs to evaluate all paths completely to see whether they lead to a
> valid
> puzzle, hence the evaluation is forced by demanding the evaluation of the
> length.
>

To avoid that presumption, you could also write

evaluate $ rnf x

whenever x is an instance of NFData.

The length function strikes me as a kludgy stand-in for rnf when rnf is
really what's meant.


-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20140526/43dc69a5/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Evaluate function

Daniel Trstenjak-2
On Mon, May 26, 2014 at 08:21:36PM +0700, Kim-Ee Yeoh wrote:
> The length function strikes me as a kludgy stand-in for rnf when rnf is really
> what's meant.

And depending on the type of the list entries, calling length won't
always have the same effect then calling rnf on the list and therefore
on all entries of the list.


Greetings,
Daniel

Reply | Threaded
Open this post in threaded view
|

Evaluate function

Brent Yorgey-2
On Mon, May 26, 2014 at 04:25:35PM +0200, Daniel Trstenjak wrote:
> On Mon, May 26, 2014 at 08:21:36PM +0700, Kim-Ee Yeoh wrote:
> > The length function strikes me as a kludgy stand-in for rnf when rnf is really
> > what's meant.
>
> And depending on the type of the list entries, calling length won't
> always have the same effect then calling rnf on the list and therefore
> on all entries of the list.
>

Though I could imagine a situation where one wants to force the spine
of the list but not the elements it contains.  In that case rnf would
do too much, and 'length' would do the right thing.  However, 'length'
still feels kludgy here. What is really wanted is a domain-specific
language for expressing which parts of a structure should be forced.
Such a domain-specific language can be found here:

  http://hackage.haskell.org/package/parallel-3.2.0.4/docs/Control-Seq.html

In particular, forcing the spine of a list but not its elements can be expressed by

  evaluate (puzzles `using` seqList r0)

.

-Brent