-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does withLabel need to have the type it does? #22
Comments
Yeah, I agree that Do you have any suggestions for what specific operations we could replace doIO with? One thing I can think of (but which would require a decent sized refactor) would be to create an AST for metric mutations and have data MetricOp
= GaugeAdd Gauge Double
| GaugeSubtract Gauge Double
| CounterIncrement Counter
| WithLabel Label Vector MetricOp
-- And so on...
class Monad m => MonadMonitor m where
doOp :: MetricOp -> m () We'd then move the logic that is currently in the public API into an interpreter and make the public API map to the corresponding value in the AST. addGauge :: MonadMonitor m => Gauge -> Double -> m ()
addGauge = doOp GaugeAdd
metricOpInterpreter :: MetricOp -> IO ()
metricOpInterpreter (GaugeAdd gauge value) = -- ... The |
I don't think
Fundamentally, everything boils down to mutating mutable references. I'll have a play with this when the open PR lands. I would like to explore this before a new release. |
We're trying to convert from I think @ocharles's suggested change would also allow us to use |
I see now we do have on problem, which is that @danclien do you have any code examples of what you'd like to write, but can't? |
Here's an example repo: https://github.com/danclien/prometheus-client-histogram-label We're trying to use I'm not sure this is the best approach, but it's an example of what we're trying to do at least. Hack:
Usage:
|
This is a work in progress and is very heavy inspired by fimad/prometheus-haskell#22 (comment)
The type of
withLabel
is:This type implies that once the
IO
action that uses the labelled metric is terminated, some clean up must happen. Yet if we actually consult the source ofwithLabel
, we haveNothing happens after
f
is called - there is no cleanup that has to happen. Thus it would be simpler to haveMy guess is that we have the type we have because we are forced into it by
doIO
. I finddoIO
a tad suspicious anyway, and think thatMonadMonitor
would likely be better if it actually had specific operations added, rather than a catch allliftIO
-like operation.What do you think?
The text was updated successfully, but these errors were encountered: