January 2009 - Haskell-Cafe

How to check object's identity?
by Xie Hanjian 04 Jan '09

04 Jan '09

Hi, I tried this in ghci: >Prelude> 1:2:[] == 1:2:[] True Does this mean (:) return the same object on same input, or (==) is not for identity checking? If the later is true, how can I check two object is the *same* object? Thanks Jan -- jan=callcc{|jan|jan};jan.call(jan)

13 15

Thoughts on Haskell and OOP
by Kevin Van Horn 04 Jan '09

04 Jan '09

Haskell has been around in one form or another for nearly two decades now, yet has never been extended with explicit support for object- oriented programming. I've been thinking about why this is so. I've come to the conclusion that Haskell simply doesn't need any explicit OOP support -- algebraic datatypes, modules, lazy evaluation, and first-class functions give you everything you need to do the kinds of things you would use classes and inheritance for in OO languages. To see why this is so, let's think about what OOP is. At the most basic level we have what some call object-based programming. This amounts to support for data hiding and abstract data types. Haskell's module system handles this function quite well, without any need to introduce a special concept of "class" (in the OO sense) nor private vs. public class members. Object-oriented programming is then object-based programming plus class hierarchies and inheritance. Why are these useful? Properly used, OOP is all about interface inheritance, not implementation inheritance. (At least in C++, implementation inheritance -- inheriting the data members and method implementations of a base class -- usually leads to bad design, and is discouraged by the experts.) (For those more familiar with Python, "duck typing" is the analog of interface inheritance for a dynamically-typed language.) Interface inheritance allows you to write procedures that operate on the base-class interface, but can be applied to objects of any type derived from the base class. Can we do this in Haskell? Yes, we can. Let's consider the Haskell analog of an immutable C++ base class: struct Base { virtual ~Base(); virtual int foo() const; virtual int bar(int n) const; }; class derived :: public Base { ... data members ... public: derived(T_1 arg1, ..., T_k argk); ... implementations of the virtual functions ... }; Haskell has no direct analog of object classes and virtual methods, but you can use lazy evaluation and first-class functions to achieve the same result: data Base = Base { foo :: Int, bar :: Int -> Int } derived :: T_1 -> ... -> T_k -> Base derived a_1 ... a_k = Base { foo = ...; bar = bar } where bar n = ... The analog of a mutable C++ base class is a little bit more involved, but not much. Suppose that we change bar(int) to be a mutating method in the C++ Base class: virtual int bar(int n); The Haskell analog then changes to data Base = Base { foo :: Int, bar :: Int -> (Int, Base) } derived :: T_1 -> ... -> T_k -> Base derived a_1 ... a_k = Base { foo = ...; bar = bar } where bar n = (..., (derived a_1' ... a_k')) (Here a_1', ..., a_k' are k expressions involving n and a_1, ..., a_k.) What do the rest of you think? Is my analysis correct?

5 5

[Fwd: Re: ANN: bytestring-trie 0.1.1 (bugfix)]
by wren ng thornton 04 Jan '09

04 Jan '09

