This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C182E4.EE840B70
Content-Type: text/plain
<Fergus Wrote>
> On 10-Dec-2001, Erik Zuurbier <EZuurbier@Abz.nl> wrote:
> > In his famous paper, John Hughes elaborates on an example where a game
> tree
> > is generated lazily and then pruned. Now say we want to insert a manual
> > prune-step, where ocasionally a GUI would display a little window,
> asking
> > the user: "Is this a good move?" I think we would have to rewrite the
> > algorithm completely and chain a unique environment (*World or *IOState)
> > through it, just to take care of the GUI-IO. I am afraid that this
> would
> > completely destroy the beauty of the lazy algorithm.
>
> I don't see why the game tree generator would need to change at all. That
> could surely remain the same pure lazy function that it was originally.
> Only the pruning part would need to change.
>
> Even for the pruning part, chaining a unique environment through is not
> what I would call a complete rewrite.
>
> As for the beauty of the lazy algorithm, I think the biggest factor in
> making it beautiful is the nice separation of concerns between the lazy
> generator and the pruner, and that would remain.
</Fergus Wrote>
I find John Hughes' algorithms also beautiful because they display plenty of
opportunities for deterministic parallellism. An experimental Clean-version
once supported that with {P} and {I} annotations (respectively Parallel and
Interleaved reduction). It had its own (rudimentary?) load balancing scheme.
If you then chain a unique environment through all the pruning steps, just
so some pruning-reductions could be manual, you insist on a particular
sequential reduction order, and many opportunities for parallellism
evaporate, so badly needed in such a demanding algorithm.
Suppose you would want to retain the parallel / distributed nature of the
algorithm, where multiple people at multiple PC's would do manual pruning
actions. You would have to - I think - use NON-deterministic parallellism by
inserting message passing functions, write your own load balancing package
and all that. That's what I call a complete rewrite.
If I could avoid all that by the possibility to write a manual (i.e. GUI)
pruning function with the type :: !String -> String, that would be very
nice.
And of course, I am not just talking about John Hughes' game algorithm. With
partly manual pruning it is an example of a work-flow application. And there
are many many more examples of those. If those could be as dense and modular
as the original game algorithm, that would be a great step forward to me:
programming in the large.
Regards Erik Zuurbier
------_=_NextPart_001_01C182E4.EE840B70
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
RE: [clean-list] Why functional programming matters more
<Fergus =
Wrote>
On 10-Dec-2001, Erik Zuurbier =
<EZuurbier@Abz.nl> wrote:
> In his famous paper, John Hughes =
elaborates on an example where a game tree
> is generated lazily and then =
pruned. Now say we want to insert a manual
> prune-step, where ocasionally a =
GUI would display a little window, asking
> the user: "Is this a good =
move?" I think we would have to rewrite the
> algorithm completely and chain a =
unique environment (*World or *IOState)
> through it, just to take care of =
the GUI-IO. I am afraid that this would
> completely destroy the beauty of =
the lazy algorithm.
I don't see why the game tree =
generator would need to change at all. That =
could surely remain the same pure lazy function that it was originally. Only the pruning part would need to =
change.
Even for the pruning part, chaining a =
unique environment through is not what I =
would call a complete rewrite.
As for the beauty of the lazy =
algorithm, I think the biggest factor in making it =
beautiful is the nice separation of concerns between the =
lazy =
generator and the pruner, and that would =
remain.
</Fergus =
Wrote>
I find John Hughes' algorithms also =
beautiful because they display plenty of opportunities =
for deterministic parallellism. An experimental Clean-version once =
supported that with {P} and {I} annotations (respectively =
Parallel and Interleaved reduction). It had its own (rudimentary?) =
load balancing scheme.
If you then chain a unique environment =
through all the pruning steps, just so some =
pruning-reductions could be manual, you insist on a =
particular sequential reduction order, and many opportunities for =
parallellism evaporate, so badly needed in such a demanding =
algorithm.
Suppose you would want to retain the =
parallel / distributed nature of the algorithm, where =
multiple people at multiple PC's would do manual pruning actions. =
You would have to - I think - use NON-deterministic =
parallellism by inserting message passing functions, write your own =
load balancing package and all that. That's what I call a =
complete rewrite.
If I could avoid all that by the =
possibility to write a manual (i.e. GUI) pruning function =
with the type :: !String -> String, that would be very nice.
And of course, I am not just talking =
about John Hughes' game algorithm. With partly manual =
pruning it is an example of a work-flow application. And there are =
many many more examples of those. If those could be as dense =
and modular as the original game algorithm, that would be a =
great step forward to me: programming in the large.
Regards Erik Zuurbier
------_=_NextPart_001_01C182E4.EE840B70--