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

Generalize utility functions previously used for a single purpose #34

Merged
merged 10 commits into from
Aug 14, 2024

Conversation

Equilibris
Copy link
Collaborator

@Equilibris Equilibris commented Jul 25, 2024

Make mkConstructors and getExpectedType more versatile, this is done by extraction constants and turning them into arguments. This is done so they can be reused later at other points where a similar functionality is wanted.

This should in practice be non-functional in the greater context of the code, but it allows for these functions that can be hooked into for more fine-grained control without requiring more boilerplate code.

@Equilibris Equilibris requested a review from alexkeizer as a code owner July 25, 2024 09:45
@alexkeizer
Copy link
Owner

Please give this PR a more descriptive name, and write PR description. Also, when stacking PRs it's best to keep this one in draft mode, and only request a review here after the other one gets merged, to avoid double reviewing the same code

@alexkeizer alexkeizer marked this pull request as draft July 26, 2024 12:07
@Equilibris Equilibris changed the title Codef 2 Generalize utility functions previously used for a single purpose Aug 8, 2024
Copy link
Contributor

@AtticusKuhn AtticusKuhn left a comment

Choose a reason for hiding this comment

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

Looks good to me. I like how this PR is small and atomic.

@Equilibris Equilibris marked this pull request as ready for review August 14, 2024 12:35
Copy link

@tobiasgrosser tobiasgrosser left a comment

Choose a reason for hiding this comment

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

Can you please explain in the commit message in which way these functions have been made more versatile.

Otherwise, LGTM.

Copy link
Owner

@alexkeizer alexkeizer left a comment

Choose a reason for hiding this comment

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

LGTM, feel free to merge after addressing the comments (either by accepting the suggestion, or leaving a comment to justify why you think the original thing is better; none of my comments I would consider super blocking)

Add convenient constructor functions to the environment
-/
def mkConstructors (view : DataView) (shape : Name) : CommandElabM Unit := do
def mkConstructorsWithNameAndType (view : DataView) (shape : Name) (nameGen : CtorView → Ident) (ty : Term) := do
Copy link
Owner

@alexkeizer alexkeizer Aug 14, 2024

Choose a reason for hiding this comment

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

I'd prefer the return type (presumably CommandElabM Unit?) to be explicit.
Also, please write a docstring to explain what this does (and crucially, how it differs from mkConstructors).

Finally, I like to limit lines to 100 chars wide, just like in Mathlib. This line feels like it might be too long (but I haven't checked, we really should set up a linter of some sort)

Add convenient constructor functions to the environment
-/
def mkConstructors (view : DataView) (shape : Name) : CommandElabM Unit := do
def mkConstructorsWithNameAndType (view : DataView) (shape : Name) (nameGen : CtorView → Ident) (ty : Term) := do
Copy link
Owner

Choose a reason for hiding this comment

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

Suggested change
def mkConstructorsWithNameAndType (view : DataView) (shape : Name) (nameGen : CtorView → Ident) (ty : Term) := do
def mkConstructorsWithNameAndType (view : DataView) (shape : Name) (nameGen : CtorView → Name) (ty : Term) := do

I feel like having the argument generate a Name is cleaner than making it generate Idents

@@ -122,11 +122,15 @@ def DataView.addDeclNameSuffix (view : DataView) (suffix : String) : DataView


/-- Returns the fully applied form of the type to be defined -/
def DataView.getExpectedType (view : DataView) : Term
:= Syntax.mkApp (mkIdent view.shortDeclName) (
def DataView.getExpectedTypeWithId (view : DataView) (id : Ident) : Term
Copy link
Owner

Choose a reason for hiding this comment

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

Please explain in the docstring what id does, also, here, too I feel Name is more appropriate

Suggested change
def DataView.getExpectedTypeWithId (view : DataView) (id : Ident) : Term
def DataView.getExpectedTypeWithId (view : DataView) (id : Name) : Term

Comment on lines 131 to 132
def DataView.getExpectedType (view : DataView) : Term
:= view.getExpectedTypeWithId (mkIdent view.shortDeclName)
Copy link
Owner

Choose a reason for hiding this comment

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

The style is to have := on the same line as the type

Suggested change
def DataView.getExpectedType (view : DataView) : Term
:= view.getExpectedTypeWithId (mkIdent view.shortDeclName)
def DataView.getExpectedType (view : DataView) : Term :=
view.getExpectedTypeWithId (mkIdent view.shortDeclName)

Comment on lines 134 to 136
/-- Returns the fully applied, explicit (`@`) form of the type to be defined -/
def DataView.getExplicitExpectedType (view : DataView) : CommandElabM Term
:= let args := Macro.getBinderIdents view.binders.getArgs true
Copy link
Owner

Choose a reason for hiding this comment

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

This function also has the wrong style, the := should be on the same line as CommandElabM Term

(This is code you haven't touched in this PR, though, so feel free to ignore.

Also, I don't remember if I wrote this, but it is very possible. I wrote a bunch of this stuff before I knew what the style should've been, so it's not necessarily good to just mimic the style of what's already there. Sorry 'bout that)

@Equilibris Equilibris merged commit 393d5e2 into master Aug 14, 2024
2 checks passed
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