<span class="Apple-style-span" style="border-collapse: collapse; "><div class="im" style="color: rgb(80, 0, 80); "><font class="Apple-style-span" color="#000000"><span class="Apple-style-span" style="border-collapse: separate;"><font class="Apple-style-span" color="#500050"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font></span></font></div></span><div class="gmail_quote">2009/10/1 Curt Sampson <span dir="ltr">&lt;<a href="mailto:cjs@starling-software.com">cjs@starling-software.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 2009-10-01 08:53 +0100 (Thu), Andrew Coppin wrote:<br>
<br>
&gt; Sure. But what is a computer program? It&#39;s a *list of instructions* that<br>
&gt; tells a computer *how to do something*.<br>
<br>
</div>Some are. Some aren&#39;t, as proven by the Haskell definition of sum, which<br>
is certainly a &quot;program.&quot;<br>
<br>
I like to think of a program as a specification. A list of instructions<br>
can certainly qualify, but so can other things, depending on what&#39;s<br>
interpreting and executing that specification.<br>
<div class="im"><br></div></blockquote><div><br></div><div><br></div><div><br></div><div>Lets say that how to do a sum is pure abstract knowledge,  and this translates nicely to a declarative haskell sentence.</div><div>
<br></div><div>But to perform a sum of two concrete numbers is procedural, because either the program or the compiler or yourself have to extract from the available knowledge a  sequence of steps in order to obtain a new knowledge, that is , the  result. </div>
<div><br></div><div>In imperative languages the sequentiation  is more explicit. in functional languages this is more implicit, because the compiler+ runtime do the sequentiation. </div><div><br></div><div>In fact, a C compiler also perform an automatic sequentiation for this simple operation and generates a sequence of assembler code for either a sum or any mathematical expression, but the haskell compiler is way more powerful for extracting sequences of steps from declarative statements.   moreover, haskell promote a declarative style because laziness avoid to express abstract knowledge as sequences. Referential transparency avoid also dependencies of expressions from other expressions, and thus avoids artificial sequencing.</div>
<div><br></div><div>however every time the program has to interact with the external world, even for printing the result,, sequencing is necessary. That´s why  the compilers and interpreters exist!!!.   </div><div><br></div>
<div>If the program has to interact many times with the external world in a given sequence, the compiler can not guess such sequence if you don&#39;t write it explicitly.</div><div> </div><div>The perfect declarative  haskell program has no main, no IO monad and no executable.</div>
<div><br></div><div><br></div><div><br></div></div>