May 2009 - Haskell-Cafe

Bool as type class to serve EDSLs.
by Sebastiaan Visser 03 Jun '09

03 Jun '09

Hello, While playing with embedded domain specific languages in Haskell I discovered the Num type class is a really neat tool. Take this simple example embedded language that can embed primitives from the output language and can do function application. >data Expr :: * -> * where > Prim :: String -> Expr a > App :: Expr (a -> b) -> Expr a -> Expr b Take these two dummy types to represent things in the output language. >data MyNum >data MyBool Now it is very easy to create an Num instance for this language: >primPlus :: Expr (MyNum -> MyNum -> MyNum) >primPlus = Prim "prim+" >instance Num (Epxr MyNum) where > a + b = primPlus `App` a `App` b > fromInteger = Prim . show > ... Which allows you to create very beautiful expression for your language embedded inside Haskell. The Haskell expression `10 * 5 + 2' produces a nice and well typed expression in your embedded domain. But unfortunately, not everyone in the Prelude is as tolerant as the Num instance. Take the Eq and the Ord type classes for example, they require you to deliver real Haskell `Bool's. This makes it impossible make your DSL an instance of these two, because there are no `Bool's only `Expr Bool's. Which brings me to the point that, for the sake of embedding other languages, Haskell's Prelude (or an alternative) can greatly benefit from (at least) a Boolean type class like this: class Boolean a where ifthenelse :: a -> b -> b -> b -- Not sure about this representation. ... And one instance: >instance Boolean (Expr MyBool) where > ifthenelse c a b = Prim "if-then-else" `App` c `App` a `App` b Now we can change (for example) the Eq type class to this: >class Eq a where > (==) :: Boolean b => a -> a -> b > (/=) :: Boolean b => a -> a -> b For which we can give an implementation for our domain: >primEq :: Epxr (a -> a -> MyBool) >primEq = Prim "==" >instance Eq (Expr a) where > a == b = primEq `App` a `App` b And now we get all functionality from the Prelude that is based on Eq (like not, &&, ||, etc) for free in our domain specific language! Off course there are many, many more examples of things from the standard libraries that can be generalised in order to serve reuse in EDSLs. Anyone already working on such a generalized Prelude? I can imagine much more domains can benefit from this than my example above. Any interesting thoughts or pointers related to this subject? Gr, -- Sebastiaan Visser

13 15

Error message reform (was: Strange type error with associated type synonyms)
by Max Rabkin 01 Jun '09

01 Jun '09

On Wed, May 27, 2009 at 11:05 PM, Bulat Ziganshin <bulat.ziganshin(a)gmail.com> wrote: > i mean just changing the words to make obvious what type was got in > what way. and check it on beginners who don't yet read your > explanations, for example teachers may test it on their students > > my English is limited... for example, it may be like this: > > read x > > Error: type of x is Integer > while type of read argument should be String For me, this word order is an improvement, but it doesn't help to leave out the words "expected" and "inferred". To me, those words add explanation. Of course they don't help if you don't know what they mean. I think they add something because they explains where the types "came from". When I get type errors, I often think "why do you say True has type Bool" (of course in most cases it is not so transparent). Although the compiler doesn't say *why* it inferred that type, at least it says it did infer it. I prefer this wording: The inferred type of `True' is `Bool', while the type of the first argument of `f' should be `Int'. In the expression: f True I prefer all three to Hugs's ERROR - Type error in application *** Expression : f True *** Term : True *** Type : Bool *** Does not match : Int --Max

13 22

How to implement this? A case for scoped record labels?
by ntupel＠googlemail.com 01 Jun '09

01 Jun '09

Hi, I would like to get some advice on how to best implement a protocol. The protocol in question is "Bayeux": http://svn.cometd.org/trunk/bayeux/bayeux.html. The details don't matter here - it defines a couple of requests and responses in JSON format, basically JSON objects with different properties, some of which are shared by all (e.g. "channel") and some which are specific for certain kinds of requests/responses (e.g. "subscription"). To give an example, a connect request would look like this: [ { "channel": "/meta/connect", "clientId": "Un1q31d3nt1f13r", "connectionType": "long-polling" } ] Now I leave the actual JSON parsing to the excellent Text.JSON library. My problem is how to get the types right. At first I started with a big discriminated union, e.g. data BayeuxMessage = HandshakeRequest { channel :: String , ... } | HandshakeResponse { channel :: String, successful :: Bool, ... } | ... This way I could create BayeuxMessage values by copying the Text.JSON parsed values over. However what I don't like is that many selector functions, e.g. successful, are only partial and using them with a BayeuxMessage value constructed with HandshakeRequest for example will result in a runtime error. So I think it would be better to have individual types for the protocol requests/responses, e.g. data HandshakeRequest = HandshakeRequest { channel :: String , ... } data HandshakeResponse = HandshakeResponse { channel :: String, successful :: Bool, ... } ... data BayeuxMessage = HSReq HandshakeRequest | HSRes HandshakeResponse ... This however does not work because record selectors have module scope, so the compiler will complain that channel et. al. are defined multiple times. As a workaround I could put each type into its own module, but at least GHC requires a file per module (which is *very* inconvenient IMO). If we would have scoped labels (e.g. like proposed here: http://legacy.cs.uu.nl/daan/pubs.html#scopedlabels) it seems like it would have been straightforward. So certainly I am missing something and there is a better way to design this. Hence this e-mail. I welcome any advice how this would best be done in Haskell with GHC. Many thanks, nt

