September 2014 - Haskell-Cafe

ANN: vimus - An MPD client with vim-like key bindings
by Simon Hengel 21 Sep '14

21 Sep '14

Hi, I just uploaded vimus [1] to Hackage. vimus is an MPD client with vim-like key bindings. I've been using it as my exclusive music player since early 2010. It comes with it's own quick & dirty ncurses bindings, which is one of the reasons why I was reluctant to push it to Hackage so far. Check the README for installation and usage: https://github.com/vimus/vimus#readme vimus is not a masterpiece of coding beauty** , but it's incredibly useful to me and a couple of other people over at #vimus on Freenode. Patches are welcome as long as they - reduce code bloat and improve hackability - do not conflict with my use cases (in case of doubt we make things configurable) - do not require lots of work from my side (vimus already works incredibly well for me and I can not spend too many cycles on it) vimus would not be what it is today without the help of others. In particular I'm grateful to - Niklas Haas for being the second user of vimus and contributing many useful features - Joachim Fasting for his work on libmpd and contributing high quality patches to vimus - Markus Klinik for contributing documentation and features - Matvey Aksenov for adding even more features Cheers, Simon ** Indeed, vimus served me as a testing ground for experimenting with both Haskell and lean software development. [1] http://hackage.haskell.org/package/vimus [2] https://github.com/vimus/vimus#using-vimus

1 1

Linking/uploading a PDF file in HaskellWiki
by Henk-Jan van Tuyl 20 Sep '14

20 Sep '14

L.S., I am trying to link a PDF file, that is to be uploaded to the HaskellWiki environment, but I encounter several problems: - The link [[File:wxhaskell.pdf | wxHaskell - A Portable and Concise GUI Library for Haskell]] is displayed as File:wxhaskell.pdf instead of wxHaskell - A Portable and Concise GUI Library for Haskell If I leave out the vertical bar, the entire string between the brackets is displayed and used as filename - If I click the link, I am asked to upload the file; the resulting file should be http://www.haskell.org/haskellwiki/File:Wxhaskell.pdf but this URL results in a blank page - The list of uploaded files should be at http://www.haskell.org/haskellwiki/Special:ListFiles but this URL results in a blank page as well Am I doing something wrong, or are these Wiki bugs? Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

2 1

Chaining modifications using (>>>)
by martin 20 Sep '14

20 Sep '14

Hello all, I've been playing with Data.Graph.Inductive, which provides functions to modify a graph. I take these functions and build something more complex from them. To do so, I have to apply several such modifications one after the other. I can write this using ($) or (.), but I didn't like to write things backwards (last function to apply comes first), so I use (>>>) from the Arrows module to chain functions Graph -> Graph (aka GraphTransforms) and my complex function looks like f >>> g >>> h. To actually build a Graph I have to apply my function to some Graph (often "empty"). This works okay as long as the inidividual functions f,g,h do not need access to the graph. However, there is one function where I use "pre" (predecessors) and "suc" (succerssors), which need the Graph as a parameter. groupNodes :: DynGraph gr => (Label,[Node]) -> GraphTransform gr pl groupNodes (lbl,ids) gr = let id = head $ newNodes 1 gr oldEdgesTo = [(toOld, old) | old <- ids, toOld <- pre gr old] -- <== here "pre" oldEdgesFrom = [(old, fromOld) | old <- ids, fromOld <- suc gr old] oldEdges = oldEdgesTo ++ oldEdgesFrom oldEdgesWithin = [ (i,j) | (i,j) <- oldEdges, i `elem` ids, j `elem` ids] newEdges = map (uncurry e0) $ uniq $ map (setDest id) (oldEdgesTo \\ oldEdgesWithin) ++ map (setOrig id) (oldEdgesFrom \\ oldEdgesWithin) in --------------- look here: ----------------------- ( insNode (id, (NN lbl)) >>> delNodes ids >>> delEdges oldEdges >>> insEdges newEdges ) gr This works, but I don't like the "in" part and I'd rather omit the braces and the gr argument. Without the gr argument to the whole function this would work, however with the gr I have to kinda eta expand (?) it. Is there a way I can write this more point free and still have access to gr for pre and suc?

2 1

Haskell FFI Question
by ye yan 20 Sep '14

20 Sep '14

I have been play around with Haskell FFI. My question is for ByteString (Strict) is there a trailing null append to it when pass to it C functions?

2 4

Confused about AllowAmbiguousTypes
by Audun Skaugen 19 Sep '14

