- Haskell-Cafe - Haskell.org

Best deployment method for Hakyll websites (with Stack)?
by Nicola Gigante 11 Sep '15

11 Sep '15

Hello, Note, this is not a Hakyll question, after all. I’m trying to host a hakyll website on a CentOS 7 server. I want to replicate the setup I had with the previous site, made with Jekyll: at each push on the git repository (hosted on the same server), the branch is recompiled and deployed to the web server. I already have the git hooks in place etc… The problem is how to manage the installation of ghc, hakyll, and their dependencies. I really really wish to have a clean solution. I really like stack, but its “per-user” directories make me wonder. The site compilation has to be performed by the git user account, which does not have an home directory. Can I setup a stack installation of a set of packages and then point stack to use that and only that? Also, how about the integration with docker? Is it really so painless as it is advertised? If I’ve understood correctly, I could install the docker image with stackage packages already installed, and tell stack to use that image with docker, having the site compilation sandboxed. Is it feasible? Thank you for any advice, Nicola

5 4

Senior Haskell developer roles at Standard Chartered, Singapore
by Don Stewart 10 Sep '15

10 Sep '15

The Strats team at SCB has two more open roles for Haskell developers in Singapore. These are exciting "director level" development roles in a large team. Location is Singapore. Details here: https://donsbot.wordpress.com/2015/09/10/senior-haskell-developer-roles-at-… Please contact me for more details.

1 0

lazily updating dependencies, git submodules and cabal
by Dimitri DeFigueiredo 10 Sep '15

10 Sep '15

Hello all, I am facing a problem that I assume others have seen before, but am stumped for a solution. It's not about Haskell per se, but about how to organize my haskell code to play nicely with the build tools. #The Setup I am currently developing a bitcoin trading agent. I produce 2 executables: the "Trader" and the "Tax" calculator. These 2 executables share a common dependency to talk to a SQLite3 database in their "Persistence" layer. (I actually have 3 levels of dependency, but we'll get to that later) I spend most of my time working on the Trader and the Persistence layer. These are just different source code files: Trader.hs and Persistence.hs. The problem is that as I update the Persistence.hs file I break Tax.hs. Because I am "lazy" and only really have to calculate taxes once I year. I do *not* want to have to continuously modify the Tax.hs file to keep up with the development in the Persistence layer. I just want it to use an old version, so that I only have to bring it up to speed later. In other words, I want to: 1. always be able to compile both executables, 2. delay updating an executable because of changes in a common dependency as much as possible. I want to be lazy and delay updating my Tax.hs code to work with latest version of the Persistence layer a much as possible. At the same time, the Trader and Persistence layer are worked on simultaneously. #My Current Solution The immediate solution that comes to mind is to put these files in 3 different packages. That way, I can use version 1.5 of the Persistence layer for the Tax calculator, but still develop version 2.0 at the same time as working on the Trader. I can use 'cabal sandbox add-source' to immediately get changes made to the Persistence layer as I develop the Trader. There is one minor problem with this approach: I have to manually track the version numbers. I need to put the proper version number in the "build-depends" section in the .cabal file. For example, for Tax.cabal I would have: "build-depends: persistence == 1.5". There is a different approach that is completely orthogonal to using Cabal packages. I can put each of the 3 files (Trader.hs, Tax.hs and Persistence.hs) in 3 different repositories and use git submodules. The Persistence layer would be a submodule of both the Trader and the Tax repos. As each submodule just points to a specific commit in the Persistence repo, I don't have to manually track version numbers and the Trader and Tax calculator can point to different commits and use different versions of the Persistence layer. The git solution is really convenient because when you clone a repo (with --recursive), it comes with the correct versions of the dependencies you need. This is what I did. #The Problem The problem I am facing is that I now have 3 (or more) levels and multiple dependencies. There are 2 changes to the original setup: 1. Persistence.hs now imports MarketModel.hs and that also changes pretty quickly as I develop the Trader. 2. The Trader now also depends on ProfitCalculator.hs that also imports MarketModel.hs Using the 'cabal sandbox add-source' solution now requires that I "add-source" the MarketModel package too. Otherwise, any change I make to this package will not be tracked. In fact, I have to "add-source" two different versions of MarketModel (in general, there's an exponential blow up as the number of levels increases). The manual tracking of version numbers in the cabal file also becomes critical. If I forget to update a version number, the package will be reinstalled over an existing one that's being used. This quickly becomes a mess. The git submodule solutions doesn't work either. Although GHC does the right thing and only complains about two modules with the same name if I use a symbol that is ambiguous. Cabal sets the paths for "import"ed modules in the "hs-source-dirs:" and that is global to the whole package. I can't say: 1. first, compile the Persistence.hs file by "import"ing files in the path /trader/persistence/marketmodel, 2. now, compile the ProfitCalculator.hs by "import"ing files in the path /trader/profitcalculator/marketmodel. That path is the same for the whole project and I can't use different versions of MarketModel.hs In short, it seems no solution works anymore. Is there a way to make this work? Is there another way for me to be lazy about updating my dependencies when building multiple targets? Any pointers on this would be much appreciated! Thanks, Dimitri

