November 2014 - Haskell-Cafe

Getting Haskell in the top 20
by Henk-Jan van Tuyl 30 Nov '14

30 Nov '14

L.S., In the Tiobe Index[0], F# jumped from position 43 in June to 13 in July and is since than in the top twenty. What happened in July and how can we get Haskell in the top 20? Regards, Henk-Jan van Tuyl [0] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html -- 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

looking for ongoing Haskell projects ..
by Vasili I. Galchin 30 Nov '14

30 Nov '14

Hi Fellow Haskellers, I was just reading at http://www.haskell.org. I am looking for a list of currently active Haskell projects needing help .. :-) Vasili

9 11

Data migration and software versioning
by Corentin Dupont 30 Nov '14

30 Nov '14

Hi the list, I have some question relative to data migration. Say you have a software in version A which save data in a file with format FA. Later, you update your software to version B, with data format FB. Now, if you want your version B of the software to be able to read data saved by version A, you're obliged to include FA in version B, together with some functions to translate from FA to FB. This is what I don't find elegant: you're obliged to keep old code (data formats) in your software. -> do you know of any way to avoid keeping old data formats (for retro-compatiblilty) in your code? In practice I use acid-state with safecopy: http://acid-state.seize.it/safecopy In this example you can see the problem: the author is obliged to keep old code (data structures) to maintain compatibility. Even worth, you might be obliged to suffix your data structure with a version number: data MyType_V1 = MyType_V1 Intdata MyType_V2 = MyType_V2 Integer Instead, I'm thinking of a process using GIT, or Cabal as a back-end. The idea would be to have an additional program (or library) specialized in the data migration of your main software. It would extract both version A and B from the repo, and then would compile an application capable of handling migrations from FA to FB. Does something like this exists (even outside of Haskell)? Cheers, Corentin

1 0

Kind signatures and closed type families syntax
by Gautier DI FOLCO 30 Nov '14

30 Nov '14

Hello all, I have the following code: {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} data Branch = Left | Right type family Product (v :: Branch) (a :: k) (b :: k) :: k where Product Left l r = l Product Right l r = r He is doing what I expect it to do and Product has the right Kind: *Main> :kind Product Product :: Branch -> k -> k -> k But when I change the Kind signature syntax, its Kind changes: type family Product v a b :: Branch -> k -> k -> k where Its Kind become: *Main> :kind Product Product :: Branch -> (Branch -> k -> k -> k) -> (Branch -> k1 -> k1 -> k1) -> Branch -> k2 -> k2 -> k2 It's even worse with this syntax: type family Product :: Branch -> k -> k -> k where Produces: *Main> :r [1 of 1] Compiling Main ( product-highkind.hs, interpreted ) product-highkind.hs:13:3: Number of parameters must match family declaration; expected 0 In the equations for closed type family ‘Product’ In the type family declaration for ‘Product’ Failed, modules loaded: none. I don't know if I'm tired or not but in the documentation [1] these syntaxes should be equivalent. If not, I'll take any explanations. Thanks in advance for your help. [1] https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/kind-polymor…

2 2

What's up on Win 8.1 64 bit, Haskell Platform?
by james 29 Nov '14

29 Nov '14

This is a transcript of the very first session I have after installing Haskell Platform 7.8.3, 64 bit. Why is cabal-install continuing to be confused about the version installed/available? How can I tell cabal to STFU about it? C:\Program Files (x86)\Microsoft Visual Studio 11.0>cabal update Downloading the latest package list from hackage.haskell.org Note: there is a new version of cabal-install available. To upgrade, run: cabal install cabal-install C:\Program Files (x86)\Microsoft Visual Studio 11.0>cabal install cabal-install Resolving dependencies... Downloading Cabal-1.20.0.2... Configuring Cabal-1.20.0.2... Building Cabal-1.20.0.2... Installed Cabal-1.20.0.2 Downloading cabal-install-1.20.0.3... Configuring cabal-install-1.20.0.3... Building cabal-install-1.20.0.3... Installed cabal-install-1.20.0.3 C:\Program Files (x86)\Microsoft Visual Studio 11.0>cabal update Downloading the latest package list from hackage.haskell.org Note: there is a new version of cabal-install available. To upgrade, run: cabal install cabal-install C:\Program Files (x86)\Microsoft Visual Studio 11.0>cabal install cabal-install Resolving dependencies... Configuring cabal-install-1.20.0.3... Building cabal-install-1.20.0.3... Installed cabal-install-1.20.0.3 C:\Program Files (x86)\Microsoft Visual Studio 11.0>cabal update Downloading the latest package list from hackage.haskell.org Note: there is a new version of cabal-install available. To upgrade, run: cabal install cabal-install C:\Program Files (x86)\Microsoft Visual Studio 11.0>cabal install cabal-install Resolving dependencies... Configuring cabal-install-1.20.0.3... Building cabal-install-1.20.0.3... Installed cabal-install-1.20.0.3 C:\Program Files (x86)\Microsoft Visual Studio 11.0>cabal update Downloading the latest package list from hackage.haskell.org Note: there is a new version of cabal-install available. To upgrade, run: cabal install cabal-install C:\Program Files (x86)\Microsoft Visual Studio 11.0>

