- Haskell-Cafe - Haskell.org

Dependency trickery
by Andrew Coppin 17 Jan '10

17 Jan '10

Suppose I write some code that can work with Gtk2hs or wxHaskell. How do I go about making that into a package? Specifically, how do I make it so that you don't have to install Gtk2hs *and* wxHaskell to build it? Do I have to actually make it into two seperate packages to do that? Also, supposing we have another package which requires the first, but doesn't care whether it's using Gtk2hs or wxHaskell. How do I do that? Obviously the answer depends on what happens in the previous step. If I make two seperate packages, for example, and they both export the same module, can I just add optional dependancies on both? Does Cabal support that? Not that I'm attempting to *do* this, you understand. I'd just like to know if it's possible...

3 3

AlternativePrelude extension
by Sjur Gjøstein Karevoll 17 Jan '10

17 Jan '10

Here's an idea I'd like to air: A new extension called AlternativePrelude. Like the NoImplicitPrelude extension we have already, this would disable implicitly importing the Prelude in every other module, but would also implicitly import a substitute. The purpose is to make it easier to play around with alternative preludes. Today we have to specify NoImplicitPrelude, but also explicitly import our alternative everywhere, making the transition between the different preludes that much more painful. With this new extension, the alternative prelude can be specified in the cabal file, or on the command line when building. This will hopefully make the alternative prelude efforts a little bit more mainstream, giving us more data we can use to consider modifications to the current standard prelude. I'm thinking the syntax would be something like AlternativePrelude="MyPrelude". This is new among the extensions in that it requires a parameter. An alternative is an ImplicitImport extension that doesn't disable the implicit importing of the Prelude, but while this does serve the same purpose as the AlternativePrelude proposal, I think it might be easier to use it for nefarious purposes. -- Sjur Gjøstein Karevoll

6 6

ANN: amqp-0.1
by Holger Reinhardt 17 Jan '10

17 Jan '10

Hi, I've built an AMQP library. It currently only works with RabbitMQ and supports most of the 0-8 spec. If you don't know that AMQP is, this is a good introduction: http://blogs.digitar.com/jjww/2009/01/rabbits-and-warrens/ I have not done much testing, so this should be regarded as alpha quality. Get it here: http://hackage.haskell.org/package/amqp For some reason it doesn't compile on Hackage. It says "At least the following dependencies are missing: network-bytestring >=0.1.2". Is there a way to solve this? Regards, Holger

2 1

Language simplicity
by Andrew Coppin 17 Jan '10

17 Jan '10

