Cabal flag to control auto-labelling of threads

[jasagredo]

Having this cabal flag allows the user to, on-demand, auto-label the async threads, pointing to the place where the async task is spawned. The idea is that the user then can go to the code/dependency and add a meaningful label to that thread.

Using CPP makes it transparent for users that don't want to opt-in to this behavior.

My idea is for this PR to be merged after #163. The first commit in this branch is the same as in #163.

[simonmar]

I'm open to the idea of labelling the internal threads - we now have two PRs for that (#162 and #163, I slightly prefer #162). But I'm not keen on adding auto-labelling functionality via cabal flags and CPP. Could you do this using a wrapper package async-labelled instead? It could use the same module name Control.Concurrent.Async so client code doesn't have to change.

[phadej]

Could you do this using a wrapper package async-labelled instead

That won't be ergonomic. If there's some other pakcage using async, you would need go and change it's .cabal file to use async-labelled; so broadly speaking some code would need to be changed.

Compared to adding --constraint="async +debug-auto-label" to cabal build command.

[jasagredo]

I agree with @phadej. I think the functionality of auto labelling the threads is a very big win.

In terms of comparing #162 and #163, I think mine is more minimal as it labels internal threads. The other one does also label the threads the user spawns. That should usually be a task for the user who presumably would want different names for his actions.

[Yuras]

Would an alias work there? Like the following:

#ifdef DEBUG_AUTO_LABEL
importqualifiedGHC.Stack#elseimportqualifiedGHC.Exts#endif...#ifdef DEBUG_AUTO_LABEL
typeHasCallStack=GHC.Stack.HasCallStack#elsetypeHasCallStack=()::GHC.Exts.Constraint#endif

That way one won't need to put ifdef in every single type signature.

[jasagredo]

Sure thing. I prioritized being explicit everywhere but what you suggest sounds good to me too.

[jasagredo]

I'm not sure if the suggested code works for as far back as 7.0.1 which is the one with base 4.3, and I don't know how I could test it or even if I can install such old versions still.

In particular it seems I need LANGUAGE ConstraintKinds and that one is available since 7.4.1, so probably not. But is it the case that the rest of the file does compile with such old compilers?

[simonmar]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO. If we merge this PR it has to be purely opt-in, no impact on the APIs or perf characteristics when the flag is off.

Also if you wouldn't mind rebasing as I've fixed the CI configs.

[jasagredo]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

[simonmar]

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

How about

#ifdef DEBUG_AUTO_LABEL
#define CALLSTACK HasCallStack =>
#else
#define CALLSTACK {- nothing -}
#endif

Slightly less horrible than #ifdef everywhere?

[jasagredo]

I implemented the suggestion, it indeed succesfully hides the HasCallStack from the Haddocks.

[jasagredo]

Having this cabal flag allows the user to, on-demand, auto-label the async threads, pointing to the place where the async task is spawned. The idea is that the user then can go to the code/dependency and add a meaningful label to that thread.

Using CPP makes it transparent for users that don't want to opt-in to this behavior.

My idea is for this PR to be merged after #163. The first commit in this branch is the same as in #163.

[simonmar]

I'm open to the idea of labelling the internal threads - we now have two PRs for that (#162 and #163, I slightly prefer #162). But I'm not keen on adding auto-labelling functionality via cabal flags and CPP. Could you do this using a wrapper package async-labelled instead? It could use the same module name Control.Concurrent.Async so client code doesn't have to change.

[phadej]

Could you do this using a wrapper package async-labelled instead

That won't be ergonomic. If there's some other pakcage using async, you would need go and change it's .cabal file to use async-labelled; so broadly speaking some code would need to be changed.

Compared to adding --constraint="async +debug-auto-label" to cabal build command.

[jasagredo]

I agree with @phadej. I think the functionality of auto labelling the threads is a very big win.

In terms of comparing #162 and #163, I think mine is more minimal as it labels internal threads. The other one does also label the threads the user spawns. That should usually be a task for the user who presumably would want different names for his actions.

[Yuras]

Would an alias work there? Like the following:

#ifdef DEBUG_AUTO_LABEL
importqualifiedGHC.Stack#elseimportqualifiedGHC.Exts#endif...#ifdef DEBUG_AUTO_LABEL
typeHasCallStack=GHC.Stack.HasCallStack#elsetypeHasCallStack=()::GHC.Exts.Constraint#endif

That way one won't need to put ifdef in every single type signature.

[jasagredo]

Sure thing. I prioritized being explicit everywhere but what you suggest sounds good to me too.

[jasagredo]

I'm not sure if the suggested code works for as far back as 7.0.1 which is the one with base 4.3, and I don't know how I could test it or even if I can install such old versions still.

In particular it seems I need LANGUAGE ConstraintKinds and that one is available since 7.4.1, so probably not. But is it the case that the rest of the file does compile with such old compilers?

[simonmar]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO. If we merge this PR it has to be purely opt-in, no impact on the APIs or perf characteristics when the flag is off.

Also if you wouldn't mind rebasing as I've fixed the CI configs.

[jasagredo]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

[simonmar]

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

How about

#ifdef DEBUG_AUTO_LABEL
#define CALLSTACK HasCallStack =>
#else
#define CALLSTACK {- nothing -}
#endif

Slightly less horrible than #ifdef everywhere?

[jasagredo]

I implemented the suggestion, it indeed succesfully hides the HasCallStack from the Haddocks.

[jasagredo]

Having this cabal flag allows the user to, on-demand, auto-label the async threads, pointing to the place where the async task is spawned. The idea is that the user then can go to the code/dependency and add a meaningful label to that thread.

Using CPP makes it transparent for users that don't want to opt-in to this behavior.

My idea is for this PR to be merged after #163. The first commit in this branch is the same as in #163.

[simonmar]

I'm open to the idea of labelling the internal threads - we now have two PRs for that (#162 and #163, I slightly prefer #162). But I'm not keen on adding auto-labelling functionality via cabal flags and CPP. Could you do this using a wrapper package async-labelled instead? It could use the same module name Control.Concurrent.Async so client code doesn't have to change.

[phadej]

Could you do this using a wrapper package async-labelled instead

That won't be ergonomic. If there's some other pakcage using async, you would need go and change it's .cabal file to use async-labelled; so broadly speaking some code would need to be changed.

Compared to adding --constraint="async +debug-auto-label" to cabal build command.

[jasagredo]

I agree with @phadej. I think the functionality of auto labelling the threads is a very big win.

In terms of comparing #162 and #163, I think mine is more minimal as it labels internal threads. The other one does also label the threads the user spawns. That should usually be a task for the user who presumably would want different names for his actions.

[Yuras]

Would an alias work there? Like the following:

#ifdef DEBUG_AUTO_LABEL
importqualifiedGHC.Stack#elseimportqualifiedGHC.Exts#endif...#ifdef DEBUG_AUTO_LABEL
typeHasCallStack=GHC.Stack.HasCallStack#elsetypeHasCallStack=()::GHC.Exts.Constraint#endif

That way one won't need to put ifdef in every single type signature.

[jasagredo]

Sure thing. I prioritized being explicit everywhere but what you suggest sounds good to me too.

[jasagredo]

I'm not sure if the suggested code works for as far back as 7.0.1 which is the one with base 4.3, and I don't know how I could test it or even if I can install such old versions still.

In particular it seems I need LANGUAGE ConstraintKinds and that one is available since 7.4.1, so probably not. But is it the case that the rest of the file does compile with such old compilers?

[simonmar]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO. If we merge this PR it has to be purely opt-in, no impact on the APIs or perf characteristics when the flag is off.

Also if you wouldn't mind rebasing as I've fixed the CI configs.

[jasagredo]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

[simonmar]

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

How about

#ifdef DEBUG_AUTO_LABEL
#define CALLSTACK HasCallStack =>
#else
#define CALLSTACK {- nothing -}
#endif

Slightly less horrible than #ifdef everywhere?

[jasagredo]

I implemented the suggestion, it indeed succesfully hides the HasCallStack from the Haddocks.

[jasagredo]

Having this cabal flag allows the user to, on-demand, auto-label the async threads, pointing to the place where the async task is spawned. The idea is that the user then can go to the code/dependency and add a meaningful label to that thread.

Using CPP makes it transparent for users that don't want to opt-in to this behavior.

My idea is for this PR to be merged after #163. The first commit in this branch is the same as in #163.

[simonmar]

I'm open to the idea of labelling the internal threads - we now have two PRs for that (#162 and #163, I slightly prefer #162). But I'm not keen on adding auto-labelling functionality via cabal flags and CPP. Could you do this using a wrapper package async-labelled instead? It could use the same module name Control.Concurrent.Async so client code doesn't have to change.

