February 2016 - Haskell-Cafe

Incredibly slow type-level Nub
by Nickolay Kudasov 08 Feb '16

08 Feb '16

Dear Cafe, I have faced a type-level performance problem (with GHC 7.10.3). I am trying to implement type-level Nub which removes duplicates from a type-level list. My implementation [1] with an example of a list of length 20 takes forever to compile. If you reduce the size of the example list (e.g. to 15 items), it will compile faster. Also, if you remove the Nub application from exampleVals, it compiles instantly (this is how I know the problem is in Nub). My question is how can I speed up type-level Nub? And less importantly why exactly is it this slow? The practical application for this is building automatic tests [2] for servant-swagger. There I am interested in generating exactly one test for each distinct type. Kind regards, Nick [1] https://gist.github.com/fizruk/06458fe8b62a1e562af1 [2] http://hackage.haskell.org/package/servant-swagger-1.0.2/docs/Servant-Swagg…

4 6

RebindableSyntax, ifThenElse, and pattern matching
by Chris Smith 08 Feb '16

08 Feb '16

In a custom prelude, I have written the following definitions: data Truth = True | False ifThenElse :: Truth -> a -> a -> a ifThenElse True x _ = x ifThenElse False _ x = x (==) :: a -> a -> Truth (==) = ... I'm replacing Bool with my own Truth type. Clients will be built with RebindableSyntax, so that they will use these definitions for desugaring. However, if I write this: f :: Text -> Text f "r" = "rrr" f other = other I get a build error indicating that GHC expected the (==) operator to return a value of type Bool, rather than Truth. Shouldn't pattern matching desugar to use overloaded ifThenElse in these situations? Or is it expected that use of GHC.Types.Bool is hard-coded even with RebindableSyntax enabled? Thanks, Chris

3 3

Re: [Haskell-cafe] Language complexity & beginners
by Gregory Guthrie 07 Feb '16

07 Feb '16

I liked this description, and isn't the term for this a "leaky abstraction"? Where one should not have to know the underlying details of an implementation of an abstraction, but.. due to limitations in the ability to actually abstract out these details, they do have to see down a level into the virtual machine (implementation). It seems like a theme of the discussion here is if users should need (want) to know the boxed/unboxed issues because it is part of the intended programming model (=good), or if they need to know it because of "details" of the underlying implementation and resulting usage effects (=baggage/complexity). IMHO the Java need to understand this early on is just an unfortunate by-product of it being a mixed paradigm language. I could see later having more advanced introduction of a feature that allows one to utilize some specific underlying unboxed/primitive representations for performance reasons, but even then seems like it is just an apology for a language weakness, that might go away with future implementations, an abstraction that didn't quite work, "so let me explain the underlying reason and how to get around it..." to optimize your code. ------------------------------------------- > It also feels like the same class of problem as what the segmentation registers in the x86 > architecture try to address. Does anyone here know how the 8086 processor addresses more > than 64k of memory with only 16-bit address registers? I sure wish I didn?t. As a budding > young programmer, reading about these details was a way to learn how computers operate, but > it?s not information I would inflict on any of my current students. > > With Int/Int#, public/private and x86 segmentation, the abstraction never really worked in > the first place. However, because there weren?t any other obvious solutions at the time, these > ?features? were grandfathered into the culture of the technology. For the disciples of a > particular technology, the recognition of problems in the fundamental design of that > technology tends to result in extensions to what they already have -- rather than backing up > and reconsidering WTF they were thinking in the first place.

1 0

generating object file for ARM
by Fabien R 07 Feb '16

07 Feb '16

Hello, I would like to link my Haskell module with existing object files for armv7-m. I use ghc 7.4.1 on debian/amd64. This command seems incorrect or incomplete: ghc -pgmcarm-none-eabi-gcc -pgmParm-none-eabi-cpp -pgmaarm-none-eabi-as -pgmlarm-none-eabi-ld -keep-tmp-files HaskellModule.hs A lot of errors appeared: [1 of 1] Compiling HaskellModule ( HaskellModule.hs, HaskellModule.o ) /tmp/ghc13654_0/ghc13654_0.s: Assembler messages: /tmp/ghc13654_0/ghc13654_0.s:5:0: Error: unrecognized symbol type "" /tmp/ghc13654_0/ghc13654_0.s:17:0: Error: unrecognized symbol type "" /tmp/ghc13654_0/ghc13654_0.s:29:0: Error: bad instruction `leaq -40(%rbp),%rax' /tmp/ghc13654_0/ghc13654_0.s:30:0: Error: bad instruction `cmpq %r15,%rax' Any hints ? -- Fabien ______________________________

