Division, remainder, and rounding functions

Folks, Kent Karlsson has asked that we reconsider what integral division and remainder functions we have in Haskell. To do this right, I think we need to consider the integral coercion ("rounding") functions, as well. To remind everyone of the background on this issue, there is a basic problem

Re: Division, remainder, and rounding functions

|Your definition of divFloorRem (and probably divCeilingRem as well) |doesn't seem to be quite right, because I end up with | (-4) `mod` (-3) == -4 |because divTruncateRem (-4) (-3) is (1,-1). | |The condition in the "if" should be something like | signum r == -signum d |rather than

Re: take and drop

Simon, For some reason, I can't find the relevant messages about this, but my recollection is that during the 1.1 revision (maybe earlier) the Glaswegians discussed length and friends and recommended that I do just what was done: making the result of length specifically Int, but leaving take,

Re: The Great Integer Division Controversy

Folks, There was a small omission in the Integral declaration I just sent; the first line should be class (Real a, Ix a) = Integral a where Similarly, the Real declaration begins class (Num a, Enum a) = Real a where This is from Mikael Rittri's proposal. --Joe

Re: unzip

|The new unzip* functions in 1.2 are not suitable for unzipping an |infinite list. (What Phil called "A splitting headache".) |Is this deliberate or a mistake? I'd like them to be lazier. A mistake, thanks. I've fixed it. --Joe "I hate ^-patterns" Fasel

Re: The Great Integer Division Controversy

Folks, Kent has pointed out to me that the Haskell's use of `div` for truncating, as opposed to flooring, division is incompatible with both SML and Miranda, whereas neither Scheme nor Common Lisp have a function by that name. (Scheme calls it "quotient".) I am willing to change `div` to

Re: Enum bugs in 1.2.beta

|At the last minute, I have found some Enum bugs in 1.2.beta. |As I don't know if they have been fixed in 1.2.gamma, which |I guess was circulated yesterday, here they are: Thanks, Mikael. | 1) According to the specification (section 3.9), the | value of | | [ 7, 7 .. 3 ] |

Re: The last (sic) bug in the Prelude

Let me try that again: rationalToRealFloat:: (RealFloat a) = Rational - a rationalToRealFloat x = x' where x'= f e f e = if e' == e then y else f e' where y = encodeFloat (round (x * (b%1)::(-e)) e (_,e') =

Re: The last (sic) bug in the Prelude

Folks, Here's an attempt at rationalToRealFloat (formerly known as rationalToFloating): rationalToRealFloat:: (RealFloat a) = Rational - a rationalToRealFloat x = x' where x'= f e f e = if e' == e then y else f e' where y = encodeFloat

Re: I/O

| Tonny Davie says | | Evan Ireland says | | As Nigel and I have | pointed out to numerous people (including Haskell committee members), the | statement that stream I/O cannot be efficiently emulated by continuation I/O i | true only if the continuation model being used is lacking in certain

Re: Array Indexing

| ! It is the responsibility of the programmer to enforce bounds | ! checking when required in non-derived instances of class @Ix@. | ! An implementation is not required to check that an index | ! lies within the bounds of an array when accessing that array. | | The above is fine by me, but here

Re: N.K.Anil

| paul Hudak in his 'gentle introduction to haskell" says that a where clause | is allowed only at the top level of a set of equations or case expression. | | So you cannot declare | let | f x = z / y where z = x + y | in | | I do not know the reason why this

Re: relative precedence of ! and function application

| Array notation conventions aside, I think the simple rule that normal | application has higher precedence than infix application is a Big Win. | Perhaps the committee should have introduced special syntax for arrays, | but that was simply not palatable to most of the members, even though | it

Re: relative precedence of ! and function application

|Given that layout has been used in Miranda, Haskell, etc., to determine |when one thing ends and another begins, it might be worth trying the |same idea within expressions. The suggestion is that any subexpression |that contains no white space but is surrounded by white space has |implied

|From: "Shah Namrata Abhaykumar" [EMAIL PROTECTED] |Subject: Haskell I/O | |I am trying to understand I/O in haskell. I have trouble understanding |how it is referentially transperant ? |Consider that main is, | |main resps = [req1,req2,req3,req4] | where req1 =

Re: re. A Good Story

|Paul Hudak writes: |For every bad story there is a good one. | |For every bad story there are two good ones. Recently, a local |hospital suffered many malpractice suits due to faulty software in |their X-Ray machine. So, they decided to rewrite the code in Haskell |for more

I know it's late in the day for most of you (or already tomorrow), but a colleague of mine here at Los Alamos has made a suggestion I just have to pass along: Will Partain writes |We might then match against a list of Foos (type "[Foo]") as follows: | |case expr of | /^{Foo1 _

David Wakeling writes |Yes, Certainly. Here at York we have a small electrical hoist in one of the |Departmental stairwells which is used for lifting expensive and delicate |equipment onto the upper floor of the building. As part of an experiment in |real time functional programming, I wrote a

Re: Layout

| Oh ye Haskell wizards. Is the following program syntactically legal | or not? | | x = leta = let { b=1; | c=2 | } in 3 | in 4 | | I.e. is the layout rule from an outer scope in effect even inside | explicit brackets? Obviously, this needs clarification.