search

turion / rhine

Haskell Functional Reactive Programming framework with type-level clocks
http://hackage.haskell.org/package/rhine
121 stars 21 forks source link

Question: Extra packages per backend vs. cabal flags #163

Closed turion closed 2 years ago

turion commented 2 years ago

Since now, rhine has gone the way of having one main library rhine and many small extra libraries rhine-some-backend, for each backend library that it connects to. I've been wondering whether it's cleverer to join them all in a single library, and use cabal flags to decide whether support for a specific backend would be pulled in. Does anyone have an opinion on this?

CC @miguel-negrao @jmatsushita

miguel-negrao commented 2 years ago

I don't have an opinion, whatever you think is best.

miguel-negrao commented 2 years ago

Btw, what would the backends be ? Do you mean dunai and essence-of-live-coding ?

turion commented 2 years ago

No, I meant external packages like gloss or terminal.

turion commented 2 years ago

Probably the question is more relevant for essence-of-live-coding where there are more backend libraries, see https://github.com/turion/essence-of-live-coding#setup-and-ghci-integration

jmatsushita commented 2 years ago

Hi @turion, I'm not quite sure what's the best pattern here. I guess right now, you would depend on rhine and rhine-gloss and that would give you the Rhine backend you want (would be a good addition I suppose to be able to pass-through the glut or glfw flag to gloss?).

With your suggested change we would be able to depend only on rhine and choose the backend based on a cabal flag.

From that point of view, I'm not so sure that it's a huge improvement and I'd be tempted to leave it as is and see if it becomes a problem or a requested feature in practice? There might be discoverability and documentation aspects to consider too...

turion commented 2 years ago

With your suggested change we would be able to depend only on rhine and choose the backend based on a cabal flag.

Yes, exactly.

From that point of view, I'm not so sure that it's a huge improvement and I'd be tempted to leave it as is and see if it becomes a problem or a requested feature in practice? There might be discoverability and documentation aspects to consider too...

Right. Also, testing is an issue because we'd have to test rhine with every combination of flags.

Ok, let's leave everything as it is right now.