Why purely in haskell?

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

Why purely in haskell?

YuTeh Shen
I got question about why haskell insist to be a purely FL. I mean is
there any feature which is only support by pure?
I mean maybe the program is much easier to prove? Or maybe we can
cache some value for laziness.
Could anyone give me some more information about why haskell needs to be  pure.

Thanks a lot.

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

Re: Why purely in haskell?

Neil Mitchell
Hi Shen,

> I got question about why haskell insist to be a purely FL. I mean is
> there any feature which is only support by pure?

Laziness. It is very difficult to have a lazy language which is not pure.

Laziness and purity together help with equational reasoning, compiler
transformations, less obscure bugs, better compositionality etc.

Thanks

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

Re: Why purely in haskell?

Achim Schneider
In reply to this post by YuTeh Shen
"Yu-Teh Shen" <[hidden email]> wrote:

> I got question about why haskell insist to be a purely FL. I mean is
> there any feature which is only support by pure?
> I mean maybe the program is much easier to prove? Or maybe we can
> cache some value for laziness.
> Could anyone give me some more information about why haskell needs to
> be  pure.
>
To give a short answer: Because if pureness would be abandoned for easy
implementation of feature X, features Y and Z would become completely
awkward.

The pureness is an ideological design decision basing on the
assumption that pureness is ideal to ensure whole-system consistency.

Most important is referential transparency, its lack of spooky
side-effects and thus making global memoization of evaluation results
feasible.

In fact, the most obvious point really seems to be that

getChar :: Char
cant' be cached, though its type implies it,

while
getChar :: IO Char
enshures that only the _action_ of getting a char can be cached, not the
char itself. (and asking why and how the IO type does that opens a big
can of worms)

It's along the lines of "a value is an unary, static function that
returns a value" vs. "an input function is an unary, dynamic function
that returns a value" and the proper handling of the terms "static" and
"dynamic" in every possible case.

--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.

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

Re: Why purely in haskell?

Dougal Stanton
In reply to this post by YuTeh Shen
On 09/01/2008, Yu-Teh Shen <[hidden email]> wrote:
> I got question about why haskell insist to be a purely FL. I mean is
> there any feature which is only support by pure?

Have a look at the ueber-retrospective on Haskell, fifty-five pages of
all the history and motivation one could possibly want.

<http://research.microsoft.com/~simonpj/papers/history-of-haskell/>

It's interesting reading, I promise! ;-)

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

Re: Why purely in haskell?

Mattias Bengtsson
On Wed, 2008-01-09 at 15:06 +0000, Dougal Stanton wrote:
> Have a look at the ueber-retrospective on Haskell, fifty-five pages of
> all the history and motivation one could possibly want.
>
> <http://research.microsoft.com/~simonpj/papers/history-of-haskell/>
>
> It's interesting reading, I promise! ;-)

I actually think it was a really interesting read when i read it a year
ago or so! :)

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

Re: Why purely in haskell?

Derek Elkins
In reply to this post by Dougal Stanton
On Wed, 2008-01-09 at 15:06 +0000, Dougal Stanton wrote:

> On 09/01/2008, Yu-Teh Shen <[hidden email]> wrote:
> > I got question about why haskell insist to be a purely FL. I mean is
> > there any feature which is only support by pure?
>
> Have a look at the ueber-retrospective on Haskell, fifty-five pages of
> all the history and motivation one could possibly want.
>
> <http://research.microsoft.com/~simonpj/papers/history-of-haskell/>
>
> It's interesting reading, I promise! ;-)

A shorter and lighter and and also interesting and entertaining read is:
http://research.microsoft.com/~simonpj/Papers/haskell-retrospective/index.htm

While the reason Haskell was pure was to support laziness, at this point
though it's safe to say Haskell "insists" on being pure no more than
water "insists" on being wet.

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

Re: Why purely in haskell?

bf3
Derek Elkins wrote:
 > A shorter and lighter and and also interesting and entertaining read is:
 >
http://research.microsoft.com/~simonpj/Papers/haskell-retrospective/index.htm

Just read it, quoting:

`Tony Hoare’s comment: “I fear that Haskell is doomed to succeed”`

LOL! Very good stuff

If Haskell wasn't pure, I would not spent so much time trying to bend my
over-imperative mind to it. I had it with impure languages, way to
tricky. Those languages were nice when I was young & reckless :)

But I'm amazed that impure (albeit strong) languages like LISP and
Scheme are still used for projects... I mean, in Scheme you can "set!"
the addition operator to become a multiplication operator at runtime,
modifying global behavior... Now that's a side effect, C/C++ is nothing
compared to that! So I guess that with such great power comes great
responsibility?

Peter





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

Re: Why purely in haskell?

Anton van Straaten
Peter Verswyvelen wrote:
> But I'm amazed that impure (albeit strong) languages like LISP and
> Scheme are still used for projects... I mean, in Scheme you can "set!"
> the addition operator to become a multiplication operator at runtime,
> modifying global behavior... Now that's a side effect, C/C++ is nothing
> compared to that! So I guess that with such great power comes great
> responsibility?

