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.
5 Likes
I can come, so I can share about the cookbook.
4 Likes
Hi! I’m new around here, but I’d like to attend. Is this open to anyone?
2 Likes
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.
5 Likes
It’s scheduled past midnight for me, but I’ll try to attend this one!
2 Likes
Cool!
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! 
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.
Pursuit:
- Searching for wildcard types.
- Didn’t know about
_. PR.
- Didn’t know about
- Add tags to packages.
- 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 -> Intin 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.
-
Smart keywords for searching in browser. For example, just type
- Better coupling with package sets
- Likely improved with new registry.
- Starsuit is a workaround for now.
Optimizations:
- 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:
3 Likes
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 
.
Here’s an ancient discussion on uncurrying from the time of ps-in-ps: https://github.com/purescript/purescript/issues/479. 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 . 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).
2 Likes
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.
3 Likes
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 , as there are cases where doing so will prevent unnecessary repeated evaluation of dictionary construction.
2 Likes