[Caml-list] Purity and lazyness

[Caml-list] Purity and lazyness

[Dario Teixeira]

Hi,

I have a question which though not strictly Ocaml-centric, I reckon is
not completely off-topic for this list.

In presentations by Haskellers, lazyness and purity are often portrayed as
going hand in hand.  Now, I can see why a language which is lazy by default
would also need to be pure, since side-effects would be indeed very messy 
if evaluation order is not predictable.  However, I cannot see the converse,
that is, I don't see why purity would require lazyness. 

So, my question is whether there is something I'm missing and in fact "purity 
<=> lazyness", or I am reading too much from those Haskeller presentations,
because they never meant to say anything beyond "lazyness => purity", and
freely mixing the two was just a casual oversight.

Your thoughts?
Best regards,
Dario Teixeira



      

Re: [Caml-list] Purity and lazyness

[Damien Doligez]

On 2011-01-07, at 16:35, Dario Teixeira wrote:

> So, my question is whether there is something I'm missing and in fact "purity 
> <=> lazyness", or I am reading too much from those Haskeller presentations,
> because they never meant to say anything beyond "lazyness => purity", and
> freely mixing the two was just a casual oversight.


For an example of a pure non-lazy language, have a look at Erlang.

-- Damien

Re: [Caml-list] Purity and lazyness

[David Rajchenbach-Teller]

Correct me if I'm wrong, but I wouldn't classify Erlang as "pure": sending and receiving messages -- which are two of the most important primitives in Erlang -- are definitely side-effects.
Also, asynchronous error-checking, Mnesia, etc. look quite impure to me.

I also vaguely remember Simon Peyton-Jones declaring something along the lines of "The next Haskell will be strict".

Cheers,
 David

On Jan 7, 2011, at 5:07 PM, Damien Doligez wrote:

> 
> On 2011-01-07, at 16:35, Dario Teixeira wrote:
> 
>> So, my question is whether there is something I'm missing and in fact "purity 
>> <=> lazyness", or I am reading too much from those Haskeller presentations,
>> because they never meant to say anything beyond "lazyness => purity", and
>> freely mixing the two was just a casual oversight.
> 
> 
> For an example of a pure non-lazy language, have a look at Erlang.
> 
> -- Damien

Re: [Caml-list] Purity and lazyness

[Holger Weiß]

* David Rajchenbach-Teller <David.Teller@univ-orleans.fr> [2011-01-07 17:38]:
> Correct me if I'm wrong, but I wouldn't classify Erlang as "pure":
> sending and receiving messages -- which are two of the most important
> primitives in Erlang -- are definitely side-effects.
> Also, asynchronous error-checking, Mnesia, etc. look quite impure to me.

Indeed.  Erlang uses single assignment, but it doesn't enforce
referential transparency.

> I also vaguely remember Simon Peyton-Jones declaring something along the
> lines of "The next Haskell will be strict".

Not really:

| Any successor language [to Haskell] will have support for both strict and lazy
| functions.  So the question then is: what's the default, and how easy is it to
| get to these things?  How do you mix them together?  So it isn't kind of a
| completely either/or situation any more.  But on balance yes, I'm definitely
| very happy with using the lazy approach, as that's what made Haskell what it is
| and kept it pure.

[ http://www.techworld.com.au/article/261007/a-z_programming_languages_haskell/?pp=7 ]

Holger

Re: [Caml-list] Purity and lazyness

[Eray Ozkural]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]

On Fri, Jan 7, 2011 at 6:38 PM, David Rajchenbach-Teller <
David.Teller@univ-orleans.fr> wrote:

> Correct me if I'm wrong, but I wouldn't classify Erlang as "pure": sending
> and receiving messages -- which are two of the most important primitives in
> Erlang -- are definitely side-effects.
> Also, asynchronous error-checking, Mnesia, etc. look quite impure to me.
>
> I also vaguely remember Simon Peyton-Jones declaring something along the
> lines of "The next Haskell will be strict".
>
>
There was a strict compiler for Haskell, whatever happened to it? Most times
I found it cumbersome to deal with the performance effects of default
laziness.

