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: Generic function definitions #618

Merged
merged 4 commits into from
Nov 14, 2024
Merged

feat: Generic function definitions #618

merged 4 commits into from
Nov 14, 2024

Conversation

mark-koch
Copy link
Collaborator

@mark-koch mark-koch commented Nov 4, 2024

Allow function definitions that are generic over parameters of kind type or nat.

  • Store currently available type parameters in the type checking context
  • Refactor type parsing logic to explicitly opt in to add free variables to the parameter mapping
  • Add a new GenericParamValue AST node to represent usages of generic nat params n inside function bodies. We need a way to encode this in Hugr. For now, we just emit a dummy node. See OpType to load BoundedNat / TypeArg into runtime value hugr#1629

Note: Nested generic functions are not supported yet, so we don't have to worry about scoping of type params.

Closes #522

@mark-koch mark-koch requested a review from a team as a code owner November 4, 2024 16:48
@mark-koch mark-koch requested a review from croyzor November 4, 2024 16:48
@codecov-commenter
Copy link

codecov-commenter commented Nov 4, 2024

Codecov Report

Attention: Patch coverage is 90.74074% with 5 lines in your changes missing coverage. Please review.

Project coverage is 92.61%. Comparing base (f527703) to head (5efa146).

Files with missing lines Patch % Lines
guppylang/checker/expr_checker.py 84.61% 2 Missing ⚠️
guppylang/tys/parsing.py 85.71% 2 Missing ⚠️
guppylang/tys/printing.py 66.66% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #618      +/-   ##
==========================================
+ Coverage   92.45%   92.61%   +0.15%     
==========================================
  Files          66       66              
  Lines        7465     7487      +22     
==========================================
+ Hits         6902     6934      +32     
+ Misses        563      553      -10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.


def test_id(validate):
module = GuppyModule("test")
T = guppy.type_var("T", module=module)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I wonder if it's possible to make type_var a method on GuppyModule? Specifying the module like this everytime seems a bit arduous

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'd prefer to keep it a guppy method because most users will work with implicit modules. Explicit modules are only really used in tests, so imo it's fine to be more verbose there


@guppy(module)
def foo(xs: array[int, n]) -> int:
return int(n)
Copy link
Collaborator

Choose a reason for hiding this comment

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

It'd be good to see versions of the call and recurse tests with nat variables

@@ -100,7 +105,9 @@ def check_cfg(
check_rows_match(input_row, compiled[bb].sig.input_row, bb)
else:
# Otherwise, check the BB and enqueue its successors
checked_bb = check_bb(bb, checked_cfg, input_row, return_ty, globals)
checked_bb = check_bb(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we not need to worry about passing along type vars that are defined in predecessor bbs? I can't quite see how that's happening

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The type vars are the same in all BBs since they are introduced by the function signature. There is no way you can define new ones in a BB

@mark-koch mark-koch added this pull request to the merge queue Nov 14, 2024
Merged via the queue into main with commit 7519b90 Nov 14, 2024
3 checks passed
@mark-koch mark-koch deleted the feat/generic-defs branch November 14, 2024 10:20
github-merge-queue bot pushed a commit that referenced this pull request Nov 15, 2024
🤖 I have created a release *beep* *boop*
---


## [0.13.1](v0.13.0...v0.13.1)
(2024-11-15)


### Features

* Generic function definitions
([#618](#618))
([7519b90](7519b90)),
closes [#522](#522)
* mem_swap function for swapping two inout values
([#653](#653))
([89e10a5](89e10a5))


### Bug Fixes

* Fix generic array functions
([#630](#630))
([f4e5655](f4e5655))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).
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.

Generic function definitions
3 participants