- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Re: Double -> CDouble, realToFrac doesn't work
by Benjamin Franksen 05 Nov '04

05 Nov '04

On Friday 05 November 2004 14:11, you wrote: > It's worse: Since according to IEEE +0 is not equal to -0, atan2 is not a > function! Sorry, I meant to write: Since according to IEEE +0 *is* to be regarded as equal to -0, atan2 is not a function. (Because it gives different values for argument combinations -0, +0.) Ben

2 1

Re: [Haskell-cafe] Making MVar and Chan Instances of Typeable
by MR K P SCHUPKE 05 Nov '04

05 Nov '04

nstance Typeable a => Typeable (MVar a) where typeOf (x::x) = mkAppTy (mkTyCon "Control.Concurrent.MVar.MVar") [typeOf (undefined::x)] Keean.

2 1

Re: Double -> CDouble, realToFrac doesn't work
by dpt＠lotus.bostoncoop.net 05 Nov '04

05 Nov '04

On Thu, Nov 04, 2004 at 08:32:52PM +0100, Sven Panne wrote: > It's an old thread, but nothing has really happened yet, so I'd like to > restate and expand the question: What should the behaviour of toRational, > fromRational, and decodeFloat for NaN and +/-Infinity be? Even if the report > is unclear here, it would be nice if GHC, Hugs, and NHC98 agreed on > something. > Can we agree on the special Rational values below? I would be very careful of adding non-rationals to the Rational type. For one thing, it breaks the traditional rule for equality a % b == c % d iff a*d == b*c You'd need to look at all the instances for Ratio a that are defined. For instance, the Ord instance would require at least lots of special cases. And when would you expect 'x/0' to give +Infinity and when -Infinity? For IEEE floats, there are distinct representations of +0 and -0, which lets you know when you want which one. But for the Rational type there is no such distinction. The behaviour that '1 % 0' gives the error 'Ratio.% : zero denominator' is clearly specified by the Library Report. In the meantime, there are utility functions for dealing with IEEE floats (isNaN, etc.) Peace, Dylan

1 0

Newbie Question on type constructors
by Brian Beckman 04 Nov '04

04 Nov '04

