I write about functional programming in Haskell and PureScript intermittently at http://blog.functorial.com
I’m continuing to finish up various tasks in the wake of the PureScript 0.9.1 release - updating the book, libraries and online services. I’m also hoping to start compiling a list of actively maintained PureScript projects, since it can be difficult for beginners to find the best examples.
We shipped the first release candidate for PureScript 0.9 yesterday, which means I’ll be spending time getting things like libraries, blog posts and tools updated, as well as fixing bugs. Hopefully we can have a stable release out by the end of the week. With the release looking more complete, I’m also looking forward to getting back to implementing interesting type system features. I started with programmable type errors yesterday, and I’m thinking about constraint kinds and a variant of functional dependencies as the next things to tackle.
I’m planning to go and hopefully talk again, and I’ll be taking part in the colocated (and free!) PureScript Conf as well.
I’m working on updating the Try PureScript website to work with the new 0.8 release, as well as adding more real world examples like canvas graphics and AJAX.
This is really cool. One question: what’s the best place to go for further depth on these topics? Is there a “taxonomy of type classes” (e.g. like Typeclassopedia) that covers all of these hierarchies (e.g. Comonad) in the same detail as the existing Typeclassopedia covers the basic ones (e.g. Functor, Applicative, Monad)?
I like this post for an application of comonads.
In general, I’m trying to understand the use cases of some of these classes myself. Of the “esoteric” ones, I’ve gotten the most experience with the Profunctor classes lately, after playing with profunctor lenses a bit.
I plan on extending this post with links to resources as I find them. The article is somewhat incomplete right now.
This week, I hope to get the PureScript 0.7.5 compiler release finished off, and for $work, I’m looking into Haskell’s wonderful inline-c package to integrate our internal Haskell packages with some C imaging libraries. This is my first time using Haskell’s FFI, and so far, it’s been a great experience.
I think this might be interesting, but I feel like I don’t know enough Haskell jargon to make sense of it.
Here’s the referenced PureScript implementation of the idea:
The idea is that your state is a big data structure. You use lenses to focus in and display certain parts, then use those lenses to update parts when events are triggered.
The lens connection is definitely elegant. I particularly like the (obvious once you see it) property of (profunctor) lenses that they give you free composition operators for anything which looks like p a b for some strong profunctor p.
p a b
The Traversal part was what really impressed me, however. OpticUI has captured the (type-safe!) essence of something like KnockoutJS in a few dozen lines.
I saw this comment and figured I could read the article and present a summary here. Turns out, I don’t know enough Haskell (specifically Lens) jargon either. My best guess is that this is an experimental alternative to React that handles state like Om. That means it has one top-level mutable state value, but individual components are only aware of their “local” state.
Yeah, I agree. Are the lenses they’re talking about the same ones that come with barbed wire, or are those lenses unrelated lenses?
I have never heard of barbed wire with respect to lenses. Is that a reference to Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire? I have not read that. The lenses in this post are van Laarhoven lenses, specifically the lens package.
The “Bananas, Lenses” paper is a naming collision; its lenses are called that because of the syntax the authors chose, and they’re unrelated to van Laarhoven lenses.
After failing miserably to implement anything practical with Elm, I’ve spent a bit of time researching PureScript. Unfortunately, while very tempting, it seems that all these projects (Elm, PureScript, GHCJS) are too new/rough/advanced for somebody without extensive FP experience. I don’t want to stick with CoffeeScript & Ramda but I might have to for the time being.
If you haven’t joined already, #purescript on FreeNode IRC is the best place to ask questions, and there is almost always someone around who can help.
It sounds (from your other comment) like you need something that compiles to JS. There’s PureScript with FRP libraries. There’s also pure JS stuff like NuclearJS that comes close to FRP even if might not be it in strict terms.
If you decide on PureScript, then depending on the flavor of FRP you want, you might also like
yes; right on, halogen, that’s the kind of thing i’m looking for, thanks!
yeah, this is what i’m tossing up between; things like PureScript and things like Elm.
it seems perhaps wiser to go with PureScript and join in with other libraries if i need it; with Elm I seem to be pretty married to the Elm environment completely.
For work, I hope to start gluing together some of the newer Haskell microservices I’ve been writing with some of our other infrastructure, which I’m quite excited about.
Outside of work, I’m hoping to get the 0.7 release of the PureScript compiler wrapped up this week, and start writing my second talk for LambdaConf. I’m hoping to get back into running outdoors as well, if the ridiculous weather cools off a bit.
What exactly is a “microservice?” A quick Google didn’t really bring back anything.
In my case, I’m using it to describe a service with a single, small responsibility: checking permissions, caching something, managing a resource on disk, whatever. The overall architecture is made up of several such services, communicating over HTTP. Some of them are written in Haskell, which has been a good way for me to use Haskell in a small way at work.
PureScript has forall! That’s super neat. Any other cool type cartwheels that PureScript can pull off?
Type classes, rank N types and extensible records/effects are the ones people usually care about. We also have a bunch of smaller features which make dealing with an expressive type system more pleasant, like scoped type variables and type wildcards.
It has row polymorphism which allows extensible records but also extensible effects.
Hopefully I will be able to wrap up the PureScript core libs documentation this week, and then get onto some more interesting things. Hopefully, I will be able to start thinking about generalizing rewrite rules in the optimizer.
I also hope to find some time to write my LambdaConf talks.
The PureScript library documentation is in need of attention, and since we recently added Markdown support to the generated docs, I plan to spend a good chunk of this week documenting the existing code. I also hope to find some time to work on integrating Pursuit with my new HTML documentation generator to create something a bit closer to the Haskell community’s Hackage/Haddocks.
For work, I hope to get my shiny new Haskell service deployed into our testing environment, and to do some performance and load testing. I’d also like to spend some time assessing React as a possible replacement for some client-side code.
React with PureScript or … ?
Probably TypeScript, but maybe both if I can get purescript-thermite up to an acceptable level of quality.
This weekend, I spent some time porting my TypeScript documentation tool to PureScript, and putting the resulting library on NPM. I have since discovered the excellent TypeDoc tool, which I have started using to document my TypeScript code. I think there is still some value in typescript-docs, especially since it seems a bit faster for large inputs, not having to rely on the TypeScript compiler to parse the source code, so I will continue to work on it. If nothing else, it might be interesting to reuse the parser to try to take advantage of TypeScript’s .d.ts files in the PureScript FFI.
Also, the PureScript bug backlog has been steadily growing, so I will spend some time squashing some bugs there.
At work, I hope to wrap up our third Haskell microservice, and start deploying that into production.
What are you using to build out the Haskell microservices?
The current one is built using Groundhog for database access and Servant for web services, both of which have been fantastic for my use case. I also wrote a little bit about using Haskell at work here previously.
At work, I’ll be spending some time getting a new service up and running using Postgres and Haskell, which has so far been a joy, using packages like Groundhog (database + migrations) and Servant (strongly-typed web services with documentation generation).
For !work, I plan to spend some time working on PureScript stuff, namely reimplementing the Pursuit search engine as a Haskell web service with a React front-end, and integrating some recent contributor work with Bower on our community server. If there’s time, I have a showcase project in the works for Haskell/PureScript, so I’ll be spending time on that.
This conference was excellent last year, and I can highly recommend it.
I hope to finish ripping out the old PureScript lexer and replacing it with the shiny new lexer from purescript-in-purescript, which has better support for optional indentation and comments.
If there’s time, I would like to start working on a small showcase project I have in mind for Haskell and PureScript.
I’ve also started working on a daily blog series: 24 Days of PureScript, in the style of Oliver Charles' wonderful 24 Days of Hackage.
I hope to get back to working on PureScript bugs this week. I would like to start thinking about building more PureScript tools for editors or a possible IDE.