March 2009 - Haskell-Cafe

Re: [Haskell-cafe] Rational and % operator remix
by michael rice 30 Mar '09

30 Mar '09

Thanks for the information. Michael --- On Mon, 3/30/09, Ryan Ingram <ryani.spam(a)gmail.com> wrote: From: Ryan Ingram <ryani.spam(a)gmail.com> Subject: Re: [Haskell-cafe] Rational and % operator remix To: "michael rice" <nowgate(a)yahoo.com> Cc: "Ketil Malde" <ketil(a)malde.org>, haskell-cafe(a)haskell.org Date: Monday, March 30, 2009, 1:21 PM 2009/3/30 michael rice <nowgate(a)yahoo.com>: > I'm still not sure what some of the error messages I was getting were about. > As I wrote the function I tried to be aware of what "mixed mode" operations > were kosher ala This is a mistake, but understandable given your lispy background; there aren't really "mixed mode" operations in Haskell. One thing that might be confusing you: Numeric literals are really calls to "fromInteger"; that is, "5" is really "fromInteger (5 :: Integer)" Generally you will find that :t in the interpreter is your friend: ghci> :t 1 1 :: (Num t) => t This says that the expression "1" can be of any type that is an instance of Num. ghci> :t (\a b -> a - b) (\a b -> a - b) :: (Num a) => a -> a -> a "-" takes two arguments that are of the same type, and returns something of that type. ghci> :m Data.Ratio ghci> :t (%) (%) :: (Integral a) => a -> a -> Ratio a "%" lifts objects from an integral type into a type that represents the ratio of two integers. ghci> :t floor floor :: (RealFrac a, Integral b) :: a -> b So "floor" is a "cast" operation that converts between any fractional type to any integral type. This is why you need to either use "fromInteger" or "%" on the result of "floor" to get it back as a Rational. -- ryan

1 0

Re: [Haskell-cafe] Internationalization of Haskell code
by Henning Thielemann 30 Mar '09

30 Mar '09

Sorry, my reply got lost in a private mailbox. :-) On Sat, 28 Mar 2009, Henning Thielemann wrote: > On Sat, 28 Mar 2009, Martijn van Steenbergen wrote: > >> Hi Henning, >> >> Henning Thielemann wrote: >>> Thanks for working on that issue! The German translation is fine. I have >>> recently written a Wiki article on how to avoid IO in Haskell code without >>> resorting to unsafePerformIO where I incidentally chose gettext as an >>> example: >>> http://progandprog.blogspot.com/2009/03/i18n-and-haskell.html >> >> I don't think this is the link you meant to post. :-) > > Right, this would be too much of an incidence. I meant this one: > http://www.haskell.org/haskellwiki/Avoiding_IO

1 0

Really need some help understanding a solution
by Günther Schmidt 30 Mar '09

30 Mar '09

Hi guys, I tried for days now to figure out a solution that Luke Palmer has presented me with, by myself, I'm getting nowhere. He has kindly provided me with this code: import Data.Monoid newtype IntTrie a = IntTrie [a] deriving Show singleton :: (Monoid a) => Int -> a -> IntTrie a singleton ch x = IntTrie $ replicate ch mempty ++ [x] ++ repeat mempty lookupTrie :: IntTrie a -> Int -> a lookupTrie (IntTrie xs) n = xs !! n instance (Monoid a) => Monoid (IntTrie a) where mempty = IntTrie (repeat mempty) mappend (IntTrie xs) (IntTrie ys) = IntTrie (infZipWith mappend xs ys) infZipWith f ~(x:xs) ~(y:ys) = f x y : infZipWith f xs ys test = mconcat [singleton (n `mod` 42) [n] | n <- [0..]] `lookupTrie` 10 It's supposed to eventually help me group a list of key value pairs and then further process them in a linear (streaming like) way. The original list being something like [('a', 23), ('b', 18), ('a', 34) ...]. There are couple of techniques employed in this solution, but I'm just guessing here. The keywords I've been looking up so far: Memmoization, Deforestation, Single Pass, Linear Map and some others. Can someone please fill me in? Günther

8 13

Record updates
by Andrew Coppin 30 Mar '09

30 Mar '09