-------- Original Message -------- Message-ID: <496176CF.3090708(a)freegeek.org> Date: Sun, 04 Jan 2009 21:56:15 -0500 From: wren ng thornton <wren(a)freegeek.org> User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: ChrisK <haskell(a)list.mightyreason.com> Subject: Re: ANN: bytestring-trie 0.1.1 (bugfix) References: <494C8B52.2040209(a)freegeek.org> <4960303E.8010102(a)freegeek.org> <4960FDA6.3020708(a)list.mightyreason.com> In-Reply-To: <4960FDA6.3020708(a)list.mightyreason.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ChrisK wrote: > Question and suggestion: > > looking at > http://hackage.haskell.org/packages/archive/bytestring-trie/0.1.1/doc/html/… > > I am questioning your choice of foldr in fromList: > > So fromList forces the whole call chain above to be traversed until it > hits the Empty. For a large input list this will force the whole list > to be allocated before proceeding AND the call chain might overflow the > allowed stack size in ghc. For a large trie (which is a likely use > case) this is a poor situation. > > If you use foldl' then the input list is only forced one element at a > time. A small change to the lambda that insert passes to adjustBy will > retain the same semantics of earlier key wins (which are an especially > good idea in the foldl' case). The reason for foldr is to play nice with build/foldr list fusion. Though you're right that foldl' is often nicer when fusion isn't used. As noted (in the code) both toList and fromList are just quick mockups for now. Have you noticed issues with stack overflows or bad performance? My quick tests don't see any problems: $> cat FromListTest.hs ---------------------------------------------------------------- module Main (main) where import qualified Data.Trie as T import Data.Trie.Convenience (insertIfAbsent) import Data.List (foldl') import qualified Data.ByteString as S import Data.ByteString.Internal (c2w) import Microbench import Control.Exception (evaluate) getList, getList' :: T.KeyString -> Int -> [(T.KeyString, Int)] getList xs n = map (\k -> (k,0)) . S.inits . S.take n $ xs getList' xs n = map (\k -> (k,0)) . S.tails . S.take n $ xs main :: IO () main = do -- 100000 is large enough to trigger Microbench's stop condition, -- and small enough to not lock up the system in trying to create it. xs <- evaluate $ S.replicate 100000 (c2w 'a') microbench "fromListR obverse" (T.null . fromListR . getList xs) microbench "fromListL obverse" (T.null . fromListL . getList xs) microbench "fromListR reverse" (T.null . fromListR . getList' xs) microbench "fromListL reverse" (T.null . fromListL . getList' xs) ---------------------------------------------------------------- $> ghc --make -O2 FromListTest.hs [1 of 5] Compiling Data.Trie.ByteStringInternal ( Data/Trie/ByteStringInternal.hs, Data/Trie/ByteStringInternal.o ) [2 of 5] Compiling Data.Trie.BitTwiddle ( Data/Trie/BitTwiddle.hs, Data/Trie/BitTwiddle.o ) [3 of 5] Compiling Data.Trie ( Data/Trie.hs, Data/Trie.o ) [4 of 5] Compiling Data.Trie.Convenience ( Data/Trie/Convenience.hs, Data/Trie/Convenience.o ) [5 of 5] Compiling Main ( FromListTest.hs, FromListTest.o ) Linking FromListTest ... $> ./FromListTest * fromListR obverse: ............... 75.664ns per iteration / 13216.30 per second. * fromListL obverse: ............. 283.380ns per iteration / 3528.84 per second. * fromListR reverse: ............. 630.597ns per iteration / 1585.80 per second. * fromListL reverse: ............... 74.894ns per iteration / 13352.28 per second. Don't mind the 4x speed difference, it's an artifact of the order of the keys being inserted (the cost of splitting an arc vs appending to it). *Main> let run f l n = T.null . f . l (S.replicate n (c2w 'a')) $ n *Main> *Main> run fromListR getList 10 (0.00 secs, 0 bytes) *Main> run fromListR getList 100 (0.00 secs, 0 bytes) *Main> run fromListR getList 1000 (0.01 secs, 599116 bytes) *Main> run fromListR getList 10000 (0.47 secs, 5198576 bytes) *Main> run fromListR getList 100000 (45.36 secs, 51067440 bytes) *Main> *Main> run fromListL getList 10 (0.00 secs, 0 bytes) *Main> run fromListL getList 100 (0.00 secs, 1063168 bytes) *Main> run fromListL getList 1000 (0.06 secs, 74587280 bytes) *Main> run fromListL getList 10000 (10.62 secs, 7438453480 bytes) *Main> run fromListL getList 100000 Interrupted. *Main> *Main> run fromListR getList' 10 (0.00 secs, 0 bytes) *Main> run fromListR getList' 100 (0.00 secs, 1063196 bytes) *Main> run fromListR getList' 1000 (0.09 secs, 74587208 bytes) *Main> run fromListR getList' 10000 (18.19 secs, 7438854556 bytes) *Main> run fromListR getList' 100000 Interrupted. *Main> *Main> run fromListL getList' 10 (0.00 secs, 0 bytes) *Main> run fromListL getList' 100 (0.00 secs, 0 bytes) *Main> run fromListL getList' 1000 (0.01 secs, 533072 bytes) *Main> run fromListL getList' 10000 (0.46 secs, 3791240 bytes) *Main> run fromListL getList' 100000 (44.71 secs, 38515056 bytes) Both options seem about the same to me. The foldl' version is somewhat better in the worst case key ordering (though it changes which ordering that is). I could offer both as alternatives, but I think it'd be better to work on a version that is less succeptable to variation for the order of keys. -- Live well, ~wren -- Live well, ~wren

