- Haskell-Cafe - Haskell.org

Stuck on design problem
by Nicolas Trangez 21 May '13

21 May '13

All, Since I'm stuck on a coding problem and can't figure out how to proceed, I decided to call for help. I'm unable to get some code to typecheck, so maybe I'm missing something obvious on the implementation side, or more likely the design is completely wrong. Here's the idea: I have some code which uses some log of "Entry a" values (for some polymorphic type 'a'), and provides actions which output "Command a" values which should be interpreted by some wrapper code, e.g. adding some new entries to the log. These actions are implemented in a custom WriterT transformer (in this demo code, the original is more complex) to output Commands, while the inner monad should give access to the log entries (this could be in-memory like in the example, or stored on disk so using IO). You can find a trimmed-down version at https://gist.github.com/NicolasT/4230251f4f87f110d197 This doesn't type-check, and I'm not sure how to proceed. Am I taking a wrong approach? Do I need a different design? Thanks, Nicolas

3 4

DSL to English and back for game rule set?
by Matthew O'Connor 20 May '13

20 May '13

Hello all, I recognize this isn't directly a Haskell-related question, but as I'd like to solve this problem in Haskell & figured it's applicable. Let me know if there's a better place to ask. I am interested in creating a DSL (or set of types) for describing rules for a computer game. I'd like the language to be able to be written out to readable and clear English. I'd also like to be able to recreate the representation by reading the English back in. The idea is that the DSL will be unambiguous in either English or its internal representation. My thinking is that this will avoid inconsistencies between the game rules and the text describing those rules to the players. I want the ruleset to be able to describe type of heroes and monsters, their abilities, the effects of their attacks, how they use resources, etc. I realize this may not be an efficient way to go about writing a game, but it seems like an interesting project. Some of my concerns are at what level the DSL should be written to allow for extensions for new heroes, monsters, etc. without having to just add very specific extensions every time a new hero or item is created. Does anyone have thoughts on how to proceed on this, previous work, and/or ways to investigate it? Thanks, Matthew

4 3

New Functional Programming Job Opportunities
by Functional Jobs 20 May '13

20 May '13

Here are some functional programming job opportunities that were posted recently: Test Engineer at Klarna http://functionaljobs.com/jobs/146-test-engineer-at-klarna Cheers, Sean Murphy FunctionalJobs.com

1 0

ANN: lambdabot-4.3
by James Cook 20 May '13

20 May '13

As discussed a couple months ago, I have assumed maintainership of Lambdabot and a a new release has been brewing for a while. It has now been Hackaged as lambdabot-4.3. There are quite a few changes in this release, mainly internal. Plugins written for older versions will require some fairly straightforward rewriting - the plugin interface is now based on a record rather than a type class, and makes use of some simple monad transformers to stabilize the API a bit in the face of future changes. There are many things I'd like to do to continue modernizing it, the most significant of which being that I'd like to overhaul the state storage system and break it down into smaller packages. Therefore, plugin-writers should consider this a bit of a stepping-stone release - in the not too distant future, another release will probably break the plugin API again. If you have open-source plugins, please let me know and I'll feed you patches to keep up with any changes coming down the pipeline. The most significant changes from the user's perspective are probably the expanded command line interface (try --help) and the changes to the eval plugin. Eval now uses Safe Haskell, and accepts a much wider array of user-supplied code - the "@let" command now accepts module imports, type declarations, class declarations, and instances, and will add clauses to existing function definitions when applicable. I apologize in advance that the documentation is still mostly in a state of non-existence. If anyone runs into issues, please report them to me. I can be reached through the following channels: - github "issues"[1] - e-mail, at this address - #haskell (I'm "mokus" there) - I'm not often present, but pretty much always connected and will see and eventually respond to PRIVMSGs. [1] https://github.com/mokus0/lambdabot/issues

1 0

More general "pattern matching"
by Tom Ellis 20 May '13

20 May '13

