- Haskell-Cafe - Haskell.org

ANN: hledger-1.13
by Simon Michael 02 Feb '19

02 Feb '19

I'm pleased to announce the release of hledger 1.13, the first hledger release of 2019! Thank you release contributors Jakob Schöttl and Dmitry Astapov. hledger is a robust, cross-platform plain text accounting tool, for tracking money, time, stocks, cryptocurrencies or any other commodity, using double-entry accounting, private or shared plain text files, revision control, and command-line, curses or web UIs. Find out more at http://hledger.org and http://plaintextaccounting.org. Release notes (condensed, see http://hledger.org/release-notes) ------------- project-wide changes for 1.13 - packaging: A docker image providing the main hledger tools is now linked on the download page. This is another way to get up-to-date hledger tools without building them yourself (and, a way to run hledger-ui on windows ?) (Dmitry Astapov, Simon Michael) - doc: fixed pandoc typography conversion in web manuals. Eg -- was being rendered as en-dash. (#954). hledger 1.13 - cli: reorganised commands list. Addons now have a + prefix. - cli: the command line help and manual section for all hledger’s commands are now consistent, and generated from the same source. - cli: comprehensive bash completion support is now provided (in shell-completion/). See how-to in the Cookbook. (Jakob Schöttl) - balance –budget: budget amounts now aggregate hierarchically, like account balances. Unbudgeted accounts can be shown with -E/–empty (along with zero-balance accounts), and the –show-budgeted flag has been dropped. (Dmitry Astapov) - balance: new –transpose flag switches the rows and columns of tabular balance reports (in txt and csv output formats). (Dmitry Astapov) - close: generated balance assertions now have exact amounts with all decimal digits, ignoring display precision. Also, balance assertion amounts will no longer contain prices. (#941, #824, #958) - files: now shows up in the commands list - import: be silent when there’s nothing to import - roi: percentages smaller than 0.01% are displayed as zero (Dmitry Astapov) - stats, ui: correct file order is preserved when using –auto (#949) - journal: account directive: the account name can now be followed by a comment on the same line - journal: account directive: account types for the bs/bse/cf/is commands can now be set with a type: tag, whose value is Asset, Liability, Equity, Revenue, Expense, A, L, E, R or X (case-insensitive). The previous syntax (account assets A) is now deprecated. - journal: account directive: account sort codes like account 1000 (introduced in 1.9, deprecated in 1.11) are no longer supported. - journal: transaction modifiers (auto postings) can affect periodic transactions (–auto can add postings to transactions generated with –forecast). (Dmitry Astapov) - journal: balance assertion errors now show exact amounts with all decimal digits. Previously it was possible, in case of a commodity directive limiting the display precision, to have a balance assertion error with asserted and actual amounts looking the same. (#941) - journal: fixed a periodic transaction parsing failure (#942) (Dmitry Astapov) hledger-ui 1.13 - on posix systems, control-z suspends the program - control-l now works everywhere and redraws more reliably - the top status info is clearer Getting started: ---------------- All install methods are described at http://hledger.org/download : windows binaries, system packages, docker, nix, cabal, stack, hledger installer, etc. Some of these might take a few days to become up to date. On systems with bash installed, the hledger installer is a reliable way to get the latest release of hledger: $ curl -s https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… > hledger-install.sh $ less hledger-install.sh # satisfy yourself that the script is safe $ bash hledger-install.sh Then try: $ hledger # list available commands $ hledger help # list built-in manuals Tutorials and all other docs: http://hledger.org Chat: #hledger on Freenode or Matrix - http://irc.hledger.org or http://riot.hledger.org . New and old users, contributors, all feedback, always welcome! Best, -Simon

1 0

Patents on Maybe and Tuple
by Henk-Jan van Tuyl 01 Feb '19

01 Feb '19

L.S., I just read the article "Apple Patents Swift".[0] It says that Apple has two patents regarding Swift: [1][2]; these patents state, amongst others, that there are new types of variables: "Additionally, an embodiment of the new language introduces advanced types not found in Objective-C. These types include Tuples and Optionals. Tuples enable a developer to create and pass groupings of values. Tuples group multiple values into a single compound value." and "In one embodiment, an optional type is provided that handles the absence of a value. Optionals are a way to say either “there is a value, and it equals x” or “there isn't a value at all.”" I hope we don't get arrested for using the Maybe monad or tuples in Haskell. Regards, Henk-Jan van Tuyl [0] https://www.i-programmer.info/news/98-languages/12495-apple-patents-swift.h… [1] https://patents.google.com/patent/US9952841B2 [2] https://patents.google.com/patent/US9329844B2 -- Message from Stanford University: Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://foldingathome.stanford.edu/ -- http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

