- Haskell-Cafe - Haskell.org

Data declaration vs type classes
by Lian Hung Hon 11 Jan '16

11 Jan '16

Dear haskellers, What is the difference between writing data Task = GroceryTask String | LaundryTask Int doTask :: Task -> IO () doTask (GroceryTask s) = print "Going to " ++ s doTask (LaundryTask n) = print (show n ++ " pieces washed" and class Task a where work :: a -> IO () data GroceryTask = GroceryTask String data LaundryTask = LaundryTask Int instance Task GroceryTask where .. instance Task LaundryTask where .. doTask :: Task a => a -> IO () doTask = work They seem to be similar functionality wise, except that one is on the data level and another is on the class level. How should one go about deciding to use data or class? Is there a semantic difference? Which is more appropriate here? Happy new year, Hon

8 11

[RFC] github-0.14.0 release candidate
by Oleg Grenrus 11 Jan '16

11 Jan '16

Hi, There are lot of breaking changes In upcoming github package, which provides accoss to the Github API, v3 [1] I’d like to hear feedback before pushing the actual release. There are many breaking changes, and would be nice to avoid new breaking changes very soon. So if you spot something which can still be fixed, don’t hesitate to contact me or create a issue on Github [3]. You can find the release candidate at Hackage [2]. Cheers, Oleg Grenrus - [1]: https://developer.github.com/v3/ - [2]: http://hackage.haskell.org/package/github-0.14.0/candidate - [3]: https://github.com/phadej/github/issues

1 0

Promotion of field accessors using DataKinds
by William Yager 11 Jan '16

11 Jan '16

Hello all, Let's say I have some data data Config = Conf (len :: Nat) (turboEncabulate :: Bool) Using DataKinds, we can promote Config to a kind and Conf to a type. However, it does not appear that GHC supports e.g. data Thing (conf :: Config) = Thing data Count (n :: Nat) = Count foo :: Thing conf -> Count (len conf) foo Thing = Count That is, it does not appear to properly replace "len conf" with the value of len from conf. Instead, the way I've found to do this is to define class Lengthed (a :: Config) where type Len a :: Nat instance Lengthed (Conf n) where type Len (Conf n t) = n Now, foo :: Thing conf -> Count (Len conf) works fine. So manually defining a type function that intuitively does the exact same thing as "len" seems to work. Is there a particular reason behind this? Thanks, Will

2 1

Merging the OpenGLRaw and gl packages
by Sven Panne 11 Jan '16

11 Jan '16

Currently there are 2 similar packages on Hackage to access raw OpenGL functionality: OpenGLRaw and gl. Taking a closer look at them, it turns out that they are only superficially different and have a lot of things in common. This is a bit confusing for users, so it might make sense to merge those packages. Therefore I'd like to start a discussion how to do this in detail, collecting user feedback and opinions. I think that haskell-cafe is the right place for this discussion, while an accompanying wiki page is more suitable to collect the results. As a basis I started a page at https://github.com/haskell-opengl/OpenGLRaw/wiki/Merging-OpenGLRaw-and-gl, which is necessarily biased at the moment. ;-) It would be nice to hear your opinions about how the package should look like, what might be missing, what could be done better, which differences I forgot, etc. Cheers, S.

3 9

ANN: true-name 0.1.0.0 released
by Liyang HU 11 Jan '16

11 Jan '16

> Also sent to comp.lang.haskell, & to convince Gmane I'm not top-posting. It is with some shame that I announce ‘true-name’, a package to assist one in violating those pesky module abstraction boundaries via the magick of Template Haskell. http://hackage.haskell.org/package/true-name Take ‘Control.Concurrent.Chan’ for example; you can get your grubby mitts on the ‘Chan’ data constructor, despite it not being exported. Here we pattern match on it, and bind ‘chanR’ and ‘chanW’ to the ‘MVar’s containing the read and write ends of the channel respectively: > chan@[truename| ''Chan Chan | chanR chanW |] <- newChan > writeChan chan (42 :: Int) Now, the type of ’chanR’ references the unexported ‘Stream’ and ‘ChItem’ types. We need the ‘ChItem’ data constructor―which is hidden under a few indirections—but that's not a problem: > streamR <- readMVar chanR > [truename| ''Chan Chan Stream ChItem ChItem | x _ |] <- readMVar streamR > putStrLn $ "chan contains: " ++ show x This gives us a rather dodgy ‘peekChan’. This sort of thing is usually a Bad Idea™, but may sometimes be more palatable than the alternatives. Full example: https://github.com/liyang/true-name/blob/master/sanity.hs Taking another example, suppose we want the ‘Array’ type constructor hidden deep in the bowels of the ‘HashMap’ implementation: ghci> :set -XQuasiQuotes ghci> import Data.HashMap.Strict ghci> :kind [truename| ''HashMap Full Array |] [truename| ''HashMap Full Array |] :: * -> * The ‘Array’ data constructor is one more reification away: ghci> :type [truename| ''HashMap Full Array Array |] [truename| ''HashMap Full Array Array |] :: ghc-prim-0.4.0.0:GHC.Prim.Array# a -> unordered-containers-0.2.5.1:Data.HashMap.Array.Array a Please don't flame me. /Liyang

1 0

pattern matching v. type checking
by Jeffrey Brown 10 Jan '16

10 Jan '16

I am, thanks to an idea from Elliot Cameron, using the Functional Graph Library (FGL) to implement [1] something resembling a hyperggraph, which I'm calling Mindmap, in which relationships can involve any number of things, including other relationships. (By contrast, in a graph, Edges cannot belong to other Edges; only Nodes can.) Here are the types: -- Exprs (expressions) play Roles in Rels (relationships). -- A k-ary (Arity k) Rel consists of a k-ary template and k members. -- Each k-ary Rel emits k+1 Edges toward the other Exprs: -- one connects it to its RelTplt (relationship template) -- k more connect it to each of its k RelMbrs (relationship members) -- The two paragraphs after it will clear up any questions about the next. type Mindmap = Gr Expr Role data Role = RelTplt | RelMbr RelPos deriving (Show,Read,Eq,Ord) data Expr = Str String | Tplt Arity [String] | Rel Arity -- TODO ? deduce the Arity of a Tplt from its [String] -- TODO ? deduce from the graph the Arity of a Rel -- rather than carrying it redundantly in the Rel constructor deriving (Show,Read,Eq,Ord) type RelPos = Int -- the k members of a k-ary Rel take RelPos values [1..k] type Arity = Int The following is a Mindmap that represents the expression "dog needs water" using the subexpressions "dog" (a string), "water" (a string), and "_ wants _" (a relationship two things can have, that is a binary Rel): -- mkGraph :: Graph gr => [LNode a] -> [LEdge b] -> gr a b -- that is, mkGraph takes a list of nodes followed by a list of edges g1 :: Mindmap g1 = mkGraph [ (0, Str "dog" ) , (1, stringToTplt "_ wants _" ) -- produces a Tplt with Arity 2 , (3, Str "water" ) , (4, Rel 2 ) ] [ -- "dog wants water" (4,1, RelTplt) -- Node 1 is the Template for the Rel at Node 4 , (4,0, RelMbr 1) -- Node 0 is the 1st Rel Member of the Rel at Node 4 , (4,3, RelMbr 2) -- Node 3 is the 2nd Rel Member of the Rel at Node 4 ] The next Mindmap encodes the previous statement and a second statement stating that the first is dubious: g2 :: Mindmap g2 = mkGraph [ (0, Str "dog" ) , (1, stringToTplt "_ wants _" ) , (3, Str "water" ) , (4, Rel 2 ) , (5, stringToTplt "_ is _") , (6, Str "dubious" ) , (7, Rel 2 ) ] [ -- "dog wants water" is represented just like it was in g1 (4,1,RelTplt), (4,0, RelMbr 1), (4,3,RelMbr 2), -- "[dog wants water] is dubious" (7,5,RelTplt), (7,4,RelMbr 1), -- Node 4, the first Member of this Rel, is itself a Rel (7,6,RelMbr 2) ] I find myself doing a lot of pattern matching that maybe should be type checking instead, to distinguish between the three Expr constructors: For instance, here is a function that, given a Node at which there is a Rel, returns the Tplt for that Rel: tpltForRelAt :: (MonadError String m) => Mindmap -> Node -> m Expr tpltForRelAt g rn = do ir <-isRel g rn if not ir then throwError $ "tpltForRelAt: Label of LNode " ++ show rn ++ " is not a Rel." else return $ fromJust $ lab g $ head [n | (n,RelTplt) <- lsuc g rn] -- todo ? head is unsafe -- but is only unsafe if graph takes an invalid state -- because each Rel should have exactly one Tplt I had to manually check whether the Expr in question was a Rel. I feel like I'm doing the type system's job. Is there a better way? [1] https://github.com/JeffreyBenjaminBrown/digraphs-with-text -- Jeffrey Benjamin Brown

1 0

Regarding Developing my skills with haskell!
by Abhijit Patel 09 Jan '16

09 Jan '16

Hello, I want to learn some practical application using haskell like some projects or developing a game. Can anyone suggest me some link to develop my skills with haskell ? Cheers, Abhijit

3 2

Re: [Haskell-cafe] Lazy series [was : Preventing sharing]
by Tom Ellis 09 Jan '16

09 Jan '16

Sharing a private conversation, with the permission of Jerzy. On Sat, Jan 09, 2016 at 11:45:00AM +0100, Jerzy Karczmarczuk wrote: > Again: *exps = 1 + integral exps* > > I said that if RHS exps is evaluated, it cannot work. > > >>>But if it evaluates to a thunk ... > >>Then, on which premises you call the language "strict"? > > >Why not? > > > >A thunk could either be a delayed function call, or it could be a memoised > >thunk, such as OCaml (a strict language) provides > > > > http://caml.inria.fr/pub/docs/manual-ocaml/libref/Lazy.html [...] > But in the original expression with exps, you don't delay anything. > You don't construct *exps()*, or equivalent. This variable is just > variable, lexical atom, and either you evaluate it or not. If not, > don't call the language strict. If there is a delay form introduced > by the compiler, the language is not strict. > > If you don't agree, I suggest that instead of asking "why this > doesn't work, it should!" , simply implement it. Oleg has already provided most of the solution http://okmij.org/ftp/ML/powser.ml The aim is exps = 1 + integral exps In Oleg's framework the answer is let exps = I.fix (fun e -> int 1 +% integ e) In a hypothetical OCaml with typeclasses, this becomes let exps = I.fix (fun e -> 1 + integ e) The remaining objection is the presence of the fix. The solution here is to allow the language to support recursive bindings of lazy values[1], not just of function values. The we could write let rec exps = 1 + integ exps If you still do not agree I would appreciate it if you could explain why such a language a) could not exist, or b) would not be called "strict" If you're still not convinced, consider a lazy language, Haskell--, which doesn't allow recursive bindings of non-function types. In Haskell-- you *cannot* write exps = 1 + integral exps but you have to write exps = I.fix (\e -> 1 + integral e) So we see that the nice syntax "exps = 1 + integral exps" is not due to laziness (since Haskell-- is lazy, but you cannot write that). Instead the nice syntax is due to lazy recursive bindings, and this sugar can exist as well in a strict language as it can in a lazy one. Tom [1] Note that recursive bindings are anyway just syntactic sugar for a fixed point. The definition sum = \x -> case x of [] -> 0 (x:xs) = x + sum xs is (essentially) sugar for sum = fix (\sum' x -> case x of [] -> 0 (x:xs) = x + sum' xs) so adding additional sugar for binding lazy values can hardly spoil anything.

3 9

async docs not on hackage for some reason?
by Noon Silk 09 Jan '16

09 Jan '16

Hello, Does anyone have any thoughts why the async docs aren't available on hackage yet? - https://hackage.haskell.org/package/async-2.1.0 It says this version was uploaded a few days ago, but no docs are available. I did a `cabal get` locally and build the docs using stack; so it works fine. -- Noon Silk, ن https://silky.github.io/ "Every morning when I wake up, I experience an exquisite joy — the joy of being this signature."

2 1

Re: [Haskell-cafe] Haskell-cafe] Preventing sharing
by Doug McIlroy 09 Jan '16

