# [Haskell-cafe] Re: Why purely in haskell?

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Thu Jan 10 20:42:26 EST 2008

```On Fri, 2008-01-11 at 01:12 +0100, Achim Schneider wrote:
> Tillmann Rendel <rendel at rbg.informatik.tu-darmstadt.de> wrote:
>
> > Achim Schneider wrote:
> > > [1..] == [1..]
> > >
> > > [some discussion about the nontermination of this expression]
> > >
> > > The essence of laziness is to do the least work necessary to cause
> > > the desired effect, which is to see that the set of natural numbers
> > > equals the set of natural numbers, which, axiomatically, is always
> > > computable in O(1) by equality by identity.
> >
> > This would make sense if Haskell had inbuild equality and (==) where
> > part of the formal semantics of Haskell, wich it isn't. (==) is a
> > library function like every other library function. How could the
> > language or a system implementing the language decide wether this or
> > any other library function returns True without actually running it?
> >
> The list instance for Eq might eg. know something about the structure
> of the lists and be smart enough not to get caught in the recursion of x
> = 1:1:x and y = 1:1:1:y so it could successfully compare x == y to
> True in six compares.

So let's imagine:

ones = 1 : ones

ones' = repeat 1
where repeat n = n : repeat n

So you're suggesting that:

ones == ones = True
but
ones' == ones' = _|_

Well if that were the case then  it is distinguishing two equal values
and hence breaking referential transparency. We can fairly trivially
prove that ones and ones' are equal so == is not allowed to distinguish
them. Fortunately it is impossible to write == above, at least using
primitives within the language.

Duncan

```