7 8

Re: [Haskell-cafe] Parsec float
by Bartosz Wójcik 31 May '09

31 May '09

On Friday 29 May 2009 08:34:36 you wrote: > myfloat = try (do{ symbol "-"; n <- float; return (negate n) }) <|> > try float <|> > do { i<-integer; return(fromIntegral i) } Thank you, this is an easy and nice solution. I've made it a bit prettier optically: myFloat = try (symbol "-" >> float >>= return . negate) <|> try float <|> (integer >>= return . fromIntegral) Best regards, Bartek

7 9

Lazy Parsing
by Günther Schmidt 31 May '09

31 May '09

Hi all, is it possible to do lazy parsing with Parsec? I understand that one can do that with polyparse, don't know about uulib, but I happen to be already somewhat familiar with Parsec, so before I do switch to polyparse I rather make sure I actually have to. The files it has to parse is anywhere from 500 MB to 5 GB. Günther

10 11

Re: Lazy Parsing
by Guenther Schmidt 31 May '09

31 May '09

Dear Doaitse, thank you very much for your help. > > I am curious to know what made you go wrong with the tutorial, and > caused that you could not find the solution below? > Well let's first agree that I'm not very bright. I hate to admit it, but it's a simple fact ;-). Second let's agree that the uu-parsinglib is a *very* sophisticated beast, I have not seen anything else like it out there, my sincere congratulations for it. Thirdly the tutorial is also a very sophisticated beast, and forthly, well just see point 1 :-). And I just figured out why I was unable to write even that simple parser. The code you sent me works just fine, I copied and pasted it, no problems. But, as soon as I comment out the "main" function the type checker complains, because now the ghci's type checker can no longer infer the types of pDate or pDot. And this is exactly what happened. I kept getting error messages from ghci, eventhough I had defined my parsers possible correctly, but, *minus* the type signatures *and* minus any main function that called it. In hindsight I realize that this is a trap I have walked into many times before, I guess I still have not acquired a Haskellers intuition. I promise to do better next time :) Günther

2 1

Type families in export lists
by Maurício 31 May '09

31 May '09

Hi, How do I include type families (used as associated types) in a module export list? E.g.: class MyClass a where type T a :: * coolFunction :: Ta -> a (...) If I just include MyClass and its functions in the list, instances in other modules complain they don't know T, but I wasn't able to find how (where) to include T in the list. Thanks, Maurício

3 3

(no subject)
by Vladimir Reshetnikov 31 May '09

31 May '09

Hi, Seems that Haskell allows to specify "dummy" type variables in a declaration of a type synonym, which do not appear in its right-hand side. This can lead to interesting effects, which appears differently in GHC and Hugs. I would like to know, what behavior is correct according to the haskell 98 report. 1) ------------------------------------------ type F a = Int class A a where foo :: A b => a (F b) ------------------------------------------ GHC - OK Hugs - Illegal type "F b" in constructor application 2) ------------------------------------------ type F a = Int class A a where foo :: F a instance A Bool where foo = 1 instance A Char where foo = 2 xs = [foo :: F Bool, foo :: F Char] ------------------------------------------ GHC: M.hs:14:6: Ambiguous type variable `a' in the constraint: `A a' arising from a use of `foo' at M.hs:14:6-8 Probable fix: add a type signature that fixes these type variable(s) M.hs:14:21: Ambiguous type variable `a1' in the constraint: `A a1' arising from a use of `foo' at M.hs:14:21-23 Probable fix: add a type signature that fixes these type variable(s) Hugs: [1,2] Thanks, Vladimir

2 2

GHCi vs. Hugs (record syntax)
by Vladimir Reshetnikov 31 May '09

31 May '09

Hi, I tried to evaluate this expression: head[[]{}] GHCi: [] Hugs: ERROR - Empty field list in update What is the correct behavior? Thanks, Vladimir

3 2

Which type variables are allowed in a context?
by Vladimir Reshetnikov 31 May '09

31 May '09

Hi, Consider this (a bit pathological) Haskell code: -------------------------------------- class A a where foo :: A (b d) => a (c b) -------------------------------------- GHC compiles it successfully, but Hugs rejects it: Ambiguous type signature in class declaration *** ambiguous type : (A a, A (b c)) => a (d b) *** assigned to : foo What is the correct behavior, and which part of the haskell 98 report explains this? Thanks, Vladimir

2 1