Small PureScript online meetup - 2020-07-06

I’m happy to announce yet another PS meetup. We want to run it on the next Monday at 19:00 UTC.

Please share the topics which you want to talk about.


I can come, so I can share about the cookbook.


Hi! I’m new around here, but I’d like to attend. Is this open to anyone?


Yep. Open to everyone.

I always like to hear about what we can do to improve the new user experience, so please join and share any feedback you have about that.


It’s scheduled past midnight for me, but I’ll try to attend this one!



Side note: the next one is going to be at 12:00 UTC so it will be a bit easier for you I think.

You probably know which of the latest lib / tool will be the topic which I want to bring to our ecosystem discovery corner… If not then stay tuned! :wink:

Oh, I’d like to join if I can make it. Where in cyberspace will this take place?

They’ll post a link to a Zoom meeting a few minutes before it begins.

1 Like

Ah cool, thanks Jordan!

1 Like

Please join the meetup here:

We are going to begin in 20 minutes.

1 Like

Notes from today’s meeting.


  • Searching for wildcard types.
    • Didn’t know about _. PR.
  • Add tags to packages.
    • For example #HTTP (affjax) and #Random (Gen).
    • Details TBD.
  • Searches with unknown number of parameters (issue).
  • Confusion with case sensitivity (issue).
  • Command line interface:
    • Proposal to build some sort of “language querying interface”.
    • Other options:
      • Smart keywords for searching in browser. For example, just type ps String -> Int in address bar.
      • Typed holes in IDE. That guide could be improved (for this use case), and moved to the docs repo.
      • Build a CLI tool that uses the Pursuit API.
  • Better coupling with package sets
    • Likely improved with new registry.
    • Starsuit is a workaround for now.


  • Areas to focus on:
    • Type class dictionaries has the greatest potential for improvement.
    • Uncurried functions are not a major concern.
  • Proposals
    • Graph reduction with GRIN
    • Compile-time constants. For example, a lot of JS code can be produced and run for generating constants on page load.

Spago Package Caching:

  • Could spago grab pre-compiled packages?
    • Similar to how TryPurescript serves pre-compiled JS.
  • Could there be a global spago cache for using the repl and running scripts?

Cookbook recipe requests:

  • Suggestion to look through Discourse / Reddit / Slack / StackOverflow for recipe request ideas.
  • SVG, Time, Websockets, Database / Selda, Concur

PS Project Demos:


There’s an issue open for this:

1 Like

Regarding optimization possibilities I would not say that the conclusion was “Uncurried functions are not a major concern.”.
I think that we can say that specialisation is more obvious and general (affecting all possible backend) optimization strategy.

Regarding uncurring I think that the conclusion was rather “it requires more experimentation”. Personally I think that it could be a huge performance boost on the V8 engine when measured properly and that (as @garyb suggested in the other thread) we should just look at other existing solutions and check how they perform.

1 Like

I think until some of the typeclass stuff is addressed, anything to do with currying is going to be a micro-optimisation in comparison for most code. There are endless discussions about this in the PS issues, and I’ve re-iterated this position on typeclasses being the biggest target many a time :smile:.

Here’s an ancient discussion on uncurrying from the time of ps-in-ps: As seen at the end there, there was/is a plugin that uncurries for rollup, and there was a branch of psc-bundle for quite a while where someone had implemented uncurrying in it, but I don’t remember ever seeing conclusive benchmark results about it being significantly better. I’m not saying it’s not better/worth having though! Just I don’t remember seeing a substantial improvement, yet everyone seems to be think currying is performance enemy #1.

Also of note, Firefox is (or was) about 2 orders of magnitude faster than v8 when it came to evaluating function heavy code in a micro benchmark setting. v8 is/was still faster in general, but it’s just a point that uncurrying would have an even smaller optimisation benefit there.

So yeah, I definitely agree with your first statement here :wink:. It might be good to fire up the uncurrying optimisers that work and do some real testing with them, although that will probably mean downgrading PS, etc. (certainly for the psc-bundle case, if that branch is even available anywhere anymore. It was in a fork, not the main PS repo, but the record of the PR for it will be there somewhere).


This is an anecdotal, but my opinion is that it’s a good “last-mile” optimization. I wrote halogen-vdom with curried functions originally and it was unusable. When I replaced everything with uncurried variations we reached acceptable performance. I don’t consider halogen-vdom to be a use case for the optimization though since I need to guarantee everything is uncurried.

I would like to see a comparison against a small runtime component that checks for function saturation, like what Elm does.

1 Like

Is there any prior art wrt optimizing type classes in PureScript?

I’ve heard of this optimization many times but I don’t think I’ve seen a proposal or proof of concept; is it only that no one has yet taken the time, or that it’s especially difficult, or that I’ve simply missed the relevant discussions?

1 Like

The optimization is common sub-expression elimination. I think it would be straightforward to do this on type-classes only, but the corefn annotations for type-class instantiations don’t propagate to the constructor wrapper functions that are actually called, so you don’t know locally which arguments are type class dictionaries and which aren’t.


Yeah, exactly that, CSE with it hoisting the dictionary constructions to the earliest point that they can be constructed also. That way currying can sometimes be a performance benefit too :smile:, as there are cases where doing so will prevent unnecessary repeated evaluation of dictionary construction.