Replies: 1 comment 1 reply
-
|
You can have a look here for an attempt at something like that: https://github.com/tomjaguarpaw/ad/blob/master/Eff-Args/app/RoseMTL.hs#L85. Unfortunately I think it's not going to work.
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
I see, thank you. It doesn't seem like it's going to be straightforward. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello. I’ve been very excited by the design of
bluefin, especially its type-level machinery. In particular, I find it fascinating how it ensures scope safety by treating the set of type-level effects as the “s” in the usualST(i.e. a collection of skolem type variables).What I’d like to ask your opinion about is adding a generalization of the current
Effmonad, which I’m callingEffT. The idea is to generalize the definition ofEff, which is currently fixed asIO a, to something like:(Or perhaps the order of the type parameters
esandmwould be better swapped.)Here,
Emb mis a generalization ofIOE.This would allow the
bluefineffect system to be “stacked on top of” existingmtl-style monad ecosystems, improving interoperability. For example, if you want to use MegaParsec and you have a parser monadParser a, you could writeEffT es Parserand thus extend MegaParsec withbluefineffects. Additionally, this is also intended as a foundation for enabling future interoperability betweenheftiaandbluefin.However, I have two concerns:
Added complexity in interface types.
All of
bluefin's interfaces would gain an extramparameter, slightly undermining its current simplicity. I personally feel it would be quite a shame to confine the powerful type-level ideas inbluefintoIOonly without generalizing them. I intuitively feel that the generalized form is the more natural one.Potential performance degradation.
This might be mitigated by adding
INLINEpragmas to various functions and, if needed, providing separate interfaces specialized form = IO. Still, I’m not entirely confident we can make the performance fully match the pre-generalized version. If performance truly becomes an issue, there is always the option (though it would make maintenance a bit more cumbersome) of starting a completely separate module forEffT, independent of the existingbluefincodebase. So, I think we’ll probably be okay.Perhaps this idea has already been considered and dismissed for such reasons. I’d love to hear your thoughts.
I'd also be happy to help with the implementation, if that's of interest.
Beta Was this translation helpful? Give feedback.
All reactions