Formalize the ProgressReporting Type #4335
Conversation
|
I'm not sure I see the attraction of this design, to be honest. I think we could instead see the tracking with files as a wrapper on top of the simpler |
soulomoon
force-pushed
the
soulomoon/formlization-of-ProgressReporting
branch
from
3b2e5d9
to
20b4304
Compare
|
Good suggestions @michaelpj , |
| -- ^ see Note [ProgressReporting API and InProgressState] | ||
| progressStop :: IO () | ||
| data ProgressReportingNoTrace m = ProgressReportingNoTrace | ||
| { progressUpdateI :: ProgressEvent -> m (), |
There was a problem hiding this comment.
You might not need to add name suffixes if you use DuplicateRecordFields?
There was a problem hiding this comment.
Nop, we have class function and data field collision. DuplicateRecordFields is not helpful here
There was a problem hiding this comment.
But maybe we can make it prefix with '_' and not export it.
| } | ||
|
|
||
| class ProgressReportingClass a where | ||
| type M a :: * -> * |
There was a problem hiding this comment.
I think I asked this before, but can everything just be in IO? The only place we use another monad is in inProgress, and I think we could also just provide that with IO and get people to use MonadUnliftIO to use it?
There was a problem hiding this comment.
Yes, we can turn them into IOs and save the m for type cleaness, but might introuce a bit runtime overhead?
|
Looks much better |
* master: Formalize the ProgressReporting Type (haskell#4335) fix future index time (haskell#4343) Cleanup disabled warnings (haskell#4341) Cleanup imports after CPP removal + few hlint fixes (haskell#4337)
follow up of #4205
This is intended to remove the useless
inProgresswhen tracking theinProgressStatefrom the outside.data ProgressStateTrackingType = ProgressStateInsideTracking | ProgressStateOutsideTrackingto distinguish the two type ofinProgressStatetracking.TProgressStateto related type location to mark what kind of tracking we used. Then we won't haveinProgressforProgressStateOutsideTracking