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
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
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
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
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
| 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,
| 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
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
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
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
(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
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
"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
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
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
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
> > 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 .
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
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
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,
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
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
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
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,
"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
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
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
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
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 .
> "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
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
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
"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
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
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
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 ->
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
37 matches
Mail list logo