Why?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
77 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Why?

johndearle
This is a matter that I genuinely at the present time do not grasp and I am hoping that some of you who are more familiar with the Haskell language may be able to help enlighten me. I feel the question to be an important one. What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? Please provide examples as I require instruction.
 
The following is what I believe to be true at the present time. It seems to be that the decision was made because it was a matter of taste under the belief that computer scientists can and often are superstitious and their superstitions can and often do materially interfere with progress. What I am saying is that at the present time perhaps due to my ignorance I am unfamiliar with how this benefits the language in a material sense. It appears to be a philosophical matter, a matter of identity, what Haskell stands for.
 
The sort of decision that Apple computer and Microsoft made not to go down the POSIX road seems relevant. Historically, Apple did not embrace POSIX. Windows continues to stand for Windows, that is the graphical user interface.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Why?

Magnus Therning
On Thu, Dec 10, 2009 at 12:01 PM, John D. Earle <[hidden email]> wrote:

> This is a matter that I genuinely at the present time do not grasp and I am
> hoping that some of you who are more familiar with the Haskell language may
> be able to help enlighten me. I feel the question to be an important one.
> What material benefit does Haskell derive from being a "pure" functional
> language as opposed to an impure one? Please provide examples as I require
> instruction.
>
> The following is what I believe to be true at the present time. It seems to
> be that the decision was made because it was a matter of taste under the
> belief that computer scientists can and often are superstitious and their
> superstitions can and often do materially interfere with progress. What I am
> saying is that at the present time perhaps due to my ignorance I am
> unfamiliar with how this benefits the language in a material sense. It
> appears to be a philosophical matter, a matter of identity, what Haskell
> stands for.
>
> The sort of decision that Apple computer and Microsoft made not to go down
> the POSIX road seems relevant. Historically, Apple did not embrace POSIX.
> Windows continues to stand for Windows, that is the graphical user
> interface.

As I understand it it all started with laziness.  I don't know if
laziness is impossible without purity, but talks and papers tend to
say something like "laziness has kept Haskell pure".

/M

--
Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
magnus@therning.org          Jabber: magnus@therning.org
http://therning.org/magnus         identi.ca|twitter: magthe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Why?

greenrd
At Thu, 10 Dec 2009 12:07:32 +0000,
Magnus Therning wrote:
> As I understand it it all started with laziness.  I don't know if
> laziness is impossible without purity

More or less.

Haskell is a language where anything can be evaluated lazily by
default. Unlike say Scheme, where if you want something to be
evaluated lazily you have to be explicit about it, in Haskell it's the
opposite - if you want something to be evaluated _strictly_ you have
to be explicit about it.

If you write an impure expression in Haskell (e.g. using
unsafePerformIO) the side-effects of it might be executed once, twice,
or never, depending on the Haskell implementation in use, the
optimisation flags, or even other Haskell code in the system. And the
side-effects might be executed at unpredictable times, in an
unpredictable order, and only some of them might occur. Now,
this might be fine for debugging purposes, where you want to see what
is being done under the hood - but for most other side-effects, you
really want them to occur in a more controllable way.

Hence, to answer John's question, a lazy language _has_ to be pure
(apart from the unsafe functions) because laziness (or, to be more
technically correct, non-strict evaluation) is incompatible with good
control of the side-effects arising from impure code. Both Clean and
Haskell deal with side-effects by allowing the programmer to write
imperative code in a pure way - in Haskell, by using monads or FRP,
and in Clean by using world-passing and uniqueness types.

Now, that answer probably suffices for a Haskell beginner. Of course
eventually you realise time and space usage is a side-effect, and
_that_ needs to be controlled as well... but despite this, I think my
answer is basically right.

However, that's not the _only_ reason why you might want purity. Even in
a strict language, purity makes it easier to reason about code,
because you don't have to consider the environment, only the
parameters that are passed in. Of course, it gets more complicated
with monads, because the Environment monad and the IO monad both give
you implicit environments at the level of "running the monadic
actions". But even then, it's supposed to be easier to reason about
(once you get the hang of it), and I'd broadly agree with this.
--
Robin
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Why?