Scheme and Lisp typically constrain this feature in various ways,
ranging from compiler options and declarations to, more recently,
features of a module system.

For example, in R6RS Scheme, variables and syntax imported via the
module system cannot be mutated, so the denotation of a name (including
names like "+") can be statically determined.

OTOH, the freedom to change things on the fly can be nice to have, and
if used with "great responsibility" (mainly an understanding of what's
safe to do and what isn't), the downside can be vanishingly small.

Anton

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

Re: Why purely in haskell?

Don Stewart-2
anton:
> OTOH, the freedom to change things on the fly can be nice to have, and
> if used with "great responsibility" (mainly an understanding of what's
> safe to do and what isn't), the downside can be vanishingly small.

It can be small, unless you need to have any kind of static assurance
(say for high assurance software, or for new kinds of optimisations, or
if you want to reorder code in the compiler for parallelism).

Then the downside to arbitrary, untracked effects in the system is huge.

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

Re: Why purely in haskell?

Anton van Straaten
Don Stewart wrote:

> anton:
>> OTOH, the freedom to change things on the fly can be nice to have, and
>> if used with "great responsibility" (mainly an understanding of what's
>> safe to do and what isn't), the downside can be vanishingly small.
>
> It can be small, unless you need to have any kind of static assurance
> (say for high assurance software, or for new kinds of optimisations, or
> if you want to reorder code in the compiler for parallelism).
>
> Then the downside to arbitrary, untracked effects in the system is huge.

Oh dear - I'm going to have to rethink the paper I was working on,
provisionally titled "In defense of arbitrary untracked effects in high
assurance software."  ;)

But by "can be vanishingly small", I definitely meant something like "in
cases where it's technically and economically appropriate".

Anton

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

Re: Why purely in haskell?

David Roundy-5
In reply to this post by Don Stewart-2
On Jan 9, 2008 4:21 PM, Don Stewart <[hidden email]> wrote:

> anton:
> > OTOH, the freedom to change things on the fly can be nice to have, and
> > if used with "great responsibility" (mainly an understanding of what's
> > safe to do and what isn't), the downside can be vanishingly small.
>
> It can be small, unless you need to have any kind of static assurance
> (say for high assurance software, or for new kinds of optimisations, or
> if you want to reorder code in the compiler for parallelism).
>
> Then the downside to arbitrary, untracked effects in the system is huge.

I just want to point out that unsafePerformIO is at the core of the
(safe) bytestring library.  As SPJ et al pointed out, this is crucial
functionality, and is only unsafe if unsafely used.  (Yes, it's
unsafe, but you can write a safe module with a purely safe interface
that uses unsafePerformIO in its core.)

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

Re: Why purely in haskell?

Henning Thielemann

On Wed, 9 Jan 2008, David Roundy wrote:

> On Jan 9, 2008 4:21 PM, Don Stewart <[hidden email]> wrote:
> > anton:
> > > OTOH, the freedom to change things on the fly can be nice to have, and
> > > if used with "great responsibility" (mainly an understanding of what's
> > > safe to do and what isn't), the downside can be vanishingly small.
> >
> > It can be small, unless you need to have any kind of static assurance
> > (say for high assurance software, or for new kinds of optimisations, or
> > if you want to reorder code in the compiler for parallelism).
> >
> > Then the downside to arbitrary, untracked effects in the system is huge.
>
> I just want to point out that unsafePerformIO is at the core of the
> (safe) bytestring library.  As SPJ et al pointed out, this is crucial
> functionality, and is only unsafe if unsafely used.

Indeed, there are hacks and they are some times necessary. The good thing
about Haskell is, that hacks look like hacks.

In Modula-3 modules using hacks must be explicitly marked as UNSAFE. See
  http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
 Maybe this is also an option for Haskell?

Wouldn't this also simplify
  http://www.haskell.org/haskellwiki/Safely_running_untrusted_Haskell_code
 ?
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Why purely in haskell?

Don Stewart-2
In reply to this post by Anton van Straaten
anton:

> Don Stewart wrote:
> >anton:
> >>OTOH, the freedom to change things on the fly can be nice to have, and
> >>if used with "great responsibility" (mainly an understanding of what's
> >>safe to do and what isn't), the downside can be vanishingly small.
> >
> >It can be small, unless you need to have any kind of static assurance
> >(say for high assurance software, or for new kinds of optimisations, or
> >if you want to reorder code in the compiler for parallelism).
> >
> >Then the downside to arbitrary, untracked effects in the system is huge.
>
> Oh dear - I'm going to have to rethink the paper I was working on,
> provisionally titled "In defense of arbitrary untracked effects in high
> assurance software."  ;)

That would be an awesome paper :)

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

Re: Why purely in haskell?

Graham Fawcett
On Jan 9, 2008 6:20 PM, Don Stewart <[hidden email]> wrote:
> anton:
> > Oh dear - I'm going to have to rethink the paper I was working on,
> > provisionally titled "In defense of arbitrary untracked effects in high
> > assurance software."  ;)
>
> That would be an awesome paper :)

Hear, hear!

Anton, if you're looking for a co-author, and you're willing to tackle
the high-assurance parts, I have years of experience with arbitrary
untracked effects. ;-)

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

Re: Why purely in haskell?

Niko Korhonen
In reply to this post by Neil Mitchell
Neil Mitchell wrote:
> Laziness and purity together help with equational reasoning, compiler
> transformations, less obscure bugs, better compositionality etc.

Although it could be argued that laziness is the cause of some very
obscure bugs... <g>

Niko


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

Re: Why purely in haskell?

jerzy.karczmarczuk
Niko Korhonen writes:

...
> Although it could be argued that laziness is the cause of some very
> obscure bugs... <g>
> Niko

Example, PLEASE.

Jerzy Karczmarczuk


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

Re: Why purely in haskell?

Achim Schneider
[hidden email] wrote:

> Niko Korhonen writes:
>
> ...
> > Although it could be argued that laziness is the cause of some very
> > obscure bugs... <g>
> > Niko
>
> Example, PLEASE.
>
[1..] == [1..]

, for assumed operational semantics of ones own axiomatic semantics.
Bugs are only a misunderstanding away.


--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.

_______________________________________________
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 purely in haskell?

Daniel Yokomizo
On Jan 10, 2008 3:36 PM, Achim Schneider <[hidden email]> wrote:

> [hidden email] wrote:
>
> > Niko Korhonen writes:
> >
> > ...
> > > Although it could be argued that laziness is the cause of some very
> > > obscure bugs... <g>
> > > Niko
> >
> > Example, PLEASE.
> >
> [1..] == [1..]
>
> , for assumed operational semantics of ones own axiomatic semantics.
> Bugs are only a misunderstanding away.

It has nothing to do with laziness, but with using an algebraic
function (==) with a codata structure (stream). If Haskell kept
laziness but enforced separation of data and codata such code wouldn't
compile. Lazy lists or streams never are a problem, but you can't
(generically) fold codata.

> --
> (c) this sig last receiving data processing entity. Inspect headers for
> past copyright information. All rights reserved. Unauthorised copying,
> hiring, renting, public performance and/or broadcasting of this
> signature prohibited.

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

Re: Why purely in haskell?

Achim Schneider
"Daniel Yokomizo" <[hidden email]> wrote:

> On Jan 10, 2008 3:36 PM, Achim Schneider <[hidden email]> wrote:
> > [hidden email] wrote:
> >
> > > Niko Korhonen writes:
> > >
> > > ...
> > > > Although it could be argued that laziness is the cause of some
> > > > very obscure bugs... <g>
> > > > Niko
> > >
> > > Example, PLEASE.
> > >
> > [1..] == [1..]
> >
> > , for assumed operational semantics of ones own axiomatic semantics.
> > Bugs are only a misunderstanding away.
>
> It has nothing to do with laziness, but with using an algebraic
> function (==) with a codata structure (stream). If Haskell kept
> laziness but enforced separation of data and codata such code wouldn't
> compile. Lazy lists or streams never are a problem, but you can't
> (generically) fold codata.
>
Exactly. Denotationally it hasn't, but axiomatically it has. Because it
looks like mathematical terms one can easily get lost in believing it
reduces like mathematics, too.

--
(c) this sig last receiving data processing entity. Inspect headers for
past copyright information. All rights reserved. Unauthorised copying,
hiring, renting, public performance and/or broadcasting of this
signature prohibited.

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

Re: Why purely in haskell?

David Roundy-5
In reply to this post by Henning Thielemann
On Jan 9, 2008 5:42 PM, Henning Thielemann
<[hidden email]> wrote:

> > I just want to point out that unsafePerformIO is at the core of the
> > (safe) bytestring library.  As SPJ et al pointed out, this is crucial
> > functionality, and is only unsafe if unsafely used.
>
> Indeed, there are hacks and they are some times necessary. The good thing
> about Haskell is, that hacks look like hacks.
>
> In Modula-3 modules using hacks must be explicitly marked as UNSAFE. See
>   http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
>  Maybe this is also an option for Haskell?

I don't think this is a good idea.  It comes down to a question of
whether you think it should be allowed for Haskell code to be used to
write core Haskell libraries in a first-class manner.  Perhaps you
think libraries should always be in C in order to avoid the use of
unsafePerformIO, but I prefer to allow them to be written in Haskell.

But then, I don't see unsafePerformIO as inherently a hack.  It's the
only possible way that certain useful abstractions can be
impelemented--at least, that's understanding.  I'd be curious as to
how much of the Prelude would be marked unsafe if you had your wish...

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