[Noisebridge-discuss] I am working through "The Implementation of Functional Programming Languages"
Jason Dusek
jason.dusek at gmail.com
Tue Oct 27 23:11:09 UTC 2009
2009/10/27 Crutcher Dunnavant <crutcher at gmail.com>:
> One of the reasons I love the Haskell-like language's lazy
> evaluation is that they permit the construction of novel
> flow-control mechanisms without relying on meta-programming.
When considering laziness's role in supporting novel flow
control, It's helpful to see how laziness supports a
relatively normal construction: the "short-circuit" operations
`||` and `&&`, available in so many languages. These would be
impossible to define in C or Java or other strict/eager
languages; call by need allows us to define them as ordinary
functions in Haskell:
and False _ = False
and True True = True
and _ _ = False
Using this definition in the interpreter verifies that it has
the usual short-circuit semantics:
:; ghci
GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude> undefined
*** Exception: Prelude.undefined
Prelude> let {and False _ = False ; and True True = True ; and _ _ = False}
Prelude> and False undefined
False
Prelude> and True undefined
*** Exception: Prelude.undefined
Here we use `undefined`, the generic, crash-the-computer value
that belongs to every type, to stand in for a conditional that
might fail under certain circumstances. Laziness assures us
that it is only evaluated when we need the second parameter in
the pattern match (which, for `and`, means the first
conditional must be true).
--
Jason Dusek
More information about the Noisebridge-discuss
mailing list