September 2016 - Haskell-Cafe

Type of divMod
by Todd Wilson 28 Sep '16

28 Sep '16

Why is the type of divMod not (Integral a, Integral b) => a -> b -> (a,b)? It would seem to make sense that if b is a size-limited Integral type (like Int), then since the remainder of a division is always smaller than the divisor, it could be given the same size-limited type. I found myself wanting such instances of divMod when writing a function to convert an Integer to a list of digits in some base that is an Int: toBase :: Integer -> Int -> [Int] I can work around not having the appropriate instance of divMod by using fromIntegral to convert from an Integer to an Int, but this seems wrong. Todd Wilson A smile is not an individual Computer Science Department product; it is a co-product. California State University, Fresno -- Thich Nhat Hanh

2 1

Re: [Haskell-cafe] Unable to register on hackage
by Erik Hesselink 28 Sep '16

28 Sep '16

For future reference, the right address here is admin(a)hackage.haskell.org, which I admit seems to be hard to find on hackage (although it's there on the homepage and Guru found it eventually). I'm looking into this. Erik > On 28 September 2016 at 14:18, Gurudev Devanla <gurudev.devanla(a)gmail.com> > wrote: > >> Hello, >> >> This may be the wrong mailing list for this question, but I appreciate >> any pointers on whom to contact. I have been unable to register as a new >> user on https://hackage.haskell.org to upload a package. I have tried >> number of times, but have not received the activation email. >> >> I have also not found any "Contact" links on that page. Therefore, any >> pointers would be of great help. >> >> Regards >> Guru >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > >

1 0

seq and lambda with patterns
by Denis Moskvin 28 Sep '16

28 Sep '16

There is some subtle, but reasonable difference between \pat1 pat2 -> expr and \pat1 -> \pat2 -> expr: > seq ((\True y -> "DEFINED") undefined) 42 42 > seq ((\True -> \y -> "DEFINED") undefined) 42 *** Exception: Prelude.undefined The reason is the translation from Haskell Report 2010 (3.3) \ p1 . . . pn -> e = \ x1 . . . xn -> case (x1 , . . . , xn ) of (p1 , . . . , pn ) -> e Today I found (GHC 8.0.1) that > seq ((\True -> \y -> undefined) undefined) 42 42 Is the last result correct? -- Denis Moskvin

2 1

Unable to register on hackage
by Gurudev Devanla 28 Sep '16

28 Sep '16

Hello, This may be the wrong mailing list for this question, but I appreciate any pointers on whom to contact. I have been unable to register as a new user on https://hackage.haskell.org to upload a package. I have tried number of times, but have not received the activation email. I have also not found any "Contact" links on that page. Therefore, any pointers would be of great help. Regards Guru

1 0

Re: [Haskell-cafe] [Haskell] GHC is a monopoly compiler
by Tom Murphy 28 Sep '16

28 Sep '16

This is not the right mailing list for this ( https://wiki.haskell.org/Mailing_lists) ; forwarding to haskell-cafe@ Tom On Tue, Sep 27, 2016 at 7:48 AM, Tony Day <tonyday567(a)gmail.com> wrote: > I would argue that the adventure that is GHC is a natural monopoly - an > example of collaboration trumping competition. Certainly the results speak > for themselves, and I personally find it the most satisfying, the only sane > way to practice the craft of coding. So, as an enthusiastic user of a > monopolistic service (the best power to weight ratio I could find to > misquote Kmett), I would like to suggest to the community that we have a > respectful discussion on the implications of natural monopolies. > > Monopolies have their problems. They create power imbalances that need > active management to control. A community should be particularly wary of > monopolies attempting to vertically integrate up the production chain into > areas where a monopoly makes less sense. I would call the whole cabal > versus stack drama a text-book case of over-reach. Everyone agrees stack > operates at a higher level of abstraction then cabal, on top of it is > accurate. Cabal shouldn't even be allowed to compete above it's current > abstraction point. > > Haddock is another example of being blessed by ghc. It hits a corner-case > of perfection for the "I'm a hackage library" monopoly. But the outside > world of documentation, editing, rendering and conversion is invisible to > this monopolistic use case. We are forced to learn and use haddock, and, > for those of us with documentation needs outside hackage, the resultant > workflow is cruel and unusual. > > GHC is a great compiler, but should actively be discouraged from > monopolizing the associated tooling and documentation chains. There is > evidence of healthy open-source competition and significant gains to be > had, and Haskell runs the risk of missing out. > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > >

14 24

technical thoughts on stack
by Richard Eisenberg 27 Sep '16

27 Sep '16

I’ve watched the recent back-and-forth about stack with quite a bit of interest (as many of us have). The discussion inspired me to take another look at stack. Here are the results of that foray. First, a disclosure: While I have appreciated the emergence of a new build tool for Haskell, I have never much liked stack. One of my chief goals in taking another look is to understand better why I do not like it. My task: Set up a Haskell environment on a new machine (a Mac). This machine has no Haskell infrastructure on it. My approach: 1. `brew install haskell-stack`. Success. At this point, I do not have a Haskell project I wish to build. Instead, I really just want the ability to run Haskell expressions in GHCi. So I skip `stack new` and go straight to 2. `stack setup`. This succeeds, but prints out some interesting messages along the way, including > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of 71c0a55d0a877954d9590e285c0eb861ace2d8cc > Right Nothing At the end, I am helpfully told > To use this GHC and packages outside of a project, consider using: > stack ghc, stack ghci, stack runghc, or stack exec > So I then 3. `stack ghci`. My computer’s first reaction is to say > Run from outside a project, using implicit global project config > Using resolver: lts-6.17 from implicit global project's config file: /home/rae/.stack/global-project/stack.yaml > Error parsing targets: The specified targets matched no packages. > Perhaps you need to run 'stack init'? > Warning: build failed, but optimistically launching GHCi anyway > which doesn’t make me feel all that comfortable, but then I am indeed delivered to the GHCi prompt, which works as expected. Done with GHCi, I quit. I then want to double-check which version of GHC I got, so I 4. `stack ghc --version`. This command reports > Invalid option `--version’ Grumble. It seems I can’t interact with GHC directly. ———— At this point, I am reminded why I dislike stack: **It’s optimized for a different workflow than I use.** And I think this fact (repeated by others’ experiences) is why a segment of our community has not celebrated stack as much as other segments have. We all have different workflows. From what I understand about it, stack is great for a project-based workflow. In this workflow, you are working on a Haskell project. You are happy to specify settings in .cabal and stack.yaml files. And you really want your build to work in the future and on other machines. In my experience, stack is not great with a compiler-based workflow. In this workflow, you aren’t quite as organized perhaps and do not have all your settings written. You also want the ability just to compile a file without changing any configurations. You want to be able to start GHCi with a nice set of libraries with which to experiment. I definitely like a compiler-based workflow. I’m sure that many of you prefer a project-based workflow. The great news here is that we have a choice: use stack for a project-based workflow, and don’t use it when you want a compiler-based workflow. No one needs to convince others about personal preferences. But there is one nagging issue: what do we suggest to newcomers? The downloads page right now is not serving us well. (I was legitimately scratching my head at first trying to figure out how to provision a new computer.) Sadly, I don’t see a good option presenting itself. Both potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) serious shortcomings. A. The Haskell Toolchain (that is, what’s currently called the Haskell Platform Minimal) does appear to lack a “here’s what you do first” tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to discover — you have to choose the oft-maligned Haskell Platform link before you are told that there is a minimal variant. B. stack sets up GHC in a way that either 1) requires a project-based workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary warnings every time GHC is invoked outside of a project. Furthermore, stack prohibits direct interaction with GHC (as in `ghc --version`). There’s more good news here! Both of these problems are really easy to fix. To fix (A), someone just has to write the tutorial. To fix (B), stack just needs a new option so that `stack setup` installs a system GHC. Perhaps it would even be sufficient for `stack setup` to clearly tell the user where ghc is installed and what to add to their PATH. I also think, if readers agree with my conclusions about workflows, we should consider writing up criteria that potential users should consider when choosing what workflow to start with. We’ll need to have a tighter recommendation for those with no experience programming, but most developers should be able to recognize what workflow they prefer and choose accordingly. Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then we’ll really be in a quandary about which installation procedure to put first. Perhaps we should incentivize fixing (A) and (B) by saying whichever one happens first gets to be featured first on the page? :) So: Does my characterization of workflows resonate? Have I perhaps identified part of the burning black heart of the reason behind the vitriol of late? Should we fix (A) and (B)? I’m looking forward to hearing your thoughts. Richard -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae

23 49

Re: [Haskell-cafe] The meaning of categories constructed from HASK
by Olaf Klinke 26 Sep '16

26 Sep '16

Dear Dimitri, I've never seen arrow or slice categories in a paper on functional programming. Commutative squares are most frequently used in the definition of typeclasses, where the documentation usually reads: Instances should satisfy: f.g = h.i where f,g,h,i are some functions involved in the definition of the typeclass. Haskell can not stop you writing an instance violating the commutative square, however. Certain special arrow categories are useful, even in Haskell. For example the Eilenberg-Moore category of a monad m. Objects are arrows m a -> a and morphisms are commutative squares liftM f m a ---------> m b | | | | v v a ----------> b f Such an f is sometimes called "linear". For example, every instance of Data.Monoid comes with an arrow mconcat :: (Monoid a) => [a] -> a and commutative squares between two monoids are precisely the functions f where f mempty = mempty and f (x `mappend` y) = (f x) `mappend` (f y) I'm sure you have looked at Control.Category in package base before asking this question. The Category typeclass defined there is not capable of expressing either of your examples, because: - The hom-set of a Category must be a HASK type (although not necessarily a function type) - Each hom-set must be parametrised by two HASK types The arrow category is not expressible, because we can not forge a HASK type that somehow specifies exacltly one function. Moreover, the cummutativity of a square is not expressible, that is, there is no HASK type consisting of all functions making a certain square commute. The slice category is not expressible, for the same reason as above. There are, however, interesting instances of Control.Category where the hom-set elements are not functions. For example, one could have memoized functions between stream types. The following goes back to Dirk Pattinson and Ulrich Berger, AFAIK. Suppose i is a type of tokens such that an infinite stream of i's encodes an element of type x. Likewise, let o be a type of tokens such that an infinite stream of o's encodes an element of type y. Now consider the type Mem below. -- Run the following in ghci -XNoImplicitPrelude import Control.Category import Data.List (head,tail) -- A memoized function [i] -> [o], representing a function x -> y. -- Either requesting an input token or yielding an output token. data Mem i o = Read (i -> Mem i o) | Write o (Mem i o) instance Category Mem where id = Read (\i -> Write i id) f . g = case f of Write p f' -> Write p (f' . g) Read r -> case g of Write o g' -> (r o) . g' Read r' -> Read (\i -> f . (r' i)) -- run a memoized function. -- This is a functor from Mem to HASK. runMem :: Mem i o -> [i] -> [o] runMem f input = case f of Write o f' -> o : runMem f' input Read r -> runMem (r (head input)) (tail input) If there are only finitely many possible input tokens i, then one can replace Read (i -> Mem i o) by Read (Map i (Mem i o)) in which case the entire memoized function really is a tree. Olaf

