WAC2021 camera-ready paper

Hey all,

The PureScript paper I’ll be presenting at WAC2021 has been submitted in its camera-ready format. Here is a draft: https://meeshkan-public-assets.s3-eu-west-1.amazonaws.com/wac2021/final.pdf. It covers:

  • Events and behaviors
  • Cofree comonads
  • Existential types
  • Linear types
  • Type-level lenses
  • Indexed binds
  • Inductive types

As I was putting it together, I was using this for unit tests which outputs this in case anyone wants to reference the concepts in code/sound.


In the 1.1 example, there’s a naming mismatch between main and myEvent, and with that fixed, there’s another show/log type mismatch preventing compilation. Here’s a working version:

main :: Effect Unit
main = do
  unsubscribe <- subscribe (makeEvent \k -> do
    k "hello"
    pure $ pure unit) log


I think that example is pretty tough to follow (especially for folks new to FP) without providing the signatures of subscribe and makeEvent. It may be most clear and concise to replace makeEvent with Event (although it looks like that newtype constructor is not exported).

I’m still confused about how that event initially fires. The terminology is a bit ambiguous where “event” either means the collection of things occurring, or one of those occurances. I’m guessing makeEvent actually creates an event “collection” that’s pre-populated with the first event “occurrence”.

Another version that might be even clearer for beginners is the following:

main :: Effect Unit
main = do
  { event, push } <- create
  stopLog <- subscribe event log
  push "hi"
  stopLogLen <- subscribe event (logShow <<< length)
  push "fish"
  push "banana"
  push "bye"


Some projects, like Elm, make FRP primitives first-class citizens via the Signal type, which functions as an application-wide event bus.

Not sure if that’s still the case: https://elm-lang.org/news/farewell-to-frp

Anyway, looking forward to reading through the rest of your paper. I plan to eventually make a web-bluetooth wrapper in PS, and will likely build on some of the work you’ve done here with web-audio.


Thanks @milesfrain !

I’ve made the changes you proposed in the example - not sure how that slipped through (I have a document where I check the compilation) - it must have been when I was editing the paper. It’d be so cool if LaTeX supported compiling inline PS snippets - perhaps it already does through some toolchain. We did a lot of this with the LilyPond project to support musicology texts, and it made it easy to avoid compilation errors.

I’ve added the types of subscribe and makeEvent as you recommend - hopefully that will make it more readable. I agree that it is difficult to follow. It is a tough balancing act, as the reviewers of the paper noted, even in the favorable reviews, that the examples were too expansive. In making them terse, I likely swung too far to the other end of the pendulum.

I’m still confused about how that event initially fires.

The implementation of subscribe is:

subscribe ::
  forall r a.
  Event a ->
  (a -> Effect r) ->
  Effect (Effect Unit)
subscribe (Event e) k = e (void <<< k)

All it does is pass the function k to the event constructor. In the example above, log is k and is fed "hello".

The term event is indeed ambiguous. In the case of the Event type, it means “a collection of things occurring.” In common parlance, though, it usually means “one of those occurances”. It may be clearer if the name of the type were Events. For example, when talking about meteorological events (ie El Niño), a single El Niño is called “an El Niño event” where as the ensemble is referred to as “events”, but El Niño itself is never referred to as an event.

Another version that might be even clearer for beginners is the following:

This is really nice. I’ll see if there’s a good spot to work it into the paper.

Not sure if that’s still the case: farewell-to-frp.

Yikes! Shows you how much I follow that project… I have changed the language to past-tense to reflect that this is no longer the case.

I hope you enjoy the paper! The most fun part, and what I’ll spend most of my time presenting at the actual conference, are the examples. Just yesterday I put together this in a few minutes & threw it into the examples folder. I find that in general, the library is easier to use and more expressive than its antecedent purescript-audio-behaviors.