1 0

emacs haskell-mode with cabal exec, test suite sections
by Stuart Popejoy 10 Sep '15

10 Sep '15

I'm having trouble coding test-suite and executable sections with the emacs REPL and flycheck. 1. cabal-repl can compile against the library code, but fails to see any modules within the non-library section. 2. flycheck has the opposite problem: it fails on library module imports but recognizes imports local to the section. Note I don't always have these issues, but they seem to crop up whenever I upgrade GHC, or emacs, or haskell-mode, flycheck-haskell etc. I'm not sure #1 ever works, but #2 is happening to me on my mac, but not at work on Linux. For #1, in the past I've tried a big .dir-locals.el to use `ghci` for the repl and just import everything -- of course losing the nice cabal integration, plus it being slow as molasses to load source files. I also briefly investigated modifying haskell-mode to support separate sessions for a given section. For #2, flycheck is just a pain to debug, my only recourse is to stick debug output into `flycheck-start-command-checker` to see what commands are going out, and try to troubleshoot. Any thoughts or suggestions? Commiseration is OK too :) Thanks, Stuart

3 5

Helsinki Haskell User Group metope, 2015-09-24 @ 18:00 Gofore
by Oleg Grenrus 09 Sep '15

09 Sep '15

Dear all, especially people not on the meetup.com. After a summer break we'll resume Helsinki Haskell User Group meetups. The first one will be on Thursday, September 24th at 18:00 at Gofore office. We'll have three talks: about hpack & stack, purescript and history of functional programming. If you are in the neighbourhood, join us. For details see: http://www.meetup.com/Helsinki-Haskell-Users-Group/ Everybody is welcome! Oleg Grenrus

2 1

ANN: Creation of Haskell-Community list for Haskell.org Community Infrastructure Discussions
by Gershom B 09 Sep '15

09 Sep '15

Dear all, The haskell.org committee [1] had a productive week during ICFP, and at some point we'll try to write up some of the small things underway and future plans -- many things are quite tentative at the moment. However, one thing that became clear to us (well, thanks to the useful prodding of SPJ) is that we have historically participated in discussions in other venues (-cafe, reddit, etc) and then had our own internal discussions (few, seldom, and largely organizational to be honest) on the low-traffic committee [at] haskell.org mail alias. But this leaves open people wondering what those discussions are. And it also leaves open where the *designated place* to discuss haskell.org community infrastructure is. The haskell-infrastructure [2] list is very quiet and really about technical considerations. Meanwhile, -cafe, reddit and soforth are about anything and everything. So we created another list, which will be a place where we seek to have our discussions related to plans for haskell.org committee work, and where we invite everyone to join us. This new list is the haskell-community list: https://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community The committee alias will still work, and is still the way to just write directly to the members of the committee -- no list to join. But if you wish to have a discussion about how we have things set up on haskell community infrastructure, services provided, and that we might wish to add, and how you can help (or even just what your thoughts are on how things might be done), now there is a good place for that. Hope to continue conversations with many of you there, Gershom (for the haskell.org committee) [1] https://wiki.haskell.org/Haskell.org_committee [2] http://community.galois.com/mailman/listinfo/haskell-infrastructure

2 2

Stuck in proof of trivial compiler
by Rustom Mody 09 Sep '15

09 Sep '15