2 1

Professor Position at University of Chile
by Éric Tanter 26 Sep '16

26 Sep '16

Full-Time Academic Position Computer Science Department, University of Chile http://www.dcc.uchile.cl <http://www.dcc.uchile.cl/> The Computer Science Department of the University of Chile (DCC) is offering a full-time permanent position to carry out research and teaching, at the undergraduate and graduate levels. The DCC is the leading Computer Science Department in Chile, and one of the most active in Latin America. It pioneered the use of Unix and the adoption of the Internet in Chile. Today, it has 22 full-time professors, 10 of which come from Argentina, Uruguay, Belgium, France, and Ireland. We carry out high-quality research, publishing frequently in the most prestigious international conferences and journals. The DCC is in charge of the undergraduate Computer Science program within the Engineering Faculty of the University of Chile, reaching a thousand students in the first year of Engineering, and taking care of the CS specialization from the third year onward for over two hundreds students. Our MSc and PhD programs attract the best students from Latin America, with currently around fifty students in each program. The DCC offers newcomers an individual office and necessary equipment, as well as a starting grant for initiating their research activities; further funding is then obtained permanently upon publications. This is usually complemented with funds from a personal research project obtained from Conicyt, the national research agency, and/or with funds from larger collaborative projects. An assistant professor can supervise students of any level and have a light administrative load. Professors in our department are expected to teach three courses per year; typically one of these courses is an elective that the professor can define according to his/her interests. The salary provided by the University is very competitive, and depends on the ranking (assistant, associate, full); it is complemented with research projects. The successful candidate should be an active researcher with a PhD in Computer Science (or about to obtain it before starting the position). We are interested in any area of Computer Science, and both junior and senior researchers are welcome to apply. The candidate will be evaluated on the basis of both research and teaching activities, impact, as well as vision for the future. Important Dates We accept applications until November 30, 2016. The expected starting date is March 1, 2017 (August 2017 at the latest). Location The DCC is located in Santiago de Chile. Santiago is the capital and largest city in Chile, with a lively cultural scene and delectable cuisine. It is located at the foothills of the Andes, with over 300 days of sun per year, and both ski slopes and the Pacific coast at a 1-hour drive. Santiago is well-connected through direct flights to major hubs in both Europe and the USA. Chile is a country with a lot to offer especially to nature lovers, with over 4,300 km of seashore and mountains, filled with stunning landscapes and national parks stretching from Patagonia to the Atacama desert. For enquiries, please contact Prof. Gonzalo Navarro at gnavarro(a)dcc.uchile.cl <mailto:gnavarro@dcc.uchile.cl>

