Skip to content
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

feat: add purity annotation #191

Merged
merged 184 commits into from
May 1, 2024
Merged

feat: add purity annotation #191

merged 184 commits into from
May 1, 2024

Conversation

bollu
Copy link
Collaborator

@bollu bollu commented Feb 28, 2024

Add a custom field into each Op that declares if its signature is pure or not. If it is pure, it returns a, and if impure, it returns IO a. The default signature object is pure.

@bollu bollu changed the title feat: add purity annotaiton feat: add purity annotation Feb 28, 2024
SSA/Core/Framework.lean Outdated Show resolved Hide resolved
@bollu bollu force-pushed the purity-annotation branch from db182e1 to 95e2030 Compare March 4, 2024 20:56
SSA/Core/ErasedContext.lean Outdated Show resolved Hide resolved
SSA/Core/Framework.lean Outdated Show resolved Hide resolved
SSA/Core/Framework.lean Outdated Show resolved Hide resolved
Copy link
Collaborator

@goens goens left a comment

Choose a reason for hiding this comment

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

Thanks @alexkeizer and @bollu for the heroic effort here! It's nice that you've also documented things well in this PR. Overall, I'm happy with it. I've left a few comments here that are small to address.

There's a bunch of TODO's introduced by this PR, and it's certainly not worth doing them all right now. It would be nice to have maybe an issue tracking the cleanup of this and all the TODO's, so we don't forget to do it afterwards?

If `m` is a `Functor`, but not a full `Monad`, then `e.toMonad m` should still be a functor too.
However, actually having these instances causes diamond problems with the aforementioned instances
implied by `Monad`. Thus, we just assume `m` is always a monad.
-/
Copy link
Collaborator

Choose a reason for hiding this comment

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

Fair enough. Why don't we just ask for the Monad m instance (ibid LawfulMonad) for the definition of toMonad then?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@goens principle of least privilege :) One can call toMonad even when m is not necessarily a monad. So, I'd rather not add a [Monad m] constraint on toMonad.

SSA/Core/EffectKind.lean Outdated Show resolved Hide resolved
SSA/Core/EffectKind.lean Show resolved Hide resolved
SSA/Core/ErasedContext.lean Show resolved Hide resolved
SSA/Core/Examples.lean Outdated Show resolved Hide resolved
SSA/Core/Framework.lean Show resolved Hide resolved
T.foldl (fun _ s a => insert ⟨_, a⟩ s) ∅

@[simp]
theorem HVector.vars_nil :
--TODO: find a name that better encapsulates that it's the *transitive* closure
Copy link
Collaborator

Choose a reason for hiding this comment

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

What about uses like you suggest below? The transitivity is not quite explicit, but uses does feel more transitive than vars.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@goens This is a good refactor, but to be consistent, we would need to change a lot of names of lemmas, theorems, and other definitions that use the vars terminology right now. I'd suggest doing this after.

SSA/Core/Framework.lean Outdated Show resolved Hide resolved
SSA/Core/Framework.lean Outdated Show resolved Hide resolved
SSA/Core/Framework.lean Outdated Show resolved Hide resolved
bollu and others added 4 commits April 22, 2024 15:32
@tobiasgrosser
Copy link
Collaborator

I think we should address #250 in this very PR, if possible, as it will minimize the diff of this PR quite a bit.

@alexkeizer
Copy link
Collaborator

I'm not sure we should block this PR on #250, since the solution is not uncontroversially clear (unless @bollu agrees with my counter-proposal)

@goens goens added this pull request to the merge queue May 1, 2024
Merged via the queue into main with commit d6c63e9 May 1, 2024
1 check passed
@goens goens deleted the purity-annotation branch May 1, 2024 15:55
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.

4 participants