johndearle
In reply to this post by Magnus Therning
Magnus, thank you. It at least gives me a lead. I can focus on the
significance of laziness and what role it may have on purity. That the
language is lazy gives me no anxiety as I see laziness as natural. I see
Haskell as having proven that laziness is viable; a language can be lazy and
fast and memory efficient. I am trying to put the puzzle pieces together and
from what I can gather purity may be a perceived outcome of combinatory
logic with Occam's razor. So perhaps the motivation is scientific. Unless
you absolutely must don't go there. Science is an evolutionary process. You
go from Newtonian mechanics to Relativity. Relativity is more complicated
than Newtonian mechanics, but it was proven that the additional complexity
was needed.

--------------------------------------------------
From: "Magnus Therning" <[hidden email]>
Sent: 10 Thursday December 2009 0507
To: "John D. Earle" <[hidden email]>
Cc: "Haskell Cafe" <[hidden email]>
Subject: Re: [Haskell-cafe] Why?

> On Thu, Dec 10, 2009 at 12:01 PM, John D. Earle <[hidden email]>
> wrote:
>> This is a matter that I genuinely at the present time do not grasp and I
>> am
>> hoping that some of you who are more familiar with the Haskell language
>> may
>> be able to help enlighten me. I feel the question to be an important one.
>> What material benefit does Haskell derive from being a "pure" functional
>> language as opposed to an impure one? Please provide examples as I
>> require
>> instruction.
>>
>> The following is what I believe to be true at the present time. It seems
>> to
>> be that the decision was made because it was a matter of taste under the
>> belief that computer scientists can and often are superstitious and their
>> superstitions can and often do materially interfere with progress. What I
>> am
>> saying is that at the present time perhaps due to my ignorance I am
>> unfamiliar with how this benefits the language in a material sense. It
>> appears to be a philosophical matter, a matter of identity, what Haskell
>> stands for.
>>
>> The sort of decision that Apple computer and Microsoft made not to go
>> down
>> the POSIX road seems relevant. Historically, Apple did not embrace POSIX.
>> Windows continues to stand for Windows, that is the graphical user
>> interface.
>
> As I understand it it all started with laziness.  I don't know if
> laziness is impossible without purity, but talks and papers tend to
> say something like "laziness has kept Haskell pure".
>
> /M
>
> --
> Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
> magnus@therning.org          Jabber: magnus@therning.org
> http://therning.org/magnus         identi.ca|twitter: magthe

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Why?

Stephen Tetley-2
In reply to this post by Magnus Therning
Hello All

Paul Hudak's 'Conception, evolution, and application of functional
programming languages' gives an account of the motivations, as its
only available to ACM members, here are some lengthy quotes:

"At least a dozen purely functional languages exist along with their
implementations. The main property that is lost when side effects are
introduced is referential transparency; this loss in turn impairs
equational reasoning..."


"Thus the analogy between goto-less programming and assignment-free
programming runs deep. When Dijkstra first introduced structured
programming, much of the programming community was aghast-how could
one do without goto? But as people programmed in the new style, it was
realized that what was being imposed was a discipline for good
programming not a police state to inhibit expressiveness. Exactly the
same can be said of side-effect free programming, and its advocates
hope that as people become more comfortable programming in the
functional style, they will appreciate the good sides of the
discipline thus imposed.

"When viewed in this way functional languages can be seen as a logical
step in the evolution of imperative languages-thus, of course,
rendering them nonimperative. On the other hand, it is exactly this
purity to which some programmers object, and one could argue that just
as a tasteful use of goto here or there is acceptable, so is a
tasteful use of a side effect. Such small impurities certainly
shouldn’t invalidate the functional programming style and thus may be
acceptable."

http://portal.acm.org/ft_gateway.cfm?id=72554&type=pdf


The History of Haskell paper has less account of the motivations, but
notes some drawbacks, and gives an advantage:

"The purity of the language removed a significant technical obstacle
to many type-system innovations, namely dealing with mutable state."


http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/index.htm

"Why purity?" / Why not?

Best wishes

Stephen
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Why?

johndearle
In reply to this post by johndearle
While going through the Haskell literature I uncovered a passage that said that, I'm paraphrasing: Complexity was at a premium. The task was very complex and what was needed to get Haskell to achieve its goals was extraordinary.
 
This might explain how laziness kept Haskell pure. Everything was at a premium and this developed a discipline to keep everything streamlined. This suggests that purity had a material benefit, but the problem is it is conceivable that its material benefit was merely psychological.
 
I do not have enough time to study what Stephen wrote at the moment so I will need to revisit it. He cited some references.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Why?

Sebastian Sylvan
In reply to this post by johndearle


