November 2017 - Haskell-Cafe

Dutch FP-day 2018 (early registration required)
by Arjen 16 Nov '17

16 Nov '17

I would like to invite you to the next Dutch Functional Programming Day. It will take place on Friday 5th of January 2018, at the Walter Bos Complex of the Dutch Tax and Customs Administration at John F. Kennedylaan 8, Apeldoorn. The Dutch Functional Programming Day is an annual gathering of researchers, students, and practitioners sharing a common interest in functional programming. Experts and newcomers to the field are equally welcome. For more information see http://wiki.clean.cs.ru.nl/NL-FP_dag_2018 Please note that to the nature of the location, registration before December 15 is required. We need a list of participants for the security staff. We also need this to order the right number of badges, drinks and pizza's. You can register by sending a mail to a.van.weelden(a)belastingdienst.nl (or reply to this e-mail) including: 1. your name (used for identification) 2. your affiliation, if any 3. whether you want (vegetarian) pizza 4. whether you want to give a talk There are no costs for anything this year, as it is fully sponsored by the Dutch Tax and Customs Administration. kind regards, Betsy Pepels and Arjen van Weelden

1 0

Project idea, seeking feedback
by Alex 15 Nov '17

15 Nov '17

Hi all, I'm seeking feedback for a project I'd like to start. I have a bit of experience developing large scale systems containing many microservices, databases, message queues, and caches over many VMs. Time and time again I find myself confronted with the same problems: 1. It is difficult to trace events through the system: Consider an HTTP request made by a customer to a public API. Which microservices were impacted by that request? What SQL queries were run as a result of that request? What 3rd party APIs were consulted during the request's fulfillment? Answers to these questions are essential to fixing bugs quickly, and yet they are so difficult to answer (at least in my experience). 2. Problems are difficult to reproduce: When Customer Success walks in and says, "I have an angry customer on the phone. They want to know why [FOO] wasn't properly [BAR]" it is often impossible to give an answer without interactive troubleshooting and hours of grepping through unstructured log files. Troubleshooting may incur additional expenses too, since (for instance) you may hit your API request limit for a 3rd party service. 3. Business and non-business logic are not well encapsulated: Often I see code related to (for example) RabbitMQ interwoven with core business logic when calls need to be made to other microservices. The fact that RabbitMQ facilitates communication between microservices is an implementation detail that I shouldn't have to think about. 4. Resource consumption is non-uniform: Some microservices are more demanding than others in terms of CPU, memory, and disk usage. Achieving optimal "packing" is difficult. In other words, some VMs will have a high load and others will remain idle. Auto scaling groups can help with this in theory, but I don't think they can achieve the kind of density I would like to see. Moreover, what constitutes a "resource"? If a 3rd party service rate limits requests by IP address, couldn't each request be considered a resource unit which needs to be properly load balanced, just as you would with CPU? Given these motivations, I would like to flesh out some ideas for a framework/platform which addresses these issues. These ideas are half-baked and may not tie in well with one another. I envision a distributed system as follows: 1. One kind of VM: DevOps people have a saying: "Treat your VMs like cattle, not pets". In practice, "cattle" becomes "cows, chickens, pigs, and lobster". VMs typically have an assigned role, and they become part of a group which may or may not be auto-scaling. For a given instantiation of this hypothetical platform, I would like to see a single kind of VM. That is, every VM is identical to every other VM, and they all run the same Haskell application. 2. Strict separation of business and non-business logic: The framework should handle all aspects of communication between nodes (like Cloud Haskell does) in a pluggable and transparent way, but that's not all. The framework should have first class support for other integrations (such as PagerDuty alerting, performance monitoring, etc) which are described below. 3. Pool coordination via DSL: The entire pool of VMs is orchestrated/coordinated by one ore more "scripts" written in a DSL, which is implemented as a Free Monad. Every single "operation" or "primitive" in your AST data type is Serializable, and when the framework interprets the DSL, it serializes the instruction and sends it over the network to a node for execution. The particular node on which the instruction gets executed is chosen by the platform, not the developer. 4. Smart resource consumption: Each node brings with it a set of resources. It is *not* my intention to create a system which views CPU, memory, etc as a contiguous unit. Rather, each primitive instruction in the AST is viewed as a "black box" which can only consume as much CPU and memory as the node has available to it. The framework is responsible for profiling each instruction and scheduling future instructions to a node for which resources are predicted to be available. The developer should be able to define new resources such as 3rd party API calls, bandwidth, database connections, etc, all of which are profiled just as CPU and memory would. 5. Browser based control panel: Engineers should have a GUI at their disposal which allows them to watch -- in real time -- the execution flow of the DSL script. 6. Structured logs with advanced filtering: All log output should be structured with first class support for shipping the data to Logstash/ElasticSearch. The aforementioned GUI should be able to selectively filter output based on certain pre-defined predicates and display them to the developer. For example, if you're building an email virus scanning system (which may see millions of emails per day), you may want to limit the real-time debugging output to only a specific customer. 7. First class integration with modern tools and services: The system should integrate with Consul, PagerDuty, statsd, RabbitMQ, memcache, DataDog, Logstash, and Slack, with new integrations being easy to add. This is vital for clean separation of business and non-business logic. For example, the developer should be able to cache certain bits of data at will, without having to worry about opening and managing a TCP connection to memcache. This is my vision, and I want to build it completely in Haskell. What do you all think? -- Alex

