Skip to content

Eq and Ord instances for Prio queues #106

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

treeowl
Copy link
Collaborator

@treeowl treeowl commented Apr 18, 2023

  • Make the Eq and Ord instances for Prio queues compare the queues in fully sorted form—that is, as key-value maps. This seems to be the only way to make these instances make any real kind of sense.

  • Document the "nondeterministic" nature of Prio queues.

* Make the `Eq` and `Ord` instances for `Prio` queues compare the queues
  in fully sorted form—that is, as key-value maps. This seems to be the
  only way to make these instances make any real kind of sense.

* Document the "nondeterministic" nature of `Prio` queues.
@treeowl
Copy link
Collaborator Author

treeowl commented Apr 26, 2023

@konsumlamm Any comments?

Copy link
Collaborator

@konsumlamm konsumlamm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I don't have much time lately, I'll try to keep up with your PRs.

I'm a bit skeptical about requiring Ord a for Eq (MinPQueue k a). That would be a breaking change and many value types I can imagine don't necessarily have an Ord instance (although I can't think of many use cases for an Eq instance anyway...). I'd be fine with just documenting that the Eq instance is non-deterministic and recommending (==) `on` toAscList. However, then we also can't change the Ord instance, since they should be compatible.

Btw, please try to link related issues, like #78. Is this supposed to close #78?

@@ -128,7 +128,7 @@ pattern Empty = Internals.Empty
infixr 5 :<

-- | A bidirectional pattern synonym for working with the minimum view of a
-- 'MinPQueue'. Using @:<@ to construct a queue performs an insertion in
-- 'Prio.MinPQueue'. Using @:<@ to construct a queue performs an insertion in
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should have been 'MinQueue', no?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'll fix that.

Comment on lines +328 to +332
-- | \(O(n)\). @'mapKeysMonotonic' f q == 'Data.PQueue.Prio.Min.mapKeys' f q@,
-- but only works when @f@ is strictly monotonic.
-- /The precondition is not checked./
-- This function has better performance than 'Data.PQueue.Prio.Min.mapKeys'.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
-- | \(O(n)\). @'mapKeysMonotonic' f q == 'Data.PQueue.Prio.Min.mapKeys' f q@,
-- but only works when @f@ is strictly monotonic.
-- /The precondition is not checked./
-- This function has better performance than 'Data.PQueue.Prio.Min.mapKeys'.
-- | \(O(n)\). @'mapKeysMonotonic' f q == 'Data.PQueue.Prio.Min.mapKeys' f q@,
-- but only works when @f@ is strictly monotonic.
-- /The precondition is not checked./
-- This function has better performance than 'Data.PQueue.Prio.Min.mapKeys'.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What am I missing?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change is to remove the blank line, unfortunately the diff doesn't show this.

@treeowl
Copy link
Collaborator Author

treeowl commented Apr 26, 2023

I really want the Eq instance to actually mean something. I think the original idea, when it was (mistakenly) thought that insertBehind could be implemented efficiently, was that Eq would be based on the order elements come out of the queue, and merge would be nondeterministic. But since insertBehind was a failure, I think we really want to make Eq equality of queues-as-maps, with merges considered deterministic. It's fine to require Ord. Is the instance really useful? Maybe not very, but the current one is nonsense. Let's do this please.

@treeowl
Copy link
Collaborator Author

treeowl commented Apr 26, 2023

Yes this should close #78.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants