On Sat, Jan 26, 2008 at 02:34:25PM -0800, [EMAIL PROTECTED] wrote:
On Sat, Jan 26, 2008 at 01:53:53AM -0600, Gabriel Sechan wrote:
Think about that for a minute- do you really want every else to always be
executed? Imagine that one branch of an if frees a resource (say closes a
file). That'd be bad.
Ah but you had to resort to a side effect. Design a purely functional langie
and "if" doesn't have to be special anymore. :)
There are a small number of "pure" functional languages, mostly Haskell and
Clean. The problem is that you have to bend over in strange ways to cause
side effects, since without side effects no program actually does anything.
Without at least one side effect (say printing a result), a pure-lazy
functional language wouldn't have to compute anything, no matter how
complex the program, since nobody would demand the result.
Pure functional programming is a wonderful way of encapsulating problems
and making code easier to reason about it. The problem is that it isn't
what happens inside the computer. Computers seem to like to be implemented
as a bunch of state (memory) that gets modified.
Both haskell and clean encapsulate the notion of state. Essentially, it
because a thing that has to get passed around, generating new state. You
think of the state of the universe as your initial state, and your program
as a set of functional transformations on that initial state. It's kind of
neat, actually.
The neat thing is that it gets rid of the need for macros. Macros are
needed in lisp because it's the only way to write forms that don't evaluate
their arguments. In haskell, I can write my own control constructs just
like everything else.
Dave
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