Haskell's record syntax is quite nice, for a number of reasons. However, suppose I have some record: data Foobar = Foobar {foo1, foo2, foo3...} Now suppose that foo3 :: [Int], and I want to prepend 5 to it. I end up having to write something like let v1 = v0 {foo3 = 5 : (foo3 v0)} If the field name isn't "foo" but something more descriptive, and the transformation to be applied to it is more intricate, you end up with quite a bit of code. In summary, record syntax gives you a nice way of replacing the value of one field with something else, but no easy way to *modify* the existing value somehow. Does anybody know of a way around this? Is there some trick I'm not seeing? Is there an extension or proposal that fixes this?

6 6

Re: [Haskell-cafe] Re: Exception handling in numeric computations
by John Lato 30 Mar '09

30 Mar '09

On Wed, Mar 25, 2009 at 7:02 PM, Gregory Petrosyan <gregory.petrosyan(a)gmail.com> wrote: > First of all, thanks everybody for the discussion -- very interesting to read! > > Apologies if this is off-topic a bit. > > While reading, I have a feeling that proposed solutions are somewhat similar > to checked exceptions. And IMO they turned out to be more harmful than useful. Do you mean checked exceptions, or the proposed solutions? IMO the problem with checked exceptions is that they conflate two ideas by trying to use the existing exception framework to do something that can't otherwise be done by the language. This leads to something that doesn't work well for either use. Languages with checked exceptions usually use them for two purposes: 1. Exceptional conditions - disk full, CPU on fire, etc. 2. Error handling - invalid arguments to a function, attempt to invert non-invertible matrix, etc. In the first case, checked exceptions are a pain because there are so many different possible exceptional conditions to enumerate. Or alternatively you have an IOException that can be one of hundreds of actual exceptional conditions. This is exactly what regular exceptions are for, and in general there's little that can be done except terminate the program, except for certain special cases explicitly handled by the programmer. For the second case, checked exceptions actually work okay IMO. The syntax is a bit clunky, but they serve the purpose. That is, they specifically indicate what functions may fail and the failure mode. They also allow calling code to either handle it there or pass the error up to a higher level as appropriate. The syntax is usually ugly, though. Combining these two functions into one tool gives suboptimal results. If you're using checked exceptions for error handling, then you also end up using them for exception handling. That means you have IOException thrown by just about everything (and in theory any function in an imperative language could have an IOException due to hardware fault), leading to complex exception handlers with a half dozen case statements. There are a few reasons why Haskell's approach is (or at least can be) different. Compare the error handling models. Checked exceptions are bolted on to an existing tool attempting to make it serve a different purpose. It seems like a good idea, but ends up being painful because the two uses are at cross purposes. Instead of using a specific implementation and trying to alter it for another use, Haskell uses a very general facility, the type system, to solve one problem, and keeps the exception handling facility separate. Haskell's syntax for error handling is also much nicer. Nobody likes using methods that could possibly throw a dozen different exceptions, some of which are IOException and some are not. Actually, Haskell IO makes a big difference to this. Conceptually, you could think of Haskell functions as purely mathematical constructs. In particular, they can't interact with the physical world. This is true even for the IO monad. Exceptional conditions only arise when the Haskell runtime actually tries to *evaluate* an IO function. As a consequence exceptional conditions only arise as part of IO actions, and can only be handled by IO actions (because they're interacting with the run-time environment). This distinction makes it possible to enforce a separation between exceptions and error conditions, which is generally not possible in imperative languages where a function could fail either for a computational reason (divide by 0) or a hardware/runtime fault. Even in Haskell this separation isn't absolute. Programmer errors, such as dividing by 0, can and do lead to exceptional conditions. The proper way to handle dividing by 0 is to not do it in the first place, but if it happens because of a programming error, you've got an exception. Unfortunately this encourages programmers to think that handling the exception is the proper way to deal with this condition, but it isn't. I've only recently come around to the camp of treating exception handling and errors separately, so some of these thoughts may be a bit loose for the moment. In particular my thoughts from the above paragraph have only recently become clear. Henning T., FYI your constant advocacy has gotten at least one person around to this view. Cheers, John Lato

13 26

Re: [Haskell-cafe] Rational and % operator remix
by michael rice 30 Mar '09

30 Mar '09

