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: uncurry 0 #949

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

feat: uncurry 0 #949

wants to merge 8 commits into from

Conversation

anmonteiro
Copy link
Member

@anmonteiro anmonteiro commented Dec 3, 2023

fixes #674

@anmonteiro
Copy link
Member Author

@jchavarri @andreypopp this is now ready for review. Note the comment (#674 (comment)) where I highlighted we're not handling @mel.meth with @u0 (those are still inferred to be 0-arity based on unit arguments).

Let me know your thoughts!

ppx/mel_ast_invariant.ml Show resolved Hide resolved

let pp fmt t =
match t with
| Unused_attribute s ->
Format.fprintf fmt
"Unused attribute [%@%s]@\n\
This means such annotation is not annotated properly.@\n\
For example, some annotations are only meaningful in externals\n"
Copy link
Member

Choose a reason for hiding this comment

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

Why removing the newline here? I found it was useful to have it (see changes in tests).

Edit: I see other messages don't include it. Maybe the newline could be added separately to have some space between the alert and the actual output when calling melc?

@anmonteiro
Copy link
Member Author

This should be ready to merge, but there are a few issues with the PR in the current state:

  • we don't have a solution for [@mel.uncurry] -- I only noticed it because there was an uncurried alert emitted for something like t -> (unit -> t [@mel.uncurry]) -> unit = ..`
    • we'd either have to add @mel.uncurry0 or go back to the old behavior where a single unit argument represents 0-arity uncurried application
  • we totally glossed over the fact that ReasonML doesn't have a syntax for this... so we won't have a way to write foo(. ()) vs foo(. ) at all
    • this is actually blocking for this PR, so we'll need to put this on the back burner until we figure it out

@jchavarri
Copy link
Member

  • we totally glossed over the fact that ReasonML doesn't have a syntax for this

just for doc purposes, found this issue: reasonml/reason#2357

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.

[@bs] at application side treats f () as 0-arity application
2 participants