- Haskell-Cafe - Haskell.org

Simplest possible Fasta shootout entry. How do I zap the ugly line? Suggest any other improvements.
by Richard Kelsall 28 Apr '08

28 Apr '08

(Extracting these questions from my previous thread for clarity.) Below is my simplest possible program to solve the Fasta shootout benchmark. http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=all http://haskell.org/haskellwiki/Shootout/Fasta I can see one remaining flaw - the line marked 'Ugly'. What's the best way to get rid of this line? Any other suggestions for simplifying or improving the program would also be interesting. This code is about three or four times slower that the current fastest GHC entry for the Fasta benchmark. I'll elaborate it for speed when I've produced the best version regardless of speed. Richard. {-# OPTIONS -O -fexcess-precision #-} -- The Computer Language Shootout : Fasta -- http://shootout.alioth.debian.org/ -- Simple solution by Richard Kelsall. -- http://www.millstream.com/ import System main = do n <- getArgs >>= readIO . head title "ONE" "Homo sapiens alu" writeLined (cycle alu) (n * 2) title "TWO" "IUB ambiguity codes" let (r1, r2) = splitAt (fromIntegral (n * 3)) (rand 42) -- Ugly !! writeLined (map (look iubs) r1) (n * 3) title "THREE" "Homo sapiens frequency" writeLined (map (look homs) r2) (n * 5) title :: String -> String -> IO () title a b = putStrLn $ ">" ++ a ++ " " ++ b look :: [(Char, Float)] -> Float -> Char look [(c, _)] _ = c look ((c, f) : cfs) r = if r < f then c else look cfs (r - f) lineWidth = 60 writeLined :: [Char] -> Integer -> IO () writeLined cs 0 = return () writeLined cs n = do let w = min n lineWidth (cs1, cs2) = splitAt (fromInteger w) cs putStrLn cs1 writeLined cs2 (n - w) rand :: Int -> [Float] rand seed = newran : (rand newseed) where im = 139968 ia = 3877 ic = 29573 newseed = (seed * ia + ic) `rem` im newran = fromIntegral newseed / fromIntegral im alu = "GGCCGGGCGCGGTGGCTCACGCCTGTAATCCCAGCACTTTGGGAGGCCGAGGCGGGCGGA\ \TCACCTGAGGTCAGGAGTTCGAGACCAGCCTGGCCAACATGGTGAAACCCCGTCTCTACT\ \AAAAATACAAAAATTAGCCGGGCGTGGTGGCGCGCGCCTGTAATCCCAGCTACTCGGGAG\ \GCTGAGGCAGGAGAATCGCTTGAACCCGGGAGGCGGAGGTTGCAGTGAGCCGAGATCGCG\ \CCACTGCACTCCAGCCTGGGCGACAGAGCGAGACTCCGTCTCAAAAA" iubs = [('a', 0.27), ('c', 0.12), ('g', 0.12), ('t', 0.27), ('B', 0.02), ('D', 0.02), ('H', 0.02), ('K', 0.02), ('M', 0.02), ('N', 0.02), ('R', 0.02), ('S', 0.02), ('V', 0.02), ('W', 0.02), ('Y', 0.02)] homs = [('a', 0.3029549426680), ('c', 0.1979883004921), ('g', 0.1975473066391), ('t', 0.3015094502008)]

2 2

CPU simulation library?
by Justin Bailey 28 Apr '08

28 Apr '08

I want to simulate various process/thread scheduling algorithms for a small project. I'm trying to compare the performance versus power consumption of several algorithms. If anyone knows of some Haskell code along those lines I'd love to hear about it. Thanks in advance! Justin p.s. I can find non-Haskell code on my own - I'm hoping there is something in my favorite language, but any particularly good suggestions are also welcome.

1 0

maintainer of StorableVector
by Henning Thielemann 28 Apr '08

28 Apr '08

I sent some patches to the maintainer of StorableVector, Spencer Janssen http://code.haskell.org/~sjanssen/storablevector but did not get some feedback and the patches are still not applied. Any idea what might went wrong?