09 Jan '16

Oleg rewrote my power-series one-liners to illustrate the fact that lazy lists defined in a strict language need not be very clumsy to use. I had implemented those funstions in many strict languages, one of which was ML using a lazy-list implementation from Dave MacQueen. But after I finally did it in Haskell, I never looked back. Though ML was the best of the strict bunch. Haskell's overloading and cleaner notation made for more perspicuous code. It also enabled elegant code like this for the exponential series: exps = 1 + integral exps As Oleg pointed out, this won't work in a strict language, and must be replaced with something much less vivid: exps = fix (\s 1 + integral s) In slightly more involved cases, such as sins = integral coss coss = 1 - integral sins the strict equivalent becomes murky: sins = fix (\s -> integral (1 - integral s)) coss = derivative sins or (sins, cosx) = fix (\sc -> (integral $ snd sc, 1 - integral $ fst sc) Further, because lazy lists are a new type, they can't be manipulated directly with the standard list vocabulary (map, take, filter, etc.). All such functions must be lifted to the new type. Thus, while lazy lists can be *programmed* in a strict language, they *play* somewhat awkwardly in it. In fairness, I must admit that the beauty of representation by naked lists may not survive when power series are embedded in a more comprehensive algebraic system. For example, if both matrices and power series were defined as list instances of Num, matrices might be confusEd with nested power series. Combinations--matrices of power series and vice versa--could be similarly ambiguous. But it could also turn out to cause no more difficulty than the already extensive degree of polymorphism in arithmetic expressions. Doug

3 3