- Haskell-Cafe - Haskell.org

Lista dos aprovados em concurso Rodrigues Alves
by Edson 29 May '13

29 May '13

Lista dos aprovados em concurso Rodrigues Alves: Novo São Joaquim: ANA ANGELICA PEREIRA ALVES, LETICIA BAIRLE, FRANCISCO ANDERSON VALE DO NASCIMENTO, PAULO DE SIQUEIRA SILVA, JOÃO CARLOS MOREIRA DE CARVALHO, DAMIANA PEREIRA DE OLIVERIA, MARIA DO SOCORRO DE ALBURQUERQUE ARRUDA BARBOSA, JAIME CUSTODIO DA SILVA FILHO. SEBASTIANA MÁRCIA GOMES DE MELO, ÉRICA FRANCISCA BATISTA DE MELO, MAYRES RAQUEL DA SILVA PINHEIRO, JUCIMARA VICENTE DOS SANTOS, WEULLER TEIXEIRA DE MAGALHAES. Governador Nunes Freire. Rodrigues Alves, ADISSON SOUZA TAVARES, JULIO CESAR DA SILVA MOURA FILHO, ERIDAN FERREIRA LEITE, MICHAEL LIMA SILVA, JOÃO CARLOS MOREIRA DE CARVALHO, CARLOS EDNAELTON DE MELO FERREIRA, MANOEL MARQUES DA CUNHA FILHO, IEDA BENTO BARROSO. ROBERTO FERREIRA LOPES FILHO, DOMINGOS SAVIO VIDAL DE LIMA FILHO, MARIANA ISABEL E SILVA, JOSE ALDER BRAGA JUNIOR, THAYS RAQUEL DA SILVA. Brás Pires. Morpará e ANNA JESSYCA ANDRADE LACERDA, LUCAS DE PAULA OLIVEIRA, GEORGE FACUNDO RICARDO, RAFAEL WESLEY MENESES MAIA, JOÃO CARLOS MOREIRA DE CARVALHO, DEBORAH LIMA BRAGA, MARIA MARIANA RIBEIRO VIEIRA, JOÃO VICTOR RODRIGUES DE C. MEDEIROS. TATIANA RODRIGUES DE CASTRO MELO, CAIO URBANO CAMURCA, MAIARA FRANKLIN DE AZEVEDO, IAGO TELES GARCIA, RITA PAULA SEVERO PATU. Hidrolândia.

1 0

Re: [Haskell-cafe] Hackage Update Brigade
by wren ng thornton 29 May '13

29 May '13

