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

Add type annotations to monadic bind #3327 #3329

Merged
merged 3 commits into from
Jun 27, 2024

Conversation

dunhamsteve
Copy link
Contributor

Description

This PR implements most of the proposal in #3327. With this change we can optionally provide a type annotation in a monadic bind, following the syntax of the same in a let statement:

test1 = do
  x : Nat <- foo
  printLn x

and with pattern matching

test6 = do
  Just x : Maybe Nat <- bar
    | Nothing => pure ()
  printLn x

The discussion in #3327 (and on discord) mentions support for declaring multiplicities on the binds like in let statements. This is implemented when binding a variable name, but not for a pattern matching bind. The syntax for pattern quantities would have broken existing code and would not function correctly because of issues related to #2513 (ICase does not have a quantity).

Should this change go in the CHANGELOG?

  • If this is a fix, user-facing change, a compiler change, or a new paper
    implementation, I have updated CHANGELOG_NEXT.md (and potentially also
    CONTRIBUTORS.md).

= do tm' <- desugarDo side ps ns tm
rest' <- expandDo side ps topfc ns rest
whenJust (isConcreteFC nameFC) $ \nfc => addSemanticDecorations [(nfc, Bound, Just n)]
ty' <- maybe (pure $ Implicit (virtualiseFC fc) False)
(\ty => desugarDo side ps ns ty) ty
Copy link
Member

Choose a reason for hiding this comment

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

Isn't it bizarre that we are using desugarDo to elaborate the type?
Does it even make sense to have an effectful function returning a type here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, that struck me as odd, but I followed the pattern of DoLet and DoLetPat. It looks like they were changed from a full desugar to desugarDo in ee063a5 to propagate the do namespace.

Copy link
Member

Choose a reason for hiding this comment

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

Right, I think that should be reverted.
Unless @Russoul has a motivation for it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll let you guys sort out what is wanted here. It looks like desugar simply calls desugarDo with a namespace of Nothing.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I think the function name threw me off, but either looks fine. The difference seems to be what namespace ends up on comprehensions, which I wouldn't expect to appear in types.

What did you want to revert? Is it just changing the otherty elaborations to desugar or more of #1700?

@gallais gallais merged commit f561c78 into idris-lang:main Jun 27, 2024
22 checks passed
@dunhamsteve dunhamsteve deleted the issue-3327 branch June 27, 2024 17:28
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