You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently dtrace leans on it's underlying effect for stack safety, which works ok for effects like IO that provide it but even IO is inadequate for dtrace needs as even for map/ap operations, we need that suspension because of our Kleisli-like nature (with the TC => F[?] that represents a span). So we use a bunch of hacks which generally "work" but only with a bunch of implicit constraints. I labeled this an enhancement but its really fixing an underlying design flaw.
The text was updated successfully, but these errors were encountered:
Currently dtrace leans on it's underlying effect for stack safety, which works ok for effects like IO that provide it but even IO is inadequate for dtrace needs as even for map/ap operations, we need that suspension because of our Kleisli-like nature (with the TC => F[?] that represents a span). So we use a bunch of hacks which generally "work" but only with a bunch of implicit constraints. I labeled this an enhancement but its really fixing an underlying design flaw.
The text was updated successfully, but these errors were encountered: