[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