Re: [Haskell] Enum class

2005-01-09 Thread Sebastian Sylvan
On Fri, 07 Jan 2005 18:57:01 -0600, Jaime Nino <[EMAIL PROTECTED]> wrote: > where value is the last value of a. > I have not found any functionality on Enum types to do this. In > particular how to > specify the last element of any Enum type, or how

Re: [Haskell] Re: Enum class

2005-01-09 Thread Sebastian Sylvan
On 09 Jan 2005 07:56:58 +0100, Peter Simons <[EMAIL PROTECTED]> wrote: > Jaime Nino writes: > > > I would like to write a function with type > >next :: Enum a => a -> a > > which will wrap a values around [...]. > > You'll need (Bounded a, Enum a) to implement that. The > function you are

[Haskell] Re: Enum class

2005-01-08 Thread Peter Simons
Jaime Nino writes: > I would like to write a function with type >next :: Enum a => a -> a > which will wrap a values around [...]. You'll need (Bounded a, Enum a) to implement that. The function you are looking for is 'maxBound'. Enumerable types are not necessarily bounded in the general

[Haskell] Enum class

2005-01-08 Thread Jaime Nino
I would like to write a function with type next :: Enum a => a -> a which will wrap a values around; that is next value == toEnum 0 where value is the last value of a. I have not found any functionality on Enum types to do this. In particular how to specify the last element of

Re: Haskell 98: Enum Class

2001-10-25 Thread George Russell
Simon Peyton-Jones wrote: [snip] > > The Revised Haskell 98 report is suppposed to be in > conclusion mode. An attempt to decide what features are > deprecated would open up a big new debate. One could > instead list features which are controversial --- that would > be easier. Whether it would

RE: Haskell 98: Enum class

2001-10-25 Thread Simon Peyton-Jones
| Somebody raised the issue why to/fromEnum doesn't use Integer | instead of Int. This would, it would seem, solve at least | some of the Enum problems that arise from (integral) types | with more than 4G values. So, again, why not? There was an extended discussion on this point, I believe,

RE: Haskell 98: Enum Class

2001-10-25 Thread Simon Peyton-Jones
| In addition, I suggest that, since it is widely agreed that | the instances of Enum for Float and Double are highly | unsatisfactory, the report should give these instances the | same status as n+k patterns have (in 1.4 of the recent | revision). In particular, their use should be "discoura

Re: Haskell 98: Enum Class

2001-10-25 Thread George Russell
Ketil Malde wrote: > > George Russell <[EMAIL PROTECTED]> writes: > > > In addition, I suggest that, since it is widely agreed that the instances of > > Enum for Float and Double > > And (Ratio a)? Yes, you've got a point there. They'd none of 'em be missed. Of course mathematicians are well

Re: Haskell 98: Enum Class

2001-10-25 Thread Ketil Malde
George Russell <[EMAIL PROTECTED]> writes: > In addition, I suggest that, since it is widely agreed that the instances of > Enum for Float and Double And (Ratio a)? >are highly unsatisfactory -kzm -- If I haven't seen further, it is by standing in the footprints of

Re:Haskell 98: Enum Class

