Sietse Achterop [EMAIL PROTECTED] writes
...
On a general note, should executing a program not always yield a
defined result? That is, either yield the correct result OR produce
an error message?
At least, i think, this will be a good idea to consider the values
like [1..] as the
Double dispatching in Smalltalk model, as I understand it,
goes like this (using Haskell keywords for integers):
Int, being a more primitive type, does not have to know how to
cope with Integer in the situations like this: Int * Integer.
So the method (*) in
Concerning Int vs. Integer:
Wouldn't it be better if Standard Haskell had "save" Int's, that is a version that
simply
would abort the program when encountering a overflow.
This can be implemented without too much of a penalty on the more relevant benchmarks.
And if Int32 and friends from the
Simon PJ writes:
I think we should
- generalise length, splitAt, drop, take, replicate
- generalise toEnum, fromEnum
- leave (!!) alone (arrays must fit in an address space)
I don't know what to do about RealFloat. Sigh
If the goal is to make life easy for beginners (and
Please help me as i'm not able to get a prog. working.
The Qus. is:
Write a predicate sorted :: Ord a = [a] - Bool which returns True if
the elements of the list appear in increasing order Make sure that the
following inefficient sort program works for short lists:--
sortSpecification x = head
At 10:58 +0100 98/09/15, Keith S. Wansbrough wrote:
The binary operations (*), (+) etc are not commutative on
all types, notably Float.
Are you sure you are not mixing up the words "commutative" and
"associative" here?
Hans Aberg
* Email: Hans Aberg mailto:[EMAIL
Bother! Sent this only to Simon...
-- Forwarded message --
From: [EMAIL PROTECTED]
Subject: Re: Int vs Integer
Date: Tue, 15 Sep 1998 18:15:01 +0100 (BST)
To: [EMAIL PROTECTED]
On 15 Sep, Simon Peyton-Jones wrote:
I think there is one powerful argument for retaining the
