Re: Int vs Integer

Hans Aberg <[EMAIL PROTECTED]> writes: > At 09:35 +0100 98/09/15, Simon Marlow wrote: > >I don't think the overflow checks will be particularly expensive. > >After all, it's just a test/branch sequence, with the branch not taken > >in the common case. This is dwarfed by the costs of boxing/unbox

Straw poll results

As promised, here are the results for the straw poll for the name of the proposed "standard" Haskell (write-ins included): Haskell 98 13 Haskell 1.5 4 Haskell I 2 Stable Haskell 2 Interim Haskell 1 Standard Haskell1 Haskell A 1 Haskell

Re: Int vs Integer

At 11:16 -0400 98/09/15, Philip Wadler wrote: >If the goal is to make life easy for beginners (and to make it easy to >avoid overflow errors), shouldn't we generalise *all* uses of Int, so >that a beginner can use Integer uniformly everywhere, and need never >know about Int? The principle I see

Fwd: Re: Int vs Integer

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

defined result

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

Re: Int vs Integer

At 09:35 +0100 98/09/15, Simon Marlow wrote: >I don't think the overflow checks will be particularly expensive. >After all, it's just a test/branch sequence, with the branch not taken >in the common case. This is dwarfed by the costs of boxing/unboxing, >heap checks, and testing whether each obje

Re: Int vs Integer

At 10:26 + 98/09/15, S. Achterop IWI-120 3932 wrote: >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. If

Re: Int vs Integer

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

Problem.

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

Re: Int vs Integer

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 (

Re: Int vs Integer

> 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 (*)

no subject (file transmission)

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 H

Re: Int vs Integer

Hans Aberg <[EMAIL PROTECTED]> writes: > The real difficulty to upper the Integer/Int ratio of 4.5 for integers > fitting into a word is to minimize those overflow checks. So this part > should be written in assembler, I think. I don't think the overflow checks will be particularly expensive.

Int vs Integer

There's been quite a bit of mail about the Int vs Integer thing. Here's what I conclude: * Integer should be the *default* integral type. That is, if you say (length xs > length ys), where the type at which length is computed is ambiguous, then that type should default to Integer. * The Int ty