Re: putting laziness back on the parallelized map

From: Sergio Antoy <>
Date: Fri, 14 Mar 2008 09:52:18 -0700 (PDT)

Hi Bernd,

I think I got your messages out of order and I may not piece them
well. I'll answer all of them in this message in the order I
received them. If I do not make sense please, try again. And
thank for your questions!

> Now I understood the example at last: The thing is that you will
> not get the finite failures with a non-parallel
> implementation. Sorry for the slow thinking!
> That makes me wonder: The point seems to be that "the result" is
> implicitly always defined by an evaluation to full normal
> form. Does this definition to normal form have an expression in
> "fx" via (&) or does it have to be primitive?

It is a primitive. The strategy computes only needed steps. In
some situations, more than one needed step is computed for the
term being evaluated. The order in which these steps are executed
is determined by a "plug-in". There are various plug-ins, some of
which executes all the computed steps in parallel.

> Is map defined here in one of the ways Sebastian proposed?

No. I hope the paragraph above gives a hint.

> Would test4/test5/test6 behave the same if g was defined as follows?
> g (x,y) = nf (f x,f y)
> nf (Loop,Fail) = (Loop,Fail)
> nf (Fail,Loop) = (Fail,Loop)
> nf (Loop,Stop) = (Loop,Stop)
> To put the question another way: is only the implicit normal form
> parallelized or also the pattern matching where possible?

Somewhat both, but not in the example you propose. The code
generator (which was implemented in literally half a day by
Sebastian Fischer with his Scrap) takes flatcurry as input. In
flatcurry, the information needed to "parallelize pattern
matching" has been lost already. However, operations that are not
compiled from flatcurry, such as integer addition, equalities,
(&), etc. "parallelize pattern matching". In principle, there are
no obstacles to extend this to the example your propose.

curry mailing list
Received on Fr Mär 14 2008 - 18:44:41 CET

This archive was generated by hypermail 2.3.0 : Mo Dez 04 2023 - 07:15:10 CET