Trying to prove a trivial compiler with respect to a corresponding interpreter --------------- Code ------------------ +-* Expression tree data Exp = Lf Int | Add Exp Exp | Mul Exp Exp eval (Lf x) = x eval (Add el er) = eval el + eval er eval (Mul el er) = eval el * eval er Simple stack machine instructions (LC is load constant) data Instr = LC Int | AddI | MulI compile (Lf x) = [LC x] compile (Add el er) = compile el ++ compile er ++ [AddI] compile (Mul el er) = compile el ++ compile er ++ [MulI] mac [] stk = stk mac (LC x : is) stk = mac is (x:stk) mac (AddI : is) (r : l : stk) = mac is (l+r : stk) mac (MulI : is) (r : l : stk) = mac is (l*r : stk) ------------ Proof Attempt ----------------------- Theorem mac(compile e).s = eval.e : s Base case mac(compile (Lf x)) s = eval (Lf x) : s LHS = mac (compile (Lf x)) s mac [LC x] s mac [] (x: s) x: s RHS = eval (Lf x) : s x: s Induction Step: Assumption l: mac (comp el).s = eval el : s Assumption r: mac (comp er).s = eval er : s LHS = mac (Add el er) s = mac (comp el ++ comp er ++ [AddI]) RHS = eval (Add el er) : s = (eval el + eval er) : s Now What???

2 2

Re: [Haskell-cafe] Thoughts about redesigning "Num" type class
by Oleg 09 Sep '15

09 Sep '15

Alexey Muranov wrote: > My, maybe naive, impression is that there should always be one class per > operation, as this is obviously the most flexible approach. Then maybe some > classes can be grouped together by introducing other classes. Truly what goes around comes around. The ``less ad hoc'' overloading which we now associate with type classes was first proposed (and even implemented!) by Stefan Kaes, a couple of years before the type classes. Kaes so-called parametric overloading may be regarded as an implementation of type classes with only one method. http://okmij.org/ftp/Computation/typeclass.html#Kaes Incidentally, Kaes' system included not only `local instances' but also `local classes'. Likewise, 'Haskell with only one type class', http://okmij.org/ftp/Haskell/TypeClass.html#Haskell1 deals first with one-method classes. Type classes like Num are then regarded as convenient collections, as bundles of previously defined methods. Naturally, the same method, like (+), can be a part of several bundles, not necessarily related otherwise. Incidentally, The `Haskell with only one type class' required NO extensions, even back in 2007, when it was first proposed.

1 0

I wrote a type checker: ARF. Is it novel?
by David Foster 09 Sep '15

09 Sep '15

I've written a small untyped language calculus (ARF) and an interprocedural flow-based type checker to explore techniques for efficiently inferring all types in the presence of recursive function calls, with no prior type declarations or annotations required in the original program. The type checking algorithm I've come up with appears not only to work but also to have good performance: O(m^2) time in the worst case and O(m) time in the average case, where m is the number of functions in the program. So the question I'd like to pose to any type system buffs on this list is: (1) Is such an interprocedural flow-based type checking algorithm with that kind of performance likely to be novel? And if you have some interest and time to actually review the strategy and/or implementation of the algorithm at <https://github.com/davidfstr/arf#assign-recurse-flow-arf>, I'd love to know: (2) Are there similar type checking algorithms that already exist in the academic literature? I'm posting these questions here because I'm guessing that a number of folk that work with type systems and type checkers are likely to be subscribed to this list. If there are other more-appropriate venues, I'd love to hear about about them as well. -- David Foster

3 3

GHC Extension Proposal: ArgumentBlock
by Andrew Gibiansky 09 Sep '15

09 Sep '15

I'd like to propose a GHC extension called (for now) `ArgumentBody`. `ArgumentBody` is a simple syntax extension, than, when enabled, permits the following code: main = when True do putStrLn "Hello!" main = forM values \value -> print value main = forM values \case Just x -> print x Nothing -> print y In this code we do not need `$` before `do`, lambda, or lambda-case (if -XLambdaCase is enabled). This change would *not* extend to `let`, `if`, `case`, or any other constructs. Pros: 1. Code is simpler and it greatly reduces the need for "operator line noise" of $ everywhere. 2. We can avoid using the type-checker hack for $ <http://stackoverflow.com/questions/9468963/runst-and-function-composition> for things such as runSt. Cons: 1. Adds complexity to the compiler. (NB: The change is minimal and not invasive at all.) 2. Contributes to a proliferation of extensions that other tools must support. (NB: This is just a parser change so should be easy for all tools to support.) I'm very interested in hearing both favoring and dissenting opinions on this proposed change. If this change is approved of, names besides -XArgumentBody can be considered. See more info on Trac <https://ghc.haskell.org/trac/ghc/ticket/10843#ticket> . -- Andrew Gibiansky

40 73