On 5/27/13 5:29 PM, Alexander Solla wrote: > As per recent discussions, I'm making a list of volunteers who are willing > to pick up some slack in Hackage package maintenance, so that we can submit > an amendment to the Haskell Prime Committee's ticket 113 ( > http://hackage.haskell.org/trac/haskell-prime/ticket/113) I'd much prefer sticking with the names (<*>), (<*), (*>), and deprecating `ap` and (>>). There's no good name for (<*) since we already have (<<) = flip (>>) which means something different entirely. Plus "`ap`" is longer than "<*>" and loses the suggestive relationship between the operator names. Not to mention the fact that these name changes would cause immense breakage for all users of Applicative, rather than relatively minor breakage for those who define Monad instances. -- Live well, ~wren

1 0

Hackage Update Brigade
by Alexander Solla 29 May '13

29 May '13

As per recent discussions, I'm making a list of volunteers who are willing to pick up some slack in Hackage package maintenance, so that we can submit an amendment to the Haskell Prime Committee's ticket 113 ( http://hackage.haskell.org/trac/haskell-prime/ticket/113) I think that showing that people are willing to pick up missing package maintainer's slack will alleviate the concern of breaking lots of code by refactoring the monad/applicative/functor hierarchy. Code will be broken, but publicly available packages can be fixed by the community during a "staging" period. To that end, I have made a Google Form to collect some volunteer information. If you are interested in helping, please visit: https://docs.google.com/forms/d/1o4B8CEE_42u9f-sgmu2t5iSEvm0cq6-um6g_fHJt6G…

5 6

Design of extremely usable programming language libraries
by Andrey Chudnov 29 May '13

29 May '13

Dear Cafe, I'm exploring the design space of programming language libraries with enhanced usability and I'd your help and comments. I'll start with a few short questions, but offer a detailed discussion of the motivations and the problems I'm facing below. So, if you have interest in the subject or feel you can offer some insight, please, do read on. * Does any generic traversal/transformation (uniplate-style) library support GADTs? * What is the best choice, performance- and memory-wise, for a parser combinator library with support for arbitrary look-ahead? Parsec is considered slow by some [1], but is it only in comparison with attoparsec (which, unfortunately, doesn't support arbitrary look-ahead)? Is there any parser library that performs better than Parsec while still supporting arbitrary look-ahead. * Any multi-mode pretty printer libraries? By multi-mode I mean writing code once and being able to generate, say, both "pretty" and "minified" text representations of a program by changing just one parameter. Also, what's the most efficient pretty-printing library nowadays? Blaze? I've been using Haskell for quite a while now, primarily, for programming-language applications: program analysis, transformation and compilation. I'm sure many would agree that PL work is where Haskell shines. In the recent years new language features and libraries --namely, GADTs, Template Haskell, quasi-quotation and generic programming--- have appeared that could make working with languages even easier than before. That's why it's sad to see that none of the PL libraries seem to make good use of these features (however, I might be starting to understand why). So, I'm currently exploring the design space for a library that uses these advanced Haskell features for delivering better usability, and I'm having problems with implementing some of them. I welcome comments on both the motivations, overall design and the more technical aspects. I've omitted a few details because it's a long e-mail as is. If something is not clear or doesn't make sense, please, let me know. I'll start by listing the features that an "ideal" PL library should have, and that I've come to cherish as both a heavy user and a developer of such. The basic features (pretty much every library has them) include a parser (text->AST (abstract syntax tree)) and a pretty-printer (AST->text), as well as a Haskell representation of the AST that is somewhat easy to use. Pretty much every library has that --- although some might debate the ease of use of the AST representations. However, there are other features that, in my opinion, are essential to a PL library. The features are motivated by three requirements: static safety (as few run-time errors as possible), minimal code duplication (DRY) and ease of use and inspection of the code. 1) the pretty-printer should be multi-mode. One should be able to write code once and be able to generate different textual representations of the AST: - the "pretty" which is nice to the eye with white spaces, indentations etc. - minified, with minimum white space (while still being valid) - debuggable which inserts comments based on AST annotations - source-map generation - being able to generate colored LaTeX/HTML code would be nice, but non-essential 2) ASTs should be statically safe: you should only be able construct values that represent valid programs, or get a typechecker/compiler error otherwise. Languages that have syntactic productions that can appear in one context but not in another need GADTs with type witnesses to achieve that. In fact, such languages are often used to motivate GADTs in the first place [2]. And while the problem in [2] could have been solved by splitting the Expr datatype into two (IntExpr and BoolExpr), in some languages this can't be done (or produces awkward syntax trees). 3) a quasi-quoter with support for anti-quotation and quoted patterns. This also saves a lot of typing *and* makes your code less error-prone and easier to read. What is better (to both write and read)? > [js|#x# = (function (a, b) {return {t1: a + b, t2: a*b};})(#x#, #y#);|] or > ExprStmt def $ AssignExpr def x (CallExpr def (FuncExpr def Nothing > [Id def "a", Id def "b"] $ ReturnStmt def $ ObjectLit [(PropId def $ > Id def "t1", InfixExpr def OpAdd (VarRef def $ Id def "a") (VarRef def $ > Id def "b")), PropId def $ > Id def "t2", InfixExpr def OpMul (VarRef def $ Id def "a") (VarRef def $ > Id def "b")])) [x, y] The caveat here is that, to help ensure correctness, the quasi-quoter and the parser should share code as much code as possible. Ideally, there should be just one parser that has a switch for recognizing normal and quasi-quoted programs. However, that would require adding additional constructors representing anti-quotations to our AST. And with that the user might be able to generate invalid AST's and cause a run-time error. The solution to the last problem is to statically constrain all the values that are passed to, say, the pretty-printer so that they are guaranteed to be free of anti-quotes (see an example definition below). However, that, again, requires GADTs (e.g. have all the AST datatypes have an extra type parameter). > data EType = Complete | HasHoles > type family Quoted a b :: * > canHaveHolesT :: a -> b -> Quoted a b > canHaveHolesT _ _ = undefined > type instance Quoted HasHoles Complete = HasHoles > type instance Quoted Complete HasHoles = HasHoles > type instance Quoted HasHoles HasHoles = HasHoles > type instance Quoted Complete Complete = HasHoles > data Expr t where > EInt :: Int -> Expr Complete > EAdd :: Expr t1 -> Expr c2 -> Expr (Holes t1 t2) > ... > EQuote :: String -> Expr HasHoles And then we could have a normal parser return a value 'Expr Complete' and a quasi-quotation parser retunr a value 'Expr HasHoles'. Similarly, the pretty printer function could have type 'Expr Complete -> Doc'. 4) We should be able to annotate ASTs with arbitrary values, and change the types of those values as we go. The most user friendly way, IMO, is to have the AST datatypes be polymorphic and have that type parameter as an extra field in every constructor. E.g., > data Expr t a where > EInt :: a -> Int -> Expr Complete a > EAdd :: a -> Expr t1 a -> Expr c2 a -> Expr (Holes t1 t2) a > ... > EQuote :: a -> String -> Expr HasHoles a Then we can use the functions in Traverseable to change types of annotations, and inspect the values by pattern-matching on constructors. 5) support for generic operations on syntax trees. Uniplate, which has been designed to work with ASTs, and is awesome for that purpose because it saves a lot of time. I use transform(Bi) and universe(Bi) all the time and it saves *a lot* of typing. Pretty much all my analysis/transformation code uses those four small-but-powerful function calls -- and, dare I say, it's quite elegant. Other useful, but not crucial features include: 1) diffs for ASTs (in the spirit of the 'gdiff' library, which, alas, doesn't work with polymorphic datatypes) 2) QuickCheck arbitrary instances for ASTs. No technical difficulty there, but writing instances that generate interesting programs and don't run out of memory is quite hard :) I wish 'Agata' was still supported, or there was some library that helps writing Arbitrary instances for ASTs. If you think there's another feature in mind that is missing from the list, please, let me know. The (perceived) challenges in implementing the functionality outlined above are as follows: 1) No multi-mode pretty-printing library. I think that the mutli-mode functionality could be implemented on top of an existing library by definining new combinators, but it would be nice to have a library that supports them out of the box. The particular features that I'm missing are: - "non-essential space/(soft-)line break" combinators that are interpreted as spaces/line-breaks in the "pretty" mode and as empty docs in the "minified" mode. - "comment" combinator which inserts the text in a comment only if the "debug" mode is on - being able to record the positions of AST nodes in the resulting text (for generating source maps). Not sure what would be a convenient interface for that. Note: I know that mainland-pretty has position information, but I don't think it's helpful for generating source maps. 2) The biggest problem is that there are two good reasons to use GADTs when specifying AST datatypes. However, uniplate doesn't work with GADTs and, as far as I know, no currently supported generic programming library does (to be precise, I need support for families of mutually recursive polymorphic GADTs). Am I missing some library, or is my understanding correct? If it's the latter, is there any fundamental limitation that prevents creating such a library? Maybe there are other (but still elegant) ways to satisfy my requirements without using GADTs? 3) 'gdiff' doesn't support polymorphic datatypes. Is there any other library that does? [1] http://www.serpentine.com/blog/2010/03/03/whats-in-a-parsing-library-1/ [2] http://en.wikibooks.org/wiki/Haskell/GADT PS: My attempts so far are in https://github.com/achudnov/language-nextgen/blob/master/Language/Nextgen/S… Regards, Andrey Chudnov

3 4

Type classes
by Johannes Gerer 29 May '13

29 May '13

Dear Haskellers, While trying to understand the interconnection and hierarchy behind the important typeclasses, I stumbled upon the following question that I am not able to answer: There seems to be a hierachy of the type classes, in the sense, that the more powerfull a class is, the more fleixblility you have for combining them to complex programs. (Functor -> Applicative -> Arrow[Choice,Plus,Apply,..] -> Monad). It was nice to read in the Typeclassopedia, that ArrowApply and Monad are equivalent, which is shown by deriving two instances from each other: instance Monad m => ArrowApply (Kleisli m) instance ArrowApply a => Monad (a anyType) The logic seems to be, that if I can derive from every instance of class A an instance of class B, then A is more powerfull than B and (in general) it is easier to be of class B than of class A (e.g. more types can be made Applicatives, than Monads) So far, I think I can follow. But what really hit me was the Cokleisli type. Using it and the logic from above, I can show that ANY type class is more (or equally) powerfull than the Monad: instance AnyClass m => Monad (Cokleilsi m anyType) I know this makes no sense, but where is the fallacy? Why even bother with the above derivation, if any type class can be made into a monad? I can see, that the Monad instance from above does not really transform the type "a", but instead simply fix its first argument. But then on the other hand, the ArrowApply Instance does transform the "m" type (in a way similar to Cokleisli). If attention needs to be paid to the details, then what are they and why did they not matter above? Thanks, Johannes

3 10

Stream instance for Parsec + conduits
by Phil Scott 29 May '13

29 May '13

Hi all. I would like to have a Parsec Stream instance for Data.Text streams in yesod's ConduitM. So far, I have this: hpaste.org/87599 The idea is that because Yesod's conduits will be chunking values in Data.Text, I should have a wrapper StreamSource to cache chunked values. For some reason, the test parser fails, saying: [Left "Blah" (line 1, column 1): unexpected "g" expecting "h" or "g"] Any ideas? Cheers! Phil

2 1

Interfacing Java/Haskell
by Hans Georg Schaathun 29 May '13

29 May '13

Hi all, I am rather new to the café, so I just hope my question fits in. Does anyone have experience with integrating Haskell and Java? I have done some searching, finding a lot of pointers but hardly anything in terms of evaluation, successes, or caveats. >From what I see Frege looks promising, arguably not haskell I suppose, but does it work? Other projects I have seen appear to have reached a stand-still for ages. The background for the question is that I will contribute some control algorithms based on machine learning or AI in a larger project. It would save me a lot of time if I could write in Haskell, but only assuming that interfacing with Java afterwards is trivial compared to writing everything in java in the first place. I am, perhaps, particularly worried that a Haskell-lookalike for JVM might be unable to optimise properly, like not being lazy. Any advice? TIA -- :-- Hans Georg

8 13

Module import and use in GHC plugin?
by Conal Elliott 29 May '13

29 May '13

In writing GHC plugins, how can I (a) add a module import (preferably qualified) and (b) make vars/ids for names imported from the newly imported module (to insert in the transformed Core code)? Thanks, - Conal

1 0

Generalizing unionWithKey, unionWith, ...
by Jose A. Lopes 29 May '13

29 May '13

Hello everyone, unionWithKey and unionWith have the following types unionWith :: Ord k => (a -> a -> a) -> Map k a -> Map k a -> Map k a unionWithKey :: Ord k => (k -> a -> a -> a) -> Map k a -> Map k a -> Map k a Since they are implemented by means of mergeWithKey, wouldn't it be possible to generalize these functions to the following types ? unionWith :: Ord k => (a -> b -> c) -> Map k a -> Map k b -> Map k c unionWithKey :: Ord k => (k -> a -> b -> c) -> Map k a -> Map k b -> Map k c Cheers, Jose -- José António Branquinho de Oliveira Lopes Instituto Superior Técnico Technical University of Lisbon

3 4

Re: [Haskell-cafe] ANN: Haskell Platform 2013.2.0.0
by harry 28 May '13

28 May '13

Good to see it released! Was there a deliberate decision not to build a Windows x64 platform, or is it just that there wasn't anyone to do it?

1 0