No longer do we have to be amazed by ImplicitParams dynamic scoping behaviour. The reflection-based API suffers from the same scoping annoyances as the ImplicitParams one [1]. Additionally, we can now have multiple hidden clocks, e.g.:
f :: (HiddenClock domA, HiddenClock domB)
=> Signal domA Bool
-> Signal domB Int
-> Signal domB Int
which is something that didn't work when we used implicit parameters.
However, you do lose the convenience of ImplicitParams binding construct.
[1] The scoping issue:
ImplicitParams
With the ImplicitParams API, this works
f :: Signal dom a -> Clock dom gated -> Signal dom b
f x = withClockReset ... $
let rr = register undefined
in ... g ...
but the following gives an "Unbound implicit param" error:
f :: Signal dom a -> Clock dom gated -> Signal dom b
f x = withClockReset ... g
where rr = register undefined
g = ...
Reflection
With the reflection API, this works
f :: Signal dom a -> Clock dom gated -> Signal dom b
f x = exposeClockReset $
let rr = register undefined
in ... g ...
but the following gives an "No instance for Given (SomeClock domain)" error:
f :: Signal dom a -> Clock dom gated -> Signal dom b
f x = exposeClockReset g
where rr = register undefined
g = ...
No longer do we have to be amazed byTheImplicitParams
dynamic scoping behaviour.reflection
-based API suffers from the same scoping annoyances as theImplicitParams
one [1]. Additionally, we can now have multiple hidden clocks, e.g.:which is something that didn't work when we used implicit parameters.
However, you do lose the convenience of
ImplicitParams
binding construct.[1] The scoping issue:
ImplicitParams
With the
ImplicitParams
API, this worksbut the following gives an "Unbound implicit param" error:
Reflection
With the
reflection
API, this worksbut the following gives an "No instance for Given (SomeClock domain)" error: