MonadMask Support

[timbess]

My MTL stack includes ExceptT and I want to leave the door open for StateT too, but UnliftIO doesn't support it. I poked around a bit and got it working by making versions of inSpan and bracketError that rely only on MonadMask instead

Would you accept a PR that adds a new version of inSpan that doesn't require UnliftIO?

Great project btw! Glad to see someone finally tackling this issue in Haskell.

[iand675]

I'd definitely accept a PR for this!

Ideally I think it'd be nice to have it as a separate package within the repo (maybe a util directory?) because I want to try to avoid adding new direct dependencies to hs-opentelemetry-api or hs-opentelemetry-sdk.

Also, for the reasons outlined here– I'd like to ensure that people opting in to tracing mtl stacks understand that there can be some subtle issues and maybe consider alternative approaches.

[timbess]

Awesome, I'll submit one soon then 👍

Sure, maybe something like hs-opentelemetry-masked?

Thanks for a link to some interesting discussion! I've actually read his FPComplete article before and I respectfully disagree with his argument (with regards to ExceptT at least). I'm glad you're open to at least supporting this style even if you don't prefer it though! I'm not a fan of libraries that don't support some behavior purely to stop the consumer from doing something they subjectively deem an anti-pattern. If it takes extra work to maintain or whatever, then sure, but people refusing to provide basic instances to control the way I choose to code really rubs me the wrong way.

Also, I'll also try to flesh out the B3 propagator if I have extra time. Again, great work on this library, so good to finally have some visibility into my Haskell services!

[iand675]

IIRC the instance comes from the exceptions library, so maybe hs-opentelemetry-util-exceptions?

I'm not a fan of libraries that don't support some behavior purely to stop the consumer from doing something they subjectively deem an anti-pattern. If it takes extra work to maintain or whatever, then sure, but people refusing to provide basic instances to control the way I choose to code really rubs me the wrong way.

Yeah, I understand. Ideally the hs-opentelemetry set of packages (especially the underlying hs-opentelemetry-api library) should be usable in any Haskell codebase due to the significant network effects that come from thorough instrumentation, so it'd be self-defeating to make it harder for people to use 😄. That being said, I don't want to cause subtle new issues crop up in people's instrumented code, so I just want to be conservative with the base offerings.

[timbess]

Sure, that makes sense to me 👍

[lf-]

I believe this was fixed by #21.