This is a tiny question on the "data" syntax. Consider the following (cribbed from Paul Hudak's "School of Expression" book, page 22): data Shape = Circle Float | Square Float I read this something along the lines of "'Shape' is a type constructor, for use in other type-defining expressions, and 'Circle' and 'Sqare' are its two data constructors, which should be used like functions of type 'Float -> Shape'". Indeed, typing "Circle" at the Hugs prompt reveals that Haskell has a "function" named "Circle" with type "Float -> Shape." However, I don't know of other circumstances where (1) I can declare functions with capitalized names (Hugs groans about syntax errors if I attempt the following: Circle2 :: Float -> Shape Circle2 = Circle And (2) where the argument-types of a function can be declared on the function's right-hand side. So, in some sense, am I right to think of "data" as a special syntax for special kinds of function declarations, namely data-constructor function declarations, and that this syntax is different in appearance, but not terribly different in meaning, from the ordinary syntax, typified by circle2 :: Float -> Shape circle2 = Circle (this is just the uncialized version of the one above, and is perfectly legal) Apologies if this is just too nitpicky and pedantic for words, but I try to notice everything.

8 13

Processing of large files
by Alexander N. Kogan 04 Nov '04

04 Nov '04

Hi! I'm newbie and I don't understand how to process large files in haskell with constant memory requirements. For example, to count numbers of different words in text file I wrote following program: -- start import System.Environment merge [] x = [(x,1)] merge (e@(a,b):xs) x | x == a = (a,b+1):xs | otherwise = e : merge xs x procFile = putStrLn . show . foldl merge [] . words main = do args <- getArgs readFile (head args) >>= procFile -- end How should I modify it to make it useful on large file? It eats too much memory... -- Alexander Kogan Auto Wave Processes Group Institute of Applied Physics RAS

11 28

Re: [Haskell-cafe] different arities
by Henning Sato Rosen 04 Nov '04

04 Nov '04

> You have met up with one of the rules for function bindings in standard > Haskell (http://www.haskell.org/onlinereport/decls.html) The use of "arity" > in the error message is a poor choice of words. The rule is that each clause > in the function binding must contain the same number of argument patterns. Oh, I see, thanks Scott and Marco for answering! I am beginning to realise that everything worth knowing about Haskell really is in the report:-) Regards/Henning -------------------------------------------------------------------------------------------------- BTW, what might the reason for that be, is it for the sake of ease of translation/implementation, or for the sake of some principle? I mean, as soon as a person realises that there are multiple syntaxes for declaring a function, he/she will unify them to one abstract function in the head (where the resulting type matters, not the syntax). So, even if one probably should avoid mixing as in the example, for readability reasons, one might still argue that the restriction goes against PoLS. Just a thought.

2 1

Fwd: [Haskell-cafe] A simple question
by Marc Charpentier 03 Nov '04

03 Nov '04

Thank you all for the friendly and helpful explanations - and for your patience. The solution to my problem is finally f :: Double -> Double f i = (-1)**i/(2**(10*i)) * (-2^5/(4*i+1)-1/(4*i+3)+2^8/(10*i+1) -2^6/(10*i+3)-2^2/(10*i+5)-2^2/(10*i+7)+1/(10*i+9)) I had confused (^) and (**) due the fact that 1.0/2^16 or (-1.0)^2/2^16 are accepted. The important sentence in the Gentle Tutorial is " It is easy to forget at times that numerals are overloaded, and not implicitly coerced to the various numeric types," (Finding my errors was made somewhat difficult due to the following messages I got while testing my conjectures: *Main> let i=1 in 1/2^i 0.5 *Main> let i=1 in i/2^i Ambiguous type variable `a' in these top-level constraints: `Fractional a' arising from use of `/' at <interactive>:1 `Integral a' arising from use of `^' at <interactive>:1 :-) ) Thanks to all. Marc Charpentier

2 1

A simple question
by Marc Charpentier 03 Nov '04

03 Nov '04

Good evening, Doing some calculations in ghci, I encountered a difficulty which I cannot resolve. Here's a distilled version, prepared for the command line: let i = 2 in (-1)^i/(2^(10*i)) * (-2^5/(4*i+1)) gives the following error messages ghci: Ambiguous type variable `b' in these top-level constraints: `Fractional b' arising from use of `/' at <interactive>:1 `Integral b' arising from use of `^' at <interactive>:1 hugs: ERROR - Unresolved overloading *** Type : (Integral a, Fractional a) => a *** Expression : let {...} in (-1) ^ i / 2 ^ (10 * i) * negate (2 ^ 5 / (4 * i + 1)) However, if I substitute i = 2 in the last fraction, then the transformed expression let i = 2 in (-1)^i/(2^(10*i)) * (-2^5/(4*2+1)) is accepted. Note that both let i=2 in (-1)^i/(2^(10*i)) and let i=2 in (-2^5/(4*i+1)) are accepted. Why? Thank you in advance. Marc Charpentier

3 2

Examples using STRef
by John Velman 03 Nov '04

03 Nov '04

I want to label items on a canvas (using HTk for gui) with a sequence of labels. It looks like STRef would provide the right capability. (Needless to say, at this point, I'm new at using Haskell and am trying to swallow everything at once.) Are there some examples of programs using STRef? I'd like examples that are not too complicated, but not too simple, either. :-) Thanks, John Velman

1 0

different arities
by Henning Sato Rosen 03 Nov '04

03 Nov '04

These two functions have the same type. Is this behaviour intended? (Can functions of the same type have different arities?) ------------------------------------------- data Fun = Increment | Square fun:: Fun -> Int -> Int fun Increment n = n+1 fun Square = (\n -> n*n) ------------------------------------------- Error message in HUGS: ERROR "arity.hs":17 - Equations give different arities for "fun GHC: arity.hs:3: Varying number of arguments for function `fun' /Regards Henning

2 1