2 2

ANN: servant-swagger and swagger2
by Nickolay Kudasov 06 Feb '16

06 Feb '16

Dear Cafe, I am pleased to announce servant-swagger [1] and swagger2 [2] packages! Swagger [3] is a project used to describe and document RESTful APIs. Here's a servant blog post, introducing both packages: https://haskell-servant.github.io/posts/2016-02-06-servant-swagger.html servant-swagger allows you to generate a Swagger specification from your Servant API. swagger2 is a standalone package for Swagger 2.0. This package introduces lenses and generic-based derivation to minimize the effort of constructing a Swagger specification for your API. Both packages are supposed to be easy to use and have great documentation! So if you have any troubles using/understanding them — feel free to report an issue or contact me directly! Kind regards, Nick [1] http://hackage.haskell.org/package/servant-swagger [2] http://hackage.haskell.org/package/swagger2 [3] http://swagger.io

1 0

How to handle recoverable errors in multi-step computation?
by Lian Hung Hon 06 Feb '16

06 Feb '16

Dear haskellers, I have a multi-step computation. The steps are predefined, but users can choose which steps to execute (something like a recipe). Here is an example recipe: Step 1 - Get data from network (multiple HTTP calls) and put into a list Step 2 - Process the data (e.g. average, sum, median, etc.) Step 3 - Persist result to database Sometimes, Step 1 can fail for some of the HTTP calls. When this happens, Step 2 should continue as much as possible using whatever data that has been retrieved, but somehow indicate that an error has occurred and the result is partial. Q1: What is the idiomatic way of achieving this? Using throwError in Control.Monad.Except aborts the computation, which isn't what I want. Q2: (General software design) Furthermore, where should the error be logged? Logging it in both Step 1 and 2 preserves modularity for each of the steps, unfortunately it would result in duplicate error messages. What is the best practice for this? Regards, Hon

4 3

Combining Pipes with Callbacks
by Alex 06 Feb '16

06 Feb '16

Is it possible to shoehorn a function which uses send/receive callbacks in to the definition of a Pipe?: http://lpaste.net/3654837866896293888#line23 If so, how would I define `cb' here? -- Alex

1 0

Can we improve Show instance for non-ascii charcters?
by Takayuki Muranushi 05 Feb '16

05 Feb '16

Show instance for non-ascii characters prints their character codes. This is sad for Haskell users that speaks language other than English. > 'A' 'A' > 'Ä' '\196' > '漢' '\28450' > print $ [(++"'s dad"), (++"'s mom")] <*> ["Simon", "John"] ["Simon's dad","John's dad","Simon's mom","John's mom"] > print $ [(++"の父"), (++"の母")] <*> ["田中", "山田"] ["\30000\20013\12398\29238","\23665\30000\12398\29238","\30000\20013\12398\27597","\23665\30000\12398\27597"] The function that needs improvement is showLitChar in GHC.Show, which currently prints any character larger than ASCII code 127 by its character code: http://haddock.stackage.org/lts-5.1/base-4.8.2.0/src/GHC-Show.html showLitChar :: Char -> ShowS showLitChar c s | c > '\DEL' = showChar '\\' (protectEsc isDec (shows (ord c)) s) On the other hand, there is GHC.Unicode.isPrint, the predicate for printable Unicode characters, that is calling on a foreign function u_iswprint for the knowledge. https://hackage.haskell.org/package/base-4.8.2.0/docs/src/GHC.Unicode.html#… I think one of the solution is to import and call u_iswprint from GHC.Show, too, but I don't know it's against any design choices. Yesterday, I had a chance to teach Haskell (in Japanese,) and I had to use English in some of the most exciting examples, like the Applicative List example above. I would heartedly like to see GHC improve in these directions, so that we can make more happy learning materials on Haskell. Let me ask your opinions on what is the best way to do this (or is better not to do this), before I submit something to GHC Trac. Best, -------------------------------- -- Takayuki MURANUSHI -- RIKEN Advanced Institute for Computational Science -- http://nushio3.github.io/ -- http://www.geocities.jp/takascience/ --------------------------------

