News aggregator

ANN: remote-json, a JSON RPC library, released

General haskell list - Wed, 02/10/2016 - 6:04pm
Announcing a new Haskell JSON RPC library, remote-json, that uses the remote monad to bundle remote procedure calls, amortizing the cost of remote execution. There are thee bundling strategies provided: * weak (calls done one at a time), * strong (calls bundled until a reply is needed, where possible), and * applicative (an applicative functor is sent to the remote JSON RPC server). Example of use: say :: Text -> RPC () say msg = notification "say" (List [String msg]) temperature :: RPC Int temperature = method "temperature" None main :: IO () main = do let s = strongSession $ clientSendAPI "http://www.wibble.com/wobble" t <- send s $ do say "Hello, " say "World!" temperature print t Blog: * http://ku-fpg.github.io/2016/02/09/remote-json/ <http://ku-fpg.github.io/2016/02/09/remote-json/> Hackage: * http://hackage.haskell.org/package/remote-json <http://hackage.haskell.org/package/remote-json> * http://hackage.haskell.org/package/remote-jso
Categories: Incoming News

tighter bounds for Data.Map operations (usingmin(n.m))?

haskell-cafe - Wed, 02/10/2016 - 5:29pm
Dear Cafe, I wonder if some of the resource bounds in https://hackage.haskell.org/package/containers-0.5.7.1/docs/Data-Map-Strict.html can be improved. I do not mean "improve the implementation", but "improve the (stated) bounds". For example, I am interested in intersection(With). Bound is stated as O(n+m) (*) This is a fine worst case bound - but I certainly use this function with the implied assumption that it will not visit both trees completely - in the case that one of them is small. So, what can we say in terms of min(n,m) ? Is it linear in that parameter? Perhaps with an additional factor log(max(n,m)) ? (for looking up the keys of the smaller tree in the larger one) The paper linked from the docs has this (p 18 before 9.3) "the running time of union is better for fortuitous inputs, for example, similar sized disjoint ranges, and trees which differ greatly in size" but does not make a formal statement. This is about union, not intersection, and not hedge_union, but it's the closest this pa
Categories: Offsite Discussion

Hackage: Tarball and package description of packagemtl differ

haskell-cafe - Wed, 02/10/2016 - 4:09pm
Hi Cafe, I just wanted to install the mtl package for GHC 8.0.1-rc2, but installation failed with Setup: Encountered missing dependencies: transformers ==0.4.* Taking a look at the package description [1], it specifies build-depends: base < 6, transformers >= 0.4 && < 0.6 but the Cabal description in the tarball [2] says build-depends: base < 6, transformers == 0.4.* Strangely, if I execute $ cabal unpack mtl-2.2.1 I obtain a version with the same specification as [1]. Does anybody has an explanation for this? Regards, Björn [1]: http://hackage.haskell.org/package/mtl-2.2.1/mtl.cabal [2]: http://hackage.haskell.org/package/mtl-2.2.1/mtl-2.2.1.tar.gz _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

Postdoctoral position in Functional,Constraint and/or Logic Programming

haskell-cafe - Wed, 02/10/2016 - 1:40pm
Prof. Tom Schrijvers invites applications for a postdoctoral position in the area of functional, constraint and logic programming. The position revolves around domain-specific languages (DSLs) embedded in Haskell for constraint programming. It is part of the EU project GRACeFUL whose overarching theme is tools for collective decision making. Responsibilities You will work closely with prof. Schrijvers and his PhD students at KU Leuven, as well as with the GRACeFUL project partners across Europe, in order to conduct research activities for the GRACeFUL project. For more details: https://icts.kuleuven.be/apps/jobsite/vacatures/53613023
Categories: Offsite Discussion

maps over arrays that provide the position index for the array and accelerate libraries?

