The sliderScalar function takes three scalar values: the slider setting, which must be read and updated, and the low and high values of the range, which only need to be read. However, the type used for both is
(HasSetter ref a, HasGetter ref a) => ref
This means that we have to create (e.g.) IORef containers for the bounds, instead of just passing pure lo. This isn't an enormous problem -- we can just create new IORefs before calling sliderScalar and they'lll be GCed after the call -- but it's one more thing to remember, and the range references don't need the extra power.
I therefore suggest that the references work the same as in sliderScalarN, separating valueRef from rangeRef. The new signature of sliderScalar would thus be
sliderScalar
:: (HasSetter valueRef a, HasGetter valueRef a, HasGetter rangeRef a, Storable a, MonadIO m)
=> String -> ImGuiDataType -> valueRef -> rangeRef -> rangeRef -> String -> ImGuiSliderFlags -> m Bool
In fact, I think that the signature is the only change that would have to be made.
The
sliderScalarfunction takes three scalar values: the slider setting, which must be read and updated, and the low and high values of the range, which only need to be read. However, the type used for both isThis means that we have to create (e.g.)
IORefcontainers for the bounds, instead of just passingpure lo. This isn't an enormous problem -- we can just create newIORefs before callingsliderScalarand they'lll be GCed after the call -- but it's one more thing to remember, and the range references don't need the extra power.I therefore suggest that the references work the same as in
sliderScalarN, separatingvalueReffromrangeRef. The new signature ofsliderScalarwould thus beIn fact, I think that the signature is the only change that would have to be made.