2 1

The 13-line example in Text.Megaparsec.Expr
by Jeffrey Brown 24 Sep '16

24 Sep '16

At the bottom of the Hackage documentation for Text.Megaparsec.Expr [1] is a 13-line demonstration program. It includes no import statements. I added the ones I could deduce, which produced this: import Text.Megaparsec import Text.Megaparsec.Expr import Text.Megaparsec.Lexer (symbol,integer) parens = between (symbol "(") (symbol ")") expr = makeExprParser term table <?> "expression" term = parens expr <|> integer <?> "term" table = [ [ prefix "-" negate , prefix "+" id ] , [ postfix "++" (+1) ] , [ binary "*" (*) , binary "/" div ] , [ binary "+" (+) , binary "-" (-) ] ] binary name f = InfixL (reservedOp name >> return f) prefix name f = Prefix (reservedOp name >> return f) postfix name f = Postfix (reservedOp name >> return f) That still won't compile, because GHC does not know what reservedOp means. Does reservedOp refer to something that no longer exists, or have I just not found it? [1] https://hackage.haskell.org/package/megaparsec-4.4.0/docs/Text-Megaparsec-E… -- Jeffrey Benjamin Brown

4 8

Debugging hanging template Haskell
by Cody Goodman 23 Sep '16

23 Sep '16

Can you use the ghci debugger to do this? I tried adding a piece of template Haskell to the frames library and now compilation never terminates: https://github.com/acowley/Frames/pull/59 One compiler warning warned me of overlapping instances in relation to my ZonedTime lift instance which could totally be wrong. I have a feeling maybe the overlapping instances could be making compilation hang, but I'm not sure. I'm more looking for help on how to move forward and keep debugging this than an answer, but if you only have time for an answer I'll gladly do the reverse engineering work to teach myself. Thanks all!

2 1