Q: Signal or Pipe or something else?

Hello,

tl;dr When creating re-usable widgets with Concur Haskell, should I use Signals, Pipes, both, or something totally different (e.g. pulling the recursion into the parent widget)?

This is a question on the recommended way of developing reusable widgets with Concur. As a caveat, I am a complete beginner in haskell (going through Learn You a Haskell right now). I also do not intend to use Purescript at this time.

My journey started with reading the concur-documentation README, which was last updated with Signals information. I did not see any mention of pipes in there, and read through the Signal code.

When I went to look at examples, I saw that the Concur Haskell example uses Pipes. Following this, I found that Pipes were removed from the main Concur Haskell repo around the same time that Signals information was added to the documentation. On the other hand, the Concur Purescript examples use Signals. In all fairness, the concur documentation does state that examples are being provided in Purescript.

Doing a quick search, I couldn’t find code for either concept in the main Concur Haskell repo, though I did see pipes in the concur-pipes repo. On the other hand, I did find Signal in FRP.purs in Concur Purescript. Maybe these concepts already exist in Haskell?

I guess the point of all this is that I just am not sure how to proceed. I also haven’t been able to get concur-react-starter running yet (various compilation issues on both Windows and Linux). So I can’t just copy paste the examples and try to run them either.

I think this post has been rambly enough, so I’ll stop. Any pointers and guidance you can provide are greatly appreciated.

[ajnsit]

Well not quite. In my opinion, it’s perfectly fine to use recursion at any point, except in the narrow case where you end up writing a never ending widget (i.e. of the type forall a. Widget HTML a). So it’s perfectly fine writing a widget that asks the user to input a number, and then asks if they want to input more numbers, and finally returns an array of numbers. This widget may loop an indeterminate number of times, but the end goal is to return a final value.

Basically treat widget organisation the same way as function organisation. The more granular they are, the easier it is to compose them. And if you write a function which loops forever processing input and changing the display (for example, an event loop) then that function best be at the top level.

And Concur actually goes one step further and gives you the ability to compose never ending widgets in meaningful ways, as long as you understand it will only be a Consumer, and not a Producer of meaningful data. (PS: There are ways to get data out of a never ending widget as well. See remoteWidget for an example).

Composing never ending widgets works because parent widgets completely control the child widgets, and can remove them from the view at will irrespective of whether the widget ended.

So you can imagine a “Dashboard” type widget which displays some complex data and even allows complex user interaction to slice and dice the data, however never supplies any data back to the rest of the app. It may have a type signature like -dashboard :: CompanyData -> forall a. Widget HTML a.

You can have a separate widget called awaitDataChange that watches for changes to the company data and returns the changed data. Perhaps it shows a UI that allows the user to edit the data themselves, or gets it from a database hook or some other source. You can still compose that with the dashboard widget like so -

app data = do
  -- The dashboard widget will be removed as soon as new data comes in
  newData <- dashboard data <|> awaitDataChange
  -- Now we can just restart the dashboard widget with the new data
  app newData

The problem with Elm’s model is all the plumbing, AND the fact that all the widgets are forced to update/recurse in lock step at the top level. Concur has no such restriction.

[zakaluka]

Thanks for all your help so far @ajnsit. I’m hoping to spend some time this weekend working on a few proofs of concept. Will keep you apprised of the progress.