7 11

Library for common AST transformations based on haskell-src-exts
by Sandra Dylus 01 Feb '19

01 Feb '19

Hi, in the last couple of years we had a number of projects that used haskell-src-exts [1]. In most of these cases we wanted to do some common AST transformations, e.g., translating function definitions via several rules into one rule using case expressions. So, after needing these transformations a couple of times, I was wondering if there is a library that works on top of haskell-src-exts and implements common transformations like the one mentioned. I took a look at the reverse dependencies of haskell-src-exts, but only found projects implementing these transformations as part of a bigger project. In a nutshell, I am asking if I did miss such a library or if there does not exist such a library yet. If the latter is the case, we will definitely implement such a library as part of the next student project that builds upon haskell-src-exts. Cheers Sandra [1] http://hackage.haskell.org/package/haskell-src-exts <http://hackage.haskell.org/package/haskell-src-exts>

2 1

Seeking: 12 month internship opportunities for Haskell enthusiasts
by Jacques Carette 30 Jan '19

30 Jan '19

I'm writing on behalf of some (quite good) undergraduate students in CS who have been quite taken by Haskell, whose program includes a 12 month internship at a company. Start time could be anytime between May and September, and duration would be 12 months. [Some students who start in May end up doing 16 months]. If anyone here has leads on such opportunities, please contact me. Location is flexible, as long as the language of work is English. Jacques

1 0

Re: [Haskell-cafe] Montreal Haskell
by Doug McIlroy 28 Jan '19

28 Jan '19

> Morgan-Stanley do their own internal version of Haskell, and they're > strongly oriented towards performance and correctness Interestingly eclectic. They also employ Bjarne Stroustup, the eminence grise of C++. Doug McIlroy

1 0

Montreal Haskell
by Asher Klein 28 Jan '19

28 Jan '19

Hi everyone! New member here! Anyone know of Haskell jobs in Montreal for new grads? Thanks!

3 5

Munich Haskell Meeting, 2019-01-28 @ 19:30
by Leah Neukirchen 27 Jan '19

27 Jan '19

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, January 28 at Cafe Puck at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-jan-2019/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> http://leah.zone

1 0

generics-sop : deep flattening of nested algebraic values ?
by Marco Zocca 27 Jan '19

27 Jan '19

Hi all, I'm a bit at a loss regarding this: say we have a value from a nested algebraic type (definitions at the bottom) testT2 :: T2 testT2 = T2 B (Left 42) a generic encoding computed with `from` only goes one level deep, leaving the sub-terms as they are : λ> from testT2 SOP (Z (I B :* (I (Left 42) :* Nil))) However, is it possible to recursively encode and collect all the sub-terms, until primitive types or enumerations are encountered? The encoded sub-terms from the example above are as follows: λ> from B SOP (S (Z Nil)) λ> from (Left 32 :: Either Int Char) SOP (Z (I 32 :* Nil)) where {-# language DeriveGeneric #-} import qualified GHC.Generics as G import Generics.SOP data T1 = A | B | C deriving (G.Generic) instance Generic T1 data T2 = T2 { t21 :: T1 , t22 :: Either Int Char } deriving (G.Generic) instance Generic T2

2 2

Is there a recursion-scheme function to push info down one level?
by Robin Palotai 26 Jan '19

26 Jan '19