19 Sep '14

I am confused about the behaviour of the AllowAmbiguousTypes extension. I tried the basic example of the user manual: > class C a where > f :: C a => Int > f = 3 > main = print f Using ghc 7.8.3, without the extension, this will cause a type error at the type signature (line 2). Adding AllowAmbgiuousTypes causes an error at the call site instead (line 4). So far so good. However, if I replace the (C a) constraint with (Num a), no type error is reported, and the example runs fine! This is true with or without the extension. Using ghc 7.6.3, however, the example is still rejected with an "ambiguous constraint" error. Is this a bug in ghc 7.8? Is ghc somehow able to prove the Num constraint even though a is universally quantified? -- Audun Skaugen

2 1

Craig Gentry of IBM
by Vasili I. Galchin 19 Sep '14

19 Sep '14

Hi, Gentry is doing on homomorphic functions cryptography. I looked on Hackage but did see a homomorphic function library. Is there.any effort in this area in Haskell? If so by whom and is contact info? Vasya

1 0

Constructors on left and right hand sides of equation
by PATRICK BROWNE 19 Sep '14

19 Sep '14

Dear list In Eq 1 is (NewGlass i) on the LHS distinct from (NewGlass i) on the RHS? In Eq2 are the occurrences of the data constructor Fill on the LHS and RHS distinct? Thanks Pat data Glass = NewGlass Int | Fill Glass Int deriving Show drink :: Glass -> Int -> Glass drink (NewGlass i) j = (NewGlass i) -- Eq 1 drink (Fill m i) j | full (Fill m i) = Fill (NewGlass (size m)) ((size m) - j) -- Eq 2 | (i >= j) = Fill m (i-j) | otherwise = drink m (j-1) size :: Glass -> Int size (NewGlass i) = i size (Fill m i) = size m level :: Glass -> Int level (NewGlass i) = 0 level (Fill m i) | (level m) + i > (size m) = size m | otherwise = (level m) + i empty :: Glass -> Bool empty m = (level m) == 0 full :: Glass -> Bool full m = (level m) == (size m) {- drink (Fill (NewGlass 4) 5) 5 drink (Fill (NewGlass 4) 3) 3 -} -- This email originated from DIT. If you received this email in error, please delete it from your system. Please note that if you are not the named addressee, disclosing, copying, distributing or taking any action based on the contents of this email or attachments is prohibited. www.dit.ie Is ó ITBÁC a tháinig an ríomhphost seo. Má fuair tú an ríomhphost seo trí earráid, scrios de do chóras é le do thoil. Tabhair ar aird, mura tú an seolaí ainmnithe, go bhfuil dianchosc ar aon nochtadh, aon chóipeáil, aon dáileadh nó ar aon ghníomh a dhéanfar bunaithe ar an ábhar atá sa ríomhphost nó sna hiatáin seo. www.dit.ie Tá ITBÁC ag aistriú go Gráinseach Ghormáin – DIT is on the move to Grangegorman <http://www.dit.ie/grangegorman>

4 6

move sandboxes
by Corentin Dupont 19 Sep '14

19 Sep '14

Hi guys, is there a pratical way to move a sandbox? I see the absolute path are hard-coded in all the .conf files. I ask the question because I have an application that uses Hint. So it needs to run with the same object files that it was compiled with. If I want to deploy the application on a server, I need to send the whole sandbox there: this way Hint/GHC finds the database when I start with "cabal exec". But this forces me to deploy it on the same path it was compiled, which is not very practical. Cheers C

1 0

preventing space leaks?
by Baojun Wang 19 Sep '14

19 Sep '14

Hi Cafe, I'm very new to Haskell, and I'm confused about haskell space leaks, even I read some wiki pages from haskell.org. Below is the scenario I''m facing at: When I use listArray to create either IArray or UArray, I found it could lead to space leaks (very high GC time), is there a way to prevent this, and why there is no fusion when create IArray/UArray from the list? I don't need the list anyway after array is created. (I used this few times for DP, based on this link: http://jelv.is/blog/Lazy-Dynamic-Programming/) Further more, suppose if I create a IArray A from list 1, later I create UArray B based some computations based on A (also I need discard another list 2). After B is generated, I don't need A anymore (so this lead to space leaks, correct)? Another quetion, by the way, after the lazy IArray is created (say from a DP), is there a way convert it to UArray for better performance (IArray -> UArray)? How can I improve the space leak problems with above use case? Best Regards Baojun

2 2

