[clean-list] Why functional programming matters more

Erik Zuurbier EZuurbier@Abz.nl
Mon, 10 Dec 2001 14:50:45 +0100


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_01C18181.AA5E36F0
Content-Type: text/plain

Dear Clean-watchers

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 see one possibility to overcome this: call a C-function :: !String ->
String, where the input string represents the game state and the output
string represents the user's answer. The C-function would then display the
input string in a window, together with an edit-field and an OK-button,
circumventing Clean's uniqueness typing, and formally destroying referential
transaparency. But it works!

But should not there be a way to do this all within Clean, where for
instance you promise to use the !String -> String function in a
referentially transparent way? Then you could do this for all data types
(not just basic ones) and also for lazy parameters.

By the way, how is this in Haskell, where there is no named environment
chained through its monadic IO-operations. Could you insert a manual
prune-step without overturning the lazy algorithm completely? 

Regards Erik Zuurbier


------_=_NextPart_001_01C18181.AA5E36F0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">



Why functional programming matters more



Dear Clean-watchers

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 see one possibility to overcome = this: call a C-function :: !String -> String, where the input string = represents the game state and the output string represents the user's = answer. The C-function would then display the input string in a window, = together with an edit-field and an OK-button, circumventing Clean's = uniqueness typing, and formally destroying referential transaparency. = But it works!

But should not there be a way to do = this all within Clean, where for instance you promise to use the = !String -> String function in a referentially transparent way? Then = you could do this for all data types (not just basic ones) and also for = lazy parameters.

By the way, how is this in Haskell, = where there is no named environment chained through its monadic = IO-operations. Could you insert a manual prune-step without overturning = the lazy algorithm completely?

Regards Erik Zuurbier

------_=_NextPart_001_01C18181.AA5E36F0--