Best,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

[-- Attachment #2: Type: text/html, Size: 1322 bytes --]

Re: [Caml-list] Purity and lazyness

[orbitz]

I believe you are thinking of 'Timber'?


On Jan 7, 2011, at 3:22 PM, Eray Ozkural wrote:

> On Fri, Jan 7, 2011 at 6:38 PM, David Rajchenbach-Teller <David.Teller@univ-orleans.fr 
> > wrote:
> Correct me if I'm wrong, but I wouldn't classify Erlang as "pure":  
> sending and receiving messages -- which are two of the most  
> important primitives in Erlang -- are definitely side-effects.
> Also, asynchronous error-checking, Mnesia, etc. look quite impure to  
> me.
>
> I also vaguely remember Simon Peyton-Jones declaring something along  
> the lines of "The next Haskell will be strict".
>
>
> There was a strict compiler for Haskell, whatever happened to it?  
> Most times I found it cumbersome to deal with the performance  
> effects of default laziness.
>
> Best,
>
> -- 
> Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University,  
> Ankara
> http://groups.yahoo.com/group/ai-philosophy
> http://myspace.com/arizanesil http://myspace.com/malfunct
>

Re: [Caml-list] Purity and lazyness

[Joel Reymont]

Isn't there Clean as well?

On Jan 7, 2011, at 8:29 PM, orbitz@ezabel.com wrote:

> I believe you are thinking of 'Timber'?

---
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont

Re: [Caml-list] Purity and lazyness

[Eray Ozkural]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

No, I don't think so.

I think these:
http://csg.csail.mit.edu/pubs/haskell.html
http://csg.csail.mit.edu/projects/languages/ph.shtml

What a cool research group, combines two of my research interests as well :)

Best,

On Fri, Jan 7, 2011 at 10:29 PM, <orbitz@ezabel.com> wrote:

> I believe you are thinking of 'Timber'?
>
>
>
> On Jan 7, 2011, at 3:22 PM, Eray Ozkural wrote:
>
>  On Fri, Jan 7, 2011 at 6:38 PM, David Rajchenbach-Teller <
>> David.Teller@univ-orleans.fr> wrote:
>> Correct me if I'm wrong, but I wouldn't classify Erlang as "pure": sending
>> and receiving messages -- which are two of the most important primitives in
>> Erlang -- are definitely side-effects.
>> Also, asynchronous error-checking, Mnesia, etc. look quite impure to me.
>>
>> I also vaguely remember Simon Peyton-Jones declaring something along the
>> lines of "The next Haskell will be strict".
>>
>>
>> There was a strict compiler for Haskell, whatever happened to it? Most
>> times I found it cumbersome to deal with the performance effects of default
>> laziness.
>>
>> Best,
>>
>> --
>> Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
>> http://groups.yahoo.com/group/ai-philosophy
>> http://myspace.com/arizanesil http://myspace.com/malfunct
>>
>>
>


-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

[-- Attachment #2: Type: text/html, Size: 2590 bytes --]

Re: [Caml-list] Purity and lazyness

[Jesper Louis Andersen]

On Fri, Jan 7, 2011 at 17:38, David Rajchenbach-Teller
<David.Teller@univ-orleans.fr> wrote:
> Correct me if I'm wrong, but I wouldn't classify Erlang as "pure": sending and receiving messages -- which are two of the most important primitives in Erlang -- are definitely side-effects.
> Also, asynchronous error-checking, Mnesia, etc. look quite impure to me.

Right.

Erlang with only the sequential primitives present is not pure either.
There is a process_dictionary which is essentially a state for the
process. Erlang programmers tend to avoid it, but it is used by some
of the standard libraries. Keeping random seed state for instance. If
you remove the process dictionary, then there is ETS, the erlang term
storage (in use as the backend for mnesia). ETS is not pure either, it
is essentially a finite map from erlang terms to erlang terms. Ok,
strip out ETS. Then we have exceptions :) Exceptions are, to the best
of my knowledge, yet another computational effect.