On Thu, Dec 10, 2009 at 12:01 PM, John D. Earle <[hidden email]> wrote:
This is a matter that I genuinely at the present time do not grasp and I am hoping that some of you who are more familiar with the Haskell language may be able to help enlighten me. I feel the question to be an important one. What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? Please provide examples as I require instruction.

The killer app for that, IMO, is parallelism these days.In large applications it's very hard to know for sure that a function truly has no side effects, so if the language can actually guarantee it for you then that certainly has immense value if you're trying to run things in parallel.

Of course, various forms of lazy processing is becoming popular even in mainstream languages (especially with LINQ etc.), which also requires that the expressions to be pure. Currently mainstream languages rely on programmers being Very Careful, but again these kinds of assumptions aren't scalable.



--
Sebastian Sylvan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

killer app, again

Bulat Ziganshin-2
Hello Sebastian,

Thursday, December 10, 2009, 4:27:49 PM, you wrote:
> The killer app for that, IMO, is parallelism these days

btw, are you seen Google App Engine? it's python/java ATM, but i think
that haskell will be ideal fit there. it's all about
computations-in-cloud, or more precisely hosting-in-a-cloud, like
Amazon EC2

so, both individual cpus and largest servers now are multi-threaded,
it just need some time so EC2/GAP developers will realize Haskell
potential

--
Best regards,
 Bulat                            mailto:[hidden email]

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Fwd: Re: Why?

Alberto G. Corona
In reply to this post by johndearle



 What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? 



Here is my list of benefits of purity (some of them are enhanced by other features like the type system).

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.

Purity also eases paralel processing, since no data is modified, each process is isolated better. Less opportunities for errors.

Purity  permits lazines because since the execution tree of an expression has pure, data, can be evaluated later, since it will not be changed.

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. .

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.

for sure there are a few more

We are superstitious and guided by "nonrational"  ideas such is beauty. but:

bauauty -> (simplicity ->  (less effort to master, less errors)
,                 utility      ->, solve more problems, solve  greater problems
                ) 



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: killer app, again

Sebastian Sylvan
In reply to this post by Bulat Ziganshin-2


On Thu, Dec 10, 2009 at 1:38 PM, Bulat Ziganshin <[hidden email]> wrote:
Hello Sebastian,

Thursday, December 10, 2009, 4:27:49 PM, you wrote:
> The killer app for that, IMO, is parallelism these days

btw, are you seen Google App Engine? it's python/java ATM, but i think
that haskell will be ideal fit there. it's all about
computations-in-cloud, or more precisely hosting-in-a-cloud, like
Amazon EC2

so, both individual cpus and largest servers now are multi-threaded,
it just need some time so EC2/GAP developers will realize Haskell
potential

Indeed. Something like Windows Azure could be a good fit too (as it more directly supports native code than GAE does).

--
Sebastian Sylvan

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Why?

Alberto G. Corona
In reply to this post by Alberto G. Corona
One more advantage that is not frequently cited

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. 

2009/12/10 Alberto G. Corona <[hidden email]>



 What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? 



Here is my list of benefits of purity (some of them are enhanced by other features like the type system).

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.

Purity also eases paralel processing, since no data is modified, each process is isolated better. Less opportunities for errors.

Purity  permits lazines because since the execution tree of an expression has pure, data, can be evaluated later, since it will not be changed.

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. .

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.

for sure there are a few more

We are superstitious and guided by "nonrational"  ideas such is beauty. but:

bauauty -> (simplicity ->  (less effort to master, less errors)
,                 utility      ->, solve more problems, solve  greater problems
                ) 




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Why?

Stephen Tetley-2
In reply to this post by Sebastian Sylvan
2009/12/10 Sebastian Sylvan <[hidden email]>:
>
>
> The killer app for that, IMO, is parallelism these days.

Parallelism has been a killer app for quite a long time:

Darlington's ALICE running Hope:
http://www.chilton-computing.org.uk/acd/dcs/projects/p011.htm

Clean was originally targeted to parallel machines:
http://wiki.clean.cs.ru.nl/FAQ

Many, many more:
http://www.di.unipi.it/didadoc/lfc/OtherPapers/parallelism/parallel-introduction.pdf
http://www.risc.uni-linz.ac.at/people/schreine/papers/pfpbib.ps.gz

Best wishes

Stephen
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Why?

David Leimbach
In reply to this post by Alberto G. Corona
And that would be true if everything were strict and not partially evaluated sometimes :-)