My query was in response to an earlier post claiming that ai was a Rational, which post he almost simultaneously said to ignore. I've used GHC and like it better than Hugs, but the Fedora Linux package is humongous and I'm only on dialup right now. I'm still not sure what some of the error messages I was getting were about. As I wrote the function I tried to be aware of what "mixed mode" operations were kosher ala Main> 1 / (6%7) 7 % 6 Main> 1 - (6%7) 1 % 7 Main> (6%7) - 1 (-1) % 7 Main> but still kept getting kicked out. Better error messages certainly couldn't hurt. Thanks. Michael --- On Mon, 3/30/09, Ketil Malde <ketil(a)malde.org> wrote: From: Ketil Malde <ketil(a)malde.org> Subject: Re: [Haskell-cafe] Rational and % operator remix To: "michael rice" <nowgate(a)yahoo.com> Cc: "Brandon S. Allbery KF8NH" <allbery(a)ece.cmu.edu>, haskell-cafe(a)haskell.org Date: Monday, March 30, 2009, 2:48 AM michael rice <nowgate(a)yahoo.com> writes: > cf2 :: Rational -> [Int] > cf2 a = let ai = floor a <-- Doesn't this make ai an Int? -Michael > in > if a == (toRational ai) > then [ai] > else ai : cf2 (1 / (a - ai)) One thing that you could try, is ghci in addition to (or instead of) Hugs. That will give you another take on the error messages, where Hugs says: > Main> :load cf.hs > ERROR "cf.hs":7 - Type error in application > *** Expression : ai : cf2 (1 / (a - ai)) > *** Term : ai > *** Type : Ratio Integer > *** Does not match : Int ghci will tell you: Couldn't match expected type `Rational' against inferred type `Int' In the second argument of `(-)', namely `ai' In the second argument of `(/)', namely `(a - ai)' In the first argument of `cf2', namely `(1 / (a - ai))' So while this is (almost) right: > cf2 a = let ai = floor a <-- Doesn't this make ai an Int? -Michael The problem is the subtraction of ai from a, which forces them to be the same type. I tend to find ghc's messages more informative than Hugs's (but perhaps it is just that I am more familiar with ghc?). -k -- If I haven't seen further, it is by standing in the footprints of giants

2 1

Darcs - dependencies between repositories (aka forests)
by Peter Verswyvelen 30 Mar '09

30 Mar '09

With Cabal we have this nice dependency system: when you install a package, it installs missing but requires packages. How do you solve this with Darcs? I hate it that I must manually figure out the dependencies, and then do a "darcs get" on them individually.

8 12

Problem using #define in .hsc files
by Johan Tibell 30 Mar '09

30 Mar '09

Hi, I'm trying to have hsc2hs interpret this snippet that picks a calling convention to use for FFI imports: #if !defined(CALLCONV) #ifdef WITH_WINSOCK #define CALLCONV stdcall #else #define CALLCONV ccall #endif #endif foreign import CALLCONV unsafe "send" c_send :: CInt -> Ptr a -> CSize -> CInt -> IO CInt Compiling results in: parse error on input `CALLCONV' Inspecting the generated .hs file shows that CALLCONV appear in the source code instead of being replaced with either stdcall or ccall as expected. What's the correct way to use #define in .hsc files? Changing the file extension to .cpphs solves the problem, by using plain CPP instead of hsc2hs I presume. Cheers, Johan

3 2

A guess on stack-overflows - thunks build-up and tail recursion
by Günther Schmidt 30 Mar '09

30 Mar '09

Hi all, I've been running into stack-overflow problems for some time now. Here is what I gathered so far. I used to think that the build up of thunks caused the stack overflow when, as it turns out, it does not. I apparently can have a huge thunk build up eventhough I use a supposedly accumulative, tail-recursive algorithm. Apparently it is the evaluation of this huge build-up that causes the stack-overflow but not the thunk-build-up *as such*. Do I understand this correctly? Günther

11 15

ANNOUNCE: wxAsteroids 1.0
by Henk-Jan van Tuyl 30 Mar '09

30 Mar '09

Your space ship enters an asteroid belt, try to avoid collisions! wxAsteroids is a game demonstrating the wxHaskell GUI. More about this at: http://www.haskell.org/haskellwiki/wxAsteroids -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ --

2 3