2001-10-25 Thread George Russell
ct 1 > (subject to > (2) above. > > 4. Rewrite D.2 to talk about deriving only, not about Enum in general. > > 5. In Appendix A, the Enum class defn, add comments to explain that the > default methods only work for types whose fromEnum/toEnum range fits=20 > inside Int

Re: [ketil@ii.uib.no: Re: Enum class]

2001-10-25 Thread Dylan Thurston
(I want to trim the headers, but don't know the history of this thread. Also cc:ed back to the Haskell list.) On Thu, Oct 25, 2001 at 11:11:42AM +0200, Ketil Malde wrote: > Dylan Thurston <[EMAIL PROTECTED]> writes: > > I agree that Enum instances for Float/Double are not likely to be > > useful

Re: Haskell 98: Enum class

2001-10-25 Thread Ketil Malde
Malcolm Wallace <[EMAIL PROTECTED]> writes: >> 5. In Appendix A, the Enum class defn, add comments to explain that the >> default methods only work for types whose fromEnum/toEnum range fits >> inside Int. > I would rather have correct default definitions. Someb

RE: Enum class

2001-10-24 Thread Jan-Willem Maessen
"Simon Peyton-Jones" <[EMAIL PROTECTED]> responds to me (and others): > The Report Section 6.3.4 (about Enum) refers back to Section 3.10 for > semantics for enumFrom etc. There you'll find a specification for > what they mean, including Float and Double. If I can improve the > wording > I'd be

Re: Haskell 98: Enum class

2001-10-24 Thread Malcolm Wallace
ing back to t with toEnum." However I agree that succ = (+1) pred = (\x-> x-1) would make better sense. > 5. In Appendix A, the Enum class defn, add comments to explain that the > default methods only work for types whose fromEnum/toEnum range fits > inside Int. I wou

Re: Haskell 98: Enum class

2001-10-24 Thread Dylan Thurston
On Wed, Oct 24, 2001 at 07:51:12AM -0700, Simon Peyton-Jones wrote: > The Report is (regrettably) silent about what the Integer > instances for succ and pred should be, but they should definitely simply > add 1 (resp subtract 1). They should emphatically not use the default > methods. I will ad

Haskell 98: Enum class

2001-10-24 Thread Simon Peyton-Jones
d) and (pred minBound) are errors. 3. Specify that succ and pred on numeric types just add/subtract 1 (subject to (2) above. 4. Rewrite D.2 to talk about deriving only, not about Enum in general. 5. In Appendix A, the Enum class defn, add comments to explain that the default methods only work for

RE: Enum class

2001-10-24 Thread Simon Marlow
> > i_succ' = succ i' > > -- ghc : 2147483648 > > -- hugs: -2147483648 > -- nhc98: -2147483648 > -- hbc: -2147483648 > > > I think Hugs is wrong. Integer shouldn't wrap. > > (Actually, ghc is `wrong': hbc, hugs and nhc98 match the Report's > specification here: succ = toEnum .

Re: Enum class

2001-10-24 Thread Malcolm Wallace
I just thought I should add the results for hbc and nhc98 to this enumeration of woes, to further illustrate the difficulties. > i :: Int > i = 0x7fff > > i_plus_1 = i+1 > -- ghc : -2147483648 > -- hugs: -2147483648 -- nhc98: -2147483648 -- hbc: -2147483648 > i_succ = succ i

RE: Enum class

2001-10-24 Thread Simon Peyton-Jones
which deal gracefully with | overflow might be a nice addition to the report as people get them | wrong. Hmm. If the specification is ok, I'm disinclined to add an implementation too -- there's every chance I'll get it wrong too! | * Add definitions for boundedEnumFrom... to the Pr

Re: Enum class

2001-10-23 Thread Ketil Malde
George Russell <[EMAIL PROTECTED]> writes: > (1) succ & pred. These appear for float to correspond to adding or subtracting > 1.0. (I am finding this out by testing with ghci; it's not specified where > it should be, in section 6.3.4 of the standard). Because of rounding errors,

Re: Enum class

2001-10-23 Thread Ketil Malde
Pixel <[EMAIL PROTECTED]> writes: > Quite a few pbs with overflow on Int too: > i :: Int > i = 0x7fff > i_plus_1 = i+1 > -- ghc : -2147483648 > -- hugs: -2147483648 Given that Int represents modulo arithmetic, this is all right, but > i_succ = succ i > -- ghc : *** Exception: Prelud

Re: Enum class

2001-10-23 Thread Tom Pledger
Jan-Willem Maessen writes: | * Split the Enum class into two. Possibly "correspondence with Int" | belongs in "Bounded"---but it depends what you think "Bounded" | means. FWIW I sometimes use a data type for the very purpose of adding bounds to an open

Re: Enum class

2001-10-23 Thread Jan-Willem Maessen
483647,-2147483648,-2147483647,-2147483646,-2147483645, etc... [GHC appears to do it right, I have no idea about current hugs or nhc versions.] * Add definitions for boundedEnumFrom... to the Prelude, or perhaps to a library. This might or might not be a big change for Haskell 98; I f

Re: Enum class

2001-10-23 Thread Pixel
George Russell <[EMAIL PROTECTED]> writes: > (1) succ & pred. These appear for float to correspond to adding or subtracting > 1.0. (I am finding this out by testing with ghci; it's not specified where > it should be, in section 6.3.4 of the standard). Because of rounding errors,

Re: Enum class

2001-10-23 Thread Lennart Augustsson
"Ch. A. Herrmann" wrote: > > "Lennart" == Lennart Augustsson <[EMAIL PROTECTED]> writes: > > Lennart> "Ch. A. Herrmann" wrote: > >> (1) What is the justification for the types "Float" and "Double" > >> to be members of the type class "Enum"? This might induce > >> students to

Re: Enum class

2001-10-23 Thread Lennart Augustsson
gt; > some lectures about floating point arithmetic. > > Real numbers (which floating point numbers are trying to be) are not enumerable > (that is, they cannot be placed in a one-one correspondence with the integers). But belonging to the Enum class does not mean that all the elem

Re: Enum class

2001-10-23 Thread Max Kirillov
On Tue, Oct 23, 2001 at 12:27:37PM +0200, Ch. A. Herrmann wrote: > Removing them would possibly cause problems with existing programs > and this is definitely not my aim. However, it'll make sense to > think about long-term improvements. I wouldn't call Float and Double > enumeration types. May

Re: Enum class

2001-10-23 Thread George Russell
I personally think the inclusion of Float and Double in Enum is an unmitigated disaster. Enum consists of three separate parts: (1) succ & pred. These appear for float to correspond to adding or subtracting 1.0. (I am finding this out by testing with ghci; it's not specified where

Re: Enum class

2001-10-23 Thread Ch. A. Herrmann
John> I think the problem is that Enum in haskell means not only John> enumerable types, but types which have enumerable subsets when John> taken with an incrementer. which the reals satisfy. This is a good justification. John> this can be demonstrated by things like [1.0, 1.1 .

Re: Enum class

2001-10-23 Thread Ch. A. Herrmann
> "Lennart" == Lennart Augustsson <[EMAIL PROTECTED]> writes: Lennart> "Ch. A. Herrmann" wrote: >> (1) What is the justification for the types "Float" and "Double" >> to be members of the type class "Enum"? This might induce >> students to use floating point values as counters

Re: Enum class

2001-10-23 Thread John Meacham
On Tue, Oct 23, 2001 at 07:32:58PM +1000, Tim Barbour wrote: > Lennart Augustsson writes: > > "Ch. A. Herrmann" wrote: > > > > > (1) What is the justification for the types "Float" and "Double" > > > to be members of the type class "Enum"? This might induce students > > > to use floa

Re: Enum class

2001-10-23 Thread Tim Barbour
Lennart Augustsson writes: > "Ch. A. Herrmann" wrote: > > > (1) What is the justification for the types "Float" and "Double" > > to be members of the type class "Enum"? This might induce students > > to use floating point values as counters in arithmetic > > sequences. > > An

Re: Enum class

2001-10-23 Thread Lennart Augustsson
"Ch. A. Herrmann" wrote: > (1) What is the justification for the types "Float" and "Double" > to be members of the type class "Enum"? This might induce students > to use floating point values as counters in arithmetic > sequences. And what's wrong with that? If the students are using

Enum class

2001-10-23 Thread Ch. A. Herrmann
Hi Haskellers, assuming that the type class "Enum" represents enumeration types, there are two questions for me: (1) What is the justification for the types "Float" and "Double" to be members of the type class "Enum"? This might induce students to use floating point values as counters in

Re: let succ be an Enum class member

1998-05-12 Thread Jon . Fairbairn
On 12 May, Jeffrey R. Lewis wrote: > I agree, in fact, I'd go one stronger. I'll propose that `fromEnum' and > `toEnum' be taken out, since clearly not all enumerable types are > subtypes of Int (as you point out, Integer leaps immediately to mind). An alternative would be to return fromEnum and

let succ be an Enum class member

1998-05-12 Thread Christian Sievers
Hello, this is about a change in the prelude I'd like to suggest. The following is obviously not what one would expect: Prelude> succ 100::Integer Program error: {primIntegerToInt 100} However, with the prelude defining succ to be succ,:: Enum a => a ->

Re: let succ be an Enum class member

1998-05-12 Thread Jeffrey R. Lewis
k? > Are there any drawbacks? > Could it be like this in standard haskell? I agree, in fact, I'd go one stronger. I'll propose that `fromEnum' and `toEnum' be taken out, since clearly not all enumerable types are subtypes of Int (as you point out, Integer leaps immediate