July 2004 - Haskell - Haskell.org

SDL binding available.
by Adrian Hey 08 Jul '04

08 Jul '04

Hello, I've put my Haskell bindings to SDL,SDL_Image, and SDL_TTF here.. http://homepages.nildram.co.uk/~ahey/HLibs/Multimedia.SDL.Core/ http://homepages.nildram.co.uk/~ahey/HLibs/Multimedia.SDL.Image/ http://homepages.nildram.co.uk/~ahey/HLibs/Multimedia.SDL.TTF/ It's not really as polished as I would like for a first release, but I haven't had much time to work on it recently and it seems a pity to see it just gathering dust when it might be useful to some people. I hope to get back to work on it myself soon. At the moment it's probably not terribly useful. It's just a raw binding to (most of) the SDL video and event handling. So it has no sound, no computed graphics capability (just text rendering and pre-prepared sprite blitting), and joystick handling still sucks a bit. Also, blitting is not very fast under X11 (no surprises there). It was much faster on Win32/DirectX last time I tested it, but that was a while ago so I don't know if the current version builds or works on Win32. BTW, If anybody finds the lack of audio too style cramping, feel free to contribute a binding to this part of SDL :-) It's not something I need particularly urgently so you might have to wait a while otherwise. I plan to give the graphics capabilities higher priority. Regards -- Adrian Hey

1 0

Re: [Haskell] for large x, log (x::Integer) :: Double
by Greg Buchholz 05 Jul '04

05 Jul '04

-- Inspired from Mr. Howard Oakley. Might not qualify as "good", -- but with this function I get log10(x)=849.114419903382 main = do print(show(log10(x))) x = 1301427272151881160612765560226881966218101403436917787184856303672382623256898455416763978959067300249652773943715743032733292602624834984761739233232794619193611954735720284761058146899246611113236700853600891798968920775344491685185906922596026543915321367577774522912315930144523472702386240645993859368230855941019371447058664115974032571881072431604651385520393674840678811793554266595013773947434115579588912967969680150473258236727830867832149867100437142705476716669039640252677955201589378051836112800268367331455296715904387732836350613539218249950829555418397197909288345303407194983545308212828662999623279222913080214196287140117582811769188486693208227570257136851945943408206281672555558289460256867016896063334140640075708083581866297494610834545554864846306383014549439540479675828018496049574066533167553894586573246931377586176000 log10 :: Integer -> Double log10 n = let i = length(show(n)) - 1 t = take 12 (show(n)) r = read(t) f = r / 10 ^ (length(t) - 1) in fromIntegral(i) + log(f)/log(10) --Greg Buchholz

3 2

Overriding Prelude functions
by André Pang 05 Jul '04

05 Jul '04

