Improve the default BootTidal.hs

[yaxu]

It would be good to document it a bit more, switching from the old startTidal function to the more flexible startStream to make it easier for people to add new targets, etc (like in this situation).

[ejconlon]

Hi @yaxu - Just went through some Tidal Club videos and I'm getting Tidal set up now! I set up my repo as a Stack project and had to make a custom BootTidal.hs to make things gel. For various reasons, I did not have immediate success copying the latest version from this repo, so I have some thoughts on how to make this part better:

My primary suggestion is to put as little as possible in the boot file. With more functions in real Haskell files you get the benefits of CI + Haddock. The primary problem here is that the functions in the boot file are essentially partial applications of library functions with some in-scope tidal :: Stream value that is initialized at the top of the file. At first I tried ImplicitParams to thread this value through, but it did not work very well in ghci. What finally worked for me was creating a nullary typeclass class Tidally where tidal :: Stream with an orphan instance in the boot file instance Tidally where tidal = tidalInst where tidalInst <- startTidal ... above. Finally, I put the Tidally typeclass and all the other functions into a project Prelude as part of a normal Haskell library.

You can see my boot file and my prelude. Please let me know what you think - I would be happy to contribute a PR if you like this approach.

[yaxu]

Hi @ejconlon, this looks good! I'm a bit unsure about the mechanics of this, how a nullary typeclass works and exactly the tidal is in scope. Can you see any drawbacks, e.g. in terms of reduced flexibility? Would this be a breaking change for some people?

In terms of moving UI definitions into a library, that's great. I wouldn't necessarily agree that there should be as little as possible in the boot file. On one hand yes it's great to put as much as possible in the haskell modules. However if the boot file works as a configuration file, I think it makes sense for it to have documented, explicit configuration in there, rather than relying on defaults - just because it's easier to edit a configuration than to create one from scratch.

Otherwise, a PR would be appreciated yes!

[ejconlon]

Can you see any drawbacks, e.g. in terms of reduced flexibility? Would this be a breaking change for some people?

I do not believe either of those are a concern. If people want to keep their existing boot file, it will still work.