I came up with this utility function so I can access some info (`n`) from the parent's level: hoistWithUpper :: forall f g s t n . (Functor g) => (forall a. f a -> n) -> n -> (forall a. n -> f a -> g a) -> (n -> s -> t) -> Free f s -> Free g t hoistWithUpper fu n0 hoistFr hoistPure = go n0 where go :: n -> Free f s -> Free g t go n fr = case fr of Pure s -> Pure (hoistPure n s) Free f -> let n2 = fu f in Free (go n2 <$> (hoistFr n f :: g (Free f s))) I wonder if there's already a generalized form of this in recursion-schemes? Admittedly I'm fine with my helper so don't loose nights on this, but a little type golfing never hurts. There's a similar function `inherit` [1] in fixplate, but that operates on Fix (Mu there), not Free. With Free I guess the complication is managing the different way of maintaining annotation at the Free and Pure ctors. Practically I pass in (\n f -> ConstProd (Pair (Const n) f)) -- for hoistFr (\n u -> (n,u)) -- for hoistPure. where newtype ConstProd c f a = ConstProd (Product (Const c) f a) Thanks! Robin [1]: http://hackage.haskell.org/package/fixplate-0.1.7/docs/src/Data-Generics-Fi…

2 1

[Job] Senior back-end engineer at CentralApp
by Ashesh Ambasta 23 Jan '19

23 Jan '19

Hi everyone, This is my first post to Haskell-Cafe, so pardon me for any errors. I'm writing on behalf of my company, CentralApp, to pitch our job opening. <https://centralapp.workable.com/j/9AFEDD1C3C> We're a small company and I'm the sole back-end engineer so far, and we're investing heavily only in Haskell as our back-end language of choice. A large part of our codebase is in Scala, since that was the choice I made 4-5 years ago. Since then, I got introduced to Haskell and I'm only considering it as the programming language of choice for our back-end infrastructure. We have plenty of engineering challenges in the pipeline since we're undergoing good growth. We serve millions of API requests per week and we're scaling the product out further. We also don't have much in the way of technological debt going forward. Some of the recent /interesting/ Haskell projects we've introduced to our infrastructure are: _Lazy SSL engine based on LetsEncrypt _ This is a Haskell program that issues SSL certificates using LetsEncrypt by doing /on-the-fly/ and /lazy/ certificate issuance. This allows us to vastly simplify HTTPS for 100's of domains we serve. _API Gateway for request pipe-lining_ We're a service oriented architecture. This usually entails that most of our API requests need to be serviced by a combination of back-end services, instead of just one. A trivial way to solve it would be: say a request needs to be passed to service A and then to B, then the responses from each of these services need to be accumulated into one client response. A can first receive the client request, do something, and then make another request to B to do something else. A can then accumulate the response from B along with its own response, and reply to the client. As one might imagine, it becomes increasingly cumbersome and hard to debug this kind of setup. Not only do you introduce dependencies between services A and B, coupling them tighter than you'd like, but it gets really messy when you're going to deal with authentication, authorisation and rapid changes in either A or B. In the worst case, you end up with request cycles (e.g. B makes a request to A), which are requests that never terminate and can bring down large parts of your infrastructure. The other big elephant in the room is also service discovery in a distributed environment. What makes sure that service A can reach a healthy instance of service B? To address this growing pain, we wrote a Haskell API Gateway service, which we lovingly call Quasar (I'm a fan of astronomical names) which flattens request pipe-lining at the API gateway level. What it does is: 1. recognises the request (based on verb + path) 2. identifies the resources being affected in this request (based on the query params/ JSON body) 3. authenticates the user 4. authorises the user for access to the identified resources 5. performs a request based pipeline flow: which is just a traversal of a request-tree, where each node is an "operation" to be performed on an input and output. The input being the response of the previous operation, and the output being the response of this operation. We leverage Haskell's elegant abstraction over operations like this (STM in particular) to ensure the responses are accumulated and returned to the client. -- These are some of the ways we're using Haskell and how it has benefited us. Going forward, given we have a fairly large codebase in Scala, we'd embark on replacing a service with its Haskell equivalent given the amount of changes required in the Scala counterpart is larger than a threshold. All new services that go into our infrastructure, however, will be written in Haskell. So far, our staple libraries of choice are: * Squeal * Servant ... and the usual suspects (Wai/Warp, Aeson, etc.) -- Other than that, we're based in the heart of Brussels, which is a fantastic city to work in, and we will offer a competitive compensation. Free weekly Belgian beers are on us. If this sounds interesting, please feel free to apply on the link above (https://centralapp.workable.com/j/9AFEDD1C3C) Or if you have any questions, please ask! While we'd prefer colleagues based /in /Belgium, or willing to relocate, we're still open to considering all applications. Thanks! -- Best, Ashesh Ambasta Founder (Engineering) CentralApp SA

1 0