>> So in Haskell, the ordering doesn't matter.
> 
> http://rinkworks.com/stupid/cs_programming.shtml
> 
> "An introductory programming student once asked me to look at his 
> program and figure out why it was always churning out zeroes as the 
> result of a simple computation. I looked at the program, and it was 
> pretty obvious:
> 
> begin
>     readln("Number of Apples", apples);
>     readln("Number of Carrots", carrots);
>     readln("Price for 1 Apple", a_price);
>     readln("Price for 1 Carrot", c_price);
>     writeln("Total for Apples", a_total);
>     writeln("Total for Carrots", c_total);
>     writeln("Total", total);
>     total := a_total + c_total;
>     a_total := apples * a_price;
>     c_total := carrots + c_price;
> end;
> 
>  * Me: "Well, your program can't print correct results before they're 
> computed."
>  * Him: "Huh? It's logical what the right solution is, and the computer 
> should reorder the instructions the right way."
> 
> ---
> 
> So he was right after all...

The trouble is, as soon as you start assigning more than one value to 
something, it suddenly matters *when* you read it's value. And that 
means if you start reordering things, everything goes horribly wrong.

Haskell does not permit you to assign more than one value to any given 
variable. Thus, Haskell is able to chase down dependencies (even 
circular ones) and Do The Right Thing(tm). So it really is a math-style 
definition that always holds rather than an imperative-style assignment 
at a specific point in time.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message