3 2

Why is type level (+) not commutative?
by Dominic Steinitz 28 Nov '14

28 Nov '14

I have a type signature (for an extended Kalman filter as it happens thought that is not relevant) > outer :: forall m n p q . > (KnownNat m, KnownNat n, KnownNat p, KnownNat q, > (1 <=? n) ~ 'True, (1 <=? m) ~ 'True, > (1 <=? p) ~ 'True, (n + q) ~ p) => > R n -> Sq n -> > L m n -> Sq m -> > (R p -> R n) -> (R n -> Sq n) -> Sq n -> > [R m] -> [R q] -> > [(R n, Sq n)] and my function compiles. If I change (n+ q) ~ p to (q + n) ~ p then I get a type error > Could not deduce (p ~ (n + q)) > from the context (KnownNat m, > KnownNat n, > KnownNat p, > KnownNat q, > (1 <=? n) ~ 'True, > (1 <=? m) ~ 'True, > (1 <=? p) ~ 'True, > (q + n) ~ p) Is expressing commutativity not possible? Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

2 2

Re: [Haskell-cafe] Generating valid html
by oleg＠okmij.org 28 Nov '14

28 Nov '14

I have sent the following message to Haskell-Cafe five days ago; it seems to have disappeared. I'm resending because HSXML answers your second question, of ensuring complex content constraints. I'm not sure why do you need Monad specifically? HSXML documents are particular monoids, which is what we want from documents. Generally speaking, all we need is a way to create primitive documents and to compose them into bigger ones. There are many more composition operations than monadic bind. Not everything is a monad and not everything has to be a monad. Old message: Somewhat related is the HSXML library for generating valid XML and HTML. To be precise, the library is designed to express in the type system content model constraints such as: block-level elements like DIV are allowed only in the block-level context; one cannot put DIV within H1, for example. Some items may be polymorphic: for example, TITLE appears in HEAD, it can be an attribute and it can be an element. It can be rendered differently in each case. The same HSXML document may be rendered as HTML or XML (or something else entirely, e.g., PDF). http://okmij.org/ftp/Scheme/xml.html#typed-SXML

3 4

--hyperlinks-in-source ?
by Johannes Waldmann 27 Nov '14

27 Nov '14

I am using 'standalone-haddock --hyperlink-source' (and I cannot praise this enough) but ... is there some way to get hyperlinks *in* the source? currently, I have to jump back and forth between doc (which has all the links) and source (which I want to navigate - actually, present for others so they can browse) I understand there's a nontrivial design space but I could imagine a basic functionality like: for each identifier i (type, class, constructor, function) that appears in the source, generate the link that haddock would produce for " -- | 'i' " (3.8.7. Hyperlinked Identifiers https://www.haskell.org/haddock/doc/html/ch03s08.html#idm140354810770608 ) - J.W.

6 9

Re: [Haskell-cafe] Increasing Haskell modularity
by oleg＠okmij.org 27 Nov '14

27 Nov '14

The issue with local instances is very complicated one. First, they are sorely missed. However, they present quite a problem. Let us assume they are implemented and consider the following function f1 :: Int -> String f1 x = let instance Show Int where show _ = "one" in show x I think we all agree (f1 1) should evaluate to "one". However, given f2 :: Show a => a -> String f2 x = let instance Show Int where show _ = "one" in show x what should (f2 (1::Int)) return? One answer is that it should still return "one" -- that is, local instances should sort of form a closure (like local variables in the real closure). That is a good answer, but may lead to unpleasant surprises because the fact of the closure is not at all reflected in the type of the function. Consider data T = T f3 :: Show a => a -> String f3 x = let instance Show T where show _ = "T" in show x and take the closure semantics. The type says that to make (f3 T) well-typed, there has to be an instance Show T in scope. The user of f3 has no way to know of the private local instance that is closed over (short of examining the source code). Since the user knows there is no global instance T, the user attempts to define in. The user will be quite surprised to discover that (f3 T) is well-typed but their global instance Show T has no effect. Let us assume the opposite of the closure semantics -- local instances are not closed. So, local instances should behave sort of dynamically scoped variables (which are not captured in closures). Therefore, (f2 (1::Int)) should return "1". Such a choice is also problematic. Suppose GHC, seeing our call to f2, notices that the polymorphic f2 is called at type Int and decides, to save time on indirect dictionary calls, to specialize f2 to the type Int. So, GHC will generate a specialized instance of f2: f2_Int :: Int -> String f2_Int x = let instance Show Int where show _ = "one" in show x and we have already decided that (f2_Int 1), should return "one" rather than "1" (since f2_Int looks just like f1). Previously, specialization of a function was easy to understand: GHC may, at will, create a copy of a polymorphic function and instantiate it at a specific type. Then all calls to the polymorphic function at that specific type are replaced with the calls to the specialized function. The user can even do such a specialization themselves. With unclosed local instances, such a specialization changes the program behavior. We have to complicate the matters. Further, what should (f4 (1::Int)) return? f4 :: Show a => a -> String f4 x = let instance Show Int where show _ = "two" in f2 x Stefan Kaes, the person who introduced ``parametric overloading'' (type classes, in modern term) chose the ``closure semantics''. His system and prototype implementation had only local instances (and even local type classes). http://okmij.org/ftp/Computation/typeclass.html#Kaes Perhaps the most comprehensive treatment of local instances is the old paper D. Duggan and J. Ophel. Open and closed scopes for constrained genericity (PDF). Theoretical Computer Science, 275, 215-258, 2002. http://dl.acm.org/citation.cfm?id=570578 They propose a method to have both closure and non-closure semantics, differentiating based on so-called open and closed types. Our HW 2004 paper with Chung-chieh Shan proposed a way to elide the problem by restricting the local instances in such a way that the problem never arises. The `reflection' facility was used to implement such local instances. The idea was that local instances can be thought of as ordinary global instances; however, the scope of the type in their head is restricted. That is, rather than make the instances local we make local the type for which they are defined (or one of the types, for multi-parameter type classes). Local types can be emulated via first-class polymorphism. (BTW, if one can leave with unsafeCoerce, local instances can be much more efficiently implemented.) Gesh wrote: > * Give up on non-associated open type families. This I have > researched less well, but it seems to me that these have no use > case. Since one can make whatever instances one wishes for these type > families, one can't do anything useful with values of their instances. On the contrary, we found them very useful in defining interpreters that provide their own interpretation of not only primitives but also of types. http://okmij.org/ftp/gengo/NASSLLI10/index.html See, for example, http://okmij.org/ftp/gengo/NASSLLI10/Lambda.hs for partial evaluation and http://okmij.org/ftp/gengo/NASSLLI10/CFG.hs In the latter case, extensibility is particularly important as we do want to add further syntactic categories and their semantic interpretations.