OK people, it's random statistics time! Haskell '98 apparently features 25 reserved words. (Not counting "forall" and "mdo" and so on, which AFAIK are not in Haskell '98.) So how does that compare to other languages? C: 32 C++: 62 Borland Turbo Pascal: ~50 [without the OOP extensions added later] Eiffel: 59 VB: The source I checked listed in excess of 120 reserved words, but I'm dubious as to how "reserved" they really are. (Is CInt really reserved? I doubt it!) It also depends wildly on which of the bazillion VB dialects you mean. Java: 50 JavaScript: 36 Smalltalk: 0 Lisp: AFAIK, there are no truly reserved words in Lisp, only predefined functions. (??) Python: 31 Ruby: 38 Tcl: Same analysis as for Lisp I believe. As you can see, this conclusively proves... something. Hmm, I wonder if there's some way to compare the size of the language specification documents? :-} PS. It comes as absolutely no surprise to me that C++ has the most keywords. But then, if I were to add AMOS Professional, that had well over 800 keywords at the last count...

25 56

Presentation about ICFP'09 programming contest
by Janis Voigtländer 17 Jan '10

17 Jan '10

Hi Haskell folk, If you are in Madrid tomorrow (Monday), you will likely not want to miss the video presentation by Andy Gill and his group about the techniques behind their running the ICFP'09 programming contest: http://www.program-transformation.org/PEPM10/SpecialFeature The presentation is scheduled to start 17:15, in the PEPM workshop room. Ciao, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ mailto:jv@iai.uni-bonn.de

1 0

Haskell Weekly News: Issue 146 - January 17, 2010
by jfredett＠gmail.com 17 Jan '10

17 Jan '10

--------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20100117 Issue 146 - January 17, 2010 --------------------------------------------------------------------------- Welcome to issue 146 of HWN, a newsletter covering developments in the [1]Haskell community. This has been a pretty light week in terms of discussion and announcments, but even in this comparative news lull we have the release of several new versions of packages. Inlcluding the start of a new IDE, some new job and graduate program openings, and some really excellent blog noise. Until next week, Haskellers, your Haskell Weekly News. Announcements haskell-src-exts 1.7.0. Niklas Broberg [2]announced a new release of haskell-src-exts Lite Haskell IDE. Mambo Banda [3]announced a new Haskell IDE, as part of his effort to learn Haskell. Functional Programming Bibliography. James Russell [4]announced the Functional Programming Bibliography, a new resource for the FP community. It, though in it's early stages, contains oer 1500 references (most of which are Haskell-related) to resources within the Functional Programming World. hakyll-1.0. Jasper Van der Jeugt [5]announced the release of version 1.0 of his static site generation tool, hakyll. From all (one) of us at the HWN, contragulations on the big 1.0! afv-0.0.0. Tom Hawkins [6]announced the initial release of 'Atom's Formal Verifier', a tool for verifying C code generated by Atom chp-2.0.0, chp-plus-1.0.0. Neil Brown [7]announced released new versions of his Comminicating Haskell Processes (CHP) packages. CHP is a message-passing concurrency library for Haskell. The major change in this version is a split of CHP into two packages, one containing core functionality, and one containing additional capabilities. Update for type-level library (0.2.4). Seyed Hosein Attarzadeh Niaki [8]announced a new version of his type-level library for type-level programming. This is a minor update to fix compatibility issues with dependencies. Two PhD positions in theoretical computer science. Alexandra Silva [9]announced vacancies for PhD positions in theoretical computer science at Leiden University. HaXml-1.20.1. Malcolm Wallace [10]announced a new, stable release of HaXml AST 2010 reminder--call for papers and presentations. John Hughes [11]reminded us of the AST 2010 call for papers and presentations. The submission deadline is only one week away. Job at Mylife. Julien Verlaguet [12]announced an availabiity for an OCaml developer at MyLife. Open Position (PhD student or Postdoc), U Tubingen, Germany. Torsten Grust [13]announced an open PhD/Postdoc position at the University of Tubingen in Germany. (ED: Apologies for the improper 'u' -- it should have an umlaut, but the compilation software is not cooperating) Palindromes 0.2. Johan Jeuring [14]announced a new release of the Palindromes package, including many new features and upgrades. Discussion From records to a type class. Taru Karttunen [15]asked about turning records into type classes, in an effort to make his bindings for Fuse more elegant. AlternativePrelude extension. Sjur Gjostein Karevoll [16]suggested a language pragma for alternative preludes. (ED: Again, apologies for the look-alike, but improper character). Blog noise [17]Haskell news from the [18]blogosphere. Blog posts from people new to the Haskell community are marked with >>>, be sure to welcome them! * Holumbus: [19]Linking Hayoo! Search Results. * Jeff Heard: [20]SPDE, Semi-functional programming for Processing. * Neil Mitchell: [21]Using .ghci files to run projects. * Neil Mitchell: [22]Better .ghci files. * Neil Brown: [23]Darcs. * Neil Brown: [24]Splitting CHP. * Darcs: [25]darcs weekly news #50. * Bryan O'Sullivan: [26]Progress on GHC's I/O manager. * Michael Snoyman: [27]New blog address. * Conal Elliot: [28]Exact Numeric Integration. I had missed this one last week (amidst the myriad, I failed to see it), so it is presented in this week's edition. Quotes of the Week * Jafet: <gwern> closures are a poor man's object <ddarius> objects are a poor man's closure <Berengal> objects are a rich man's structs <Jafet> Poor programmers should start unions * monochrom: Time flies like an Arrow. Space leaks like a Monad. * monochrom: Haskell already has natural language support. Just switch your natural language to simple-typed lambda calculus. * edwardk: @remember Baugn @remember lambdabot fasta says: I think the @remember command is way overused. * Berengal: data Neither a b = Left | Right * Cale: Removing monad comprehensions was actually the snowball which caused the avalanche of fail in Haskell 98 About the Haskell Weekly News New editions are posted to [29]the Haskell mailing list as well as to [30]the Haskell Sequence and [31]Planet Haskell. [32]RSS is also available, and headlines appear on [33]haskell.org. To help create new editions of this newsletter, please see the information on [34]how to contribute. Send stories to jfredett . at . gmail . dot . com. The darcs repository is available at darcs get [35]http://patch-tag.com/r/jfredett/HWN2/pullrepo HWN2 . References 1. http://haskell.org/ 2. http://article.gmane.org/gmane.comp.lang.haskell.cafe/69197 3. http://article.gmane.org/gmane.comp.lang.haskell.cafe/69176 4. http://article.gmane.org/gmane.comp.lang.haskell.cafe/69153 5. http://article.gmane.org/gmane.comp.lang.haskell.cafe/69106 6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/68995 7. http://article.gmane.org/gmane.comp.lang.haskell.cafe/68943 8. http://article.gmane.org/gmane.comp.lang.haskell.cafe/68940 9. http://article.gmane.org/gmane.comp.lang.haskell.general/17727 10. http://article.gmane.org/gmane.comp.lang.haskell.general/17725 11. http://article.gmane.org/gmane.comp.lang.haskell.general/17724 12. http://article.gmane.org/gmane.comp.lang.haskell.general/17723 13. http://article.gmane.org/gmane.comp.lang.haskell.general/17722 14. http://article.gmane.org/gmane.comp.lang.haskell.general/17721 15. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/69207 16. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/69194 17. http://planet.haskell.org/ 18. http://haskell.org/haskellwiki/Blog_articles 19. http://holumbus.fh-wedel.de/blog/?p=30 20. http://vis.renci.org/jeff/2010/01/15/spde-semi-functional-programming-for-p… 21. http://neilmitchell.blogspot.com/2010/01/using-ghci-files-to-run-projects.h… 22. http://neilmitchell.blogspot.com/2010/01/better-ghci-files.html 23. http://chplib.wordpress.com/2010/01/14/darcs/ 24. http://chplib.wordpress.com/2010/01/11/splitting-chp/ 25. http://blog.darcs.net/2010/01/darcs-weekly-news-50.html 26. http://www.serpentine.com/blog/2010/01/11/progress-on-ghcs-io-manager/ 27. http://snoyberg.wordpress.com/2010/01/10/new-blog-address/ 28. http://conal.net/blog/posts/exact-numeric-integration/ 29. http://www.haskell.org/mailman/listinfo/haskell 30. http://sequence.complete.org/ 31. http://planet.haskell.org/ 32. http://sequence.complete.org/node/feed 33. http://haskell.org/ 34. http://haskell.org/haskellwiki/HWN 35. http://patch-tag.com/r/jfredett/HWN2/pullrepo%20HWN2

1 0

Data.Ring -- Pre-announce
by John Van Enk 17 Jan '10

17 Jan '10

Hi List, I recently needed a ring structure (circular list with bi-directional access) and didn't see anything obvious on Hackage. I threw something together fairly quickly and would like some feedback before tossing it on Hackage. I'd really appreciate if some one would: 1. make sure the code looks goodish (127 lines with full docs) 2. make sure my tests look saneish If I hear nothing, I'll assume wild support and push to Hackage. Code: http://github.com/sw17ch/data-ring/blob/master/src/Data/Ring.hs Tests: http://github.com/sw17ch/data-ring/blob/master/tests/quickcheck.hs Package Root: http://github.com/sw17ch/data-ring Thanks ahead of time, John Van Enk

16 25

What's going on here?
by michael rice 17 Jan '10

17 Jan '10

I don't see anything wrong with this function, which just subtracts 1 from the first element of an Int list (if there is a first element). Michael My function: dropFirst :: [Int] -> [Int] dropFirst [] = [] dropFirst (x:xs) = (x-1) : xs My output: > :l dropfirst [1 of 1] Compiling Main ( dropfirst.hs, interpreted ) Ok, modules loaded: Main. *Main> dropFirst [3 4 5 6] <interactive>:1:11: No instance for (Num (t -> t1 -> t2 -> Int)) arising from the literal `3' at <interactive>:1:11-17 Possible fix: add an instance declaration for (Num (t -> t1 -> t2 -> Int)) In the expression: 3 4 5 6 In the first argument of `dropFirst', namely `[3 4 5 6]' In the expression: dropFirst [3 4 5 6] *Main>

3 3

ANNOUNCE: nntp 0.0.3
by Maciej Piechotka 17 Jan '10

17 Jan '10

Rather a 'bug-fix' release. Intended to add additional symbols to group names. I'd like to add support for explicit fetching some headers only and giving the message a more MIME-like behaviour but I'm afraid there is nowhere written how XHDR/HDR would behave with multiline headers nor I found a suitable package (mime[1] seems to not include even parsing the headers only and mime-string[2] does not take into account comments which may or may not be a problem with Message-ID comparaison). Regards [1] http://hackage.haskell.org/package/mime [2] http://hackage.haskell.org/package/mime-string

1 0

RFC: Space-leak-free, efficient symbol table implementation.
by Thomas Schilling 16 Jan '10

16 Jan '10

Hello Café, Symbol tables are a very common data structure in compilers but the most common implementation uses a hash table as a global variable which results in a space leak. If we decide to use several symbol tables we still cannot join different symbol tables. After some Googling I found the following implementation. It could still be argued that there are some smaller space leaks left, but decide for yourself. The use case I have in mind is a collection of several long-running compiler worker threads, that for the most part write their result to disk but may occasionally need to communicate with each other (and agree on symbol identities.) I'd appreciate comments / code review on the following code. I think it's fairly well-commented. Thanks, / Thomas {-# LANGUAGE BangPatterns #-} {-# OPTIONS_GHC -funbox-strict-fields #-} -- | -- Module : Data.Atom.UF -- Copyright : (c) Thomas Schilling 2010 -- License : BSD-style -- -- Maintainer : nominolo(a)gmail.com -- Stability : experimental -- Portability : portable -- -- Symbols without a central symbol table. -- -- Symbols provide the following efficient operations: -- -- - /O(1)/ equality comparison (in practise) -- - /O(1)/ ordering comparison (in practise) -- - /O(n)/ creation -- -- This can be implemented by using a global variable mapping strings -- to symbols and a counter assigning ids to symbols. However, this -- has two problems: -- -- 1. It has a space leak. No symbols can ever be removed from this -- table. For example, if we add the symbol @\"foo\"@ the first -- time it might get assigned id 1, if we then delete it and -- insert it again it might get assigned id 42. However, there -- may still be symbols in memory which got assigned id 1. -- Instead, symbols should be garbage collected like other data. -- Using weak pointers has bad effects on performance due to -- garbage collector overhead. -- -- 2. It is not reliable to compare symbols created using different -- symbol tables. They would most likely get assigned different -- ids. -- -- This implementation of symbols allows *optional* use of a symbol -- table. If a symbol table is used, this implementation will tend to -- use less memory and its operations will be a little bit faster at -- the beginning. For longer runs, it won't make a big difference -- though, since the representation is self-optimising. -- -- Inspired by Richard O'Keefe's message to Erlang's eeps mailing list -- <http://www.erlang.org/cgi-bin/ezmlm-cgi/5/057>, which in turn was -- inspired by the Logix implementation of Flat Concurrent Prolog. -- -- -- * Implementation -- -- Each symbol is represented a pointer to the symbol info, which -- consists of: -- -- * a 'String' -- * a 'Hash' -- * a null-able parent pointer to an equivalent symbol info -- -- Creating the same symbol twice will at first be represented as two -- different entities. -- -- @ -- .----+-------+-----. -- A -----> | 42 | "foo" | nil | -- '----+-------+-----' -- B --. -- '--> .----+-------+-----. -- C -----> | 42 | "foo" | nil | -- '----+-------+-----' -- @ -- -- (Note that @A@, @B@ and @C@ are @IORefs@.) -- -- When comparing @A@ and @B@ we use the following properties: -- -- 1. If @A@ and @B@ are identical then they must be equal. -- -- 2. If they point to the same object, they must equal. -- -- 3. If they have different hashes, they are different. -- -- Unless there is a hash collision, we can decide equality and -- ordering for all symbols that have been built with the same hash -- table. -- -- If the two objects have no parent, have the same hash, and the same -- string, we now make one the first the parent of the other and -- update the pointer of @B@ accordingly. If there are no references -- to the second object left it can now be garbage collected. -- -- If an object already has a parent pointer we follow each object's -- parents to the roots and compare the roots. This process might -- again result in updates to @A@ or @B@ and various parent pointers. -- -- In the example above, after @A == B@ we have: -- -- @ -- .----+-------+-----. -- A -----> | 42 | "foo" | nil | -- .--> '----+-------+-----' -- B --' ^ -- .----+-------+--|--. -- C -----> | 42 | "foo" | * | -- '----+-------+-----' -- @ -- -- After @C == A@ or @C == B@ we have. -- -- @ -- A -----> .----+-------+-----. -- .--> | 42 | "foo" | nil | -- B --'.-> '----+-------+-----' -- | ^ -- | .----+-------+--|--. -- C ---' | 42 | "foo" | * | -- '----+-------+-----' -- @ -- -- The second object will now be garbage collected. -- -- In fact, after the first @A == B@, the remaining updates could use -- some help from the garbage collector. This could be done by -- somehow forcibly (and unsafely) replacing the second object by an -- update frame and then rely on the GC's indirection shortening -- feature. This is /very/ unsafe, since some code may rely \"know\" -- that the object is already evaluated. E.g., C's pointer could be -- tagged (c.f. \"Faster Laziness Using Dynamic Pointer Tagging\"). -- It /might/ work if we can match the physical layout of both -- structures, but it's equally likely that hell freezes over, so I'll -- leave that as an exercise for more braver hackers. -- -- * TODO -- -- - generalise to arbitrary hashable objects. need not be -- restricted to 'String'. -- -- - make thread-safe. (we only need a lock for the uncommon cases) -- -- - make sure the pointer update code is correct and has no bad -- cases -- -- - implement IntMap variant\/wrapper that respects that two -- different objects may have the same key (however unlikely). -- module Data.Atom.UF ( Symbol, intern, internInto, SymTab(..) ) where import Data.Word ( Word32 ) import Data.Char ( ord ) import Data.Bits ( xor ) import Data.IORef import System.IO.Unsafe import Control.Monad -- ( unless ) import System.Mem.Weak import System.Mem import Data.Maybe -- ------------------------------------------------------------------- -- Public API: -- | A symbol. newtype Symbol = Symbol (IORef SymbolInfo) instance Eq Symbol where x == y = cmpSymbol x y == EQ instance Ord Symbol where compare = cmpSymbol instance Show Symbol where show = showSym -- | Create a new local symbol. For best performance use -- 'internInto' together with a symbol table / map. intern :: String -> Symbol class SymTab s where lookupSymbol :: s -> String -> Maybe Symbol insertSymbol :: String -> Symbol -> s -> s -- | Insert a symbol into an existing table. internInto :: SymTab s => s -> String -> (s, Symbol) -- ------------------------------------------------------------------- -- Internals data SymbolInfo = SymInfo {-# UNPACK #-} !Word32 -- hash {-# UNPACK #-} !(IORef Link) -- parent [really unpack]? String type Link = Maybe SymbolInfo internInto st str = case lookupSymbol st str of Just sym -> (st, sym) _ -> let sym = intern str in (insertSymbol str sym st, sym) showSym :: Symbol -> String showSym (Symbol r) = unsafePerformIO $ do -- dupable/inline is fine, too, since the string never changes (SymInfo _ _ str) <- readIORef r return str intern s = unsafePerformIO $ do lnk <- newIORef Nothing r <- newIORef $ SymInfo (hash s) lnk s return (Symbol r) mkSymbolInfo :: String -> SymbolInfo mkSymbolInfo s = unsafePerformIO $ do lnk <- newIORef Nothing return $ SymInfo (hash s) lnk s cmpSymbol :: Symbol -> Symbol -> Ordering cmpSymbol (Symbol r1) (Symbol r2) | r1 == r2 = EQ | otherwise = unsafePerformIO $ do -- We only read. It should be safe to use unsafeInlineIO for -- the two reads. sym1@(SymInfo h1 l1 s1) <- readIORef r1 sym2@(SymInfo h2 l2 s2) <- readIORef r2 case h1 `compare` h2 of -- If the hashes are different they cannot be the same symbol LT -> return LT GT -> return GT EQ | sameSym sym1 sym2 -> -- The two references are not the same, but they point to -- the same object. That's fine, we can't optimise any -- further. return EQ -- END OF COMMON CASE -- -- If the symbols have been built using the same symbol table -- we will only reach this case if we have a hash collision or -- the symbols were built from different symbol tables. -- -- TODO: Extract into NOINLINE function, wrap unsafePerformIO, -- and use an MVar-based lock. | otherwise -> do -- The hashes are the same. It could be a collision, or the -- symbol was created using a different symbol table. -- -- Case 1: The symbols have already be joined, but this -- Symbol's IORef still points to the old version. We can -- determine this by following the union/find structure. rep1 <- repr sym1 rep2 <- repr sym2 let string_cmp = s1 `compare` s2 -- lazy! if sameSym rep1 rep2 || string_cmp == EQ then do -- They should in fact be the same symbol. Update the -- atoms and the symbol infos if necessary. -- TODO: Use MVar / lock. unless (sameSym sym1 rep1) $ do writeIORef r1 rep1 writeIORef l1 (Just rep1) -- path shortening unless (sameSym sym2 rep1) $ do writeIORef r2 rep1 writeIORef l2 (Just rep1) return EQ else do -- They are not the same, and they shouldn't return string_cmp {-# NOINLINE cmpSymbol #-} -- We abuse the fact that IORefs give us an identity (i.e., observable -- sharing) and that we need the IORef anyway. sameSym :: SymbolInfo -> SymbolInfo -> Bool sameSym (SymInfo _ r1 _) (SymInfo _ r2 _) = r1 == r2 repr :: SymbolInfo -> IO SymbolInfo repr sym@(SymInfo _ r _) = do parent <- readIORef r -- TODO: perform path shortening. case parent of Nothing -> return sym Just sym' -> repr sym' test1 = do let s1@(Symbol r1) = intern "foo" s2@(Symbol r2) = intern "foo" print $ r1 == r2 -- should be False -- create a weak reference to the second symbol, so we can observe -- when it is garbage collected w <- mk_weak =<< readIORef r2 print $ s1 == s2 -- should print True print =<< liftM2 sameSym (readIORef r1) (readIORef r2) -- should print True putStrLn "GCing" performGC -- this should print goodbye, representing the -- fact that the second symbol has been garbage -- collected. print . isJust =<< deRefWeak w -- should print False (object has been collected) where mk_weak o = mkWeakPtr o (Just (putStrLn "goodbye")) -- ------------------------------------------------------------------- -- Fowler / Noll / Vo (FNV) hash. Original code expected 'unsigned -- char' input. Don't know whether it behaves worse for unicode -- chars. hash :: String -> Word32 hash str = go magic_start (map ord str) where magic_start = 2166136261 :: Word32 go :: Word32 -> [Int] -> Word32 go !h [] = h go !h (c:cs) = go ((h * 16777619) `xor` fromIntegral c) cs

2 1

FASTER primes (was: Re: Code and Perf. Data for Prime Finders (was: Genuine Eratosthenes sieve))
by Will Ness 16 Jan '10

16 Jan '10

apfelmus <apfelmus <at> quantentunnel.de> writes: > ~~ This is a repost, with apologies to anyone who sees this twice (I've replied to a two years old thread, and it doesn't show up in GMANE as I thought it would). ~~ > Dave Bayer wrote: > > What I'm calling a "venturi" > > > > venturi :: Ord a => [[a]] -> [a] > > > > merges an infinite list of infinite lists into one list, under the > > assumption that each list, and the heads of the lists, are in > > increasing order. > > > > I wrote this as an experiment in coding data structures in Haskell's > > lazy evaluation model, rather than as explicit data. The majority of the > > work done by this code is done by "merge"; the multiples of each prime > > percolate up through a tournament consisting of a balanced tree of > > suspended "merge" function calls. In order to create an infinite lazy > > balanced tree of lists, the datatype > > > > data List a = A a (List a) | B [a] > > > > is used as scaffolding. One thinks of the root of the infinite tree as > > starting at the leftmost child, and crawling up the left spine as > > necessary. > > After some pondering, the List a data structure for merging is really > ingenious! :) Here's a try to explain how it works: > > The task is to merge a number of sorted and infinite lists when it's > known that their heads are in increasing order. In particular, we want > to write > > primes = (2:) $ diff [3..] $ venturi $ map multiple primes > > Thus, we have a (maybe infinite) list > > xss = [xs1, xs2, xs3, ...] > > of infinite lists with the following properties > > all sorted xss > sorted (map head xss) > > where sorted is a function that returns True if the argument is a > sorted list. A first try to implement the merging function is > > venturi xss = foldr1 merge xss > = xs1 `merge` (xs2 `merge` (xs3 `merge` ... > > where merge is the standard function to merge to sorted lists. > > However, there are two problems. The first problem is that this doesn't > work for infinite lists since merge is strict in both arguments. But > the property head xs1 < head xs2 < head xs3 < ... we missed to exploit > yet can now be used in the following way > > venturi xss = foldr1 merge' xss > > merge' (x:xt) ys = x : merge xt ys > > In other words, merge' is biased towards the left element > > merge' (x:_|_) _|_ = x : _|_ > > which is correct since we know that (head xs < head ys). > > The second problem is that we want the calls to merge to be arranged > as a balanced binary tree since that gives an efficient heap. It's not > so difficult to find a good shape for the infinite tree, the real > problem is to adapt merge' to this situation since it's not associative: > > ...... > > The problem is that the second form doesn't realize that y is also > smaller than the third argument. In other words, the second form has to > treat more than one element as "privileged", namely x1,x2,... and y. > This can be done with the aforementioned list data structure > > data People a = VIP a (People a) | Crowd [a] > > The people (VIPs and crowd) are assumed to be _sorted_. Now, we can > start to implement > > merge' :: Ord a => People a -> People a -> People a Hi, ... replying to a two-years-old post here, :) :) and after consulting the full "VIP" version in haskellwiki/Prime_Numers#Implicit_Heap ... It is indeed the major problem with the merged multiples removing code (similar one to Richard Bird's code from Melissa O'Neill's JFP article) - the linear nature of foldr, requiring an (:: a->b->b) merge function. To make it freely composable to rearrange the list into arbitrary form tree it must indeed be type uniform (:: a->a->a) first, and associative second. The structure of the folded tree should be chosen to better suit the primes multiples production. I guestimate the total cost as Sum (1/p)*d, where p is a generating prime at the leaf, and d the leaf's depth, i.e. the amount of merge nodes its produced multiple must pass on its way to the top. The structure used in your VIP code, 1+(2+(4+(8+...))), can actually be improved upon with another, (2+4)+( (4+8)+( (8+16)+...)), for which the estimated cost is about 10%-12% lower. This can be expressed concisely as the following: primes :: () -> [Integer] primes () = 2:primes' where primes' = [3,5] ++ drop 2 [3,5..] `minus` comps mults = map (\p-> fromList [p*p,p*p+2*p..]) $ primes' (comps,_) = tfold mergeSP (pairwise mergeSP mults) fromList (x:xs) = ([x],xs) tfold f (a: ~(b: ~(c:xs))) = (a `f` (b `f` c)) `f` tfold f (pairwise f xs) pairwise f (x:y:ys) = f x y : pairwise f ys mergeSP (a,b) ~(c,d) = let (bc,b') = spMerge b c in (a ++ bc, merge b' d) where spMerge u@(x:xs) w@(y:ys) = case compare x y of LT -> (x:c,d) where (c,d) = spMerge xs w EQ -> (x:c,d) where (c,d) = spMerge xs ys GT -> (y:c,d) where (c,d) = spMerge u ys spMerge u [] = ([], u) spMerge [] w = ([], w) with ''merge'' and ''minus'' defined in the usual way. Its run times are indeed improved 10%-12% over the VIP code from the haskellwiki page. Testing was done by running the code, interpreted, inside GHCi. The ordered "split pairs" representing ordered lists here as pairs of a known, finite (so far) prefix and the rest of list, form a _monoid_ under mergeSP. Or with wheel, primes :: () -> [Integer] primes () = 2:3:5:7:primes' where primes' = [11,13] ++ drop 2 (rollFrom 11) `minus` comps mults = map (\p-> fromList $ map (p*) $ rollFrom p) $ primes' (comps,_) = tfold mergeSP (pairwise mergeSP mults) fromList (x:xs) = ([x],xs) rollFrom n = let x = (n-11) `mod` 210 (y,_) = span (< x) wheelSums in roll n $ drop (length y) wheel wheelSums = roll 0 wdiffs roll = scanl (+) wheel = wdiffs ++ wheel wdiffs = 2:4:2:4:6:2:6:4:2:4:6:6:2:6:4:2:6:4:6:8:4:2:4:2: 4:8:6:4:6:2:4:6:2:6:6:4:2:4:6:2:6:4:2:4:2:10:2:10:wdiffs Now _this_, when tested as interpreted code in GHCi, runs about 2.5x times faster than Priority Queue based code from Melissa O'Neill's ZIP package mentioned at the haskellwiki/Prime_Numbers page, with about half used memory reported, in producing 10,000 to 300,000 primes. It is faster than BayerPrimes.hs from the ZIP package too, in the tested range, at about 35 lines of code in total. ~~ This is a repost, with apologies to anyone who sees this twice (I've replied to a two years old thread, and it doesn't show up in GMANE as I thought it would). ~~

5 69

Arch Haskell News: Nov 23 2008
by Don Stewart 16 Jan '10

16 Jan '10

News about Haskell on Arch Linux * Arch now has 734 Haskell packages now * That’s an increase of 29 new packages in the last 8 days! * 3.6 new Haskell releases are occuring each day. Noteworthy, * haskell-hledger-0.2: “A ledger-compatible text-based accounting tool.” * gitit-0.3.1: “Wiki using HAppS, git, and pandoc.” * lhc-20081121: “Lhc Haskell Compiler” * haskell-hosc-0.6: “Haskell Open Sound Control” * haskell-flickr-0.3.2: “Haskell binding to the Flickr API” * haskell-delicious-0.3.2: “Accessing the del.icio.us APIs from Haskell (v2)” * haskell-mediawiki 0.2.3: “Interfacing with the MediaWiki API” * darcs-2.1.2.2: “a distributed, interactive, smart revision control system” Full update list, http://archhaskell.wordpress.com/2008/11/24/arch-haskell-news-nov-23-2008/ -- Don

24 56

addFinalizer to which object?
by Henning Thielemann 16 Jan '10

16 Jan '10

The documentation of System.Mem.Weak.addFinalizer suggests to me, that this function is very fragile, because the object we track, might be optimized away. In my case this applies. I have a resource that is needed for generating chunks of a lazy byte string. If the byte string is created completely or the byte string cannot be accessed anymore, this resource must be freed. It must also be freed within Haskell code, thus addForeignPtrFinalizer does not help. To illustrate that I have attached a small example, where I use a StablePtr as resource, that points to a list. This Haskell list is read from C code and written to a chunk of a lazy ByteString. A Haskell function creates the ByteString lazily and calls the C function for every new chunk. I have added a finalizer to the StablePtr itself. That works without optimization, but using optimization the finalizer is run immediately and the program aborts with segmentation fault. Thus my question: How to get reliable finalization? #include "ProcessList_stub.h" /* The function copies elements from a Haskell list to a piece of memory and returns the number of bytes that could be fetched. */ int copy_list_to_chunk (unsigned long int n, HsStablePtr list, char *p) { unsigned long int k = n; while (k>0) { if (!get_next_element(list, p)) {break; } p++; k--; } return (n-k); } {- # generate C stubs ghc -c ProcessList.hs # generate executable ghc -O --make ProcessChunk.c ProcessList.hs -} {- Use a C function for filling chunks of a lazy ByteString with data from a Haskell list. A StablePtr is needed to pass the list to C and back to Haskell. Somehow we must assert that the StablePtr is deleted and the list can be garbage collected, once the ByteString is constructed. We concatenate infinitely many such lists, thus many StablePtrs and referenced lists must be freed. Use addFinalizer? To which object shall I add the finalizer? Without optimization adding the finalizer to the StablePtr works, with optimization, its finalizer is run too early. I also tried to add the finalizer to the end of the list, which is not quite correct, but then the finalizer is run never. Whatever I tried: Finalizer is run immediately or never. What is the right way? -} {-# LANGUAGE ForeignFunctionInterface #-} module Main where import qualified Data.ByteString as B import qualified Data.ByteString.Internal as BI import qualified Data.ByteString.Lazy as BL import qualified Data.ByteString.Lazy.Internal as BLI import System.IO.Unsafe (unsafePerformIO, unsafeInterleaveIO, ) import System.Mem.Weak (addFinalizer, ) import Foreign.StablePtr (StablePtr, newStablePtr, freeStablePtr, deRefStablePtr, ) import Foreign.Storable (poke, ) import Foreign.C.Types (CULong, ) import Foreign.Ptr (FunPtr, Ptr, nullPtr, castPtr, ) import Data.IORef (IORef, newIORef, readIORef, writeIORef, ) import Data.Word (Word8, Word32, ) import Control.Monad (liftM2, ) getNextElement :: StablePtr (IORef [Word8]) -> Ptr Word8 -> IO Bool getNextElement stable elemPtr = do listRef <- deRefStablePtr stable xt <- readIORef listRef case xt of [] -> return False x:xs -> do poke elemPtr x writeIORef listRef xs return True foreign export ccall "get_next_element" getNextElement :: StablePtr (IORef [Word8]) -> Ptr Word8 -> IO Bool foreign import ccall "copy_list_to_chunk" copyListToChunk :: CULong -> StablePtr (IORef [Word8]) -> Ptr Word8 -> IO CULong chunkSize :: Int chunkSize = 13 byteStringFromList :: [Word8] -> BL.ByteString byteStringFromList list = unsafePerformIO $ do stable <- newStablePtr =<< newIORef list addFinalizer stable (putStrLn "free stable pointer" >> freeStablePtr stable) let go = unsafeInterleaveIO $ do v <- BI.createAndTrim chunkSize $ fmap fromIntegral . copyListToChunk (fromIntegral chunkSize) stable fmap (BLI.chunk v) $ if B.length v < chunkSize then return BL.empty else go go main :: IO () main = print $ BL.unpack $ -- BL.take 1000 $ BL.concat $ map (BL.take 42 . byteStringFromList . iterate (1+)) (iterate (1+) 0)

1 0

Naïve Parallelization: C++ vs Haskell
by Jon Harrop 16 Jan '10

16 Jan '10

I felt the previous comparison left a little to be desired so I have repeated the experiment on 8 cores using the original Haskell code and giving results for 9, 12 and 13 levels of spheres: http://flyingfrogblog.blogspot.com/2010/01/naive-parallelization-c-vs-haske… -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e

1 0

From records to a type class
by Taru Karttunen 16 Jan '10

16 Jan '10

Hello I am wrapping Fuse in a pure Haskell binding and have some issues with the interface. Currently I am using a record for managing the callback functions, but I think there may be a more elegant formulation. Any ideas how to formulate the Fuse record as a typeclass elegantly? Some notes: + TFs not FDs. + Separate fh* implementations (raw/stableptr/custom implemented by user) easily selected by the library user. + Readable type errors. + One large typeclass + overlapping instances works, but seems hacky. + MPTCs will probably work but is it good form to use them with TFs? + Or is using a record better currently? ps. Note that the interface is very much simplified for the sake of the discussion. (e.g. [Word8] instead of ByteString). > import Data.Word > > data IsDir > data IsFile > > type Ino = Word32 > data Attr = Attr {} > > data Fuse (fh :: * -> *) = Fuse { > open :: Ino -> IO (fh IsFile) > , read :: Ino -> fh IsFile -> Word64 -> Word32 -> IO [Word8] > , opendir :: Ino -> IO (fh IsDir) > , getattr :: forall fileOrDir. Ino -> fh fileOrDir -> IO Attr > -- ... > > -- File handle management > , fhFree :: Word64 -> IO () > , fhAlloc :: forall any. fh any -> IO Word64 > , fhRef :: forall any. Word64 -> IO (fh any) > } > > -- Optimally get rid of this wrapping... > newtype RawFH t = R { r :: Word64 } > noFhEmpty :: Fuse RawFH > noFhEmpty = Fuse { fhFree = \_ -> return () > , fhAlloc = return . r > , fhRef = return . R > } > > stablePtrEmpty :: Fuse anyfh > stablePtrEmpty = Fuse {} -- implement fh* with StablePtrs (omitted) > > -- User file handle type might be like this: > > data Obj t where > Dir :: {} -> Obj IsDir > File :: {} -> Obj IsFile - Taru Karttunen

2 2

Capped lists and |append|
by John Millikin 15 Jan '10

15 Jan '10

Earlier today I uploaded the capped-list package; I didn't think there would be any interest, since it's a relatively trivial data structure, but already there's been three emails and an IRC convo about it. In short, this is Heinrich Apfelmus's "Train" type from <http://www.haskell.org/pipermail/haskell-cafe/2009-December/069895.html>, which showed up in a thread I posted regarding lazy error handling <http://www.haskell.org/pipermail/haskell-cafe/2009-November/069825.html>. The structure of a Train / CappedList (I like my name better) is: data Train a b = Wagon a (Train a b) | Loco b data CappedList cap a = Next a (CappedList cap a) | Cap cap Since uploading, there's been a big problem pointed out to me regarding this structure, namely the possible definitions of |append|. Because the list terminus is itself a value, but isn't / shouldn't be the same type as the elements, either obvious implementation will drop it. append :: CappedList cap a -> CappedList cap a -> CappedList cap a append (Cap 0) (Cap 1) = -- either (Cap 0) or (Cap 1), but information has been lost This problem can be solved using an unusual type signature for |append|, such as: append :: CappedList cap1 a -> CappedList cap2 a -> (cap1, CappedList cap2 a) or by declaring that a capped list is truly "capped": append :: CappedList cap a -> CappedList cap2 b -> CappedList cap a but these makes defining a reasonable |concat| difficult. Any ideas? This seems like a useful structure, since several people have described it, but some of the semantics seem troublesome.

6 7

ANN: haskell-src-exts 1.7.0
by Niklas Broberg 15 Jan '10

15 Jan '10

Fellow Haskelleers, As I was asked to start spamming again, I'm hereby pleased to announce the release of haskell-src-exts-1.7.0! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts For users of hsx, this version works fine with hsx-0.6.1. Since I haven't sent out one of these announcements in a while, here's the complete CHANGELOG since the previous announcement: ** 1.7.x 1.6.1 --> 1.7.0 =============== * Operators defined on the form (a `op` b) c = ... could not be handled by the (annotated) AST, nor the parser. I had to change the definition of the AST node for InfixMatch to allow a list of right-hand subpatterns, i.e. InfixMatch l (Pat l) (Name l) (Pat l) ... has become InfixMatch l (Pat l) (Name l) [Pat l] ... I also had an epiphany and fixed the issue that would arise with exact printing of prefix definitions including parentheses (e.g. (foo x) y = ...), so that now works too! ** 1.6.x 1.6.0 --> 1.6.1 =============== * UnicodeSyntax now works not only for identifiers, but also for ->, <- and =>, as well as Arrows arrows and kind stars. (And before you send me bug reports for this one, do check that your version of readFile is Unicode aware, i.e. you use GHC 6.12 or the utf8-string version). 1.5.3 --> 1.6.0 =============== * (=~=) turns out to be too general at Functor (for intuitive and not technical reasons), so is specialised to Annotated to closer mirror the original intention. * applyFixities is hoisted to a monad, and now fails on ambiguous infix expressions. ** 1.5.x 1.5.2 --> 1.5.3 =============== * Several small bug fixes in the exact printer, and fail more gracefully if the number of srcInfoPoints doesn't match the needs of the node. 1.5.1 --> 1.5.2 =============== * Fix a bug in the exact printer that made it always print the first token at position (0,0). * In fixing the above, Annotated is now a superclass of ExactP. It was already a superclass in spirit, and nothing can break from this since ExactP is only exported abstractly. 1.5.0 --> 1.5.1 =============== * The pretty printer now introduces parentheses for non-atomic arguments to function application. Note that infix applications are left untouched, no parentheses will be inserted there, as it is assumed that fixities are already properly resolved. * Fix a bug in the pretty printer where view patterns and n+k patterns were not properly parenthesised. 1.4.0 --> 1.5.0 =============== * Add support for acting on LINE pragmas while parsing, i.e. updating the source position according to info given in LINE pragmas. This is done conditionally based on a new flag ignoreLinePragmas in the ParseMode, hence the need to increase the major version. ** 1.4.x 1.3.5 --> 1.4.0 =============== * The AST node for Proc in the simple AST is changed to include a SrcLoc argument, to make it consistent with similar nodes e.g. Lambda. This is specifically needed for transformation of patterns in HSX. ** 1.3.x 1.3.4 --> 1.3.5 =============== * Added an entry point in the parser for statements, and an instance Parseable Stmt to go with it. * Ensured that .Annotated exports all relevant parseXXX(WithYYY) functions. 1.3.3 --> 1.3.4 =============== * Operator fixities are now resolved in patterns. 1.3.2 --> 1.3.3 =============== * Fixes a bug where qualified keywords are rejected even if the extension that enables the keyword in question is not turned on. 1.3.0 --> 1.3.2 =============== (Let's forget 1.3.1 ever existed.) * Fix a bug where declarations of infix operators were not properly merged as FunBinds.

2 3

Re: [Haskell] ANN: Streaming Component Combinators 0.4
by Mario Blažević 15 Jan '10

15 Jan '10

Henning Thielemann wrote: > Mario Blažević schrieb: >> Version 0.4 of Streaming Component Combinators, or SCC for short, has >> been released on Hackage. Get it at >> >> http://hackage.haskell.org/package/scc >> >> There isn't much new high-level functionality compared to the >> previous version, but the implementation has been heavily refactored and >> the foundations completely replaced. > > Stupid question: Is it related to Arrows? Not really. You might say it's more general than arrows, because the streaming components are not restricted to a single input and single output type. On the other hand, they are all specific to stream processing, much like Fudgets and Yampa which are arrow-based. I suppose the Transducer data type [1] could be made an Arrow instance, which would let me rename the 'connect' combinator [2] to (>>>). I'll have a look at Yampa to see if I can harvest more combinator names, thank you! [1] http://hackage.haskell.org/packages/archive/scc/0.4/doc/html/Control-Concur… [2] http://hackage.haskell.org/packages/archive/scc/0.4/doc/html/Control-Concur…

2 1

Haddock question: hiding internal instances
by Niklas Broberg 15 Jan '10

15 Jan '10

Hi all, The question I have is this: How can I get Haddock to omit listing instances of package-internal data types for exported classes? Here's an example of what I mean: http://hackage.haskell.org/packages/archive/haskell-src-exts/1.6.0/doc/html… At the very end of the rather extensive list of instances, you'll find the following: SrcInfo loc => Pretty (PAsst loc) SrcInfo loc => Pretty (PType loc) SrcInfo loc => Pretty (PContext loc) SrcInfo loc => Pretty (ParseXAttr loc) SrcInfo loc => Pretty (PFieldUpdate loc) SrcInfo loc => Pretty (PExp loc) All these data types are internal to the package, and the module they live in is marked with 'hide'. As expected no links are generated to any documentation for these data types, but I want them removed from this list entirely. They are internal after all, so what's the point of listing them? How can I achieve this? Cheers, /Niklas

3 3

Hackage strangeness
by Roel van Dijk 15 Jan '10

15 Jan '10

I wrote a small cronjob to update my hackage reverse-deps. When checking if it worked I noticed that my hackage appears to be more up-to-date than the real thing! Compare the "What's new" of both: Real hackage: http://hackage.haskell.org/packages/archive/recent.html Play thing: http://bifunctor.homelinux.net/~roel/hackage/packages/archive/recent.html At the time of writing this message the newest package on Hackage is dated Tue Jan 12 16:24:18 UTC 2010. The newest on my mirror is Thu Jan 14 20:07:04 UTC 2010. I thought that possibly the recent.html page wasn't being built, but when I follow an actual package, like vacuum-opengl the most recent version on hackage is 0.0.2 while on my mirror it is 0.0.3. Is this a case of data loss or something else?

3 4

space leaks and optimizations
by Alexei Kitaev 15 Jan '10

15 Jan '10

Dear Haskellers, Recently I have been looking for a programming language that would be suitable for small scientific and recreational projects and palatable to a picky person like me. (I do theoretical physics and some math; I do not program very often.) Haskell and Clean look attractive from a mathematician's point of view and allow for very elegant solutions in some cases. I tried Clean first because it has a more efficient implementation and better array support. However, I am leaning toward Haskell since it has more libraries, larger community, and some nice features (e.g., the "do" notation). I thought it would be easier to avoid errors when programming in a pure functional language. Indeed, the Haskell type system is great and catches many errors. But in practice, I found it very difficult to write correct programs in Haskell! This is because my definition of correctness includes asymptotic complexity (time and space). I have pondered why Haskell is so prone to space leaks and whether this can be fixed. I posted a related message (describing a space leak caused by inlining) to Glasgow-haskell-users, http://www.haskell.org/pipermail/glasgow-haskell-users/2009-November/018063… but apparently the GHC developers were busy preparing a new release. Perhaps on Haskell-cafe there are more people with some spare time; I would really appreciate your comments. So, there seem to be several reasons why controlling space usage is difficult: 1) The operational semantics of Haskell is not specified. That said, it seems that unoptimized programs behave in a predictable way if you follow the execution step by step. The Clean report explicitly says that the execution model is graph reduction; I believe that Haskell uses the same model. However, there are some subtleties, e.g., the tail call and selector optimizations. (I read about the selector optimization in Wadler's paper, http://homepages.inf.ed.ac.uk/wadler/topics/garbage-collection.html and saw it mentioned on the GHC development page. It's really nice and indispensable, but it seems to be missing from the user documentation. Is this the following description accurate? After the rhs of a lazy pattern like (a,b) = expression has been evaluated, the pattern does not take up any space, and the space occupied by a and b can be reclaimed independently.) There must be more subtleties. I imagine that a rigorous definition of operational semantics would be too complicated and impractical. But maybe an informal specification is better than nothing? Why people have not attempted to write it? 2) While each step is predictable, the overall behavior of a lazy program can be rather surprising. So one must be very careful. GHC provides two ways to control the evaluation order, seq and bang patterns, but I am not sure which of these (if any) is the right tool. Consider the following example (from the Real World Haskell book): mean :: [Double] -> Double mean xs = sum / fromIntegral num where (num,sum) = foldl' f (0,0) xs :: (Int, Double) f (n,s) x = (n+1, s+x) Although it uses foldl', there is a space leak because Haskell tuples are not strict. There are two possible fixes: f (!n,!s) x = (n+1, s+x) or f (n,s) x = let n1=n+1; s1=s+x in n1 `seq` s1 `seq` (n1,s1) The first one is short, but less natural than the second one, where the offending thunks are suppressed on the spot. Unfortunately, the syntax is awkward; it would be nice to write something like f (n,s) x = (!n+1, !n+1) Well, I am becoming too grumpy, perhaps the bang patterns are fine. More important question: are there established practices to *avoid* space leaks rather than fixing them afterwards? 3) The standard library was not designed with space efficiency in mind; for example, there is sum but no sum'. 4) GHC does a pretty good job optimizing programs for speed, but compiling with the -O option can easily introduce a space leak. I have not encountered such problems with Clean, though my experience is very limited. Apparently, the Clean developers have disallowed some unsafe optimization, see e.g., this message: http://mailman.science.ru.nl/pipermail/clean-list/2009/004140.html I doubt that the Clean solution is 100% reliable because the compiler still uses strictness analysis, which can change the asymptotic space usage (usually for better, but sometimes for worse). So I wonder whether it would be feasible to identify a set of conservative optimizations that do not change the space or time usage more than by a constant factor. For example, the strictness analysis could be limited to fixed-size data. Or instead of strictness analysis, one could inline the top-level patterns of every function. Of course, that would make the optimization less efficient on the average, but predictability is more important. Best regards, Alexei

4 4

Force -threaded from a library
by John Van Enk 15 Jan '10

15 Jan '10

Hi List, Is it possible to prevent a library from being used unless -threaded is enabled? I have a specific case where lots-of-nasty shows up if the library is linked against an executable built without -threaded. I suppose this is GHC specific. /jve

2 2

deleteBy type too restrictive
by Dan Rosén 15 Jan '10

15 Jan '10

Hello, I realized today that the type for deleteBy in Data.List is too restrictive. The code is: deleteBy :: (a -> a -> Bool) -> a -> [a] -> [a] deleteBy _ _ [] = [] deleteBy eq x (y:ys) = if x `eq` y then ys else y : deleteBy eq x ys though the type deleteBy :: (b -> a -> Bool) -> b -> [a] -> [a] will do good as well. Is there a particular reason that the type has this restriction? Otherwise, where can I post a suggestion to have it untightened? Best regards, Dan Rosén references: http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Data-List.ht… http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/src/Data…

2 1

New blog: mainly Haskell and wxHaskell related
by Jeremy O'Donoghue 15 Jan '10

15 Jan '10

Hi all, I have just started a new blog at http://wewantarock.wordpress.com. At least initially, my intention is to provide a set of 'tutorial' style articles to help new wxHaskell users get beyond the 'Hello World' stage by offering a few worked examples on things you might want to do to put together a usable application. The idea is to offer something which fits between the first tutorial and the reference documents. The first few postings will explain the anatomy of a complete custom wxHaskell control written in Haskell. Comments gratefully accepted, including (gentle please - I'm not dons!) criticism of my Haskell style. Regards Jeremy O'Donoghue

2 1

Quick, somebody do something!
by Henk-Jan van Tuyl 15 Jan '10

15 Jan '10

Haskell has dropped out of the top 50 at Tiobe [1]; how could this hapen? Let's start selling mobile phones that can only be programmed in Haskell :-) [1] http://www.tiobe.com/content/paperinfo/tpci/index.html -- Met vriendelijke groet, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html --

5 4

Typed Configuration Files
by Sebastian Fischer 15 Jan '10

15 Jan '10

Dear Café, Neil Mitchell's cmdargs package [1] is pretty neat. It can be used to parse command-line arguments into a user-defined data structure. Is there something similar for parsing config files? There are a number of config file parsers on Hackage. But even the most sophisticated one I found, ConfigFile by John Goerzen [2], only yields primitive data like strings, booleans, and numbers. Did I overlook something? I'd like to write something like do fc <- configFile ... ac <- cmdArgs ... let conf = fc `mappend` ac where the type of `conf` is a user defined monoid. I found that the fez-conf package [3] provides a function `parseToArgs` which creates a list similar to the one returned by `System.getArgs` from a config file. Neil, if you would add a function to your cmdargs package that allows to specify the argument list, then one could reuse your machinery to create typed config data from config files too, right? Maybe along the lines of do args <- parseToArgs <$> readFile "/my/conf" conf <- cmdArgsWithDefault args "My Program" [myMode] The new function `cmdArgsWithDefault` could require the return type to be a monoid in order to allow users to specify themselves how to deal with multiple options of the same kind. Would that be reasonable or is there a better alternative? Cheers, Sebastian [1] http://hackage.haskell.org/package/cmdargs [2] http://hackage.haskell.org/package/ConfigFile [3] http://hackage.haskell.org/package/fez-conf -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

7 10

Design question, HTML for GUIs?
by Günther Schmidt 15 Jan '10

15 Jan '10

Hi everyone, as probably most people I find the GUI part of any application to be the hardest part. It just occurred to me that I *could* write my wxHaskell desktop application as a web app too. When the app starts, a haskell web server start listening on localhost port 8080 for example and I fire up a browser to page localhost:8080 without the user actually knowing too much about it. Is that a totally stupid idea? Which haskell web servers would make good candidates? Are there any *continuation* based web server in haskell, something similar to Smalltalk's Seaside? Is Hyena continuation-based? Günther

7 7

ANN: Lite Haskell IDE
by Mambo Banda 15 Jan '10

15 Jan '10

Hi Just started an open source project called Hoodoo. It is meant to be a Lite IDE for Haskell. I wrote it to learn Haskell, so if you are a beginner (like me) it might interest you. If you're interested follow this link (http://hoodoo.kenai.com/) and if you like what you see, grab the code and add something:) Mambo

1 0

Haskell implementation of ideas from StandardML as a Metaprogramming language
by CK Kashyap 15 Jan '10

15 Jan '10

Hi All, I was just going over the paper titled - "Standard ML as a meta programming language" by Samuel Kamin - It has a few ideas of generating C++ code from ML. The first one being generating C++ top down parser. I wanted to try out the sample in Haskell - I was wondering if anyone's already done that - I could just look at that implementation for reference. Regards, Kashyap

2 2

General Advice Needed ..
by Ian675 15 Jan '10

15 Jan '10

Hi, First of all, sorry if its in the wrong section.. But I'm just having trouble getting to grips with Haskell. I have my functional programming exam tommorow and I'm struggling to understand any of this. We worked through the book The Craft Of Functional Programming and Im trying to work my way through it but still no luck.. I find it really hard to put down code onto paper. I can understand the code in the book I can do the simple simple functions like cube.. cube :: Int -> Int cube n = n*n*n But after that im lost :( Is there any general advice? Just keep reading the book till it drills into my big head? You can make sarcastic n00b jokes if you like.. I'm just a very frustrated student right now! -- View this message in context: http://old.nabble.com/General-Advice-Needed-..-tp27161410p27161410.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

8 10

I/O performance drop in ghc 6.12.1
by Peter Simons 14 Jan '10

14 Jan '10

Hi, I just updated to GHC 6.12.1, and I noticed a significant drop in I/O performance that I can't explain. The following code is a simple re-implementation of cat(1), i.e. it just echos all data from standard input to standard output: > module Main ( main ) where > > import System.IO > import Foreign ( allocaBytes ) > > bufsize :: Int > bufsize = 4 * 1024 > > catBuf :: Handle -> Handle -> IO () > catBuf hIn hOut = allocaBytes bufsize input > where > input ptr = hGetBuf hIn ptr bufsize >>= output ptr > output _ 0 = return () > output ptr n = hPutBuf hOut ptr n >> input ptr > > main :: IO () > main = do > mapM_ (\h -> hSetBuffering h NoBuffering) [ stdin, stdout ] > catBuf stdin stdout That program used to have exactly the same performance as /bin/cat, but now it no longer does: | $ dd if=/dev/urandom of=test.data bs=1M count=512 | | $ time /bin/cat <test.data >/dev/null | | real 0m1.939s | user 0m0.003s | sys 0m1.923s | | $ time ./cat-hgetbuf <test.data >/dev/null | | real 0m4.327s | user 0m1.967s | sys 0m2.317s I've tested different variants of the program that were built with -O, -O2, and -O2 -funbox-strict-fields, respectively, but it doesn't seem to make a difference. Is there something I'm missing? Any suggestion would be kindly appreciated. Take care, Peter

4 4

wildcards for type variables?
by Evan Laforge 14 Jan '10

14 Jan '10

Occasionally I have a function with an unused argument, whose type I don't want to restrict. Thus: f :: _unused -> A -> B f _ a = b Since it's a little unusual, I try to make it clear that the type is intentionally ignored. But it makes me wonder, would it make sense to allow _ as a type variable name, with the same meaning as in pattern matching?

8 10

Re: [Haskell-cafe] sizeOf on a type
by Henning Thielemann 14 Jan '10

14 Jan '10

On Fri, 25 Dec 2009, Lennart Augustsson wrote: > sizeOfPtr :: Ptr a -> Int > sizeOfPtr = sizeOf . (undefined :: Ptr a -> a) > > No need for scoped type variables. But it does assume sizeOf does not > use its argument. That's even better. I'll add that to the Wiki. http://www.haskell.org/haskellwiki/Scoped_type_variables#Avoiding_Scoped_Ty…

1 0

looking for origin of quote on preprocessors and language design
by Johannes Waldmann 14 Jan '10

14 Jan '10

Dear all, It's not exactly Haskell-specific, but ... I am trying to track down the origin of the proverb "the existence (or: need for) a preprocessor shows omissions in (the design of) a language." I like to think that in Haskell, we don't need preprocessors since we can manipulate programs programmatically, because they are data. In other words, a preprocessor realizes higher order functions, and you only need this if your base language is first-order. Yes, that's vastly simplified, and it does not cover all cases, what about generic programming (but this can be done via Data.Data) and alex/happy (but we have parsec) etc etc. Best regards, J.W.

7 9

ANN: hakyll-1.0
by Jasper Van der Jeugt 14 Jan '10

14 Jan '10

Hello, I have just released hakyll[1] 1.0. It is now available on hackage[2]. This is considered a first stable release (hence 1.0), and pretty it is functional. Hakyll is a Haskell library for generating static sites. It is written in a very configurable way and uses an xmonad-like DSL for configuration. Important changes: - Switched from the template library to a custom template system, because we needed some more flexibility, but not quite as much as something like HStringTemplate would give. - Switched from inconsistent String/ByteString usage to String only for the external API. - Added a $root system so it is easy to work with relative/absolute URL's. - Many bugfixes. - More documentation and a reference are online now. All feedback and questions are welcome. Kind regards, Jasper Van der Jeugt [1]: http://jaspervdj.be/hakyll [2]: http://hackage.haskell.org/package/hakyll

1 0

Re: [Haskell-cafe] Web application interface
by Michael Snoyman 14 Jan '10

14 Jan '10

On Thu, Jan 14, 2010 at 1:58 PM, Alberto G. Corona <agocorona(a)gmail.com>wrote: > > > 2010/1/14 Michael Snoyman <michael(a)snoyman.com> > >> >> >> On Thu, Jan 14, 2010 at 1:20 PM, Alberto G. Corona <agocorona(a)gmail.com>wrote: >> >>> >>> >>> 2010/1/14 Michael Snoyman <michael(a)snoyman.com> >>> >>> >>>> >>>> Well, for one thing, you'd need to use lazy IO to achieve your goal, >>>> which has some safety issues. As things get more and more complex, the >>>> requirements of lazy IO will continue to grow. This also has implications >>>> for number of open file handles and deterministic space usage. Given the >>>> fact that a lazy bytestring and easily be converted to an enumerator, I >>>> think it makes sense to start a new package using this approach. >>>> >>>> These must be issues of base library developers, not application >>> developpers. TIme ago a guy said me that using an standard library like >>> malloc for memory allocation where not the optimum. And he was right. >>> Fortunately things went in the "non-optimum" direction. You can make the >>> application faster by using your own plumbing code instead of standard >>> libraries provided that you have enough time and knowledge. Because I don´t >>> have neither of the two :-) (nor have the people that read my code and >>> maintain the application), I really like the laziness of haskell and the >>> lazy bytestring interface. >>> >>> Lazy bytestring interface is one thing; lazy IO is another. If you have >> pure code generating a lazy bytestring, Hack will work fine for you. Try >> this one however: take a 10MB YAML file, reformat it using something in the >> IO monad (for example, look up values from a database) and produce HTML >> output. Hack will *not* allow you to run in constant space without >> significant usageof unsafe functions. >> >> Michael >> > > So there are memory leaks somewhere in the lazy bytestring IO libraries > (not in hack neither is an inherent problem in the lazy bytestring design, > the lazy IO concept or laziness as such). > > I did''t take a look, but surely a lazy bytestring IO read is composed of > an iteration of strict block reads that present a lazy bytestring interface. > It must be essentially the same than a iteratee IO, but with a higher level > interface (at least higher from my point of view). > > I like haskell for Internet applications because streaming is the essence > of communications and function call is the building block of programming. > Haskell deals with both with zero impedance because its laziness. Don't > break this!! > > > No, that's not the way it works. Lazy IO requires the use of unsafeInterleaveIO, which is, well, unsafe. Pure functions in Haskell can safely be lazy, not so with IO. If you don't believe me, you can read more about it here: http://okmij.org/ftp/Streams.html#iteratee Michael

1 0

Re: [Haskell-cafe] Web application interface
by Pasqualino "Titto" Assini 14 Jan '10

14 Jan '10

Hi Michael, no, the message was not meant to be off-list, that was just me pressing the wrong button :-) Regarding happstack, I do not believe that there is a contrast with your effort, the core of happstack is in its persistency mechanism not in its http interface so I think it would be great to engage the happstack community in this effort. We have so many half-baked and dispersed attempts in the web area that any attempt at consolidation can only be welcome. Personally I have been using happstack for a few years though now I am running it behind a nginx server because of its known deficiencies (no HTTPS etc). titto P.S. I will be away for a few days and unable to answer my email 2010/1/13 Michael Snoyman <michael(a)snoyman.com>: > Not sure if you replied off-list on purpose or not, but I'll continue this > off list for the moment. I think we have a bit of a problem in the Haskell > web community: you've got the Happstack camp and then the rest of us. "The > rest of us" need to rally around *something*, and it seems that Hack didn't > get people's attention for some reason. > > I'm happy to write WAI, but I'd like more to make it a community effort. You > have any thoughts on this? My first stab at the idea is to create a github > repo, write the code, and then try to get people to comment on it. However, > I also want to give it at least a day so I can get people's feedback on this > e-mail. > > What have you been using for Haskell web development until now? It seems > like each non-Happstack person has a totally different approach, and I'd > like to try and consolidate this together somehow. > > Michael > > On Wed, Jan 13, 2010 at 11:12 PM, Pasqualino "Titto" Assini > <tittoassini(a)gmail.com> wrote: >> >> A unified web app interface would be a God-sent, please please go ahead. >> >> Regarding point 1, I find hack interface nice and clean and would like >> to see something similar. >> >> Regarding point 2 I vote for correctness/performance vs convenience. >> >> titto >> >> 2010/1/13 Michael Snoyman <michael(a)snoyman.com>: >> > Hi, >> > >> > I recently read (again) the wiki page on a web application interface[1] >> > for >> > Haskell. It seems like this basically works out to Hack[2], but using an >> > enumerator instead of lazy bytestring in the response type. Is anyone >> > working on implementing this? If not, I would like to create the >> > package, >> > though I wouldn't mind some community input on some design decisions: >> > >> > * Hack has been fairly well-tested in the past year and I think it >> > provides >> > the features that people want. Therefore, I would want to model the >> > Environment variable for WAI from Hack. I *could* just import Hack in >> > WAI >> > and use the exact same Environment data type. Thoughts? >> > >> > * If using a different data type for Environment, should I replace the >> > String parts with ByteStrings? On the one hand, ByteStrings are the >> > "correct" data type since the HTTP protocol does not specify a character >> > encoding; on the other hand, Strings are easier to deal with. >> > >> > * It's simple to write a function to convert between a lazy bytestring >> > and >> > an enumerator, meaning it would be very easy to write conversion >> > functions >> > between Hack and WAI applications. This would make it simpler for people >> > to >> > use either backend. >> > >> > If someone else is already working on WAI, please let me know, I don't >> > want >> > to have duplicate implementations. The idea here is to consolidate, not >> > split the community. I have a few Hack handlers (simpleserver, cgi, >> > fastcgi) >> > that I would happily convert to WAI handlers as well. >> > >> > Michael >> > >> > [1] http://www.haskell.org/haskellwiki/WebApplicationInterface >> > [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hack >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe(a)haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >> > >> >> >> >> -- >> Pasqualino "Titto" Assini, Ph.D. >> http://quicquid.org/ > > -- Pasqualino "Titto" Assini, Ph.D. http://quicquid.org/

1 0

Name overloading
by Cristiano Paris 14 Jan '10

14 Jan '10

Hi, these days I'm thinking about name scoping in Haskell and a question built up silently but steadily in my mind. Many times I see code like this: data Foo = { fooBar :: Int, fooSay :: String, fooClose :: String } which reminds me of "Ye Olde Times" of C where you prepend the structure name (or an abbreviation) to the structure's fields so as to avoid clashes with other (possibly included) structures (here Haskell qualified imports don't help as they just let you cut down the size of the prefix which is still present though and is module-scoped anyway). One of the most appreciated (at least by me) features of OOP languages like C++, Java, Python and co. is the possibility to name instance methods the same in different classes and have the compiler resolve to the correct implementation (at least indirectly through a virtual table when inheritance is in place) simply looking at the type of the variable which "->" is applied to. The most fulgid example of this is the "open" method, which is likely to be present in lots of classes. Now, in Haskell we have type inference, which is "The Good Thing" as it allows to "validate" your program at compile time. Hence, the idea coming up to my mind is that type inference actually forbids a type-directed resolution of names as in C++ or Java. Is this correct? Think about this piece of code: data DB = { open :: DBHandle } data FS = { open :: File } foo x = open x or, worse: foo x = open (open x) if the result of the first "open" application should typecheck with the second. Notice that, in my understanding, adding a signature doesn't help as the type checker must guarantee that "foo" code complies with its signature, which is actually impossible if open is left undetermined in its type. Thank you for any comment. Cristiano

5 7

Strategies
by Alexei Kitaev 14 Jan '10

14 Jan '10

Dear Ryan, Thanks a lot for your support and for pointing out a problem with my approach to forcing the state. I was aware of this issue but I didn't know there was a standard solution. It is indeed very natural to let each type specify how to evaluate itself. I will try this technique on the nearest occasion. Incidentally, the link to Control.Parallel.Strategies from the latest GHC User Guide is broken... --Alexei Ryan Ingram wrote: > On Sat, Jan 9, 2010 at 2:23 AM, Alexei Kitaev <kitaev(a)iqi.caltech.edu> wrote: >> Reading the discussion related to your blog, I >> realized that strict State is different in that it does not actually >> force the state. But forcing can be achieved by wrapping all actions >> with the following function: >> >> sState :: (s -> (a,s)) -> State s a >> sState f = State $ \s -> case f s of >> (a,s') -> s' `seq` (a,s') >> >> I hope that somebody will answer my other questions about the >> operational semantics and optimizations. > > Hi Alexei, you have a ton of great points but I wanted to discuss an > issue with this one. > > It's unusual that this is what you want either; since it only reduces > the state to WHNF. For example, if your state is a string, this only > evaluates enough to know whether or not the string is empty at each > step, and you can still get into trouble with code like this: > > put ("xxx" ++ some_bad_computation) > > which leave bottoms inside of your state which won't show up until later. > > Several attempts to solve this problem exist, but the most commonly > used one is the "rnf" strategy from Control.Parallel.Strategies, which > uses a typeclass to allow each type to specify how to evaluate itself > completely. > > -- ryan

1 0

How to fulfill the "code-reuse" destiny of OOP?
by Magicloud Magiclouds 13 Jan '10

13 Jan '10

Hi, I think when people talk about OOP, especially the inheriting, their focus mainly is on functions (methods). My concern here is about the data member inheriting. In OOP, when I inherit a class, I also got the members of it. But in haskell, how to inherit a "data"? -- 竹密岂妨流水过山高哪阻野云飞

19 27

status of wash?
by Günther Schmidt 13 Jan '10

13 Jan '10

Hi, is WASH still active, what's the current status of it? I'm looking for a Haskell version of Smalltalk's Seaside, at first glance WASH seems to come close. Günther

2 2

ghc -e
by Tony Morris 13 Jan '10

13 Jan '10

Can I import a module when using ghc -e? e.g. ghc -e "import Control.Monad; forM [[1,2,3]] reverse" -- Tony Morris http://tmorris.net/

5 6

what is *hack*?
by Günther Schmidt 13 Jan '10

13 Jan '10

Hi, References to a Hack. module came in the responses to my posts on HTML-GUIs. What is Hack then? Günther

6 9

What is the difference between Strachey diff from Scott Semantic Domain?
by Daryoush Mehrtash 13 Jan '10

13 Jan '10

On Stack overflow page Conal Elliot says: > Beware that denotational semantics has two parts, from its two founders > Christopher Strachey and Dana Scott: the easier & more useful Strachey part > and the harder and less useful (for design) Scott part. > http://stackoverflow.com/questions/1028250/what-is-functional-reactive-prog… > Any more information on how the Scott version is different from Starchey? On Tue, Jan 12, 2010 at 3:24 PM, Raoul Duke <raould(a)gmail.com> wrote: > http://lambda-the-ultimate.org/node/1665#comment-55086 > <http://perlustration.blogspot.com/> Daryoush

1 0

Xhtml?
by Günther Schmidt 13 Jan '10

13 Jan '10

Hi, apologies upfront. As time presses I decided to post questions immediately as soon as I run into dead-ends. I just don't want to give the impression that I'm not willing to do my homework. I'm trying to find documentation on Xhtml, the site on hackage refers to http://www.cse.ogi.edu/~andy/html/intro.htm for an introduction to the library, the link is dead. I managed to locate Andy Gill's current homepage (http://www.cse.ogi.edu/~andy/html/intro.htm) but there is no mention of his html combinatory library. Does anyone else know where an introduction to this library can be retrieved from? Günther

3 3

QuickCheck: test passes in GHCi, fails when compiled
by Lauri Pesonen 13 Jan '10

13 Jan '10

I provided a Java solution to a problem of returning the first digit of an integer on StackOverflow and someone wondered if there were any floating point point problems with the solution, so I though I'd implement the algorithm in Haskell and run QuickCheck on it. Everything works fine on GHCi, but if I compile the code and run the test, it fails with -1000, 1000, -1000000. Any ideas why? In any case it seems that the commenter was right and there are some subtle problems with my solution. I'd just like to know more details... import Data.Char import Test.QuickCheck -- my solution getFirstDigit :: Int -> Int getFirstDigit 0 = 0 getFirstDigit x = let x' = abs x digits = (floor $ logBase 10 $ fromIntegral x') in x' `div` (floor $ 10 ** (fromIntegral digits)) -- two reference implementation that agree with each other getFirstDigitRef1 :: Int -> Int getFirstDigitRef1 x = digitToInt $ head $ show $ abs x getFirstDigitRef2 :: Int -> Int getFirstDigitRef2 x | x < 0 = getFirstDigitRef2 (-x) | x < 10 = x | otherwise = getFirstDigitRef2 $ x `div` 10 myTest x = getFirstDigit x == getFirstDigitRef1 x --myTest x = getFirstDigitRef2 x == getFirstDigitRef1 x myCheck n = check (defaultConfig { configMaxTest = n }) myTest main = myCheck 1000000000 -- ! Lauri

2 2

overloaded overloading?
by Alberto G. Corona 13 Jan '10

13 Jan '10

Hi, I sometimes strumble on the same quiestion that forces me to insert functions that process objects of a certain class inside their class definition. This occurs when a computation uses the object internally, neiter as parameter or as a return value or in the case of existential types. An example of the first: class Example a where irec :: IO a pr :: a → IO String sample2 :: a → IO () sample2 _ = do x ← irec :: IO a pr x return () sample :: Example a ⇒ a → IO () sample _ = do x ← irec :: IO a pr x return () With the flag -fglasgow-exts, the following error below appears in sample. without the flag, the error appears in both sample and sample2. I´m too lazy to find what concrete extension is involved and why, anyhow, in the case of sample, the compiler must generate a new type a1 with no context. Could not deduce (Example a1) from the context () arising from a use of `irec' at Control\Workflow\Users.hs:73:7-10 Possible fix: add (Example a1) to the context of an expression type signature In a stmt of a 'do' expression: x <- irec :: IO a In the expression: do x <- irec :: IO a pr x return ()

3 2

ANN: afv-0.0.0
by Tom Hawkins 12 Jan '10

12 Jan '10

Hi, Here is the first release of Atom's Formal Verifier (AFV) [1], a tool intended to verify Atom -- or human -- generated C code. With the help of the Yices SMT solver [2], AFV uses bounded model checking and k-induction to verify assertions in iteratively called C functions, such as an embedded control loop. For each assertion in a design, AFV will return a pass, a fail, or an inconclusive result -- or it will die trying. In addition to Yices, AFV needs GCC for C preprocessing. This is a very early release. There are many things missing including counter example generation, finite precision modeling, and basic model reduction. And they is a chance -- say about 100% -- that there are bugs with the modeling transformations. In addition, the list of unsupported C syntax is embarrassingly long: - recursive functions - non-unique top level names (e.g. top level names hidden with static) - loops - switch statements - pointers - arrays - type casting - non void functions - functions with arguments - structs - enums - unions - typedefs Still, AFV works well for the handful of tests I have tried so far. AFV comes with a simple example. To run: $ afv example # This generates afv.h and example.c shown below... // Provides assert and assume functions. #include "afv.h" // Periodic function for verification. Implements a simple rolling counter. void example () { // The rolling counter. static int counter = 0; // Assertions. GreaterThanOrEqualTo0: assert(counter >= 0); // The 'counter' must always be greater than or equal to 0. LessThan10: assert(counter < 10); // The 'counter' must always be less than 10. // Implementation 1. if (counter == 10) counter = 0; else counter++; // Implementation 2. // if (counter == 9) // counter = 0; // else // counter = counter + 1; // Implementation 3. // if (counter >= 9) // counter = 0; // else // counter++; // Implementation 4. // if (counter >= 9 || counter < 0) // counter = 0; // else // counter++; // Implementation 5. // counter = (counter + 1) % 10; } To run the verification on the example: $ afv verify example -k 20 example.c # Which returns... parsing example.c ... verifying assertion example.GreaterThanOrEqualTo0.assert ... inconclusive: unable to proved step up to max k = 20 verifying assertion example.LessThan10.assert ... FAILED: disproved basis in k = 11 These results state AFV was unable to prove the "GreaterThanOrEqualTo0" assertion and it disproved the "LessThan10" assertion. The different implementations in the example yield different results. Any feedback or questions are more than welcome. I would like to thank Benedikt Huber and friends for the language-c library [3], Ki Yung Ahn for the yices library [4], and the folks at SRI for their work on the Yices SMT solver. Without these tools and libraries, AFV would not have been possible. -Tom [1] http://hackage.haskell.org/package/afv [2] http://yices.csl.sri.com/ [3] http://hackage.haskell.org/package/language-c [4] http://hackage.haskell.org/package/yices

1 0

Windows Automation - COM package - HaskellDirect
by Günther Schmidt 12 Jan '10

12 Jan '10

Hi all, I want to use Sigbjorn's com-package to do some automation under Windows. There seems to be some program "HaskellDirect" wich can create Haskell modules from type-libs, it's mentioned in the examples to the com package on Sigbjorn's site http://haskell.forkio.com/com-examples . Cabal install com does not seem to build / install the program though. Does anybody know how to get it? Günther

1 0

short licensing question
by Sebastian Fischer 12 Jan '10

12 Jan '10

Hello Café, when writing a Haskell library that uses two other Haskell libraries -- one licensed under BSD3 and one under LGPL -- what are allowed possibilities for licensing the written package? PublicDomain? BSD3? LGPL? Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)

12 16