[phadej]

Could you do this using a wrapper package async-labelled instead

That won't be ergonomic. If there's some other pakcage using async, you would need go and change it's .cabal file to use async-labelled; so broadly speaking some code would need to be changed.

Compared to adding --constraint="async +debug-auto-label" to cabal build command.

[jasagredo]

I agree with @phadej. I think the functionality of auto labelling the threads is a very big win.

In terms of comparing #162 and #163, I think mine is more minimal as it labels internal threads. The other one does also label the threads the user spawns. That should usually be a task for the user who presumably would want different names for his actions.

[Yuras]

Would an alias work there? Like the following:

#ifdef DEBUG_AUTO_LABEL
importqualifiedGHC.Stack#elseimportqualifiedGHC.Exts#endif...#ifdef DEBUG_AUTO_LABEL
typeHasCallStack=GHC.Stack.HasCallStack#elsetypeHasCallStack=()::GHC.Exts.Constraint#endif

That way one won't need to put ifdef in every single type signature.

[jasagredo]

Sure thing. I prioritized being explicit everywhere but what you suggest sounds good to me too.

[jasagredo]

I'm not sure if the suggested code works for as far back as 7.0.1 which is the one with base 4.3, and I don't know how I could test it or even if I can install such old versions still.

In particular it seems I need LANGUAGE ConstraintKinds and that one is available since 7.4.1, so probably not. But is it the case that the rest of the file does compile with such old compilers?

[simonmar]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO. If we merge this PR it has to be purely opt-in, no impact on the APIs or perf characteristics when the flag is off.

Also if you wouldn't mind rebasing as I've fixed the CI configs.

[jasagredo]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

[simonmar]

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

How about

#ifdef DEBUG_AUTO_LABEL
#define CALLSTACK HasCallStack =>
#else
#define CALLSTACK {- nothing -}
#endif

Slightly less horrible than #ifdef everywhere?

[jasagredo]

I implemented the suggestion, it indeed succesfully hides the HasCallStack from the Haddocks.

[jasagredo]

Having this cabal flag allows the user to, on-demand, auto-label the async threads, pointing to the place where the async task is spawned. The idea is that the user then can go to the code/dependency and add a meaningful label to that thread.

Using CPP makes it transparent for users that don't want to opt-in to this behavior.

My idea is for this PR to be merged after #163. The first commit in this branch is the same as in #163.

[simonmar]

I'm open to the idea of labelling the internal threads - we now have two PRs for that (#162 and #163, I slightly prefer #162). But I'm not keen on adding auto-labelling functionality via cabal flags and CPP. Could you do this using a wrapper package async-labelled instead? It could use the same module name Control.Concurrent.Async so client code doesn't have to change.

[phadej]

Could you do this using a wrapper package async-labelled instead

That won't be ergonomic. If there's some other pakcage using async, you would need go and change it's .cabal file to use async-labelled; so broadly speaking some code would need to be changed.

Compared to adding --constraint="async +debug-auto-label" to cabal build command.

[jasagredo]

I agree with @phadej. I think the functionality of auto labelling the threads is a very big win.

In terms of comparing #162 and #163, I think mine is more minimal as it labels internal threads. The other one does also label the threads the user spawns. That should usually be a task for the user who presumably would want different names for his actions.

[Yuras]

Would an alias work there? Like the following:

#ifdef DEBUG_AUTO_LABEL
importqualifiedGHC.Stack#elseimportqualifiedGHC.Exts#endif...#ifdef DEBUG_AUTO_LABEL
typeHasCallStack=GHC.Stack.HasCallStack#elsetypeHasCallStack=()::GHC.Exts.Constraint#endif

That way one won't need to put ifdef in every single type signature.

[jasagredo]

Sure thing. I prioritized being explicit everywhere but what you suggest sounds good to me too.

[jasagredo]

I'm not sure if the suggested code works for as far back as 7.0.1 which is the one with base 4.3, and I don't know how I could test it or even if I can install such old versions still.

In particular it seems I need LANGUAGE ConstraintKinds and that one is available since 7.4.1, so probably not. But is it the case that the rest of the file does compile with such old compilers?

[simonmar]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO. If we merge this PR it has to be purely opt-in, no impact on the APIs or perf characteristics when the flag is off.

Also if you wouldn't mind rebasing as I've fixed the CI configs.