17 24

New type of ($) operator in GHC 8.0 is problematic
by Theodore Lief Gannon 05 Feb '16

05 Feb '16

(Sorry you got this twice, Kyle!) I agree wholeheartedly with this: > Its extremely important to not lose touch with the people that make the community; the newcomers. Sacrificing the 99% of beginner and intermediate haskellers for the 1%, I believe is a step in the wrong direction. But also with this: > There's a real drawback to flags like -fdefault-levity: they hide things from unsuspecting users. We already get a steady trickle of bug reports stemming from confusion around hidden kinds. Users diligently try to make a minimal test case and then someone has to point out that the user is wrong. It's a waste of time and, I'm sure, is frustrating for users. I'm worried about this problem getting worse. I've been learning Haskell for about a year and a half, and using it in production for roughly a third of that. More than once I've run into a language construct which struck me as odd, asked about it, and was told it was that way for pedagogical reasons. I consider this a poor state of affairs on all sides, including pedagogy! I had a correct intuition that something was amiss, but here's the language itself sewing unjustified doubt about my understanding. It was discouraging. Lowering the garden wall is good, but not at the expense of hiding a hedge maze just inside the gate. The advantage of an alternate prelude is that the hedge maze is no longer hidden, and maps are handed out on entry; the disadvantage is that from the outside it just looks like a second, higher wall. This is a very hard problem and I have no idea how to solve it in the long term. For now though, why not cause -fdefault-levity to produce prominent warnings that it's simplifying types? Possibly even annotate simplified output, e.g.: ($) ::# (a -> b) -> a -> b On Fri, Feb 5, 2016 at 11:46 AM, Kyle Hanson <me(a)khanson.io> wrote: > Richard, > > I appreciate your response and have some genuine questions about how you > see the Language growing in the future. As much as I am a principled > developer in terms of adhering closely to the truth as possible, I also > view code as a product that needs to "customers" to be successful. In order > for that to happen, it needs to easily accessible and easy to understand. > > I learned Haskell almost entirely by looking at existing projects and > exploring the very awesome Hackage documentation. What would be the hackage > definition for ($)? Would it be `($) :: forall (r :: RuntimeRep) (a :: *) > (b :: TYPE r). (a -> b) -> a -> b` with an asterisk that says "*For > beginners: ($) :: (a -> b) -> a -> b" > > Would there be a "Simple Hackage"? > > It would be interesting for me to see how the skill levels of Haskell are > distributed. In most languages it would look like a pyramid with a small > group advanced developers on top and a mountain of people underneath. > Haskell seems to be pushing towards the inverse, in which to code and > understand standard, non beginners mode haskell you have to be "advanced". > The barrier to entry looks to be increasing. > > I agree with Christopher Allen and also do not agree with your assessment > and comparison to the unnecessary syntax in Java. You can explain that > program using simple english. That is why it was used for so many years as > an introductory language. > How do you explain `forall (r :: RuntimeRep) (a :: *) (b :: TYPE r).` > using simple english? > > I think its important to identify who you want your "customers" to be. If > you only want the most advanced type theorists to use the language, that is > perfectly fine, but what you lose are thousands of developers that can > benefit the Haskell community without having to know advanced Typing. > > Needing a "Beginners" mode in a language is *not* a feature, its a > fundamental design flaw. It shows that the language was not sufficiently > thought out and designed for everyone. > > Its extremely important to not lose touch with the people that make the > community; the newcomers. Sacrificing the 99% of beginner and intermediate > haskellers for the 1%, I believe is a step in the wrong direction. > > -- > Kyle > > On Fri, Feb 5, 2016 at 10:13 AM, Richard Eisenberg <eir(a)cis.upenn.edu> > wrote: > >> Perhaps it will aid the discussion to see that the type of ($) will, for >> better or worse, be changing again before 8.0. >> >> The problem is described in GHC ticket #11471. The details of "why" >> aren't all that important for this discussion, but the resolution might be. >> The new (hopefully final!) type of ($) will be: >> >> > ($) :: forall (r :: RuntimeRep) (a :: *) (b :: TYPE r). (a -> b) -> a >> -> b >> >> Once again, it's easy enough to tweak the pretty-printer to hide the >> complexity. But perhaps it's not necessary. The difference as far as this >> conversation is concerned is that Levity has been renamed to RuntimeRep. I >> think this is an improvement, because now it's not terribly hard to explain: >> >> --- >> 1. Types of kind * have values represented by pointers. This is the vast >> majority of data in Haskell, because almost everything in Haskell is boxed. >> 2. But sometimes, we don't care how a value is represented. In this case, >> we can be polymorphic in the choice of representation, just like `length` >> is polymorphic in the choice of list element type. >> 3. ($) works with functions whose result can have any representation, as >> succinctly stated in the type. Note that the argument to the function must >> be boxed, however, because the implementation of ($) must store and pass >> the argument. It doesn't care at all about the result, though, allowing for >> representation-polymorphism. >> >> In aid of this explanation, we can relate this all to Java. The reference >> types in Java (e.g., Object, int[], Boolean) are all like types of kind *. >> The primitive types in Java (int, boolean, char) do not have kind *. Java >> allows type abstraction (that is, generics) only over the types of kind *. >> Haskell is more general, allowing abstraction over primitive types via >> representation polymorphism. >> --- >> >> Could this all be explained to a novice programmer? That would be a >> struggle. But it could indeed be explained to an intermediate programmer in >> another language just learning Haskell. >> >> For point of comparison, Java is widely used as a teaching language. And >> yet one of the simplest programs is >> >> public class HelloWorld >> { >> public static void main(String[] args) >> { >> System.out.println("Hello, world!"); >> } >> } >> >> When I taught Java (I taught high-school full time for 8 years), I would >> start with something similar to this and have to tell everyone to ignore >> 90% of what was written. My course never even got to arrays and `static`! >> That was painful, but everyone survived. This is just to point out that >> Haskell isn't the only language with this problem. Not to say we shouldn't >> try to improve! >> >> We're in a bit of a bind in all this. We really need the fancy type for >> ($) so that it can be used in all situations where it is used currently. >> The old type for ($) was just a plain old lie. Now, at least, we're not >> lying. So, do we 1) lie, 2) allow the language to grow, or 3) avoid certain >> growth because it affects how easy the language is to learn? I don't really >> think anyone is advocating for (3) exactly, but it's hard to have (2) and >> not make things more complicated -- unless we have a beginners' mode or >> other features in, say, GHCi that aid learning. As I've said, I'm in full >> favor of adding these features. >> >> Richard >> >> On Feb 5, 2016, at 12:55 PM, Kyle Hanson <me(a)khanson.io> wrote: >> >> I am also happy the discussion was posted here. Although I don't teach >> Haskell professionally, one of the things I loved to do was show people how >> simple Haskell really was by inspecting types and slowly putting the puzzle >> pieces together. >> >> Summary of the problem for others: >> >> From *Takenobu Tani* >> >> Before ghc7.8: >> >> Prelude> :t foldr >> foldr :: (a -> b -> b) -> b -> [a] -> b >> >> Prelude> :t ($) >> ($) :: (a -> b) -> a -> b >> >> Beginners should only understand about following: >> >> * type variable (polymorphism) >> >> >> After ghc8.0: >> >> Prelude> :t foldr >> foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b >> >> Prelude> :t ($) >> ($) >> :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). >> (a -> b) -> a -> b >> >> >> >> With this change it looks like I will no longer be able to keep `$` in my >> toolbox since telling a beginner its "magic" goes against what I believe >> Haskell is good at, being well defined and easy to understand (Not well >> defined in terms of Types but well defined in terms of ability to precisely >> and concisely explain and define whats going on). >> >> It looks like where the discussion is going is to have these types show >> by default but eventually have an Alternative prelude for beginners. >> >> From *Richard Eisenberg:* >> >> - It's interesting that the solution to the two problems Takenobu pulls out below (but others have hinted at in this thread) is by having an alternate Prelude for beginners. I believe that having an alternate beginners' Prelude is becoming essential. I know I'm not the first one to suggest this, but a great many issues that teachers of Haskell have raised with me and posts on this and other lists would be solved by an alternate Prelude for beginners. >> >> I don't like the idea of fragmenting Haskell into "beginners" and >> "advanced" versions. Its hard enough to get people to believe Haskell is >> easy. If they see that they aren't using the "real" prelude, Haskell will >> still be this magic black box that is too abstract and difficult to >> understand. If they have to use a "dumbed down" version of Haskell to >> learn, its not as compelling. >> >> There is something powerful about using the same idiomatic tools as the >> "big boys" and have the tools still be able to be easy to understand.... by >> default. Adding complexity to the default Haskell runs the risk of further >> alienating newcomers to the language who have a misconception that its too >> hard. >> >> Admittedly, I am not well informed of the state of GHC 8.0 development >> and haven't had time to fully look into the situation. I am very interested >> to see where this conversation and the default complexity of Haskell goes. >> >> -- >> Kyle >> >> >> On Fri, Feb 5, 2016 at 8:26 AM, Tom Ellis < >> tom-lists-haskell-cafe-2013(a)jaguarpaw.co.uk> wrote: >> >>> On Fri, Feb 05, 2016 at 05:25:15PM +0100, Johannes Waldmann wrote: >>> > > What's changed? >>> > >>> > I was referring to a discussion on ghc-devs, see >>> > https://mail.haskell.org/pipermail/ghc-devs/2016-February/011268.html >>> > and mixed up addresses when replying. >>> >>> I'm glad you did, because this is the first I've heard of it! >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >

3 3

Month in haskell-ide-engine January 2016
by Alan & Kim Zimmerman 05 Feb '16

05 Feb '16

Welcome Haskell IDE Engine users, Haskell IDE Engine progress report for January 2016 [1] What is Haskell IDE Engine? Not an IDE. It is a common point for people in the Haskell community to pool their efforts with respect to tooling. For tool writers, provide tools as a HIE plugin, so it can be available on supported IDEs For IDE developers, integrate to HIE, and all the Haskell tools supported as plugins become available For users, it means the overall Haskell experience should improve. Important developments A new ghc-dump-tree plugin based on https://github.com/edsko/ghc-dump-tree Current project focus The current focus is to get the initial version working well enough for an alpha release. To this end, there are some hardy developers using it in their daily work in emacs. Issues closed in January Querying a graph database instead of using GHC-API? #10 Decide how haskell-ide project is run #13 Rework the Console #20 Use an error handler in the dispatcher #50 Protocol definition #66 (emacs) "Selecting deleted buffer" after hie buffer killed #121 emacs : process HieDiff result #132 Create a doc entry describing how to run hie with leksah #142 Create --one-shot flag to run one cmd and exit #154 Update to ghc-mod 5.5 #156 Fix warnings #159 HIE and current working directory #161 Improve error message for badly-formatted json #166 ghc-mod not properly detecting project #175 thread blocked indefinitely in an STM transaction -- Running tests #178 Create Report-2015-12.md #151 [POC] Move plugin and command names to the typelevel #152 Pull requests merged in January Just some textual improvements #153 Starting to bring in async streaming command #155 One shot invocation #158 leksah instructions #160 Bump deps and adapt to new apis #162 Improve error messages in JSON parsing #167 Add ide-backend plugin #168 Refactor ExtensibleState #169 Ghc-dump-tree plugin #170 Fix warnings #171 Emacs: log parse error even if there is no handler #172 Add an error handler in the dispatcher (fixes #50) #173 Recreate buffers if they have been killed #174 ghc-mod 5.5 #176 Remove ide-backend #179 Move emacs tests to buttercup #180 Increase timeout for cash upload #181 Update stack.yaml for ghc-mod-5.5 and HaRe-0.8.2.3 #182 Support multiple sessions in emacs #183 Fix warnings #165 Harmonise nightly versions, install ide-backend-server #177 Contributors active in January Alan Zimmerman, Alexey Shmalko, Cies Breijs, Griffin Smith, JP Moresmau, Justin Wood, Moritz Kiefer Contributing Haskell IDE Engine needs volunteers like any other open source project. For more information see: https://github.com/haskell/haskell-ide-engine Also drop by our IRC channel: #haskell-ide-engine at irc.freenode.net. Thanks! Alan [1] https://github.com/haskell/haskell-ide-engine/blob/master/docs/Report-2016-…

1 0