My understanding is the following... (and I could be way off)

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.

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.  

I'm sure this gets easier with practice, but it's not something I was expecting to be as difficult as it all was.

Dave

On Thu, Dec 10, 2009 at 5:57 AM, Alberto G. Corona <[hidden email]> wrote:
One more advantage that is not frequently cited

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. 

2009/12/10 Alberto G. Corona <[hidden email]>




 What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? 



Here is my list of benefits of purity (some of them are enhanced by other features like the type system).

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.

Purity also eases paralel processing, since no data is modified, each process is isolated better. Less opportunities for errors.

Purity  permits lazines because since the execution tree of an expression has pure, data, can be evaluated later, since it will not be changed.

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. .

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.

for sure there are a few more

We are superstitious and guided by "nonrational"  ideas such is beauty. but:

bauauty -> (simplicity ->  (less effort to master, less errors)
,                 utility      ->, solve more problems, solve  greater problems
                ) 




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Why?

wren ng thornton
In reply to this post by johndearle
John D. Earle wrote:
> This is a matter that I genuinely at the present time do not grasp and I am hoping that some of you who are more familiar with the Haskell language may be able to help enlighten me. I feel the question to be an important one. What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? Please provide examples as I require instruction.
>
> The following is what I believe to be true at the present time. It seems to be that the decision was made because it was a matter of taste under the belief that computer scientists can and often are superstitious and their superstitions can and often do materially interfere with progress. What I am saying is that at the present time perhaps due to my ignorance I am unfamiliar with how this benefits the language in a material sense. It appears to be a philosophical matter, a matter of identity, what Haskell stands for.
>
> The sort of decision that Apple computer and Microsoft made not to go down the POSIX road seems relevant. Historically, Apple did not embrace POSIX. Windows continues to stand for Windows, that is the graphical user interface.

Laziness, referential transparency, equational reasoning,... They're
excellent things, but how about a pragmatic example?

I was working recently on a metaprogramming framework to automate the
generation of a bunch of shell scripts for wiring programs together. To
ensure bug-free scripts we want to maintain a few invariants. One
invariant is that the names of files to be generated should not be
accessible prior to the file actually being generated (to avoid the file
equivalent of a null-pointer dereference). Another invariant is that if
someone wants to run a particular generated script then we should ensure
that all prerequisite scripts are run first (a la any other build system).

After some familiarity with Haskell it's easy to see that what we want
here is a monad. This particular monad keeps track for each value (i.e.,
script) the prerequisite values necessary for it to be valid (i.e.,
tracking all other values used in constructing this one). The monad laws
ensure that no values can escape--- but only with purity. If we could,
for example, make global assignments without altering the type
signatures then it would be possible to smuggle a file name out of the
monadic scope, and thus to violate our invariant about names only being
accessible when they're valid. These sorts of issues were painfully
apparent because I was writing this framework in an impure language for
non-Haskellites to use.

There are many other examples along these lines as well. In general,
purity means we can actually use mathematical notions in a rigorous way
to ensure the program behaves appropriately and are not susceptible to
various logic bugs. Referential transparency and equational reasoning
are just two special-case examples of this general benefit. Having
monads actually be monads is another less recognized one.

--
Live well,
~wren
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Fwd: Re: Why?

Alberto G. Corona
In reply to this post by David Leimbach
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 a large list and the function handles a few elements?.

All of these consideration pales when a programmer has to call a procedure 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.

2009/12/10 David Leimbach <[hidden email]>

And that would be true if everything were strict and not partially evaluated sometimes :-)

My understanding is the following... (and I could be way off)

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.

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.  

I'm sure this gets easier with practice, but it's not something I was expecting to be as difficult as it all was.

Dave

On Thu, Dec 10, 2009 at 5:57 AM, Alberto G. Corona <[hidden email]> wrote:
One more advantage that is not frequently cited

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. 

2009/12/10 Alberto G. Corona <[hidden email]>




 What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? 



Here is my list of benefits of purity (some of them are enhanced by other features like the type system).

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.

Purity also eases paralel processing, since no data is modified, each process is isolated better. Less opportunities for errors.

Purity  permits lazines because since the execution tree of an expression has pure, data, can be evaluated later, since it will not be changed.

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. .

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.

for sure there are a few more

We are superstitious and guided by "nonrational"  ideas such is beauty. but:

bauauty -> (simplicity ->  (less effort to master, less errors)
,                 utility      ->, solve more problems, solve  greater problems
                ) 




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe





_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Why?

johndearle
In reply to this post by David Leimbach
David, think of the machine as being the earth and laziness is in the
clouds. Strict evaluation is closer to the machine. The relationship between
a lazy algorithm and the earth is abstract; hence, it will make creating
algorithms especially efficient ones difficult. All of this is still a work
in progress. The Haskell creed appears to be, This is the way so stick to
it! The idea appears to be that by sticking to the program the problems will
be overcome in time and we will be left with all the glorious goodness. At
one time it was not possible to achieve the sort of efficiency that Haskell
achieves as a matter of course.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Why?

David Leimbach
In reply to this post by David Leimbach


On Thu, Dec 10, 2009 at 6:31 AM, Alberto G. Corona <[hidden email]> wrote:
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?.

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.

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).

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".  

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.

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.

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.

Dave
 

2009/12/10 David Leimbach <[hidden email]>

And that would be true if everything were strict and not partially evaluated sometimes :-)

My understanding is the following... (and I could be way off)

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.

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.  

I'm sure this gets easier with practice, but it's not something I was expecting to be as difficult as it all was.

Dave

On Thu, Dec 10, 2009 at 5:57 AM, Alberto G. Corona <[hidden email]> wrote:
One more advantage that is not frequently cited

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. 

2009/12/10 Alberto G. Corona <[hidden email]>




 What material benefit does Haskell derive from being a "pure" functional language as opposed to an impure one? 



Here is my list of benefits of purity (some of them are enhanced by other features like the type system).

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.

Purity also eases paralel processing, since no data is modified, each process is isolated better. Less opportunities for errors.

Purity  permits lazines because since the execution tree of an expression has pure, data, can be evaluated later, since it will not be changed.

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. .

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.

for sure there are a few more

We are superstitious and guided by "nonrational"  ideas such is beauty. but:

bauauty -> (simplicity ->  (less effort to master, less errors)
,                 utility      ->, solve more problems, solve  greater problems
                ) 




_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe





_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Why?

johndearle
In reply to this post by greenrd
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.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Why?

David Leimbach
In reply to this post by johndearle
I understand that this is very much a work-in-progress.  But we have to also come to the realization that there's people forming "industrial groups" and such around Haskell, and trying very earnestly to show that it's worth looking into for serious practical applications.

I do believe that it's important to point out where there is work that needs to be done to meet all the goals that Haskell wants to achieve such that the selling points aren't possibly construed by the audience as disingenuous claims.

Now having said that, this is *not* meant to be a slap in the face of those who want Haskell to be used in a practical way *now*.  I am in fact one of them, having created code that has shipped and will continue to ship (at least until I'm forced to rewrite it... let's hope not) in Haskell in management systems that may, if our plans work out,  be deployed potentially all over the world.

Dave

On Thu, Dec 10, 2009 at 6:50 AM, John D. Earle <[hidden email]> wrote:
David, think of the machine as being the earth and laziness is in the clouds. Strict evaluation is closer to the machine. The relationship between a lazy algorithm and the earth is abstract; hence, it will make creating algorithms especially efficient ones difficult. All of this is still a work in progress. The Haskell creed appears to be, This is the way so stick to it! The idea appears to be that by sticking to the program the problems will be overcome in time and we will be left with all the glorious goodness. At one time it was not possible to achieve the sort of efficiency that Haskell achieves as a matter of course.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Why?

MightyByte
In reply to this post by johndearle
On Thu, Dec 10, 2009 at 9:50 AM, John D. Earle <[hidden email]> wrote:
> in progress. The Haskell creed appears to be, This is the way so stick to
> it! The idea appears to be that by sticking to the program the problems will
> be overcome in time and we will be left with all the glorious goodness. At

I think this is a bit of a misnomer.  My perception of a "Haskell
creed", if there really is one, is something more along the lines of:

"Purity (also laziness, amongst other things) gives us some desirable
properties.  Let's see how far we can go with these ideas and if we
can use them to solve practical problems."

The Haskell community is not trying to shove these ideas down your
throat.  We're just interested in exploring them.  Before monadic I/O
was introduced, the absence of side effects made practical
applications clumsy if not impossible [1].  But the Haskell
researchers persisted.  It just so happens that now the industry seems
to be taking note of what the Haskell community has accomplished with
careful adherence to these ideas.

[1] http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
1234