[jasagredo]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

[simonmar]

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

How about

#ifdef DEBUG_AUTO_LABEL
#define CALLSTACK HasCallStack =>
#else
#define CALLSTACK {- nothing -}
#endif

Slightly less horrible than #ifdef everywhere?

[jasagredo]

I implemented the suggestion, it indeed succesfully hides the HasCallStack from the Haddocks.

[jasagredo]

Having this cabal flag allows the user to, on-demand, auto-label the async threads, pointing to the place where the async task is spawned. The idea is that the user then can go to the code/dependency and add a meaningful label to that thread.

Using CPP makes it transparent for users that don't want to opt-in to this behavior.

My idea is for this PR to be merged after #163. The first commit in this branch is the same as in #163.

[simonmar]

I'm open to the idea of labelling the internal threads - we now have two PRs for that (#162 and #163, I slightly prefer #162). But I'm not keen on adding auto-labelling functionality via cabal flags and CPP. Could you do this using a wrapper package async-labelled instead? It could use the same module name Control.Concurrent.Async so client code doesn't have to change.

[phadej]

Could you do this using a wrapper package async-labelled instead

That won't be ergonomic. If there's some other pakcage using async, you would need go and change it's .cabal file to use async-labelled; so broadly speaking some code would need to be changed.

Compared to adding --constraint="async +debug-auto-label" to cabal build command.

[jasagredo]

I agree with @phadej. I think the functionality of auto labelling the threads is a very big win.

In terms of comparing #162 and #163, I think mine is more minimal as it labels internal threads. The other one does also label the threads the user spawns. That should usually be a task for the user who presumably would want different names for his actions.

[Yuras]

Would an alias work there? Like the following:

#ifdef DEBUG_AUTO_LABEL
importqualifiedGHC.Stack#elseimportqualifiedGHC.Exts#endif...#ifdef DEBUG_AUTO_LABEL
typeHasCallStack=GHC.Stack.HasCallStack#elsetypeHasCallStack=()::GHC.Exts.Constraint#endif

That way one won't need to put ifdef in every single type signature.

[jasagredo]

Sure thing. I prioritized being explicit everywhere but what you suggest sounds good to me too.

[jasagredo]

I'm not sure if the suggested code works for as far back as 7.0.1 which is the one with base 4.3, and I don't know how I could test it or even if I can install such old versions still.

In particular it seems I need LANGUAGE ConstraintKinds and that one is available since 7.4.1, so probably not. But is it the case that the rest of the file does compile with such old compilers?

[simonmar]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO. If we merge this PR it has to be purely opt-in, no impact on the APIs or perf characteristics when the flag is off.

Also if you wouldn't mind rebasing as I've fixed the CI configs.

[jasagredo]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

[simonmar]

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

How about

#ifdef DEBUG_AUTO_LABEL
#define CALLSTACK HasCallStack =>
#else
#define CALLSTACK {- nothing -}
#endif

Slightly less horrible than #ifdef everywhere?

[jasagredo]

I implemented the suggestion, it indeed succesfully hides the HasCallStack from the Haddocks.

[jasagredo]

Having this cabal flag allows the user to, on-demand, auto-label the async threads, pointing to the place where the async task is spawned. The idea is that the user then can go to the code/dependency and add a meaningful label to that thread.

Using CPP makes it transparent for users that don't want to opt-in to this behavior.

My idea is for this PR to be merged after #163. The first commit in this branch is the same as in #163.

[simonmar]

I'm open to the idea of labelling the internal threads - we now have two PRs for that (#162 and #163, I slightly prefer #162). But I'm not keen on adding auto-labelling functionality via cabal flags and CPP. Could you do this using a wrapper package async-labelled instead? It could use the same module name Control.Concurrent.Async so client code doesn't have to change.

[phadej]

Could you do this using a wrapper package async-labelled instead

That won't be ergonomic. If there's some other pakcage using async, you would need go and change it's .cabal file to use async-labelled; so broadly speaking some code would need to be changed.

Compared to adding --constraint="async +debug-auto-label" to cabal build command.

[jasagredo]

I agree with @phadej. I think the functionality of auto labelling the threads is a very big win.

In terms of comparing #162 and #163, I think mine is more minimal as it labels internal threads. The other one does also label the threads the user spawns. That should usually be a task for the user who presumably would want different names for his actions.

[Yuras]

