- Haskell-Cafe - Haskell.org

Return of the revenge of the revisit of the extensible records, reiterated
by oleg＠okmij.org 28 Nov '13

28 Nov '13

First of all, I should point out that faster extensible records have already been developed, within the HList framework: Just Do It While Compiling! Fast Extensible Records In Haskell http://www.fing.edu.uy/~mviera/papers/pepm13.pdf The authors did it without needing the total order on labels. However, one of the encoding of labels described in the HList paper had total order. I guess we weren't motivated enough to exploit it. > The real benefit of keeping the row sorted is that { x = 0 , y = 0 } and { > y = 0, x = 0 } have the same type. When a row is not sorted, as in HList, > then if we for example have an instance Eq for a row (because all elements > support Eq) then for using (==) both arguments would have to the same order > in the row or we need a manual call to a permutation function. When keeping > the row ordered, this is not necessary. The same kind of problem > occurs > > The same kind of problem occurs when we fix the type of a function to > a specific row: ( using whishful syntax ) > > f :: Rec [ x = Int , y = Int] -> Int > > If the row is not ordered, then f { y = 0 , x = 0 } will not typecheck and > will require a manual call to permute the row. This is all very true. However, if we wish to pass the function f above the record {y=0, x=0} (with permuted fields), we most likely wish to pass that function a record {x=0, y=0, z='a'} with more fields. Most of the time when we deal with extensible records, we really wish to explore their extensibility. Keeping fields sorted does not help at all in the latter problem -- we must manually insert the call to the subtyping coercion function. Once we do that, the problem with the order of the fields disappears. I also would like to point out that there are two sorts of record types. One sort is Rec [x: Int, y:Bool] in the imagine syntax. Current HList types are uglier versions of the above. But there is another sort: (HasField r x Int, HasField r y Bool) => r It represents an extensible record type. Extensibility is build in, and the order of the fields is immaterial. Quite a few functions on records can be given the above type. Furthermore, the second sort can be used not only with structural subtyping but also with nominal subtyping.

1 0

Compiling to STG problem
by Maarten Dungen 27 Nov '13

27 Nov '13

