<br><br><div class="gmail_quote">On Thu, Dec 10, 2009 at 6:31 AM, Alberto G. Corona <span dir="ltr"><<a href="mailto:agocorona@gmail.com">agocorona@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
My understanding is that a pointer to the lazy expression tree for the calcualtion of the parameter is put it the corresponding location of the function expression tree. But at any time you can force the evauation before the call. or the compiler itself. Optimization is possible depending on the knowledge. What happens if the parameter is an infinite list and the function handles a few items of it?.<div>
<br></div><div>All of these consideration pales when a programmer has to call a procdure in a library made by others with no documentation, and no clue about what the procedure does inside. The purity and the type system removes many concerns.<br>
</div></blockquote><div><br></div><div>That's not a "safe" way to think of 3rd party libraries. It is a convenient claim for promoting the language, and is probably more often than not the case though it does not quite capture the whole truth. unsafePerformIO can exist in any library you import, and while you may think it's pure, you still have to implicitly trust the library writers (unless you bother to look at the source).</div>
<div><br></div><div>Take Debug.Trace.trace for example, it's a pure computation, yet causes side effects. Yes, it's a controlled side effect, but a polluted version of the same function signature could "launch the missles" while looking like the function is synonymous with "id". </div>
<div><br></div><div>In short unsafePerformIO, while it's "supposed to be" avoided, may not be avoided as much as the advice given to do so :-). Might be interesting to see how many occurrences of unsafePerformIO exist in hackage.</div>
<div><br></div><div>I fully realize that someone will probably claim I'm taking this position to the extreme, but I think we're tempted to pretend that all functions with pure signatures are always safe which is another kind of extreme when you consider the existence of backdoors to the Monads that provide the guarantees we're clinging to to talk about how great Haskell is.</div>
<div><br></div><div>I think the existence of unsafePerformIO is a bit of an admission that there's some things yet to be figured out to make this system 100% consistent with where we want pure functional programming to be.</div>
<div><br></div><div>Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>
<br><div class="gmail_quote">2009/12/10 David Leimbach <span dir="ltr"><<a href="mailto:leimy2k@gmail.com" target="_blank">leimy2k@gmail.com</a>></span><div><div></div><div class="h5"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And that would be true if everything were strict and not partially evaluated sometimes :-)<div><br></div><div>My understanding is the following... (and I could be way off)</div><div><br></div><div>Remember that a function of arity N is really N functions of arity 1 with their arguments bound one at a time to create a new function along the way. At least you *can* write your code that way if you really want to, but the laziness might make it such that all the parameters are not bound, due to not being "needed" at that moment. Instead a thunk or what some other languages might call a "Future" is put in the argument's place, to be evaluated when needed.</div>
<div><br></div><div>If Haskell were strict by default, I think your claim of passing references around could be true, but my experience with Haskell has been that sometimes it's too lazy for me to write the code that I first thought would be efficient without a lot f study and refactoring of that code. </div>
<div><br></div><div>I'm sure this gets easier with practice, but it's not something I was expecting to be as difficult as it all was.</div><div><br></div><div>Dave<br><br><div class="gmail_quote"><div><div></div>
<div>On Thu, Dec 10, 2009 at 5:57 AM, Alberto G. Corona <span dir="ltr"><<a href="mailto:agocorona@gmail.com" target="_blank">agocorona@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div>One more advantage that is not frequently cited<div><br></div><div>Purity permits to pass every parameter of a procedure by reference (giving the pointer) rather that by value giving a copy, and still be sure that the data has not been modified. Besides the safety. this is great language optimization itself. </div>
<div><br><div class="gmail_quote">2009/12/10 Alberto G. Corona <span dir="ltr"><<a href="mailto:agocorona@gmail.com" target="_blank">agocorona@gmail.com</a>></span><div><div></div><div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div class="gmail_quote"><div><br><br><div><span style="font-family:arial, sans-serif;font-size:large;border-collapse:collapse"> What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? </span><br>
<br></div></div><div><br><div><div><br><div>Here is my list of benefits of purity (some of them are enhanced by other features like the type system).</div></div><div><br><div class="gmail_quote">Purity means referential transparency. that means that the programmer has no way to modify pure data. That cut the tree of possible programmer errors.In particular, since there are no variables, every state change must be in the form o a call to a function with new parameters. each function has no state change (except when needed and then the type system labels the stateful code as such)( This enforcement goes in the righ direction for clarity and readability, maintainability, modularity xxxxxbility.</div>
<div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Purity also eases paralel processing, since no data is modified, each process is isolated better. Less opportunities for errors.</div><div class="gmail_quote"><br>
</div></div><div class="gmail_quote">Purity permits lazines because since the execution tree of an expression has pure, data, can be evaluated later, since it will not be changed.</div><div class="gmail_quote"><br></div>
<div class="gmail_quote">
Lazy evaluation eases mathematical reasoning,because mathematics has no notion of eager evaluation, but to make use of mathematical equations when the calculation is needed. .</div><div><div class="gmail_quote">
<br></div><div class="gmail_quote">
Mathematical reasoning permits the full use of a long tradition of mathematical knowledge. This makes code more simple, understandable, general, proof guarantted and elegant (for those that know the mathematical domain). This also permits high level optimization of code, both by the programmer and the compiler.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">for sure there are a few more</div><div class="gmail_quote"><br></div><div class="gmail_quote">We are superstitious and guided by "nonrational" ideas such is beauty. but:</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">bauauty -> (simplicity -> (less effort to master, less errors)</div></div><div class="gmail_quote">, utility ->, solve more problems, solve greater problems</div>
<div class="gmail_quote"> ) </div><div class="gmail_quote"><br></div></div></div></div>
</div><br>
</blockquote></div></div></div><br></div>
<br></div></div><div>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div></div></div><br></div>
</blockquote></div><br>