Hi all, Inspired by a bit of hackery today, I managed to find a nice way to re-define Prelude functions in modular way. There may be some functions in the Prelude that you would like to redefine: in this example, we redefine the "lookup" function, which normally has a type signature of lookup :: forall b a. (Eq a) => a -> [(a, b)] -> Maybe b Here, we make lookup a bit more generic, so that we can look up any data structure that is "lookupable" -- we override the Prelude's lookup function with our own. The motivation is that there may be a module which provides you many useful functions, but unfortunately has namespace clashes with your own module. One example is that you've defined a generic 'zip' function named gzip, which could substitute perfectly for the Prelude's own zip function, but you have to call it gzip only because the function name 'zip' is already taken. The advantage of this is that you can smoothly integrate extra functionality with already-existing functions by overriding them -- and by providing the extra functionality in a module, you leave it up to the module user whether they want to take advantage of that functionality or not. The essential idea is to define a module (e.g. MyPrelude), which does the following: module MyPrelude(module Prelude, lookup) where import qualified Prelude as P import Prelude hiding (lookup) lookup = ... (your own definition here) ... That module re-exports the Prelude and its own lookup function. Then, a module which wants to use the overridden lookup function does the following: {-# OPTIONS -fno-implicit-prelude #-} module UseLookup where import MyPrelude ... now uses MyPrelude's lookup function instead of Prelude's lookup ... A concrete implementation of this idea is below. Have the appropriate amount of fun :). MyPrelude.hs {-# OPTIONS -fglasgow-exts #-} module MyPrelude(module Prelude, lookup) where import qualified Prelude as P import Prelude hiding (lookup) import Data.FiniteMap import Data.Set -- override the lookup function, defined in the Prelude as: -- -- lookup :: forall b a. (Eq a) => a -> [(a, b)] -> Maybe b class Lookup lookupable key value | lookupable -> key value where lookup :: Ord key => lookupable -> key -> Maybe value instance Lookup (FiniteMap key value) key value where lookup = lookupFM instance Lookup [(key, value)] key value where lookup = lookupListOfTuples instance Lookup (Set value) value value where lookup container element | elementOf element container = Just element | otherwise = Nothing lookupListOfTuples [] _ = Nothing lookupListOfTuples ((key, value):xs) key' | key == key' = Just value | otherwise = lookupListOfTuples xs key' UseLookup.hs: {-# OPTIONS -fno-implicit-prelude #-} module UseLookup where import Data.FiniteMap import Data.Set import MyPrelude fm = addToFM emptyFM "foo" "bar" set = mkSet ["foo"] tupleList = [("foo", "bar")] An example session: *UseLookup> lookup fm "foo" Just "bar" *UseLookup> lookup fm "baz" Nothing *UseLookup> lookup set "foo" Just "foo" *UseLookup> lookup tupleList "foo" Just "bar" *UseLookup> -- % Andre Pang : trust.in.love.to.save

1 0

Licensing problem, caused by static linking on windows
by Kevin Backhouse 05 Jul '04

05 Jul '04

For past year or so, a group of us at ARM having been developing some software in Haskell. We have recently discovered that there may be a licensing problem if we wish to release a Windows version of the software. No doubt others have encountered the same problem, so we would be very grateful for any advice on how to solve it. The problem is that on Windows, GHC statically links the program with the libgmp library, which has an LGPL license. The LGPL license says that we can distribute the executable under our own terms, provided that we do this: Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. Does anyone have any experience of doing this with GHC? Is it relatively straightforward? Or better still, has anyone figured out a way of avoiding the problem by dynamically linking with libgmp on Windows? Any help would be greatly appreciated! Kevin Kevin Backhouse ARM Limited, 110 Fulbourn Road, Cambridge, CB1 9NJ, UK. Tel: +44 1223 400601 This e-mail message is intended for the addressee(s) only and may contain information that is the property of, and/or subject to a confidentiality agreement between the intended recipient(s), their organisation and/or the ARM Group of Companies. If you are not an intended recipient of this e-mail message, you should not read, copy, forward or otherwise distribute or further disclose the information in it; misuse of the contents of this e-mail message may violate various laws in your state, country or jurisdiction. If you have received this e-mail message in error, please contact the originator of this e-mail message via e-mail and delete all copies of this message from your computer or network, thank you.

3 2

Re: [Haskell] Licensing problem, caused by static linking on windows
by MR K P SCHUPKE 03 Jul '04

03 Jul '04

Re LGPL... I beleive it is acceptable to supply source code on request, and you should make it clear in the distributed code that the source for gmp is available on request. Keean.

2 1

for large x, log (x::Integer) :: Double
by Hal Daume III 01 Jul '04

01 Jul '04

i'm looking for an accurate way to take the log of a very large integer, for example: let x :: Integer = 1301427272151881160612765560226881966218101403436917787184856303672382623256898455416763978959067300249652773943715743032733292602624834984761739233232794619193611954735720284761058146899246611113236700853600891798968920775344491685185906922596026543915321367577774522912315930144523472702386240645993859368230855941019371447058664115974032571881072431604651385520393674840678811793554266595013773947434115579588912967969680150473258236727830867832149867100437142705476716669039640252677955201589378051836112800268367331455296715904387732836350613539218249950829555418397197909288345303407194983545308212828662999623279222913080214196287140117582811769188486693208227570257136851945943408206281672555558289460256867016896063334140640075708083581866297494610834545554864846306383014549439540479675828018496049574066533167553894586573246931377586176000 this # is approximately 10^850. not surprisingly, if i do: log (fromIntegral x) :: Double i get "Infinity". i can think of several ways to try to combat this: (1) divide x by something large (10^850) and then take the log of the integer part (requires finding that x ~ 10^850 by some search method); (2) multiply x by something large (10^10) and then take the log of this *as an Integer* and then convert that to a double. has anyone encountered this problem before? surely there must be a "good way" to do this... - hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

5 5