Would an alias work there? Like the following:

#ifdef DEBUG_AUTO_LABEL
importqualifiedGHC.Stack#elseimportqualifiedGHC.Exts#endif...#ifdef DEBUG_AUTO_LABEL
typeHasCallStack=GHC.Stack.HasCallStack#elsetypeHasCallStack=()::GHC.Exts.Constraint#endif

That way one won't need to put ifdef in every single type signature.

[jasagredo]

Sure thing. I prioritized being explicit everywhere but what you suggest sounds good to me too.

[jasagredo]

I'm not sure if the suggested code works for as far back as 7.0.1 which is the one with base 4.3, and I don't know how I could test it or even if I can install such old versions still.

In particular it seems I need LANGUAGE ConstraintKinds and that one is available since 7.4.1, so probably not. But is it the case that the rest of the file does compile with such old compilers?

[simonmar]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO. If we merge this PR it has to be purely opt-in, no impact on the APIs or perf characteristics when the flag is off.

Also if you wouldn't mind rebasing as I've fixed the CI configs.

[jasagredo]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

[simonmar]

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

How about

#ifdef DEBUG_AUTO_LABEL
#define CALLSTACK HasCallStack =>
#else
#define CALLSTACK {- nothing -}
#endif

Slightly less horrible than #ifdef everywhere?

[jasagredo]

I implemented the suggestion, it indeed succesfully hides the HasCallStack from the Haddocks.

[jasagredo]

Having this cabal flag allows the user to, on-demand, auto-label the async threads, pointing to the place where the async task is spawned. The idea is that the user then can go to the code/dependency and add a meaningful label to that thread.

Using CPP makes it transparent for users that don't want to opt-in to this behavior.

My idea is for this PR to be merged after #163. The first commit in this branch is the same as in #163.

[simonmar]

I'm open to the idea of labelling the internal threads - we now have two PRs for that (#162 and #163, I slightly prefer #162). But I'm not keen on adding auto-labelling functionality via cabal flags and CPP. Could you do this using a wrapper package async-labelled instead? It could use the same module name Control.Concurrent.Async so client code doesn't have to change.

[phadej]

Could you do this using a wrapper package async-labelled instead

That won't be ergonomic. If there's some other pakcage using async, you would need go and change it's .cabal file to use async-labelled; so broadly speaking some code would need to be changed.

Compared to adding --constraint="async +debug-auto-label" to cabal build command.

[jasagredo]

I agree with @phadej. I think the functionality of auto labelling the threads is a very big win.

In terms of comparing #162 and #163, I think mine is more minimal as it labels internal threads. The other one does also label the threads the user spawns. That should usually be a task for the user who presumably would want different names for his actions.

[Yuras]

Would an alias work there? Like the following:

#ifdef DEBUG_AUTO_LABEL
importqualifiedGHC.Stack#elseimportqualifiedGHC.Exts#endif...#ifdef DEBUG_AUTO_LABEL
typeHasCallStack=GHC.Stack.HasCallStack#elsetypeHasCallStack=()::GHC.Exts.Constraint#endif

That way one won't need to put ifdef in every single type signature.

[jasagredo]

Sure thing. I prioritized being explicit everywhere but what you suggest sounds good to me too.

[jasagredo]

I'm not sure if the suggested code works for as far back as 7.0.1 which is the one with base 4.3, and I don't know how I could test it or even if I can install such old versions still.

In particular it seems I need LANGUAGE ConstraintKinds and that one is available since 7.4.1, so probably not. But is it the case that the rest of the file does compile with such old compilers?

[simonmar]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO. If we merge this PR it has to be purely opt-in, no impact on the APIs or perf characteristics when the flag is off.

Also if you wouldn't mind rebasing as I've fixed the CI configs.

[jasagredo]

The DebugCallStack stuff appears in the Haddocks, which is too invasive IMO

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

[simonmar]

Hiding it from the haddocks sounds like a very reasonable ask, but honstly I don't really know how we could achieve that without modifying the file a lot (like the previous version did, I could revert back to that other version but then there are more CPPs everywhere)

How about

#ifdef DEBUG_AUTO_LABEL
#define CALLSTACK HasCallStack =>
#else
#define CALLSTACK {- nothing -}
#endif

Slightly less horrible than #ifdef everywhere?

[jasagredo]

I implemented the suggestion, it indeed succesfully hides the HasCallStack from the Haddocks.