2 1

Haskell as a general purpose programming language...
by Martin Grabmueller 28 Apr '08

28 Apr '08

Hi all, just a thought: is it just me, or is Haskell really really really the coolest general-purpose programming language? If I had the time, I would love to do a re-implementation of Harpy [1] using category-extras [2]. Martin [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/harpy-0.4 [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/category-extras-…

2 1

ANNOUNCE: Haskell XML Toolbox Version 8.0.0
by Uwe Schmidt 28 Apr '08

28 Apr '08

Haskell XML Toolbox 8.0.0 I would like to announce a new version of the Haskell XML Toolbox. The main change is the separation of the old filter interface into a separate package "hxt-filter". This makes the API simpler and more readable. The filter API will not be developed further. But all the functionality ist still available. The filter package hxt-filter must be installed on top of hxt. The darcs repos for HXT are at http://darcs.fh-wedel.de/hxt http://darcs.fh-wedel.de/hxt-filter Furthermore there is a new wiki page http://www.haskell.org/haskellwiki/HXT/Conversion_of_Haskell_data_from/to_X… describing the serialization and deserialization of Haskell values to/from XML data. More information and download: http://www.fh-wedel.de/~si/HXmlToolbox/index.html There's also a copy on Hackage. Please email comments, bugs, etc. to hxmltoolbox(a)fh-wedel.de or si(a)fh-wedel.de Uwe -- University of Applied Sciences, Wedel, Germany http://www.fh-wedel.de/~si/index.html

1 0

ANNOUNCE: category-extras 0.2
by Dan Doel 28 Apr '08

28 Apr '08

Hello, all. After quite a bit of collaboration with Edward Kmett over the past few days, I've rolled up a new release of category-extras. Perhaps the most significant addition is the generalized hylomorphism he first blogged about here: http://comonad.com/reader/2008/generalized-hylomorphisms/ added to Control.Recursion under the name 'refoldWith', as all other combinators in the library turn out to be special cases of it. Other changes include: * Data.BranchingStream moves to Control.Comonad.Cofree, and various functions are renamed accordingly, as it is the cofree comonad of a functor: Cofree F A = nu X. A * FX * Similarly, a new module has been added: Control.Monad.Free, the free monad of a functor. Free F A = mu X. A + FX * Several new recursion combinators have been added to Control.Recursion. The generalized hylomorphism 'refoldWith' was mentioned above, but we now also have: - Futumorphisms (futu, g_futu) - Chronomorphisms (chrono, g_chrono; name coined by edwardk; they're a combination of a histomorphism and a futumorphism). - Dynamorphisms (dyna, g_dyna; formalize dynamic programming) - Codynamorphisms (codyna, g_codyna; these apparently don't appear in any literature (like chronomorphisms), and we didn't attempt to give them a name, but once one sees dynamorphisms in terms of chronomorphisms/ g_hylomorphisms, this becomes fairly obvious). As can be seen, there's quite a glut of these combinators, and they all correspond to choices of distributive laws for refoldWith, so in the future, it may be better to talk about those directly. For now, though, we have lots of functions with fancy-sounding names. I believe those are the significant updates for this release. Enjoy. hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/category-extras-… darcs: darcs get http://code.haskell.org/~dolio/category-extras/ -- Dan

1 0

Trouble compiling collections-0.3 (from Hackage)
by David F. Place 27 Apr '08

27 Apr '08

Hi, I am not able to build collections-0.3 because on an error. I hope someone can give me a hint. Below, please find a short transcript with various version information. Cheers, David [david@congo ~]$ cd Desktop/collections-0.3 [david@congo collections-0.3]$ runghc Setup.hs configure Configuring collections-0.3... [david@congo collections-0.3]$ runghc Setup.hs build Preprocessing library collections-0.3... Building collections-0.3... Data/Collections.hs:154:17: Could not find module `Data.ByteString.Lazy': it is a member of package bytestring-0.9.0.4, which is hidden [david@congo collections-0.3]$ uname -a Linux congo 2.6.16-1.2111_FC5 #1 SMP Thu May 4 21:16:04 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux [david@congo collections-0.3]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 [david@congo collections-0.3]$ ghc-pkg list /usr/local/lib/ghc-6.8.2/package.conf: ALUT-2.1.0.0, Cabal-1.2.3.0, GLUT-2.1.1.1, HUnit-1.2.0.0, OpenAL-1.3.1.1, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, array-0.1.0.0, base-3.0.1.0, bytestring-0.9.0.1, bytestring-0.9.0.4, cgi-3001.1.5.1, containers-0.1.0.1, directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, (ghc-6.8.2), haskell-src-1.0.1.1, haskell98-1.0.1.0, hpc-0.5.0.0, html-1.0.1.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.0, template-haskell-2.2.0.0, time-1.1.2.0, unix-2.3.0.0, xhtml-3000.0.2.1 [david@congo collections-0.3]$

4 4

Help with complicated type inference
by Paul Johnson 27 Apr '08

27 Apr '08

I'm trying to write an AMQP framing layer. AMQP has two very similar union types: there is a "variant" that contains a single item, and an "array" which consists of a list of elements of the same type. So I thought I could define a "Unit" type container thus: > newtype Unit a = Unit {unUnit :: a} So now I can say: > type AmqpVariant = AmqpVariantBase Unit > type AmqpArray = AmqpVariantBase [] Then the AmqpVariantBase type looks something like this (except that it doesn't work, see below): > data forall a . (AmqpWire a, AmqpWire (c a)) => > AmqpVariantBase c = AmqpVarBin8 (c Bin8) > | AmqpVarInt8 (c Int8) > | AmqpVarUint8 (c Word8) > | AmqpVarChar (c Word8) > | AmqpVarBoolean (c Bool) > | AmqpVarBin16 (c Bin16) > | AmqpVarInt16 (c Int16) > | AmqpVarUint16 (c Word16) > | AmqpVarBin32 (c Bin32) > | AmqpVarInt32 (c Int32) > -- And on for about 20 more types, including compound types. All AMQP types have to be seralised, so I've defined a class "AmqpWire" for serialisation in AMQP format. All the individual types (Bin8, Int8 etc) are instances of this class. I've also defined instances for Unit and [] such as: > instance (AmqpWire a) => AmqpWire (Unit a) where > amqpPut = amqpPut . unUnit > amqpGet = map Unit amqpGet The problem is with the type constraint for AmqpVariantBase. I need to say "AmqpWire (c a)" without explicitly listing all the values of "a" (i.e. Bin8, Int8, etc) because any time I use AmqpVariantBase I have to repeat the same constraint. How do I do this? Paul.

3 4

some questions about type improvement, FDs vs TFs, and Hugs vs GHCi
by Claus Reinke 27 Apr '08

27 Apr '08

consider class FD a b | a -> b instance CFD a b => FD a b class CFD a b instance CFD Bool Char and the constraint 'CFD Bool c'. logically, we know that if we have 'CFD Bool c', we also have 'FD Bool c', which implies that 'c' is uniquely determined, which implies that 'c~Char'. practically, the need to find an instance for 'CFD Bool c' does not generate a demand for implied instances that could lead to this improvement. q1: should there be such a forward demand? ie, instead of failing to find the instance for 'CFD Bool c', should the transitive closure of forward implications be taken into account for FDs, similar to the transitive closure of backward implications? without such forward inferences, consistency of FDs seems hard to guarantee, unless one conservatively rules out everything that might lead to an inconsistency. without such forward inference, implementations differ in their interpretation of this kind of code (as so often): Hugs rejects the program ("Instance is more general than a dependency allows"), which is conservative, but seems to make perfect sense: there's no FD for class 'CFD', so there's no guarantee that all those implied instances of class 'FD' will conform to its own FD. that is easily fixed, it seems: class FD a b | a -> b instance CFD a b => FD a b class FD a b => CFD a b instance CFD Bool Char now, there cannot be an instance of 'CFD' unless there also is an instance of 'FD', in such a way that the parameters of 'CFD' obey the FD of 'FD'. and, in fact, Hugs does now accept this code, and is able to improve 'CFD Bool c' to 'CFD Bool Char', reducing the latter as given: :t undefined :: CFD Bool c => c undefined :: Char but wait a second: we have given an instance of 'CFD', which according to the superclass constraint for that class, is valid only if there is a corresponding instance of 'FD', and there is such an instance of 'FD' if there is an instance of 'CFD'. in other words: if the 'CFD' instance is accepted, it is valid, if it isn't accepted, it is not valid. q2: is this treatment of recursion for class instances intended, or is it an unexpected artifact of the special treatment of superclass constraints? GHCi also accepts this code, but it doesn't seem to do the reduction or improvement: :t undefined :: CFD Bool c => c undefned :: CFD Bool c => c :: (CFD Bool c) => c actually, GHCi accepts the first program, too! perhaps it is delaying the FD consistency check until there is an actual rather than a possible FD conflict? unfortunately not, as we can see if we add a conflicting 'CFD' instance: class FD a b | a -> b instance CFD a b => FD a b class {- FD a b => -} CFD a b instance CFD Bool Char instance CFD Bool Bool note that the conflict is not in 'CFD' but in the implied instances of 'FD', which GHCi doesn't seem to take into account for any FD consistency check: *Main> :t undefined :: CFD Bool c => c undefined :: CFD Bool c => c :: (CFD Bool c) => c *Main> :t undefined :: CFD Bool Char => c undefined :: CFD Bool Char => c :: c *Main> :t undefined :: FD Bool c => c undefined :: FD Bool c => c :: (CFD Bool c) => c *Main> :t undefined :: FD Bool Char => c undefined :: FD Bool Char => c :: c only if we explicitly mention the inconsistent constraints together, and directly in terms of 'FD', not just in terms of 'CFD', do we get the expected error, and even then, the FD isn't used for improvement: *Main> :t undefined :: (CFD Bool Char,CFD Bool Bool) => c undefined :: (CFD Bool Char,CFD Bool Bool) => c :: c *Main> :t undefined :: (FD Bool Char,FD Bool Bool) => c <interactive>:1:0: Couldn't match expected type `Char' against inferred type `Bool' When using functional dependencies to combine FD Bool Bool, arising from the polymorphic type `forall c. (FD Bool Char, FD Bool Bool) => c' at <interactive>:1:0-44 FD Bool Char, arising from the polymorphic type `forall c. (FD Bool Char, FD Bool Bool) => c' at <interactive>:1:0-44 *Main> :t undefined :: (FD Bool Char,FD Bool c) => c undefined :: (FD Bool Char,FD Bool c) => c :: (CFD Bool c) => c this looks like a bug to me, or am i missing something? perhaps we fare better with TFs, as FD development in GHC was put on hold while the new foundations for TFs were put in place? unfortunately, we can't even define TFs in terms of classes, as has been discussed here before (in the context of using FD-based libaries in TF-based client code). what we'd like to write is something like: type family TF a type instance TF a = CTF a b => b -- won't work.. class {- FD a b => -} CTF a b instance CTF Bool Char instance CTF Bool Bool as with the FD-based variant, the definition of TF should not work unless there is a functional relationship between the parameters of 'CTF', but the 'TF' instance isn't even accepted syntactically ("Illegal polymorphic type in type instance"). q3: (a) are qualified types in type instances problematic, or just not yet implemented, or not yet investigated in theory? (b) what about the intended interaction of TFs and FDs in the example. it would seem to permit the use of FD-based code in TFs, as requested here earlier, but is this ever going to be supported? questions, questions,.. does anybody have answers?-) claus

1 0

Ann: Lekash.org
by Jürgen Nicklisch-Franken 27 Apr '08

27 Apr '08

The Haskell IDE written in Haskell (currently in early infancy) called Leksah has now a website (with reference to a Google Code issue tracker): http://leksah.org/ Contributions of all kind welcome. (The released version is still 0.11 but the development version 0.3 has made some progress.) Jürgen

1 0