6 5

An opportunity in Singapore
by Camps, Tony 27 Nov '14

27 Nov '14

Good morning Haskellers! Hope all is well; I understand that the natural reaction to recruiters posting on these mailing lists would be spite and malice so I took some advice from a Haskell Developer I know. He said to cut the buzzword bingo, be transparent about remuneration and be honest about location. So here we go: - This is an opportunity to relocate to Singapore on a permanent basis to work for a leading Investment Bank (I think we all know who I am talking about...) - The role is working on the development & support of Cortex/ Mu(Haskell) based applications for the Process Automation and Efficiency team including a proprietary reporting tool. - The salary is set at SGD 105,000 basic with a good bonus and benefits – more details on request. All relocation is handled by the bank. This role is perfect for someone with a passion or FP and keen to have an adventure in Asia! I hope I have been brief but to the point – further details are available on request via return email: tcamps(a)teksystems.com<mailto:tcamps@teksystems.com> Look forward to hearing from you! Regards, Tony [http://www.allegisgroup.co.uk/images/tek/tek_sig_logo.gif] Tony Camps T +44 (0)207 997 1026 | M +44 (0)781 790 3478 [http://www.allegisgroup.co.uk/images/tek/tek_sig_linkedin.gif]<https://www.linkedin.com/company/teksystems> [http://www.allegisgroup.co.uk/images/tek/tek_sig_facebook.gif] <https://www.facebook.com/TEKsystemsJobs> [http://www.allegisgroup.co.uk/images/tek/tek_sig_twitter.gif] <https://twitter.com/TEKsystemsJobs> Our People Make IT Possible. Learn why.<http://www.teksystems.com> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Trading under the TEKsystems brand. Registered in: England: Allegis Group Ltd, OTV House, East Wing, Wokingham Road, Bracknell, Berkshire, RG42 1NG, United Kingdom. No. 2876353. Belgium: Allegis Group SA 9 Rue Guimard, 1040 Brussels, Belgium. No. 0543691037. France: Aston Carter International SAS. 2e étage, 40-42 Rue La Boétie, 75008 Paris, France. Co Reg/Siren 499 449 494 RCS Paris. Germany: TEKsystems ist ein Geschäftsbereich der Allegis Group GmbH mit Sitz in Frankfurt am Main. Amtsgericht Frankfurt Am Main, HRB 52009, Geschäftsführer Christopher Lee Hartman. Netherlands: Allegis Group B.V., Godebaldkwartier 365, Kantoor Janssoenborch, 3e Verdieping, 3511 DT Utrecht, Nederland. Company No. 14109133. Allegis Contracting B.V., Godebaldkwartier 365, Kantoor Janssoenborch, 3e Verdieping, 3511 DT Utrecht, Nederland. Company No. 34254913. Sweden: Aston Carter International Ltd UK Filial. Grev Turegatan 3, 114 46 Stockholm, Sweden. No. 516404-0163. This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Allegis Group, Allegis Group companies or Allegis Group brands. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify postmaster(a)teksystems.com<mailto:postmaster@teksystems.com> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This electronic mail (including any attachments) may contain information that is privileged, confidential, and/or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic mail or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please notify us immediately by reply e-mail so that we may correct our internal records. Please then delete the original message (including any attachments) in its entirety. Thank you

1 0