Injective type families for GHC - syntax proposals
by Jan Stolarek 19 Sep '14

19 Sep '14

Haskellers, there is some discussion going on at the moment about implementing injective type families in GHC [1]. I'd like to hear your opinions on proposed syntax for this new feature. == Problem == Currently GHC assumes that type families are not injective. This is of course conservative and the idea behind implementing injective type families is to allow the programmer to explicitly declare that a type family has the injectivity property (which GHC will of course verify). == Forms of injectivity == Injectivity can take forms more complicated than just determining the LHS from RHS: A. RHS determines all arguments on the LHS. Example: type family Id a where Id a = a Here the RHS uniquely determines LHS. B. RHS determines some but not all arguments on the LHS. Example (contrieved): type family G a b c where G Int Char Bool = Bool G Int Char Int = Bool G Bool Int Int = Int Here RHS uniquely determines `a` and `b` but not `c`. C. RHS and some LHS arguments uniquely determine some LHS arguments. Example: type family Plus a b where Plus Z m = m Plus (S n) m = S (Plus n m) Here knowing the RHS and one of LHS arguments uniqely determines the other LHS argument. At the moment we've only seen use cases for A, which means that we will most likely only implement A. If someone comes up with compelling examples of either B or C we will revise and consider implementing these more involved forms of injectivity. == Syntax == So the most important decission to make is what syntax do we want for this new feature :-) One of the features we would like is extensibility, ie. if we only implement injectivity of type A we still want to be able to add injectivities B and C sometime in the future without breaking A. When thinking about syntax an important (and open) question is whether injectivity becomes part of TypeFamilies language extension or do we add a new InjectiveTypeFamilies extension for this feature. The problem with incorporating injectivity into existing TypeFamilies is that we would have to come up with syntax that is fully backwards compatible with what we have now. Below is a list of proposals that have come up until now in the discussion between developers. Note that all proposals are given for closed type families. For open type families things would be identical except that the `where` keyword would be skipped. === Proposal 1 === Use syntax similar to functional dependencies. The injectivity declaration begins with `|` following type family declaration head. `|` is followed by a list of comma-separated injectivity conditions. Each injectivity condition has the form: {{{ result A -> B }}} where `A` is a possibly-empty list of type variables declared in type family head and `B` is non-empty list of said type variables. Things on the left and right of `->` are called LHS and RHS of an injectivity condition, respectively. `result` becomes a restricted word that cannot be used as a type variable's identifier in a type family head. Examples: type family Id a | result -> a where type family G a b c | result -> a b where type family Plus a b | result a -> b, result b -> a where Pros: * has natural reading: `result a -> b` reads as "knowing the result and the type variable a determines b". * extensible for the future Cons: * steals `result` identifier in the type family head. This means it would be illegal to have a type variable named `result` in a type family. * the above also makes this proposal backwards incompatible with TypeFamilies extension. Further proposals are based on this one in an attempt to solve the problem of stealing syntax and backwards incompatibility. === Proposal 2 === Use `Result` instead of `result`: type family Id a | Result -> a where type family G a b c | Result -> a b where type family Plus a b | Result a -> b, Result b -> a where Pros: * has natural reading * extensible for the future * allows to have type variables named `result` (does not steal syntax) Cons: * all other keywords in Haskell are lowercase. This would be the first one that is capitalized. * confusion could arise if we have a type `Result` and use it in the type family head. Unknowns (for me): * not sure if it would be possible to avoid name clash between `Result` and type of the same name. If not then this proposal would also be backwards incompatible with TypeFamilies. === Proposal 3 === Use `type` instead of `result`: type family Id a | type -> a where type family G a b c | type -> a b where type family Plus a b | type a -> b, type b -> a where Pros: * extensible for the future * no syntax stealing Cons: * no natural reading * usage of `type` here might seem unintuitive === Proposal 4 === Use name of the type family instead of `result`: type family Id a | Id -> a where type family G a b c | G -> a b where type family Plus a b | Plus a -> b, Plus b -> a where Pros: * extensible for the future * no syntax stealing Cons: * writing something like `Plus a` might be confusing. It looks as if Plus could be partially applied. == Further discussion == I'd like to hear what you think about these proposals. Neither of them is perfect so perhaps someone can come with something better. You can also check out the GHC Trac ticket [1] and the GHC Wiki page [2] (which repeats most of this but has some more details as well). [1] https://ghc.haskell.org/trac/ghc/ticket/6018 [2] https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies Janek

8 14