Suppose I have a Category C > import Prelude hiding ((.), id) > import Control.Category > > data C a b > > instance Category C where > (.) = undefined > id = undefined which has "products" in the sense that there exists a "factors" function with suitable properties > factors :: C a (b, c) -> (C a b, C a c) > factors = undefined Then I can define this interesting combinator > (~~) :: (C a b -> r) -> (C a c -> r') -> C a (b, c) -> (r, r') > (f ~~ g) h = let (l, r) = factors h in (f l, g r) which allows some form of "pattern matching", for example > a :: C z a > b :: C z b > c :: C z c > d :: C z d > e :: C z e > ((a, b), (c, (d, e))) = ((id ~~ id) ~~ (id ~~ (id ~~ id))) undefined and even > w :: C a w > x :: C a x > y :: C a y > z :: (C a z, C a z') > ((w, x), (y, z)) = ((id ~~ id) ~~ (id ~~ (id ~~ id))) undefined Does anyone have anything to say about this? I'm sure others must have come across it before. There's something very lensy going on here too. There's nothing special about 'Category's here, but it's an example where the structure is demonstrated nicely. It's a shame that the structure of the pattern must be duplicated on the left and right of the binding. Tom

1 0

Re: [Haskell-cafe] partially applied data constructor and corresponding type
by Stephen Tetley 18 May '13

18 May '13

What you probably want are type level integers (naturals) Yury Sulsky used them in the message above - basically you can't use literal numbers 1,2,3,... etc as they are values of type Int (or Integer, etc...) instead you have to use type level numbers: data One data Two Work is ongoing for type level numbers in GHC and there are user libraries on Hackage so there is a lot of work to crib from.

3 4

question about GADT and deriving automatically a Show instance
by TP 18 May '13

18 May '13

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)': Constructor `Alive' must have a Haskell-98 type Possible fix: use a standalone deriving declaration instead In the data declaration for `Person' So I modify my code by removing "deriving Show", and adding the line: ---------------------------- instance Show (Person gender) ---------------------------- But now, I obtain: $ runghc test_show.hs GHC stack-space overflow: current limit is 536870912 bytes. Use the `-K<size>' option to increase it. Why (I imagine this is because there is an infinite loop in the construction of the show function)? Is there any workaround? Thanks, TP

4 6

Compiler error in Parsec using ByteString
by mukesh tiwari 18 May '13

18 May '13