Dear all, While trying to retrieve the STG using ghc I bumped into the following problem: I try to compile the source file in a more or less standard way, found in many examples on the web: ... setTargets targets _ <- load LoadAllTargets mgraph <- depanal [] False mapM_ (compileModSummary) mgraph Then I compile the individual files through the following pipeline (also more or less standard, I thought): compileModSummary = do ... stg <- parseModule theMod >>= typecheckModule >>= desugarModule >>= liftIO . hscSimplify env . coreModule >>= liftIO . tidyProgram env >>= prepPgm env . fst >>= liftIO . coreToStg dynflags … Then I do a dump to (just to check the results): writeFile “filename” (show . showOutputable $ stg) The problem is, if I do a stg dump from the command line (like <compiler> -ddump-stg --make Main.hs (where <compiler> is the intended compiler program) the dump is different from the stg dump I do at writefile, to the extent that functions are missing, which gives problems when linking the results. They are numbered functions, like ‘value1’, etc. I’m not very much into the ghcmake stuff, and I’m probably missing a lot, however I have been struggling with this for a couple of days now, and it is not getting any clearer. I guess my question would be, why is there a difference, and how could I avoid this? Any help or pointers appreciated. kind regards, Maarten p.s. This is just pseudo code. I necessary, I could probably strip my sources into a working example that displays the problem, if that would help.

2 1

Monad classes and FreeT
by Alejandro Serrano Mena 27 Nov '13

27 Nov '13

Dear Café, I'm continuing my travel through operational and free, and was wondering: which is the reason why there's no instance such as (Functor f, MonadReader e m) => MonadReader e (FreeT f m) included in the 'free' package? It seems reasonable to me to have those instances. At least, there's the corresponding one for MonadIO. Should Free be considered as some monad to have 'at the bottom of the stack' as IO is? Thanks in advance.

2 2

btc-e interfacing + bot
by Miro Karpis 27 Nov '13

27 Nov '13

Am thinking to inteface btc-e + make a bot. Anybody willing to join forces? m.

4 3

Re: [Haskell-cafe] using external instance declarations
by Kata 27 Nov '13

27 Nov '13

The problem is that your definition of arbitrary for the Building instance isn’t indented under the ‘instance Arbitrary Building’, so it’s getting interpreted as two top-level statements: one that Building is an Arbitrary of Instance, and one that defines a value named ‘arbitrary’. Hence the error message. To fix this, just indent the definition of arbitrary like you did in the Glass definition. On Tuesday, November 26, 2013 at 11:06 AM, Kees Bleijenberg wrote: > I have a Building with a field glass: Glass. > I want to use quickcheck. Therefor I wrote a TestGlass.hs with the Arbitrary instance declaration for Glass. I also want to make Building an instance of Arbitrary. For the field glass in the Building I need the arbitrary :: Gen Glass function out of TestGlass.hs. > How do I export and use the instance declarations from TestGlass.hs? > > Glass.hs > module Glass( > Glass(..)) > where > data Glass = Glass Int > > TestGlass.hs > module TestGlass() > where > import Test.QuickCheck > import Test.QuickCheck.Gen > import Glass > > instance Arbitrary Glass where > arbitrary = do > n <- choose (1,8) :: Gen Int > return $ Glass n > > > Building.hs > module Building () > where > import Glass > import TestGlass > import Test.QuickCheck > import Test.QuickCheck.Gen > > data Building = Building { > glass :: Glass > } > instance Arbitrary Building where > arbitrary = do > g <- arbitrary :: (Gen Glass) > return Building { glass = g} > > > When I compile Building I get: > Building.hs:13:23: > Ambiguous occurrence `arbitrary' > It could refer to either `Building.arbitrary', > defined at Building.hs:12:1 > or `Test.QuickCheck.arbitrary', > imported from `Test.QuickCheck' at Building.hs:5:1-22 > (and originally defined in `Test.QuickCheck.Arbitrary') > > It looks like the compiler doesn’t look at the instance declarations in the TestGlass module. > What is wrong in my code? > I want to split the testcode as much as possible from the non-test code and I don’t want to merge the modules Building and Glass (they are both already big). > > Kees > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org (mailto:Haskell-Cafe@haskell.org) > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

using external instance declarations
by Kees Bleijenberg 27 Nov '13

27 Nov '13

I have a Building with a field glass: Glass. I want to use quickcheck. Therefor I wrote a TestGlass.hs with the Arbitrary instance declaration for Glass. I also want to make Building an instance of Arbitrary. For the field glass in the Building I need the arbitrary :: Gen Glass function out of TestGlass.hs. How do I export and use the instance declarations from TestGlass.hs? Glass.hs module Glass( Glass(..)) where data Glass = Glass Int TestGlass.hs module TestGlass() where import Test.QuickCheck import Test.QuickCheck.Gen import Glass instance Arbitrary Glass where arbitrary = do n <- choose (1,8) :: Gen Int return $ Glass n Building.hs module Building () where import Glass import TestGlass import Test.QuickCheck import Test.QuickCheck.Gen data Building = Building { glass :: Glass } instance Arbitrary Building where arbitrary = do g <- arbitrary :: (Gen Glass) return Building { glass = g} When I compile Building I get: Building.hs:13:23: Ambiguous occurrence `arbitrary' It could refer to either `Building.arbitrary', defined at Building.hs:12:1 or `Test.QuickCheck.arbitrary', imported from `Test.QuickCheck' at Building.hs:5:1-22 (and originally defined in `Test.QuickCheck.Arbitrary') It looks like the compiler doesn't look at the instance declarations in the TestGlass module. What is wrong in my code? I want to split the testcode as much as possible from the non-test code and I don't want to merge the modules Building and Glass (they are both already big). Kees

1 0

Witnessing lifted types?
by Andras Slemmer 26 Nov '13

26 Nov '13

Hi, not sure whether this has been addressed before. Basically the goal is to have a standardised way of witnessing lifted types (=simulating pattern matching on type indices). A particular problem this would be useful for: Given a standard natural-indexed vector (Vec n) provide an Applicative instance for it with n left polymorphic. The issue is that we don't have a way of pattern matching on n, therefore we cannot implement pure/<*>. The way I addressed situations like this before was to have two Applicative instances, one for Vec Zero and one for Vec (Succ n), however I think there is a way to decouple this way of "pattern matching on types" by introducing a GADT: data WNat n where WZero :: WNat Zero WSucc :: WNat n -> WNat (Succ n) and a class class WNatClass n where witness :: WNat n instance WNatClass Zero where witness = WZero instance (WNatClass n) => WNatClass (Succ n) where witness = WSucc witness Now whenever we need to pattern match on a natural index we can just put a WNatClass restriction on it and pattern match on the automatically constructed witness. For the Vec example: instance (WNatClass n) => Applicative (Vec n) where pure = pure' witness where pure' :: WNat n -> a -> Vec n a pure' WZero _ = VecNil pure' (WSucc w) a = a ::: pure' w a (<*>) = app' witness where app' :: WNat n -> Vec n (a -> b) -> Vec n a -> Vec n b app' WZero _ _ = VecNil app' (WSucc w) (f ::: fs) (a ::: as) = f a ::: app' w fs as We can also generalise this concept to any index type with PolyKinds, although I'm not 100% sure why it works in general: class Construct (a :: k) where data Wit a :: * class (Construct a) => Witness a where witness :: Wit a The idea is that each instance of Construct will leave the type 'a' polymorphic and will only bind the kind 'k' and provide an indexed witness: instance Construct (n :: Nat) where data Wit n where WZero :: Wit Zero WSucc :: Wit n -> Wit (Succ n) and the Witness instances will be the same as with WNatClass. We need two classes because one will define the witness type, the other will do the "pattern matching". The part I don't understand is that together with the (n :: Nat) instance we can also have instance Construct (a :: SomeOtherType) where ... without triggering any 'overlapping' diagnostic, even though both instances are "fully polymorphic". I am assuming this is because internally the compiler adds a kind parameter to the class that disambiguates the instances? If so then I think this is a nice uniform way of handling lifted type witnesses. (The instances can be generated automatically too). What do you think? Is there a better way of doing this? Is the decoupling even worth the trouble? Is the performance hit big compared to the explicit instance splitting?

2 1

IDE
by Corentin Dupont 26 Nov '13

26 Nov '13

Hi cafe, I would like to know which IDE are you using? I use Leksah, I like the GUI design and constant compilation process. However, the development seems to be slowing down: last version date from early 2012. The installation process is very painful. There is FPComplete IDE coming up, but it's commercial. I'm experimenting with it, anyway: how to compile using cabal files? It doesn't seem to recognize them. Will there be an off-line version? I'm interested to know if you are using vim to develop: which extension are you using? I'm interested in continuous compilation, project files browsing, code completion, search-in-files. Best, Corentin

24 28

New Functional Programming Job Opportunities
by Functional Jobs 25 Nov '13

25 Nov '13

Here are some functional programming job opportunities that were posted recently: Software Developer - Functional Programming at Genetec http://functionaljobs.com/jobs/8660-software-developer-functional-programmi… Cheers, Sean Murphy FunctionalJobs.com

1 0

[ANNOUNCE]hPDB - Is it the fastest parallel PDB parser? Part of structural bioinformatics library collection...
by Michal J Gajda 25 Nov '13

25 Nov '13

Dear Haskellers, I would like to present a benchmark of Protein Databank parsers that indicates that one written in Haskell seems to outpace all others when using 4 or more of parallel cores: hPDB - Haskell library for processing atomic biomolecular structures in Protein Data Bank format -- Michal Jan Gajda BMC Research Notes.2013, 6:483. DOI: 10.1186/1756-0500-6-483 URL: http://www.biomedcentral.com/1756-0500/6/483 Please let me know if you know of any other parsers that could be added to this benchmark. Along with hTalos, and parseSTAR parser libraries for nuclear magnetic resonance data it adds to growing collection of bioinformatic libraries written in Haskell. Together with CloudHaskell and modern 48-core machines, they allow to process multigigabyte bioinformatic databases in a matter of few minutes (slightly over 8 minutes in case of over 10GB of PDB.) If interested, please see: http://biohaskell.org/. -- Best regards Michał J. Gajda

1 0