1 0

Fwd: [Haskell-cafe] Auto-deriving Control.Exception.Exception
by Antoine Latter 04 Jan '09

04 Jan '09

Forwarding response to cafe ---------- Forwarded message ---------- From: Antoine Latter <aslatter(a)gmail.com> Date: Sun, Jan 4, 2009 at 2:13 PM Subject: Re: [Haskell-cafe] Auto-deriving Control.Exception.Exception To: "eyal.lotem(a)gmail.com" <eyal.lotem(a)gmail.com> On Sun, Jan 4, 2009 at 11:50 AM, eyal.lotem(a)gmail.com <eyal.lotem(a)gmail.com> wrote: > If this is valid: > > import qualified Control.Exception as Exc > > genericFromException :: Typeable a => Exc.SomeException -> Maybe a > genericFromException (Exc.SomeException e) = cast e > instance Exc.Exception SomeType where fromException = > genericFromException > > then why not have an auto-deriving rule for Exception (fromException = > cast . unSomeException)? If you just say: > instance Exception YourType where and leave the instance body empty, it will use the default definitions of 'fromException' and 'toException', which do the right thing by default. At least, I'm pretty sure that's what happens. The Haddock docs have lost their links to the source code. -Antoine

1 0

Haskell, successing crossplatform API standart
by Belka 04 Jan '09

04 Jan '09

