News aggregator

Hal8 - Haskell in Leipzig, June 21. visit the workshop web site for program and registration: http://www.bioinf.uni-leipzig.de/conference-registration/13haskell See you - Johannes Waldmann. _______________________________________________ Haskell mailing list Haskell< at >haskell.org http://www.haskell.org/mailman/listinfo/haskell

Hi everybody, I have a question about deriving automatically a Show instance when using GADT. It works in this situation: ---------------------------- {-# LANGUAGE GADTs #-} data Male data Female data Person gender where Dead :: Person gender Alive :: { name :: String , weight :: Float , father :: Person gender } -> Person gender deriving Show main = do let a = Alive "Joe" 60 Dead :: Person Male let b = Alive "Jim" 70 a :: Person Male print a print b ---------------------------- Indeed: $ runghc test_show.hs Alive {name = "Joe", weight = 60.0, father = Dead} Alive {name = "Jim", weight = 70.0, father = Alive {name = "Joe", weight = 60.0, father = Dead}} But when I replace "father :: Person gender" by "father :: Person gender2" in the code (this is one of the advantages of GADT: with a classical algebraic data type declaration, gender2 would have to be a type variable for the data type), I obtain: Can't make a derived instance of `Show (Person gender)

submitted by bos
[link] [11 comments]

What is your recommendation for type-level integers? I'd like to use it to improve the unittyped, https://bitbucket.org/xnyhps/haskell-unittyped/ the library for physical dimension. Therefore, I need negative numbers, additions, but multiplications are not necessary. I've been looking forward for the type-nats extension of GHC, but I haven't been able to compile the type-nats branch. Just learned that it still takes a few month to merge the branch into the main. http://hackage.haskell.org/trac/ghc/wiki/Status/May13 Thijs, the original author of unittyped, has commited a branch that uses type-nats, but I can't try that out for the same reason. Best, -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html

submitted by wheatBread
[link] [4 comments]

submitted by cpa
[link] [1 comment]

I want to convert lambda expressions into a vocabulary of monoidal categories, so that they can be given multiple interpretations, including circuit generation and timing analysis, and hopefully some other far-out alternatives (3D visualization, animated evaluation, etc). More specifically, I want a GHC plugin that makes this transformation on GHC's Core language. If you know of related work, have suggestions, and/or are interested in collaborating/consulting, I'd love to hear. Thanks, - Conal _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hello everyone, I was playing with Word8 and list comprehensions and the following examples came up. I have to admit the behavior looks quite strange because it does not seem to be consistent. Can someone shed some light on reason behind some of these outputs? By the way, I have abbreviated some outputs with ellipsis ... [1..10] :: [Word8] [1,2,3,4,5,6,7,8,9,10] [1..100] :: [Word8] [1,2,3,4,5,6,7,8,9,10,...,100] [1..1000] :: [Word8] [1,2,3,4,5,6,7,8,9,10,...,232] [1..10000] :: [Word8] [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16] [1..100000] :: [Word8] [1,2,3,4,5,6,7,8,9,10,...,160] [1..1000000] :: [Word8] [1,2,3,4,5,6,7,8,9,10,...,64] [1..10000000] :: [Word8] [1,2,3,4,5,6,7,8,9,10,...,128] [1..100000000] :: [Word8] [] [1..1000000000] :: [Word8] [] Thank you, Jose

submitted by yitz
[link] [3 comments]

Hello everybody, please find attached the description of a newly opened PhD position in bioinformatics at our group in Vienna. Mit freundlichem Gruss, Christian _______________________________________________ Haskell mailing list Haskell< at >haskell.org http://www.haskell.org/mailman/listinfo/haskell

Reading the other thread (Adding Applicative/Functor instances to all Monads in GHC) I was wondering if there was infrastructure for testing what effect making the often-discussed Functor/Monad change would have: How many packages on hackage would break etc. I have read a few times that people have "compiled all of hackage" to see the impact of whatever. How do you do that? Do you just run a loop around cabal install or have you built some more advanced tools to visualize the results better or compile the packages "from ground up", in order of their dependencies? I'm interested in anything in this direction.

Hello everyone, I recently went through GHC's source, and discovered there are quite a few instances of Monad that don't have Functor or Applicative instances. Fixing this is very easy by adding the standard instances (pure = return etc.), and will not break code. There is one exception to this: Hoopl defines its own (<*>). However, since it does not seem to have any packages depend on it otherwise, renaming this operator is also easily done (the thing is only used ten times or so). I called it (<*|*>) to complement (|*><*|), but naming should be the least important issue here. Small piece of backstory: The idea behind this is making GHC future-proof for changing Applicative to be a superclass of Monad. However, I think adding the Applicative instances is a good idea regardless of whether this will ever happen, so that's the only thing I'm proposing right now. Greetings, David

I just released the latest language-puppet version. For the full list of changes, please take a look at the changelog. Here are the highlights.

PuppetDB code reworked

The PuppetDB code and API has been completely overhauled. It is now more generic : the resource collection and puppet query functions now work the same. Additionally, a PuppetDB stub has been created for testing use.

Better diagnostic facilities

As the main use of this library is to test stuff, the following features were added:

• Several error messages have been reworked so that they are more informative.
• A dumpvariables built-in function has been added. It just prints all known variables (and facts) to stdout, and can be quite handy.
• The “scope stack” description is stored with the resources. This turned out to be extremely useful when debugging resource names colisions or to find out where some resource is defined.

Here is an example, let’s say you do not remember which package installs the collectd package. Just run this :

<figure class="code">1 2 3 4 5 6 7 » puppetresources . default.domain 'Package[collectd]' package { "collectd": #"./modules/collectd/manifests/base.pp" (line 4, column 9) ["::","site::baseconfig","collectd","collectd::client","collectd::base"] ensure => "installed", require => [Class["collectd"], Class["collectd::base"], Class["collectd::client"], Class["site::baseconfig"]]; }</figure>

You now know exactly where the package resource is declared, and the list of “scopes” that have been traversed in order to do so. Note that this information is displayed when resources names collide.

Easier to setup

This library doesn’t depend from a newish bytestring anymore, and should build with the package provided with a GHC compiler of the 7.6.x serie.

This is not yet done, but I will certainly soon publish a debian-style repository of the compiled puppetresources binary. I am interested in suggestions for an automated building system.

Better testing

The testing API seems sufficient to write pretty strong tests, but would still benefit from a few more helper functions. The testing “daemon” has been reworked to use the new PuppetDB stub. It makes it possible to test complex interactions between hosts using the exported resource or PuppetDB query features.

Work in progress

I will probably lensify the code until I get a descent understanding of it.

I do not intend to work on Hiera emulation just yet, as I am probably the only user of this library for now and I do not use this feature.

One area of improvement would be to embed the ruby interpreter in the library. I am not sure how to do this, but as there are quite a few projects of lightweight interpreters sprouting from the earth, it might be possible in the near future. The only problem would be figuring out how to build a large C project with cabal.

Some other considerations

I recently ported the code from random.c to Haskell (here). This has been quite tedious, and is quite hard to read. This is an almost naive port of the code found in the Ruby interpreter, without the useless loop variables. For some reason, there are many loops like this :

<figure class="code">1 2 3 4 5 6 7 8 9 10 i=1; j=0; k = (N>key_length ? N : key_length); for (; k; k--) { mt->state[i] = (mt->state[i] ^ ((mt->state[i-1] ^ (mt->state[i-1] >> 30)) * 1664525U)) + init_key[j] + j; /* non linear */ mt->state[i] &= 0xffffffffU; /* for WORDSIZE > 32 machines */ i++; j++; if (i>=N) { mt->state[0] = mt->state[N-1]; i=1; } if (j>=key_length) j=0; }</figure>

As you can see, the value of k is never used in the loop. I am not sure why the author didn’t go for something like :

<figure class="code">1 for(i=1;i<k;i++) {</figure>

Anyway, the Haskell code is pretty bad, and will certainly only work for 64-bit builds. I am not sure how I should have written it. I suppose staying in the ST monad would have lead to nicer code, and I am open to suggestions.

submitted by yitz
[link] [13 comments]