Hello all, I am trying to write a small calculator using Parsec. Every thing went fine and I wrote this [1] and now I am trying to use ByteString to make it more faster but getting compiler error which I am not able to figure out. Could some one please tell me what is wrong with this code. In case of indentation error, code on hpaste[2] {-# LANGUAGE OverloadedStrings #-} import qualified Text.Parsec.Token as Token import Text.Parsec.Prim import Text.Parsec.Char import Text.Parsec.Expr import Text.Parsec.Combinator import Text.Parsec.Language import qualified Text.Parsec.ByteString.Lazy as T import qualified Data.ByteString.Lazy.Char8 as BS import Control.Applicative hiding ( ( <|> ) , many ) import Data.Maybe ( fromJust ) languageDef = emptyDef { Token.commentStart = "/*" , Token.commentEnd = "*/" , Token.commentLine = "//" , Token.nestedComments = False , Token.identStart = letter <|> char '_' , Token.identLetter = alphaNum <|> oneOf "_'" , Token.opStart = Token.opLetter emptyDef , Token.opLetter = oneOf ":!#$%&*+./<=>?@\\^|-~" , Token.reservedOpNames= ["*" , "/" , "^" , "+" , "-" ] , Token.reservedNames = [] , Token.caseSensitive = True } lexer = Token.makeTokenParser languageDef identifier = Token.identifier lexer reserved = Token.reserved lexer operator = Token.operator lexer reservedOp = Token.reservedOp lexer natural = Token.natural lexer integer = Token.integer lexer float = Token.float lexer lexeme = Token.lexeme lexer parens = Token.parens lexer whiteSpace = Token.whiteSpace lexer semi = Token.semi lexer comma = Token.comma lexer colon = Token.colon lexer dot = Token.dot lexer semiSep = Token.semiSep lexer commaSep = Token.commaSep lexer data Expr = Num Integer | Add Expr Expr | Sub Expr Expr | Mul Expr Expr | Div Expr Expr | Exp Expr Expr deriving Show exprCal :: T.Parser Expr exprCal = buildExpressionParser table factor table = [ [ op "^" Exp AssocRight ] , [ op "*" Mul AssocLeft, op "/" Div AssocLeft ] , [ op "+" Add AssocLeft, op "-" Sub AssocLeft ] ] where op s f assoc = Infix ( reservedOp s >> return f ) assoc factor :: T.Parser Expr factor = parens exprCal <|> Num <$> integer calExpression :: Expr -> Integer calExpression ( Num n ) = n calExpression ( Add e1 e2 ) = calExpression e1 + calExpression e2 calExpression ( Sub e1 e2 ) = calExpression e1 - calExpression e2 calExpression ( Mul e1 e2 ) = calExpression e1 * calExpression e2 calExpression ( Div e1 e2 ) = div ( calExpression e1 ) ( calExpression e2 ) calExpression ( Exp e1 e2 ) = calExpression e1 ^ ( calExpression e2 ) calculator :: String -> Integer calculator expr = case parse ( whiteSpace >> exprCal ) "" ( BS.pack expr ) of Left msg -> error "failed to parse" Right ( val ) -> calExpression val *Main> :load "/Users/mukeshtiwari/Programming/Code/Compilers/ParsecExample.hs" [1 of 1] Compiling Main ( /Users/mukeshtiwari/Programming/Code/Compilers/ParsecExample.hs, interpreted ) /Users/mukeshtiwari/Programming/Code/Compilers/ParsecExample.hs:56:36: Couldn't match type `[Char]' with `BS.ByteString' Expected type: OperatorTable BS.ByteString () Data.Functor.Identity.Identity Expr Actual type: [[Operator String () Data.Functor.Identity.Identity Expr]] In the first argument of `buildExpressionParser', namely `table' In the expression: buildExpressionParser table factor In an equation for `exprCal': exprCal = buildExpressionParser table factor /Users/mukeshtiwari/Programming/Code/Compilers/ParsecExample.hs:67:11: Couldn't match type `[Char]' with `BS.ByteString' Expected type: ParsecT BS.ByteString () Data.Functor.Identity.Identity Expr Actual type: ParsecT String () Data.Functor.Identity.Identity Expr In the return type of a call of `parens' In the first argument of `(<|>)', namely `parens exprCal' In the expression: parens exprCal <|> Num <$> integer /Users/mukeshtiwari/Programming/Code/Compilers/ParsecExample.hs:67:19: Couldn't match type `BS.ByteString' with `[Char]' Expected type: ParsecT String () Data.Functor.Identity.Identity Expr Actual type: T.Parser Expr In the first argument of `parens', namely `exprCal' In the first argument of `(<|>)', namely `parens exprCal' In the expression: parens exprCal <|> Num <$> integer /Users/mukeshtiwari/Programming/Code/Compilers/ParsecExample.hs:68:21: Couldn't match type `[Char]' with `BS.ByteString' Expected type: ParsecT BS.ByteString () Data.Functor.Identity.Identity Integer Actual type: ParsecT String () Data.Functor.Identity.Identity Integer In the second argument of `(<$>)', namely `integer' In the second argument of `(<|>)', namely `Num <$> integer' In the expression: parens exprCal <|> Num <$> integer /Users/mukeshtiwari/Programming/Code/Compilers/ParsecExample.hs:82:46: Couldn't match type `BS.ByteString' with `[Char]' Expected type: ParsecT String () Data.Functor.Identity.Identity Expr Actual type: T.Parser Expr In the second argument of `(>>)', namely `exprCal' In the first argument of `parse', namely `(whiteSpace >> exprCal)' In the expression: parse (whiteSpace >> exprCal) "" (BS.pack expr) /Users/mukeshtiwari/Programming/Code/Compilers/ParsecExample.hs:82:62: Couldn't match type `BS.ByteString' with `[Char]' Expected type: String Actual type: BS.ByteString In the return type of a call of `BS.pack' In the third argument of `parse', namely `(BS.pack expr)' In the expression: parse (whiteSpace >> exprCal) "" (BS.pack expr) Failed, modules loaded: none. Prelude> Mukesh Tiwari [1] http://hpaste.org/88155 [2] http://hpaste.org/88156

2 2

Extensible Records using Implicit Parameters
by Thomas Jaeger 18 May '13

18 May '13

Hello, Records in Haskell are somewhat of a contentious issue and many proposals have been put forth to address the shortcomings of the current record system [1]. Below, I introduce a small library relying on several GHC extensions, crucially Implicit Parameters and Constraint Kinds, which implements an extensible record system. While by no means production-ready, it is remarkably close to how I think an extensible record system should function. Record access is very convenient (reminiscent of Pascal's with statement), while record update is somewhat cumbersome (but could potentially be improved using Template Haskell). Two caveats: * Type inference for records does not work, so type signatures have to be provided. * When more than one binding for an implicit parameter is in scope, it is not always clear which one takes precedence. However, I think it is safe to assume that if the innermost binding is a let/where binding, it will carry the day. In all other cases, it is probably safest to rely on explicit type signatures to resolve the ambiguity. > {-# LANGUAGE ImplicitParams #-} > {-# LANGUAGE ConstraintKinds #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE RankNTypes #-} The record type is simply the dictionary type, which is more commonly used to reify type class dictionaries. Here, we use it to record a number of implicit parameter bindings, i.e. if implicit parameters of types `fields' are in scope, then the data constructor `Rec' will create a dictionary from them, provided an appropriate type signature is given. > data Record fields where > Rec :: fields => Record fields The `?' operator will bring the implicit parameter bindings previously captured by `Rec' into scope. > infixr 1 ? > (?) :: Record fields -> (fields => r) -> r > Rec ? e = e This is the complete library. Examples follow below. ======================================================================== Type synonyms to replace the awkward syntax for implicit parameter constraints. > type X a = ?x::a > type Y a = ?y::a > type Z a = ?z::a As a first example, construct a record with fields ?x and ?y, both of type Int. > xy :: Record (X Int, Y Int) > xy = let ?x = 1; ?y = 2 in Rec To access the fields of the record, we can use the `?' operator. Expressions involving any of the fields can appear to the right of the operator. * xy ? ?x ==> 1 * xy ? ?x + ?y ==> 3 The next example illustrates record update > xy' :: Record (X Int, Y Int) > xy' = xy ? let ?y = -2 in Rec * xy' ? ?y ==> -2 Type signatures are required, but can be placed directly after `Rec'. > xz = let ?x = -1; ?z = 3 in Rec :: Record (X Int, Z Int) Record Restriction > y :: Record (Y Int) > y = xy ? Rec We can combine records as follows, but the result may be implementation- dependent if both records share fields. > xyz, xyz' :: Record (X Int, Y Int, Z Int) > xyz = xz ? xy ? Rec * xyz ? ?x ==> -1 So it is probably better to disambiguate. > xyz' = xz ? y ? Rec * xyz' ? ?x ==> -1 ======================================================================== As an application, we use records to build a rudimentary object system. A class is a record which can access its own fields, which are supplied as an argument. > type Class fields = Record fields -> Record fields Originally I tried the type 'fields => Record fields', which leads to problems when tying the knot. Given a class, we can get a record for property and method access by using a fixed point combinator. > runClass :: Class fields -> Record fields > runClass inst = inst (runClass inst) Type signatures for our next example. > type N = ?n::Int > type AbstractFact = (?fact::Int, ?factHelper::Int -> Int -> Int) > type ConcreteFact = (AbstractFact, N) This is an abstract class that computes the factorial of its abstract property `?n'. Notice how `?n' is not included in the function's return type. > abstractFact :: Record ConcreteFact -> Record AbstractFact > abstractFact r = Rec where > ?fact = r ? ?factHelper 1 ?n > ?factHelper = r ? > \p k -> if k == 1 then p else ?factHelper (p*k) (k-1) It is important that `r' only be opened inside the definitions of the methods, otherwise `runClass' will cause an infinite loop. To go from an abstract class to a concrete class, all we need to do is provide the missing property. > concreteFact :: Int -> Class ConcreteFact > concreteFact n r = abstractFact r ? let ?n = n in Rec Quick sanity check > testFact :: Class ConcreteFact > testFact = concreteFact 10 * runClass testFact ? ?fact ==> 3628800 Example of overloading. > overrideFact :: Class ConcreteFact > overrideFact r = testFact r ? let ?fact = fact in Rec where > fact = r ? product [1.. ?n] It is tempting to use the following definition overrideFact r = testFact r ? let ?fact = product [1.. ?n] in Rec However, this will use `?n' from the current environment and not respond to `?n' being overridden in a subclass. The final example concerns multiple inheritance. We first define a class for computing Fibonacci numbers, similar to the one for the factorial above. > type Fib = (?fib::Int, N) > fib :: Int -> Class Fib > fib n r = Rec where > ?n = n > ?fib = let fibs = 0:zipWith (+) fibs (1:fibs) in r ? fibs !! ?n A multiple-inheritance combinator > diamond :: Class c1 -> Class c2 -> Class (c1,c2) > diamond c1 c2 r = c1 (r ? Rec) ? c2 (r ? Rec) ? Rec > testFactFib :: Class (ConcreteFact, Fib) > testFactFib = diamond testFact (fib 5) This is C++-style inheritance: We now have two copies of the field `?n'. * runClass testFactFib ? ?fact ==> 3628800 * runClass testFactFib ? ?fib ==> 5 However, if we were to update `?n' in a subclass, both the factorial and the Fibonacci class would both use the new value. Alternatively, we can force the class to use a single value for `?n' by making sure `?n' only occurs once in the list of fields, but it's anyone's guess which value GHC will pick for `?n'. > testFactFib' :: Class (AbstractFact, Fib) > testFactFib' r = testFactFib (r ? Rec) ? Rec * runClass testFactFib' ? ?fact ==> 120 * runClass testFactFib' ? ?fib ==> 5 Thomas [1] http://hackage.haskell.org/trac/ghc/wiki/Records

1 0

A use case for *real* existential types
by oleg＠okmij.org 18 May '13

18 May '13

But Haskell (and GHC) have existential types, and your prototype code works with GHC after a couple of trivial changes: > main = do > W nd0 <- init > wd0 <- addWatch nd0 "foo" > wd1 <- addWatch nd0 "bar" > W nd1 <- init > wd3 <- addWatch nd1 "baz" > printInotifyDesc nd0 > printInotifyDesc nd1 > rmWatch nd0 wd0 > rmWatch nd1 wd3 > -- These lines cause type errors: > -- rmWatch nd1 wd0 > -- rmWatch nd0 wd3 > printInotifyDesc nd0 > printInotifyDesc nd1 The only change is that you have to write W nd <- init and that's all. The type-checker won't let the user forget about the W. The commented out lines do lead to type errors as desired. Here is what W is > data W where > W :: Inotify a -> W > init :: IO W [trivial modification to init's code] I must say though that I'd rather prefer Adres solution because his init > init :: (forall a. Inotify a -> IO b) -> IO b ensures that Inotify does not leak, and so can be disposed of at the end. So his init enforces the region discipline and could, after a trivial modification to the code, automatically do a clean-up of notify descriptors -- something you'd probably want to do.

2 2