And then there are all the concurrency primitives...

-- 
J.

Re: [Caml-list] Purity and lazyness

[Alain Frisch]

On 01/07/2011 04:35 PM, Dario Teixeira wrote:
> that is, I don't see why purity would require lazyness.

I'd say that while purity certainly does not require laziness, they are 
a natural match: purity can benefit from laziness as an alternative to 
mutability in some situations.

For instance, you cannot do memoization of unary functions like you 
would do in OCaml, using a mutable datastructure as a cache. You can 
pass this cache around or use a monad to maintain it, but using laziness 
gives a natural alternative: extend the object data structure itself 
with an extra slot to hold the result of the function to be memoized and 
you want this extra slot to be computed lazily.



Alain

Re: [Caml-list] Purity and lazyness

[Christophe Raffalli]

[-- Attachment #1.1: Type: text/plain, Size: 1181 bytes --]

Le 07/01/11 18:21, Alain Frisch a écrit :
> On 01/07/2011 04:35 PM, Dario Teixeira wrote:
>> that is, I don't see why purity would require lazyness.
lazyness implies eta equivalence :
  (fun x -> f x) is not observationally equivalent to f in a strict
language.

I don't think this is a major problem of strict language over lazy ones
... Especially
compared to the problem of complexity prediction which is harder in lazy
languages ...

And by the way : PML is strict, pure with exceptions ... And I consider
exceptions to be pure because they enjoy reference transparency ... But
the PML compiler is not yet there ...

Cheers,
Christophe
 

-- 
Christophe Raffalli
Universite de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tel: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution 
can check this signature. The public key is
stored on www.keyserver.net
---------------------------------------------


[-- Attachment #1.2: Christophe_Raffalli.vcf --]
[-- Type: text/x-vcard, Size: 310 bytes --]

begin:vcard
fn:Christophe Raffalli
n:Raffalli;Christophe
org:LAMA (UMR 5127)
email;internet:christophe.raffalli@univ-savoie.fr
title;quoted-printable:Ma=C3=AEtre de conf=C3=A9rences
tel;work:+33 4 79 75 81 03
note:http://www.lama.univ-savoie.fr/~raffalli
x-mozilla-html:TRUE
version:2.1
end:vcard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Caml-list] Purity and lazyness

[Holger Weiß]

* Dario Teixeira <darioteixeira@yahoo.com> [2011-01-07 07:35]:
> In presentations by Haskellers, lazyness and purity are often portrayed as
> going hand in hand.  Now, I can see why a language which is lazy by default
> would also need to be pure, since side-effects would be indeed very messy 
> if evaluation order is not predictable.  However, I cannot see the converse,
> that is, I don't see why purity would require lazyness. 
> 
> So, my question is whether there is something I'm missing and in fact "purity 
> <=> lazyness", or I am reading too much from those Haskeller presentations,
> because they never meant to say anything beyond "lazyness => purity", and
> freely mixing the two was just a casual oversight.

Simon Peyton-Jones argues like this:

| Because Haskell is lazy it meant that we were much more consistent about
| keeping the language pure.  You could have a pure, strict, call by value
| language, but no one has managed to do that because the moment you have
| a strict call by value language, the temptation to add impurities (side
| effects) is overwhelming.  So "laziness kept us pure" is the slogan!

[ http://www.techworld.com.au/article/261007/a-z_programming_languages_haskell/?pp=7 ]

Holger

Re: [Caml-list] Purity and lazyness

[Brian Hurt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 968 bytes --]



On Fri, 7 Jan 2011, Holger Weiß wrote:

> Simon Peyton-Jones argues like this:
>
> | Because Haskell is lazy it meant that we were much more consistent about
> | keeping the language pure.  You could have a pure, strict, call by value
> | language, but no one has managed to do that because the moment you have
> | a strict call by value language, the temptation to add impurities (side
> | effects) is overwhelming.  So "laziness kept us pure" is the slogan!
>
> [ http://www.techworld.com.au/article/261007/a-z_programming_languages_haskell/?pp=7 ]
>

Unless there is some other driver to keep things pure even while being 
strict.  And I would argue there is- concurrency.  Concurrency has a lot 
of similarities with laziness, in that the ordering of computations can be 
(and often is) undefined, with all the fun that entails.  Haskell is 
really good at multithreaded because it has already "paid the price" of 
dealing with asynchronous computations.

Brian

Re: [Caml-list] Purity and lazyness

[Petter Urkedal]

On 2011-01-07, Brian Hurt wrote:
> 
> 
> On Fri, 7 Jan 2011, Holger Weiß wrote:
> 
> > Simon Peyton-Jones argues like this:
> >
> > | Because Haskell is lazy it meant that we were much more consistent about
> > | keeping the language pure.  You could have a pure, strict, call by value
> > | language, but no one has managed to do that because the moment you have
> > | a strict call by value language, the temptation to add impurities (side
> > | effects) is overwhelming.  So "laziness kept us pure" is the slogan!
> >
> > [ http://www.techworld.com.au/article/261007/a-z_programming_languages_haskell/?pp=7 ]
> >
> 
> Unless there is some other driver to keep things pure even while being 
> strict.  And I would argue there is- concurrency.  Concurrency has a lot 
> of similarities with laziness, in that the ordering of computations can be 
> (and often is) undefined, with all the fun that entails.  Haskell is 
> really good at multithreaded because it has already "paid the price" of 
> dealing with asynchronous computations.

And on the more theoretical side, strictness in not sufficient to make
impurity sound in ML, since the let-polymorphism must also be
restricted, e.g. with the value-restriction.

Re: [Caml-list] Purity and lazyness

[Eray Ozkural]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

On Fri, Jan 7, 2011 at 8:52 PM, Brian Hurt <bhurt@spnz.org> wrote:

>
>
> On Fri, 7 Jan 2011, Holger Weiß wrote:
>
>  Simon Peyton-Jones argues like this:
>>
>> | Because Haskell is lazy it meant that we were much more consistent about
>> | keeping the language pure.  You could have a pure, strict, call by value
>> | language, but no one has managed to do that because the moment you have
>> | a strict call by value language, the temptation to add impurities (side
>> | effects) is overwhelming.  So "laziness kept us pure" is the slogan!
>>
>> [
>> http://www.techworld.com.au/article/261007/a-z_programming_languages_haskell/?pp=7]
>>
>>
> Unless there is some other driver to keep things pure even while being
> strict.  And I would argue there is- concurrency.  Concurrency has a lot of
> similarities with laziness, in that the ordering of computations can be (and
> often is) undefined, with all the fun that entails.  Haskell is really good
> at multithreaded because it has already "paid the price" of dealing with
> asynchronous computations.


Seconded. And probably more advanced compilers could make better decisions
at optimizing parallel execution.

Best,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

[-- Attachment #2: Type: text/html, Size: 2089 bytes --]

RE: [Caml-list] Purity and lazyness

[Jon Harrop]

Brian Hurt wrote:
> Unless there is some other driver to keep things pure even while being
> strict.  And I would argue there is- concurrency.  Concurrency has a
> lot
> of similarities with laziness, in that the ordering of computations can
> be
> (and often is) undefined, with all the fun that entails.  Haskell is
> really good at multithreaded because it has already "paid the price" of
> dealing with asynchronous computations.

I agree except for "Haskell is really good at multithreaded" because, space
leaks aside, getting Haskell to force lazy computations at the necessary
times to take advantage of multithreading is usually a nightmare.

Cheers,
Jon.

Re: [Caml-list] Purity and lazyness

[Eray Ozkural]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

On Sun, Jan 9, 2011 at 6:11 PM, Jon Harrop <
jonathandeanharrop@googlemail.com> wrote:

> Brian Hurt wrote:
> > Unless there is some other driver to keep things pure even while being
> > strict.  And I would argue there is- concurrency.  Concurrency has a
> > lot
> > of similarities with laziness, in that the ordering of computations can
> > be
> > (and often is) undefined, with all the fun that entails.  Haskell is
> > really good at multithreaded because it has already "paid the price" of
> > dealing with asynchronous computations.
>
> I agree except for "Haskell is really good at multithreaded" because, space
> leaks aside, getting Haskell to force lazy computations at the necessary
> times to take advantage of multithreading is usually a nightmare.
>
>
I think the lesson to learn there is that there is no simple evaluation
strategy
that is good for all architectures.

Best,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

[-- Attachment #2: Type: text/html, Size: 1640 bytes --]

Re: [Caml-list] Purity and lazyness

[Florian Weimer]

* Dario Teixeira:

> So, my question is whether there is something I'm missing and in fact "purity 
> <=> lazyness", or I am reading too much from those Haskeller presentations,
> because they never meant to say anything beyond "lazyness => purity", and
> freely mixing the two was just a casual oversight.

As specified, Haskell is not a pure language because every pattern
match can have side effects.  The Haskell community is split between
those who think that this is a good thing, and those that consider it
problematic.  (Obviously, there is a large pure subset, much more
useful than Erlang's pure subset and covering almost the whole
language; you just avoid lazy I/O and use unsafePerformIO only for
correcting the type of functions imported through FFI.)

In my very limited experience, there are two kinds of laziness:
essential laziness and laziness for presentation purposes.

Essential laziness occurs when you construct values which would not
otherwise be possible to construct in a pure language.  For instance,
if you have got some sort of compiler, at one point, you might want to
perform name resolution.  At that point, you want to translate names
(references) to the program entities they denote (referents).  In
general, these references do not form a tree (for instance, a function
body can refer to another function by name, which refers to the
original function).  With laziness, you can compute a map from names
to entities, and the entities use this maps to resolve the names they
use as references.  Name lookup is only performed once per name.
Without laziness, you have to perform name lookup each time you follow
a reference because the self-referential nature of the data structure
cannot be reflected in the program.

The other type of laziness occurs when you write programs which work
on large (perhaps even infinite) data structures, and carefully look
only at the parts you need.  This can lead to notationally elegant
programs, but you have to be extremely careful not to keep references
to parts you no longer need, otherwise your program will require too
much memory (the live set might even be unbounded).  Space retention
behavior is quite implementation-dependent, too.

It bothers me a bit that you cannot tell the first form from second
just by looking at the types.  You just don't know if the data
structure is bounded or not.

[Caml-list] Purity and lazyness

[bluestorm]

[-- Attachment #1: Type: text/plain, Size: 3385 bytes --]

On Fri, Jan 7, 2011 at 8:17 PM, Florian Weimer <fw@deneb.enyo.de> wrote:

> Essential laziness occurs when you construct values which would not
> otherwise be possible to construct in a pure language.  For instance,
> if you have got some sort of compiler, at one point, you might want to
> perform name resolution.  At that point, you want to translate names
> (references) to the program entities they denote (referents).  In
> general, these references do not form a tree (for instance, a function
> body can refer to another function by name, which refers to the
> original function).  With laziness, you can compute a map from names
> to entities, and the entities use this maps to resolve the names they
> use as references.  Name lookup is only performed once per name.
> Without laziness, you have to perform name lookup each time you follow
> a reference because the self-referential nature of the data structure
> cannot be reflected in the program.
>

I'm not convinced by your example. You need lazyness because you want to
build a cyclic data structure. But is this such a good idea ? In my
experience, implicit cyclicity often raises more problems than it solves,
and it is much safer to use an explicit indirection layer.

In your example, the resolved identifiers could contain not the declaration
code itself, but a unique key that is associated to those declaration sites.
This can be done easily, with only one traversal. Then in a second pass you
can record the mapping of keys to resolved declaration sites, and therefore
tie the knot.

Below is a simple code example:

  type unique_loc = int
  type name = string

  (* a simple language with identifiers and mutually recursive definitions
*)
  type 'a term =
    | Name of 'a
    | Lets of ((name * unique_loc) * 'a term) list * 'a term

  (* unique_loc are supposed to be unique, names are not due to
     shadowing. In a source program, a identifier points to a name,
     which is ambiguous. To resolve it means to turn all such names into
     the unique identifiers corresponding to the binding declaration
  *)
  type input_term = name term
  type resolved_term = unique_loc term

  let resolve : input_term -> resolved_term =
    let rec resolve (env : (name * unique_loc) list) = function
      | Name n -> Name (List.assoc n env)
      | Lets (decls, body) ->
        let env' = List.map fst decls @ env in
        let resolve_decl (binder, code) =
          binder, resolve env' code in
        Lets (List.map resolve_decl decls, resolve env' body)
    in resolve []

  (* we can easily build a table that, to each unique location,
     associates the declaration code; during further analysis, this may
     allow some handling of identifiers based on the expression they
     denote. *)
  let rec resolution_table : resolved_term -> (unique_loc * resolved_term)
list =
    function
      | Name _ -> []
      | Lets (decls, body) ->
        let decl_table ((_, loc), code) =
          (loc, code) :: resolution_table code in
        resolution_table body @ List.concat (List.map decl_table decls)

  (* if you want to test *)
  let input : input_term =
    Lets ([
      ("x", 1), Name "y";
      ("y", 2), Name "x";
      ("z", 3),
        Lets ([
          ("a", 4), Name "x";
          ("b", 5), Name "y";
        ], Name "z");
    ],
      Lets (
        [("x", 6), Name "x"],
        Name "z"))

[-- Attachment #2: Type: text/html, Size: 4747 bytes --]

RE: [Caml-list] Purity and lazyness

[Jon Harrop]

Bluestorm wrote:
> You need lazyness because you want to build a cyclic data structure.
> But is this such a good idea? In my experience, implicit cyclicity
> often raises more problems than it solves, and it is much safer to
> use an explicit indirection layer.

Don't closures often end up forming cyclic data structures on the heap that
are a good idea and don't cause problems?

Cheers,
Jon.

Re: [Caml-list] Purity and lazyness

[Elias Gabriel Amaral da Silva]

2011/1/7 Florian Weimer <fw@deneb.enyo.de>:
> * Dario Teixeira:
>
>> So, my question is whether there is something I'm missing and in fact "purity
>> <=> lazyness", or I am reading too much from those Haskeller presentations,
>> because they never meant to say anything beyond "lazyness => purity", and
>> freely mixing the two was just a casual oversight.
>
> As specified, Haskell is not a pure language because every pattern
> match can have side effects.  The Haskell community is split between
> those who think that this is a good thing, and those that consider it
> problematic.  (Obviously, there is a large pure subset, much more
> useful than Erlang's pure subset and covering almost the whole
> language; you just avoid lazy I/O and use unsafePerformIO only for
> correcting the type of functions imported through FFI.)

Wait, a pattern match can have side effects? Can you provide some
example code? (do you mean, pattern match failure / exceptions / run
time errors?)

I'm new to Haskell, but in my understanding, it is said that Haskell
is pure because the whole Haskell code is just specification of
(types, .. and) values, and this specification is enjoy referential
transparency.

One defines "main" to hold a certain value, which describe the
computations that will performed at run time; but main is defined
using compositions that preserve referential transparency (a >>= b has
value a that depends only on a and b; and in general, f a b .. has a
value that depends only on f, a, b, ..; I know no exception for this)

Re: [Caml-list] Purity and lazyness

[Christophe Raffalli]

[-- Attachment #1.1: Type: text/plain, Size: 1825 bytes --]


> Wait, a pattern match can have side effects? Can you provide some
> example code? (do you mean, pattern match failure / exceptions / run
> time errors?)
>
> I'm new to Haskell, but in my understanding, it is said that Haskell
> is pure because the whole Haskell code is just specification of
> (types, .. and) values, and this specification is enjoy referential
> transparency.
There are two definition of "pure".

1°) a purely functional language without any side effect (no exception
or error)
Haskell do have partial match allowed, producing a "bottom" value and it
also have non terminating program. For this definition, I think there
are no pure language except may be languages used in theorem prover
where totality is a requirement.

2°) enjoying referential transparency but alowwing side effects in a
controlled way : you can list all possible side effects and have good
way to predict them (the compiler warns you that side effect are possible).

Actually very few language implement a termination checker to warn you
about possible non terminating recursive definition in your code ...
This means that currently non termination is not really considered as a
side effect which allows to say that haskell is "pure" for the second
definition.

Cheers,
Christophe

-- 
Christophe Raffalli
Universite de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tel: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution 
can check this signature. The public key is
stored on www.keyserver.net
---------------------------------------------


[-- Attachment #1.2: Christophe_Raffalli.vcf --]
[-- Type: text/x-vcard, Size: 310 bytes --]

begin:vcard
fn:Christophe Raffalli
n:Raffalli;Christophe
org:LAMA (UMR 5127)
email;internet:christophe.raffalli@univ-savoie.fr
title;quoted-printable:Ma=C3=AEtre de conf=C3=A9rences
tel;work:+33 4 79 75 81 03
note:http://www.lama.univ-savoie.fr/~raffalli
x-mozilla-html:TRUE
version:2.1
end:vcard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Caml-list] Purity and lazyness

[Florian Weimer]

* Elias Gabriel Amaral da Silva:

>> As specified, Haskell is not a pure language because every pattern
>> match can have side effects.  The Haskell community is split between
>> those who think that this is a good thing, and those that consider it
>> problematic.  (Obviously, there is a large pure subset, much more
>> useful than Erlang's pure subset and covering almost the whole
>> language; you just avoid lazy I/O and use unsafePerformIO only for
>> correcting the type of functions imported through FFI.)
>
> Wait, a pattern match can have side effects? Can you provide some
> example code? (do you mean, pattern match failure / exceptions / run
> time errors?)

<http://article.gmane.org/gmane.comp.lang.haskell.prime/3083>

It uses seq instead of pattern matches for clarity.  But laziness
means that you could hide the side effect in any pattern match
whatsoever.

> I'm new to Haskell, but in my understanding, it is said that Haskell
> is pure because the whole Haskell code is just specification of
> (types, .. and) values, and this specification is enjoy referential
> transparency.

A small part of the standard library pretends that some externally
visible effects are not impure.  Other programmers follow that style.
In their code bases, you will occasionally see commits which add
additional laziness to avoid blocking on network input (when the
client will never send data because the protocol is half-duplex) or to
avoid reading too much data from disk.

Re: [Caml-list] Purity and lazyness

[Petter Urkedal]

On 2011-01-08, Florian Weimer wrote:
> * Elias Gabriel Amaral da Silva:
> 
> >> As specified, Haskell is not a pure language because every pattern
> >> match can have side effects.  The Haskell community is split between
> >> those who think that this is a good thing, and those that consider it
> >> problematic.  (Obviously, there is a large pure subset, much more
> >> useful than Erlang's pure subset and covering almost the whole
> >> language; you just avoid lazy I/O and use unsafePerformIO only for
> >> correcting the type of functions imported through FFI.)
> >
> > Wait, a pattern match can have side effects? Can you provide some
> > example code? (do you mean, pattern match failure / exceptions / run
> > time errors?)
> 
> <http://article.gmane.org/gmane.comp.lang.haskell.prime/3083>
> 
> It uses seq instead of pattern matches for clarity.  But laziness
> means that you could hide the side effect in any pattern match
> whatsoever.

Do you mean that pattern matching could be used instead of seq in this
example?  But the example is do demonstrate that hGetContents has side
effects, whereas seq is only used to force two different evaluation
orders.

IIUC, the issue with pattern matching is that it may throw an exception,
and exceptions are impure because *if* and *where* they are thrown is
hard to predict, and may affect the outcome of a program witch tries to
catch it.

My experience with Haskell is limited, but I suspect a pattern matching
failure is to be considered a bug, and that the exception mechanism
doubles as a software diagnostic system, like in many languages.  That
is, a program should not try to catch those exceptions, except at the
for bug-reporting and recovery purposes.  From this point of view,
shouldn't a pattern match be considered pure in a bug-free program?