bang patterns and deepseq

[Jonathan Gallagher]

Greetings,

I am trying to understand how strictness works in Haskell. Here is
the story, along with a description of where it unravels.

I want to define a function that computes the nth and n+1st Fibonacci
number. There will be recursive calls made.
fib n =
...
(a,b) = fib k
...

The question I have is: should one use deepseq (or seq, or something
like it) to force an evaluation of the value of the recursion or
should one use a bang pattern

fib !n =
...

or should one do nothing at all?

[Roman W]

If you don't care about the stack blowing up, you don't have to do anything.

RW

[blufox]

Hello,
Is Ord Typeclass strictly required to have a Total Ordering defined? Or
is it enough for me to define `compare` between all members of the data
declaration? Is there any ill effects to not having a total ordering?
except that things like maximum may not work?


Regards,
blufox

[blufox]

Sorry for hijacking the old thread, I am new to newsgroups, and didn't
realize that my reply would come as a part of the older thread even if
the subject was changed.

[Dirk Thierbach]

blufox <blu...@gmail.com> wrote:
> Is Ord Typeclass strictly required to have a Total Ordering defined?

The Haskell 98 report says: "The Ord class is used for totally ordered
datatypes."

> Or is it enough for me to define `compare` between all members of
> the data declaration? Is there any ill effects to not having a total
> ordering? except that things like maximum may not work?

Well, there are many functions using Ord that expect a total order,
not only "maximum". If you don't count this as "ill effect", then I
guess there are no "ill effects". :-)

It would probably still make a lot more sense to define your own
typeclass for a partial order. Saves you from surprises.

- Dirk

[Nobody]

The only *requirement* for membership is that the necessary functions are
provided with the correct type signature. Haskell has no way to enforce
(or even specify) a "contract" such as total ordering.

Functions which operate upon members of a class may not behave correctly
if any documented contract is violated, but that would be a direct
consequence of the way that the function is written, not because the
compiler is relying upon functions conforming to a contract.

Type classes are fundamentally about the type system. They provide a
middle ground between a concrete type and an unconstrained type variable.
Without them, it would be impossible to write e.g.:

max :: (Ord a) => a -> a -> a
max x y = if x > y then x else y

If "a" was unconstrained, ">" would have to be defined for any type.
Alternatively, you'd need a separate "max" function for each type, which
in turn would require a separate ">" function for each type.