<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=text/html;charset=utf-8 http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.18865"></HEAD>
<BODY style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
id=MailContainerBody leftMargin=0 topMargin=0 CanvasTabStop="true"
name="Compose message area">
<DIV><FONT size=4 face="LM Mono 12">Dear Gregg,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=4 face="LM Mono 12">You wrote, "Just think about how one reads a
mathematical text - you need not actually compute subformulae or even analyze
them logically in order to work with them." I hate to have to say this, but do
you realize that algebra is concerned with functions among other things and it
is the fact that these expressions are functions and not that they are algebraic
that gives them this property? Functional programming is not a misnomer. It is
called functional programming because you are quite literally working with
functions.</FONT></DIV>
<DIV><FONT size=4 face="LM Mono 12"></FONT> </DIV>
<DIV><FONT size=4 face="LM Mono 12">Functions have a profound simplifying
effect. The truth is as Haskell has demonstrated that much of the complexity in
computer programming is artificial and doesn't need to be there. It makes having
to prove correctness a lot easier, but that is not the only motivation behind
Haskell and other functional programming languages. The push has been getting
performance up to a point where the language may be regarded as respectable.
This has been a problem that has dogged artificial intelligence languages. It is
easier to get a functional language to be efficient compared to a logic
language. </FONT></DIV>
<DIV><FONT size=4 face="LM Mono 12"></FONT> </DIV>
<DIV><FONT size=4 face="LM Mono 12">This reason for this is that you get the
opportunity to work out more of the details as compared to a logic
language. In assembler you get to work out every blessed detail to your hearts
content or until you drop. That is why assembler has a reputation for being
fast. It is the same reason why functional languages are fast comparatively
speaking.</FONT></DIV>
<DIV style="FONT: 10pt Tahoma">
<DIV><BR></DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A
title="mailto:dev@mobileink.com CTRL + Click to follow link"
href="mailto:dev@mobileink.com">Gregg Reynolds</A> </DIV>
<DIV><B>Sent:</B> 10 Thursday December 2009 0939</DIV>
<DIV><B>To:</B> <A
title="mailto:JohnDEarle@cox.net CTRL + Click to follow link"
href="mailto:JohnDEarle@cox.net">John D. Earle</A> </DIV>
<DIV><B>Cc:</B> <A title=haskell-cafe@haskell.org
href="mailto:haskell-cafe@haskell.org">Haskell Cafe</A> </DIV>
<DIV><B>Subject:</B> Re: [Haskell-cafe] Re: Why?</DIV></DIV></DIV>
<DIV><BR></DIV>On Thu, Dec 10, 2009 at 9:13 AM, John D. Earle <SPAN
dir=ltr><<A title="mailto:JohnDEarle@cox.net CTRL + Click to follow link"
href="mailto:JohnDEarle@cox.net">JohnDEarle@cox.net</A>></SPAN> wrote:<BR>
<DIV class=gmail_quote>
<BLOCKQUOTE
style="BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0pt 0pt 0pt 0.8ex; PADDING-LEFT: 1ex"
class=gmail_quote>Most of the discussion centers on the benefits of functional
programming and laziness. Haskell is not merely a lazy functional language. It
is a pure lazy functional language. I may need to explain what laziness is.
Laziness is where you work through the logic in its entirely before acting on
the result. In strict evaluation the logic is worked out in parallel with
execution which doesn't make complete sense, but it does allow for an
architecture that is close to the machine. <BR>
<DIV>
<DIV></DIV><BR></DIV></BLOCKQUOTE>
<DIV><BR>Just to roil the waters a bit: no programming language can ever hope to
be "purely functional", for the simple reason that real computation (i.e.
computation involving IO, interactivity) cannot be functional. "Functional
programming" is an unfortunate misnomer. On the other hand, languages can
be algebraic. The whole point is provability, not
function-ness.<BR><BR>More generally: judging by the many competing
proposals addressing the issue of how to think formally about real computation
(just google stuff like hypercomputation, interactive computation, etc.; <A
href="http://www.hums.canterbury.ac.nz/phil/people/copeland.shtml#articles">Jack
Copeland</A> has lots of interesting stuff on this) is still an open
question. Soare has <A
href="http://www.people.cs.uchicago.edu/%7Esoare/History/">three essential
papers</A> on the subject. I guess the moral of the story is that the
concepts and the terminology are both still unstable, so lots of terms in common
use are rather ill-defined and misleading (e.g. functional
programming).<BR><BR>Lazyness is just a matter of how one attaches an actual
computation to an expression; a better term would be something like "delayed
evaluation" or "just-in-time computation". You don't have to work through
any logic to have laziness. Just think about how one reads a mathematical
text - you need not actually compute subformulae or even analyze them logically
in order to work with them. This applies right down to expressions like
"2+3" - one probably would compute "5" on reading that, but what about
"12324/8353"? You'd leave the computation until you absolutely had to do
it - i.e. one would probably try to eliminate it algebraically
first.<BR><BR>-gregg<BR></DIV></DIV></BODY></HTML>