Hello! (1) Is anybody aware of SOA approach being supported in Haskell? Found HAIFA package (SOAP, WEB services), but it seems to be a RIP project (with it's last updated in 2006) - trying to install it is a total mess (for me, a newby). (2) Please, perhaps experienced developers could suggest any better crossplatform (crosslanguage) API standart supported in Haskell? For me the main priority is orientation on "being supported everywhere in far future"... Thanks in advance -- View this message in context: http://www.nabble.com/Haskell%2C-successing-crossplatform-API-standart-tp20… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

8 10

WriterT [w] IO is not lazy in reading [w]
by Paolino 04 Jan '09

04 Jan '09

As someone suggested me, I can read the logs from Writer and WriterT as computation goes by, if the monoid for the Writer is lazy readable. This has been true until I tried to put the IO inside WriterT > {-# LANGUAGE FlexibleContexts #-} > import Control.Monad.Writer > k :: (MonadWriter [Int] m) => m [Int] > k = let f x = tell [x] >> f (x + 1) in f 0 > works :: [Int] > works = snd $ runWriter k > hangs :: IO [Int] > hangs = snd `liftM` runWriterT k > main = take 20 `liftM` hangs >>= print The main hangs both interpreted and compiled on ghc 6.10.1. The issue is not exposing with IO alone as main = print "test" >> main is a working program. Thanks for explanations. paolino

9 22

ANN: bytestring-trie 0.1.0
by wren ng thornton 04 Jan '09

04 Jan '09

-------------------------------------------- -- Announcing: bytestring-trie 0.1.0 (beta) -------------------------------------------- An efficient finite map from (byte)strings to values. The implementation is based on big-endian patricia trees, like Data.IntMap. We first trie on the Word8 elements of a Data.ByteString, sharing string prefixes where possible, and then trie on the big-endian bit representation of those elements. Patricia trees have efficient algorithms for union and other merging operations, but they're also quick for lookups and insertions. -------------------------------------------- -- Future Extensions -------------------------------------------- * I've done spot checking to make sure it works, but haven't constructed an extensive test suite. Does anyone know of a good data set already out there for testing corner cases? I'm sure other dictionary writers have come up with one. * A Word8 is much smaller than the architecture's natural Word size. Therefore it'd be more efficient for the trie on bits to read off a whole Word at a time. This work is in progress, but I need help from people with 64-bit and big-endian machines in order to verify the code works on those architectures. * Using ByteStrings allows for trieing on any packed byte representation of a value, but they're not Strings. Integration with Data.ByteString.Char8, utf8-string, and utf8-light should happen. * The current implementation also only accepts strict ByteStrings. When chopping up strings to share prefixes we share the smaller string. For very long strings when many deletions are expected, this can still hold onto more memory than necessary. Accepting lazy ByteStrings or adding heuristics for when to copy prefixes instead of sharing will fix this. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-trie Darcs: http://code.haskell.org/~wren/bytestring-trie/ Haddock (Darcs version): http://code.haskell.org/~wren/bytestring-trie/dist/doc/html/bytestring-trie/ -- Live well, ~wren

3 3

Auto-deriving Control.Exception.Exception
by eyal.lotem＠gmail.com 04 Jan '09

04 Jan '09

If this is valid: import qualified Control.Exception as Exc genericFromException :: Typeable a => Exc.SomeException -> Maybe a genericFromException (Exc.SomeException e) = cast e instance Exc.Exception SomeType where fromException = genericFromException then why not have an auto-deriving rule for Exception (fromException = cast . unSomeException)?

1 0

teaching functional programming at work
by Warren Harris 04 Jan '09

04 Jan '09

I am seeking suggestions from the haskell cafe for teaching functional programming concepts to colleagues at work. I'm currently working on a project using ocaml and functional programming techniques, and am a lone ranger at my workplace when it comes to this sort of thing (we are primarily a python shop). However there seems to be a growing curiosity in functional programming, and I think there's a lot to be learned from from it whether one chooses a functional language for their next big project or not. But I'm a practitioner, not an academic or lecturer, and although I find the idea of helping my colleagues understand these concepts to be an exciting prospect, I'm not really sure where to start in terms of materials or overall direction. My sense is to form a study group (perhaps going through Real World Haskell together), but I'm a little afraid of assembling people together for a "now what?" experience. So my first question is whether this is even a good idea? Some things I think would be useful to get across are: - fp is more than just an exercise in avoiding assignment statements -- why a smart programmer should care? - reading knowledge of ocaml and/or haskell (even syntax, precedence and infix operators can be an initial stumbling block) - core concepts: type classes, proper tail recursion, higher-order functions, folds, combinators, monads, monad transformers, arrows - evidence that concise expression can lead to less bugs / better maintainability (hard to prove, but perhaps a sense can be conveyed) - relationship between types / theorems / programs / proofs and why this is important for the future of software Regarding this last point, my own sense has been that by leveraging a powerful type system such as found in ocaml or haskell has allowed me to achieve things I never would have been able to without it (or at least would have ended up with a much less elegant implementation and much more debugging) but many seem to find types to be either an impedance to getting things done quickly, or at best irrelevant. I know this is for the most part a religious war, but I would like my colleagues to arrive at their opinion from an informed perspective, which means learning that there's more to typeful programming than what is presented by java or c++. Finally, any comments on how to make the learning experience fun, engaging, and a positive experience would be greatly appreciated. Warren

3 2

ANN: wxHaskell 0.11.1
by Jeremy O'Donoghue 04 Jan '09

04 Jan '09

The wxHaskell development team is pleased to announce the release of wxHaskell 0.11.1, a Haskell binding for the wxWidgets GUI library. The Haskell support is built on a reasonably complete C language binding, which could be used as the basis for wxWidgets support on other languages/platforms which do not have easy mechanisms for linking with C++ code. The main highlights of wxHaskell 0.11.1 are: - Support for XRC resource files, allowing GUI design using a visual tool. Note that this is currently not type safe, and programs will crash if a widget is not cast to the correct type on loading. - Support for wxWidgets 2.8.x. Support for wxWidgets 2.4.2 is now dropped and wxHaskell will not compile against versions of wxWidgets prior to 2.6. This means that exploratory development using GHCi is no longer possible. Workaround is to continue to use older wxHaskell versions. - Support for GHC 6.10 - Preliminary support for Cabal / Hackage The full list of changes is provided at the end of this mail. Binary packages are available from the wxHaskell download site at http://sourceforge.net/project/showfiles.php?group_id=73133, for the following platforms: - Windows - OS X (Intel platform only) - Source code .tar.gz and .zip - Documentation (cross-platform) The wxHaskell libraries (wxcore and wx) are also available from Hackage (http://hackage.haskell.org) About wxHaskell --------------- wxHaskell is a Haskell binding to the wxWidgets GUI library for recent versions of the Glasgow Haskell Compiler. It provides a native look and feel on Windows, OS X and Linux, and a medium level programming interface. The main project page for wxHaskell is at http://wxhaskell.sourceforge.net. The latest source code for wxHaskell can always be obtained from http://darcs.haskell.org/wxhaskell. There are developer (wxhaskell-devel(a)lists.sourceforge.net and user (wxhaskell-users(a)lists.sourceforge.net) mailing lists, and a wiki page at http://haskell.org/haskellwiki/WxHaskell which can provide more information to those interested. The C language binding for wxHaskell was derived from an original C language binding created for the Eiffel programming language by the ELJ project (http://elj.sourceforge.net) Non backward compatible changes: - Preliminary Cabal / Hackage support - Added "--global" argument to configure script - Added "--user" argument to configure script - Changed wxhaskell official web page to Haskell wiki at http://haskell.org/haskellwiki/WxHaskell - Changed official darcs repository to code.haskell.org - Adapted the wxHaskell C-layer to work with wxWidgets 2.8 - Adapted some part of wxcore API to be able to refer to wxWidgets 2.8 documentation for wxcore functions - Added "TopLevelWindow", which mainly removes some functionality from "Frame" - Changed "--with-stc" argument to "--with-contrib" - Removed "Wave" type synonym Backward compatible additions: - Added support for using XRC resource files to load most controls and menus attached to frames. - Added sample file showing how to use XRC support to attach command handlers to menu items - Added sample file showing how to use properties with many controls. - Added "--enable-optimization" argument to configure script - Added "--O*" argument to configure script - Added "--enable-library-profiling" argument to configure script - Added "--p" argument to configure script - Added "-fvia-C" argument to configure script. And moved this compilation flag to configure script - Added Image / ByteString conversion functions - Adapted the configuration to work with GHC 6.10. - Changed "Var" type synonym from "IORef" to stm's "TVar" for thread safety - Changed "imageGetPixelArray" and "imageCreateFromPixelArray" to be more flexible. - Changed "Point", "Size", "Vector" and "Rect" to be type synonym. - Added "wxcMilliSleep". Now, "wxcAppUSleep" is deprecated. Use "wxcMilliSleep" instead - Added very experimental wxGraphicsContext support - Added wxSVGFileDC functions Bugfixes: - Applied DEPRECATED pragma to old deprecated functions. Just documented in Haddock before. - Fixed "processExecAsync" hangs Windows GUI-only program - Fixed Windows binary install problem when path with spaces (bug 1400488) - Probably fixed the applicattion failed to initialize properly when using Windows binary. -- Jeremy O'Donoghue jeremy.odonoghue(a)gmail.com -- Jeremy O'Donoghue jeremy.odonoghue(a)gmail.com

1 0