haskell-cafe - Tue, 02/09/2016 - 1:25pm
In vector library there's this useful function: imap :: (Int -> a -> b) -> Vector a -> Vector b And in Data.Map there's this similar function: mapWithKey :: (k -> a -> b) -> Map k a -> Map k b I'm looking for something similar in the array and accelerate libraries, i.e. On arrays in Data.Array.IArray: imap :: (IArray a e, IArray a e', Ix i) => (i -> e -> e') -> a i e -> a i e' And on Accelerate arrays: imap :: (Shape ix, Elt a, Elt b) => (Exp ix -> Exp a -> Exp b) -> Acc (Array ix a) -> Acc (Array ix b) Is anyone aware of such map implementations for arrays in the array and accelerate libraries, that provide your mapped function not only the element at a position, but also the index at that position? Thanks, -- Rob
Categories: Offsite Discussion

PSA: If you're serializing floating point numbers,don't use binary

haskell-cafe - Tue, 02/09/2016 - 12:19pm
Serialization of floating point numbers with binary is fantastically slow and incorrect if you’re using NaNs, see https://github.com/kolmodin/binary/issues/64 <https://github.com/kolmodin/binary/issues/64> https://github.com/kolmodin/binary/issues/69 <https://github.com/kolmodin/binary/issues/69> I recently spent half a day debugging performance problems because of this, and since backwards compatibility with older formats is required, this problem is probably not going to be solved. We decided to switch to cereal for this reason. With some patches <https://github.com/GaloisInc/cereal/pull/46> cereal was 30x faster for the data we were serializing (scientific computing, mostly Doubles packed in nested records containing vectors). The size of the serialized data is also roughly 3 times smaller – with binary a Double takes at least 25 bytes of space instead of 8. With Float it’s even worse, 25 bytes instead of 8._______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >has
Categories: Offsite Discussion

Joachim Breitner: GHC performance is rather stable

Planet Haskell - Tue, 02/09/2016 - 9:17am

Johannes Bechberger, while working on his Bachelor’s thesis supervised by my colleague Andreas Zwinkau, has developed a performance benchmark runner and results visualizer called “temci”, and used GHC as a guinea pig. You can read his elaborate analysis on his blog.

This is particularly interesting given recent discussions about GHC itself becoming slower and slower, as for example observed by Johannes Waldmann and Anthony Cowley.

Johannes Bechberger’s take-away is that, at least for the programs at hand (which were taken from the The Computer Language Benchmarks Game, there are hardly any changes worth mentioning, as most of the observed effects are less than a standard deviation and hence insignificant. He tries hard to distill some useful conclusions from the data; the one he finds are:

  • Compile time does not vary significantly.
  • The compiler flag -O2 indeed results in faster code than -O.
  • With -O (but not -O2), GHC 8.0.1 is better than GHC 7.0.1. Maybe some optimizations were promoted to -O?

If you are interested, please head over to Johannes’s post and look at the gory details of the analysis and give him feedback on that. Also, maybe his tool temci is something you want to try out?

Personally, I find it dissatisfying to learn so little from so much work, but as he writes: “It’s so easy to lie with statistics.”, and I might add “lie to yourself”, e.g. by ignoring good advise about standard deviations and significance. I’m sure my tool gipeda (which powers perf.haskell.org) is guilty of that sin.

Maybe a different selection of test programs would yield more insight; the benchmark’s games programs are too small and hand-optimized, the nofib programs are plain old and the fibon collection has bitrotted. I would love to see a curated, collection of real-world programs, bundled with all dependencies and frozen to allow meaningful comparisons, but updated to a new, clearly marked revision, on a maybe bi-yearly basis – maybe Haskell-SPEC-2016 if that were not a trademark infringement.

Categories: Offsite Blogs

ICFP 2016 Second Call for Papers

General haskell list - Tue, 02/09/2016 - 8:09am
ICFP 2016 The 21st ACM SIGPLAN International Conference on Functional Programming http://conf.researchr.org/home/icfp-2016 Second Call for Papers Important dates --------------- Submissions due: Wednesday, March 16 2016, 15:00 (UTC) https://icfp2016.hotcrp.com (now open) Author response: Monday, 2 May, 2016, 15:00 (UTC) - Thursday, 5 May, 2016, 15:00 (UTC) Notification: Friday, 20 May, 2016 Final copy due: TBA Early registration: TBA Conference: Monday, 19 September - Wednesday, 21 September, 2016 (note updated conference dates) Scope ----- ICFP 2016 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional prog
Categories: Incoming News

ICFP 2016 Second Call for Papers

haskell-cafe - Tue, 02/09/2016 - 8:09am
ICFP 2016 The 21st ACM SIGPLAN International Conference on Functional Programming http://conf.researchr.org/home/icfp-2016 Second Call for Papers Important dates --------------- Submissions due: Wednesday, March 16 2016, 15:00 (UTC) https://icfp2016.hotcrp.com (now open) Author response: Monday, 2 May, 2016, 15:00 (UTC) - Thursday, 5 May, 2016, 15:00 (UTC) Notification: Friday, 20 May, 2016 Final copy due: TBA Early registration: TBA Conference: Monday, 19 September - Wednesday, 21 September, 2016 (note updated conference dates) Scope ----- ICFP 2016 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional prog
Categories: Offsite Discussion

Combining ST with STM

haskell-cafe - Tue, 02/09/2016 - 5:43am
Hi friends, I have an STM transaction that needs some private, temporary state. The most obvious way is to simply pass pure state as arguments, but for efficiency, I would like this state to be some kind of mutable array, like STArray. I know, STM has TVars and TArray, but since this state is private to the transaction, I am wondering if using TVars/TArrays for private state might be overkill that will unnecessarily slow down the STM commit process. The private state is, by definition, not shared, so including it in the STM log and commit process is, as far as I can tell, pointless. ST and STArray still appear to be the most appropriate tools for the private state, because STRefs and STArrays really, really are private. So this basically means I want to interleave ST and STM in a "safe" way. That is, if the STM transaction retries, I want the ST state to be vaporised as well. Ideally, I would love to be able to say something like this:
Categories: Offsite Discussion

Matrices as Applicatives and Monads

haskell-cafe - Tue, 02/09/2016 - 4:02am
I have been writing code encoding matrices here <https://github.com/Strikingwolf/Learning/blob/master/haskell/src/math/Matrix.hs> as a learning experience. However, I cannot figure out a method to make Matrix an instance of Applicative and Monad. I believe it is possible, but I cannot find an implementation. For context my form of Matrix does not have a requirement to be of integers, it is just a 2-Dimensional array in essence. Thank you in advance for any help you may provide :) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

[ANN] aeson 0.11.0.0

haskell-cafe - Mon, 02/08/2016 - 11:22pm
Hi haskellers, As a new co-maintainer of aeson I'm happy to announce aeson 0.11.0.0[1]. v0.10 had a number of issues and v0.11 aims to fix all of these. I'm happy to see that all known regressions have been fixed, and I didn't have to write any code myself! ;) Going 0.9 to 0.11 should be no work for most users. I've built all packages in stackage nightly[2] and out of 222 only one needs a non-trivial change (sorry pagerduty maintainers!) Please help out by letting us know if we missed something, including if something should be added to the CHANGELOG[3]. A big thanks to everyone who contributed code to this release: Bryan O'Sullivan Bas van Dijk Oleg Grenrus Herbert Valerio Riedel Ben Weitzman Daniel Díaz RyanGlScott David Johnson Artyom Cale Gibbard Mikhail Glushenkov Ondrej Palkovsky Tim Bodeit mrkkrp And a thank you to everyone else who helped in other ways! All the best, Adam [1] https://hackage.haskell.org/package/aeson-0.11.0.0 [2] https://github.com/bos/aeson/issues/355 [3] https://github.co
Categories: Offsite Discussion

Call for PhD students: Logical Methods in Computer Science (Vienna, Austria)

General haskell list - Mon, 02/08/2016 - 9:44pm
(* Apologies if you got multiple copies of this email *) Funded Doctoral Positions in Computer Science [http://logic-cs.at/phd/] TU Wien, TU Graz, and JKU Linz are seeking exceptionally talented and motivated students for their joint doctoral program LogiCS. The LogiCS doctoral college focuses on interdisciplinary research topics covering (i) computational logic, and applications of logic to (ii) databases and artificial intelligence as well as to (iii) computer-aided verification. THE PROGRAM LogiCS is a doctoral college focusing on logic and its applications in computer science. Successful applicants will work with and be supervised by leading researchers in the fields of computational logic, databases and knowledge representation, and computer-aided verification. FACULTY MEMBERS M. Baaz A. Biere R. Bloem A. Ciabattoni U. Egly T. Eiter C. Fermueller R. Grosu A. Leitsch M. Ortiz R. Pichler S. Szeider H. Tompits H. Veith G. Weissenbacher The LogiCS faculty comprises 15
Categories: Incoming News

ANNOUNCE: hoppy, qtah

haskell-cafe - Mon, 02/08/2016 - 8:11pm
Are you sick and tired of the ease with which Haskell code flows onto the page? Even the thrill of binding to a C library losing its lustre? Look no further! I present to you a tool restoring the good old days of pointer arithmetic, manual memory management, and hours lost to the debugger: Hoppy is a new C++ FFI generator for Haskell. It takes Haskell code that describes a C++ API, and generates C++ and Haskell code to allow the two languages to interact. It supports a good subset of C++, including functions, classes, variables, enums and bitflags, operator overloading, constness, and simple templates. Adding a function takes only a few lines of code, and you normally don't need to write C++ yourself. For example, a definition for std::string is: c_string :: Class c_string = addReqIncludes [includeStd "string"] $ classAddFeatures [Assignable, Comparable, Copyable, Equatable] $ makeClass (ident1 "std" "string") (Just $ toExtName "StdString") [] [ mkCtor "new" []
Categories: Offsite Discussion

Functional Programming Group at the University of Kansas: The Remote JSON library

Planet Haskell - Mon, 02/08/2016 - 6:00pm

JSON-RPC is a simple and well supported protocol for remote procedure calls over HTTP, supporting both synchronous remote methods calls and asynchronous notifications. We want to access JSON-RPC from Haskell, but in a principled way. This blog post discusses the design and user-facing interface of remote-json, a new library for JSON-RPC that makes use of the remote monad design pattern

To give an example from the specification, consider calling a method subtract, with the arguments 42 and 23.

<figure class="highlight">--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1} <-- {"jsonrpc": "2.0", "result": 19, "id": 1}</figure>

Here, --> is the data sent from client to server, and <-- is what the server responds. The packet being sent is a simple JSON object, as is the reply from the server.

The JSON-RPC protocol supports batching (sending several method calls and notifications at the same time) and is easy to debug, because it is straightforward to read JSON structures. Furthermore, by using JSON-RPC we can implement our clients in Haskell, and be agnostic about what language or framework the server is written in.

There are at least five existing Haskell libraries that support JSON-RPC. So why a new library? We wanted to build our own because we saw a way of simplifying the API considerably, while still allowing access to all the capabilities of JSON-RPC. Specifically, by using the remote monad design pattern we can automate taking advantage of the batch capability, amortizing the cost of the remote call. Rather than have separate entry points for batched and singleton calls, a single entry point can provide both batched and singleton calls. The library also acts as a case study of using the remote monad.

Basic Design of the JSON-RPC API

We center our design around the RPC monad.

<figure class="highlight">-- The monad data RPC :: * -> * deriving (Monad, Applicative, Functor) -- The primitives method :: FromJSON a => Text -> Args -> RPC a notification :: Text -> Args -> RPC () -- the remote send send :: Session -> RPC a -> IO a</figure>

This is a classical remote monad design - a restricted monad, a small number of primitives for this monad, and a send function. Session is an abstract handle to the web server we want to talk to; we’ll come back to how to generate a Session shortly.

This API gives an (aeson) Value-based access to JSON-RPC. Adding specific primitives gives stronger typing. As an example, consider providing say notifications, that make the remote server say things, a temperature method that returns the remote server’s temperature, and an uptime method that returns the uptime of a specific service.

<figure class="highlight">say :: Text -> RPC () say msg = notification "say" $ List [String msg] temperature :: RPC Int temperature = method "temperature" None uptime :: Text -> RPC Double uptime nm = method "uptime" $ List [String nm] -- provided utilities for generating Args, and parsing the Value result of a method. List :: [Value] -> Args None :: Args</figure>

As an example we have our typed API for temperature, uptime and say, saying “Hello, World!”, getting the temperature, and the uptime of “orange”.

<figure class="highlight">example :: Session -> IO () example s = do (t,u) <- send s $ do say "Hello, " t <- temperature say "World!" u <- uptime "orange" return (t,u) print t print u </figure>

send can be used multiple times if needed, acting as translation between our IO monad, and the remote RPC monad. Furthermore, the following JSON-RPC interaction with the server would be a valid trace of interactions for the above example.

<figure class="highlight">--> {"jsonrpc": "2.0", "method": "say", "params": ["Hello, "]} // No reply --> {"jsonrpc": "2.0", "method": "temperature", id: 1 } <-- {"jsonrpc": "2.0", "result": 99, "id": 1} --> {"jsonrpc": "2.0", "method": "say", "params": ["World "]} // No reply --> {"jsonrpc": "2.0", "method": "uptime", "params": ["orange"], id: 1 } <-- {"jsonrpc": "2.0", "result": 3.14, "id": 1}</figure>

In this interaction:

  • notifications are methods without id’s, and do not have replies, and
  • methods use an id to tag a result.

This usage is reasonable, but we can do better. We want to bundle together notifications and methods, to amortize the cost of network traffic, but without comprising the API. Specifically, we want users to just write code using send, and the RPC library to figure out the best bundling possible.

The Remote Monad

In the remote monad theory, there are two key concepts:

  • Splitting the monadic primitives into commands and procedures.
    • Commands do not have a result value (typically () in Haskell), and
    • Procedures have a result.

    There are restrictions on commands and procedures, specifically that they must be serializable.

  • Choosing a bundling strategy. There are two strategies that were documented in the original paper and one new bundling strategy that we are investigating.
    • Weak - a bundle of a single command or a single procedure, or
    • Strong - a bundle of a sequence of commands, optionally terminated by a procedure, or
    • Applicative - a bundle of a sequence of commands and procedures, held together using an applicative functor.

By factoring our primitives into commands and procedures, we can automatically split up a monadic computation into maximal bundles, and then use a transport layer to send, execute and get the result from each bundle. The good news is there is a library, called the remote-monad, that has a plug-and-play API. If we provide the best bundling transport we can, then the library can pick the best way of splitting up the monadic computation into our bundles.

Considering JSON-RPC, the concept of notification and method map straight onto the remote monad concepts of commands and procedures. This makes things straightforward.

Weak Bundles

You can create a JSON-RPC instance using weakSession, which takes an encoding of how to send values to a remote server, and returns a Session.

<figure class="highlight">weakSession :: (SendAPI :~> IO) -> Session</figure>

SendAPI :~> IO is a natural transformation.

<figure class="highlight">newtype f :~> g = Nat (∀ a. f a -> g a)</figure>

Specifically, SendAPI :~> IO is a functor morphism between SendAPI and IO, and isomorphic to ∀ a. SendAPI a -> IO a. Operationally, this transformation is how you run SendAPI, using IO. SendAPI is a deep embedding of both synchronous and asynchronous communications of JSON Value.

<figure class="highlight">data SendAPI :: * -> * where Sync :: Value -> SendAPI Value Async :: Value -> SendAPI () </figure>

So, calling send with the RPC monadic remote commands factors up the specifics commands, and calls the natural transformation argument with either Sync or ASync. With the weakSession, every primitive causes its own Sync or ASync; there is no complex bundling.

You can write your own matcher for SendAPI, or use remote-json-client, which provides a function that, when given a URL, returns the SendAPI to IO natural transformation using the wreq library.

<figure class="highlight">clientSendAPI :: String -> (SendAPI :~> IO)</figure>

Putting this together, we get

<figure class="highlight">main :: IO () main = do let s = weakSession (clientSendAPI "http://www.wibble.com/wobble") (t,u) <- send s $ do say "Hello, " t <- temperature say "World!" u <- uptime "orange" return (t,u) print t print u </figure>

Having selected the weak remote monad, we have the weakest JSON-RPC interaction - four transactions.

<figure class="highlight">// (1) --> {"jsonrpc": "2.0", "method": "say", "params": ["Hello, "]} // No reply // (2) --> {"jsonrpc": "2.0", "method": "temperature", id: 1 } <-- {"jsonrpc": "2.0", "result": 99, "id": 1} // (3) --> {"jsonrpc": "2.0", "method": "say", "params": ["World "]} // No reply // (4) --> {"jsonrpc": "2.0", "method": "uptime", "params": ["orange"], id: 1 } <-- {"jsonrpc": "2.0", "result": 3.14, "id": 1}</figure> Strong Bundles

The strong remote monad bundles together commands, where possible, to amortize the cost of the remote call. In our example above, we have two notifications, and a method call. We want to combine them together. We do so by using the strongSession combinator.

<figure class="highlight">main :: IO () main = do let s = strongSession (clientSendAPI "http://www.wibble.com/wobble") (t,u) <- send s $ do say "Hello, " t <- temperature say "World!" u <- uptime "orange" return (t,u) print t print u </figure>

Now, we get a two transactions, which conforms to the JSON-RPC specification.

<figure class="highlight">--> [ {"jsonrpc": "2.0", "method": "say", "params": ["Hello. "]} , {"jsonrpc": "2.0", "method": "temperature", id: 1 } ] <-- [ {"jsonrpc": "2.0", "result": 99, "id": 1} ] --> [ {"jsonrpc": "2.0", "method": "say", "params": ["World "]} , {"jsonrpc": "2.0", "method": "uptime", "params": ["orange"], id: 1 } ] <-- [ {"jsonrpc": "2.0", "result": 3.14, "id": 1} ]</figure>

The same RPC send command gives better bundling, solely from changing the strategy from a weakSession to a strongSession. Now, the JSON-RPC specification says

  • “The Server MAY process a batch rpc call as a set of concurrent tasks, processing them in any order and with any width of parallelism.”

This is where it gets interesting. The RPC monad reflects the concurrency policy of the the server, up to method calls. If you wish to insist on sequentiality, then use the weakSession.

Applicative Bundles

One obvious question is “can we improve this reflection of concurrency, and bundle method calls as well as notification?” Yes! For example, Haxl, a Haskell DSL for database access, uses an even stronger bundling strategy, which we call the applicative bundling strategy. In this strategy, methods that are expressed using applicative functors can be bundled together, as well as commands that can already be bundled.

The remote-json library supports applicative bundling. Again, the details are abstracted by the library, and again the monad and applicative functor reflect the concurrency semantics of the server. We’ve added a new remote command uptime that returns the uptime of a specific machine, to aid the demonstration of batching, and reworked the computation to use applicative.

<figure class="highlight">main :: IO () main = do let s = applicativeSession (clientSendAPI "http://www.wibble.com/wobble") (t,u) <- send s $ say "Hello, " *> (pure (,) <*> temperature <* say "World!" <*> uptime "orange") print (t,u)</figure>

The packet now includes two notifications and two methods. (Remember, a notification is a JSON-RPC method that has no id tag.)

<figure class="highlight">--> [ {"jsonrpc":"2.0","params":["Hello,"],"method":"say"} , {"jsonrpc":"2.0","method":"temperature","id":2}, , {"jsonrpc":"2.0","params":["World!"],"method":"say"} , {"jsonrpc":"2.0","params":["orange"],"method":"uptime","id":1} ] <-- [ {"result":65,"jsonrpc":"2.0","id":2} , {"result":68.28,"jsonrpc":"2.0","id":1} ]</figure>

When Applicative do arrives with GHC 8, we can take immediate advantage of this, and start using do-notation to write out remote applicative functors. In fact, we can interperse our usage of monads and applicative RPC, and the package will choose the best bundling it can for the specific strategy.

Summary

We have written a remote monad for JSON-RPC. The library automatically bundles inside send to attempt to amortize the cost of the remote procedure call. It simplifies making multiple requests, without resorting to specialized variants of send. These idea has been used before. For example, Haxl lead the charge of using the applicative bundling strategy, and Oleg implemented a remote monad in OCaml several years ago. And we’ve been using predecessors to remote-json for several years now. Feel free to try remote-json, and if you are adventurous, remote-monad. Or roll your own remote monad. Once you know the pattern, it’s quite straightforward!

In a future blog post, we will look at our JSON-RPC server.

Enjoy!

Justin Dawson and Andy Gill

Resources and Related Work Existing JSON-RPC packages Our Publications about the Remote Monad
  • A. Gill, N. Sculthorpe, J. Dawson, A. Eskilson, A. Farmer, M. Grebe, J. Rosenbluth, R. Scott, and J. Stanton, “The remote monad design pattern,” in Proceedings of the 8th ACM SIGPLAN Symposium on Haskell. New York, NY, USA: ACM, 2015, pp. 59–70.

Categories: Offsite Blogs

Including a "XXX_stub.h" file from another Haskelllibrary?

haskell-cafe - Mon, 02/08/2016 - 3:34pm
Hello -cafe! Let's say I have two Haskell libraries, `A` and `B`. `A` uses the FFI, `foreign export` to be precise, to make a Haskell function available to C land. This generates a "stub" C header file with a corresponding C function declaration. `B` has some C code in it and needs to include the stub header that was generated when compiling `A`, in order to call the function that I 'foreign export'ed in A. When I "naively" include the stub header file for the module in A that contains the 'foreign export' statement, inside one of the C files of the `B` library, the said header can't be found. Is what I want to do at all possible? If yes, how could I make this work? Thanks!
Categories: Offsite Discussion

[ANNOUNCE] GHC 8.0.1 release candidate 2

glasgow-user - Sun, 02/07/2016 - 8:13pm
Hello everyone, The GHC Team is very pleased to announce the second release candidate of the Glasgow Haskell Compiler 8.0.1 release. Source and binary distributions as well as the newly revised users guide and Haddock documentation can be found at http://downloads.haskell.org/~ghc/8.0.1-rc2/ This is the second in a series of release candidates leading up to the 8.0.1 release and fixes many of the issues reported in -rc1. These fixes include, * A re-rewrite of the pattern checker by George Karachalias. The new checker should have far more predictable performance characteristics while sacrificing minimal reasoning power. This should resolve a large number of the issues felt in -rc1. * Richard Eisenberg has been hammering out all manner of type-application- and TypeInType-related issues (#11335, #11416, #11405). There is still more work to do here, however (e.g. #11471). * Matthew Pickering has restored support for multi-clause pattern synonyms (#11367) * A latent bug
Categories: Offsite Discussion

New gtk2hs 0.12.4 release

gtk2hs - Wed, 11/21/2012 - 12:56pm

Thanks to John Lato and Duncan Coutts for the latest bugfix release! The latest packages should be buildable on GHC 7.6, and the cairo package should behave a bit nicer in ghci on Windows. Thanks to all!

~d

Categories: Incoming News