4 4

Re: [Haskell-cafe] how to make a KnownNat at runtime?
by dominic＠steinitz.org 15 Nov '17

15 Nov '17

You mean something like this? > withMatrix > :: forall z > . Matrix ℝ > -> (forall m n . (KnownNat m, KnownNat n) => L m n -> z) > -> z > withMatrix a f = > case someNatVal $ fromIntegral $ rows a of > Nothing -> error "static/dynamic mismatch" > Just (SomeNat (_ :: Proxy m)) -> > case someNatVal $ fromIntegral $ cols a of > Nothing -> error "static/dynamic mismatch" > Just (SomeNat (_ :: Proxy n)) -> > f (mkL a :: L m n) > Dear Cafe, > > I am using type-level numbers for > representing dimensions of vectors and matrices > (similar to https://github.com/ekmett/ersatz/blob/master/tests/Z001.hs ) > Now when I indeed know all the dimensions at compile time, > (in the example code, line 20) everything works nicely. > > But what do I do when the dimensions > will only become available at run time? > > Here is a simplified example: print the null vector > where the size is read from the command line - > of course in my application "handle" does more, > but it essentially has the type given here. > > I can extend the "case" in the "main" function > to include all the values I want to handle. > Looks ugly. Is there a better way? > > - J. > > {-# language KindSignatures, RankNTypes, LambdaCase, > TypeApplications, DataKinds, ScopedTypeVariables > #-} > > import GHC.TypeLits > import Data.Proxy > import System.Environment > > main :: IO () > main = getArgs >>= \ case > [ "2" ] -> handle (Proxy :: Proxy 2) > [ "3" ] -> handle (Proxy :: Proxy 3) > > handle :: forall (n::Nat) . KnownNat n => Proxy n -> IO () > handle (_ :: Proxy n) = print (zero :: V n Int) > > data V (n::Nat) a = V [a] deriving Show > > zero :: forall (n::Nat) a . (KnownNat n, Num a) => V n a > zero = V $ replicate (fromIntegral $ natVal (Proxy :: Proxy n)) 0 > Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 0

ANNOUNCE: Haskell Communities and Activities Report (33rd ed., November 2017)
by Mihai Maruseac 15 Nov '17

15 Nov '17

On behalf of all the contributors, we are pleased to announce that the Haskell Communities and Activities Report (33rd edition, November 2017) is now available, in PDF and HTML formats: http://haskell.org/communities/11-2017/report.pdf http://haskell.org/communities/11-2017/html/report.html All previous editions of HCAR can be accessed on the wiki at https://wiki.haskell.org/Haskell_Communities_and_Activities_Report Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. We hope you will find it as interesting a read as we did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline) to the call. The editors collect all the contributions into a single report and feed that back to the community. When we try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: ======================================== End of February 2018: target deadline for contributions to the May 2018 edition of the HCAR Report ======================================== Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to "register" with the editors for a simple e-mail reminder in November (you could point us to them as well, and we can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya

3 2

uninstalling libraries
by Evan Laforge 15 Nov '17

15 Nov '17

For a very long time, I've used a local script to uninstall libraries. Initially it was very simple: use ghc-pkg field to find and remove library-dirs, import-dirs, and haddock-html, and call ghc-pkg unregister. It served well for a long time, but eventually I got tired of copy paste games and extended it to be able to recursively delete dependents too. Unfortunately now it's no longer so simple. The main problem is that the only way I know to find dependents is to ghc-pkg unregister, and see what the error message complains about. That's obviously pretty bad, since by that time you've already unregistered, so it's too late to back out. The non-atomic nature of unregister+rm has always caused problems anyway, since if unregister succeeds, but the remove fails, we are stuck with a partial install. Recursive delete is too error prone, so I reverted that. And then I discovered that hmatrix helpfully includes /opt/local/lib and /usr/local/lib in its library-dirs, so clearly just deleting whatever the package tells me is not very safe. All this has led me to believe uninstalling packages is not so simple, and maybe there should be an actual real way to do it, not everyone hacking up their own dangerous shell scripts. So... is there? Should there be one? Is there interest in one? How do other people uninstall libraries? Is there a better interface to the pkg db than ghc-pkg? Is there a better way to find dependents than ghc-pkg unregister?

7 12

how to make a KnownNat at runtime?
by Johannes Waldmann 14 Nov '17

14 Nov '17

Dear Cafe, I am using type-level numbers for representing dimensions of vectors and matrices (similar to https://github.com/ekmett/ersatz/blob/master/tests/Z001.hs ) Now when I indeed know all the dimensions at compile time, (in the example code, line 20) everything works nicely. But what do I do when the dimensions will only become available at run time? Here is a simplified example: print the null vector where the size is read from the command line - of course in my application "handle" does more, but it essentially has the type given here. I can extend the "case" in the "main" function to include all the values I want to handle. Looks ugly. Is there a better way? - J. {-# language KindSignatures, RankNTypes, LambdaCase, TypeApplications, DataKinds, ScopedTypeVariables #-} import GHC.TypeLits import Data.Proxy import System.Environment main :: IO () main = getArgs >>= \ case [ "2" ] -> handle (Proxy :: Proxy 2) [ "3" ] -> handle (Proxy :: Proxy 3) handle :: forall (n::Nat) . KnownNat n => Proxy n -> IO () handle (_ :: Proxy n) = print (zero :: V n Int) data V (n::Nat) a = V [a] deriving Show zero :: forall (n::Nat) a . (KnownNat n, Num a) => V n a zero = V $ replicate (fromIntegral $ natVal (Proxy :: Proxy n)) 0

4 4

[ANN] Book About Simulation
by David Sorokin 11 Nov '17

11 Nov '17

Hi Cafe, I am delightful to inform that I wrote a book about simulation, Haskell and my Aivika libraries. http://aivikasoft.com/downloads/aivika/aivika.pdf It depends on point of view how to concern with this book. It can be a book about discrete event simulation per se. Also it can be considered as Aivika User’s Manual, or as a book about that how we can apply Haskell for simulation. I would be very grateful if someone could review my book, especially the English text as I’m a Russian native speaker. Best regards, David Sorokin

3 3

[ANN] Haskell Theory Exploration scripts
by Chris Warburton 09 Nov '17

09 Nov '17

Hello all, I thought I'd make a public announcement about some scripts I've built up over the last few years for "exploring" Haskell code. They can be found at: http://chriswarbo.net/git/haskell-te With mirrors at /ipns/QmWv958VzBJQchGjYKiSaxLC9ugrjvXkqMpVrmjp9AonXq and https://github.com/Warbo/haskell-te These use the excellent QuickSpec library from: https://hackage.haskell.org/package/quickspec This empirically (through brute force and QuickCheck testing) conjectures equations about given Haskell function definitions. I think it's a very under-utilised library, perhaps due to a couple of reasons: - It requires hand-holding from the user, e.g. installing packages, importing modules, naming functions, monomorphising types, picking an arity, etc. - It can be very resource-intensive! I know there's some work to address the efficiency concerns in a newer version, but that's not made its way to Hackage, Nixpkgs, etc. yet: https://github.com/nick8325/quickspec My scripts try to address the usability issues. More details are in the README, but basically we can run: quickspec myHaskellDir | renderEqs This will (hopefully) output conjectures found by QuickSpec about the functions defined in myHaskellDir. This automatically finds all function definitions, looks up their types, arities, etc. and invokes QuickSpec in a subprocess (with optional timeouts and memory limits). If we leave off the 'renderEqs', we get an easily-parsed JSON format, which we can feed into other tools. Note that I make *heavy* use of the Nix language, and it's quite hit-or-miss whether a package will work. My hope is that more widespread knowledge of these tools will alleviate some of the existing pain points. In particular, many packages define `Arbitrary` instances for their types, but they do so in their test suites rather than their libraries, so nobody else can make use of them (I assume this is to keep down library dependencies?) Suggestions and contributions are welcome! -- Thanks, Chris Warburton

1 0

Re: [Haskell-cafe] Proposal: Instance apartness guards
by Anthony Clayden 09 Nov '17

09 Nov '17

Surprisinlgy little comment on this proposal. Perhaps it landed when yous were busy elsewhere. I'd like to push it to the committee soon; this is an invitation for more feedback. Richard E wrote a nice brief summary https://github.com/ghc-proposals/ghc-proposals/pull/56#issuecomment-3114214… Thank you AntC ----- Original Message Follows ----- > After years of pondering this idea (in various forms), > and several rounds of discussion on several forums, > I've written it up. > > "This proposal tackles the thorny topic of Overlapping > instances, > for both type classes and Type Families/Associated types, > by annotating instance heads with type-level apartness > Guards. > Type-level disequality predicates appear in Sulzmann & > Stuckey 2002; > in the type-level case selection in HList 2004; > and in various guises in Haskell cafe discussions in > following years. > This proposal builds on the apartness testing implemented > as part of the Closed Type Families work." > > All feedback welcome. > > https://github.com/AntC2/ghc-proposals/blob/instance-apartness-guards/propo… > > AntC

2 1

Functional programming job opportunity
by Nathan van Doorn 08 Nov '17

08 Nov '17

Myrtle is looking for skilled developers to join our growing development team and assist with the development of our core compiler technology. Ideally candidates would have an interest in either efficient hardware design and/ or machine learning models and frameworks. We use the functional language, Haskell, for every aspect of our work and developers will get the chance to be involved in every part of the project. Familiarity and interest with hardware design would be viewed positively but is not essential. Applicants should be familiar with Unix based systems as all our development is done on Ubuntu or NixOS. More information at https://www.myrtlesoftware.com/vacancies/

1 0