Open jmatsushita opened 2 years ago
Hi :)
Yes, fsnotify
is a great idea! I was wondering about something like that in https://github.com/turion/rhine/issues/145 as well. I won't get around implementing anything like that any time soon, but I'll definitely welcome and review PRs :) It should be like rhine-terminal
: A separate library with dependencies on rhine
and hfsnotify
implementing one clock type and Clock
instance. Bonus points for an example application and tests.
There could definitely be brick
or other terminal library backends. Also, yes, graphics and audio lend themselves well to that. Databases I'm not so sure about. When would a database clock tick? I could imagine clocks for message buses like Kafka, Rabbitmq, etc. though! It would also be cool to have a parametric clock for https://hackage.haskell.org/package/servant, since type level annotations are used there as well to split up the control flow into components. And when we go into ghcjs
or another JS compiler, we could add backends that connect to DOM manipulation events and write reactive frontends with rhine
! See https://github.com/fphh/rhine-ghcjs for an early prototype that was developed at Haskell At Leipzig 5 years ago.
Hi @turion
Hope you're well! I'm building a bit further up my more involved example with
rhine-terminal
and I find myself wanting to play with file change notifications and specificallyfsnotify
https://github.com/haskell-fswatch/hfsnotify.This makes me wonder, should there be
rhine-fsnotify
backend? Or would that maybe fit better as a source or a clock rather than a backend? It also makes me wonder, what do you envision as possible backends for rhine? I suppose graphics and audio backends make sense, maybe something more involved thanrhine-terminal
withbrick
for instance? Any other ideas that you might want to share? I'm wondering about database backends for instance too.Cheers,
Jun