search

reflex-frp / reflex-ghci

Run GHCi from within a Reflex FRP application and interact with it using a functional reactive interface.
https://reflex-frp.org
BSD 3-Clause "New" or "Revised" License
38 stars 3 forks source link

Move ob thunks to reflex-ghci (or create a new tool) #15

Closed srid closed 4 years ago

srid commented 4 years ago

I had this idea. ob thunk is pretty tied to obelisk; its key feature of loading unpacked thunks to the ghci repl (ghcid and ghci) is very useful in non-reflex projects as well.

If reflex-ghci aims to be an alternative to ghcid, but with a more interesting UI, I think it would be cool to add thunks to the 'distinguishing features' list as well. If that's gonna lead to scope creep, perhaps this can all be done on top of reflex-ghci as a new tool (name: lingam? :-D), just as reflex-ghci itself is done on top of reflex-vty.

I could certainly use it for my Haskell project, without abusing cabal file (which gets tiresomely unwieldy beyond a point).

/cc @ali-abrar @3noch

kmicklas commented 4 years ago

I don't see what relation thunks have to GHCi. They'd be equally useful with any nix-based project. I do think it could be nice to have ob thunk as a standalone executable available in nixpkgs though.

3noch commented 4 years ago

You're absolutely right, but ob thunk should be its own standalone tool.

srid commented 4 years ago

ob thunk should be its own standalone tool.

Sure; but what about the ob run (ob repl) feature which interacts with (unpacked) thunks, and loads them in the ghcid session? I would think that would also be useful as a standalone tool (as a replacement for ghcid).

(I think my original request would have made more sense had this project been named reflex-ghcid).

3noch commented 4 years ago

Ah now I understand why you paired that with this project. I think that is yet a 3rd "featureset" which possibly deserves to be its own library to help tools like ghcid and reflex-ghci work with multi-package projects. However, that actually has nothing to do with thunks. It only cares about finding Haskell source and it just so happens that unpacked thunks contain Haskell source.

3noch commented 4 years ago

Thanks for clarifying BTW. I do think a good chunk of the "tech" in obelisk could be useful in other places. It's just a matter of doing the work to "pull them out" and then polish those things as their own standalone packages.

kmicklas commented 4 years ago

@srid Worth noting that multi-package GHC sessions is one of the Haskell GSOC projects this year. (@Ericson2314 is mentoring. :smile:)

Given the large amount of interest in having this feature in GHC I don't think it's worth investing more time in hacks like the Obelisk preprocessor.