Skip to content

[ fix ] Backticked names cannot be used as prefix operators#3740

Open
spcfox wants to merge 3 commits intoidris-lang:mainfrom
spcfox:backticker-parser
Open

[ fix ] Backticked names cannot be used as prefix operators#3740
spcfox wants to merge 3 commits intoidris-lang:mainfrom
spcfox:backticker-parser

Conversation

@spcfox
Copy link
Contributor

@spcfox spcfox commented Feb 16, 2026

Description

Fixes #3550

Self-check

  • If this is a fix, user-facing change, a compiler change, or a new paper
    implementation, I have updated CHANGELOG_NEXT.md

@gallais
Copy link
Member

gallais commented Feb 17, 2026

Is there any chance we could have a more helpful message suggesting the use of
a section? The following is valid:

(`minus` 5)

@spcfox
Copy link
Contributor Author

spcfox commented Feb 17, 2026

Is there any chance we could have a more helpful message suggesting the use of a section? The following is valid:

(`minus` 5)

Not sure if this error can be easily added during parsing. I couldn't get it to work.

@spcfox
Copy link
Contributor Author

spcfox commented Feb 18, 2026

@andrevidela, could we add this kind of error to the parser? Perhaps we shouldn't modify the parser itself and instead throw the error during desugaring?

I think it’s better to make it a parsing error, but I couldn't figure out how to add an informative error message.

@andrevidela
Copy link
Collaborator

andrevidela commented Feb 18, 2026

In my experience, it's easier to catch this kind of error during desugaring, we have more contextual information than during parsing and it keeps the parser simple.

It also keeps the parse tree semantically simple, if we catch the backtick misuse at parsing time, we still produce a value of type OpStr which could be backticked at desugaring time, but since the error would have already been thrown by then it would be an impossible value to have. This would force us to handle a case that we know cannot happen. I'd rather have this handling code in the desugarer such that we're not saddled with a value of OpStr that doesn't faithfully represent the space of possible values accurately.

@spcfox spcfox force-pushed the backticker-parser branch 3 times, most recently from 38e1a76 to dd6866e Compare February 18, 2026 16:29
@spcfox
Copy link
Contributor Author

spcfox commented Feb 18, 2026

Ok, now the error is handled during desugaring

^^^^^^

Possible solutions:
- Use section: (`Elem` _ . fst)
Copy link
Member

Choose a reason for hiding this comment

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

Should the section not be

(`Elem` _) . fst

?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Should we be guessing the parenthesis placement here? Both cases could potentially be correct

Copy link
Contributor Author

@spcfox spcfox Feb 19, 2026

Choose a reason for hiding this comment

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

The internal error occurred in the shunting algorithm, which reorders operators according to their precedence. That’s why I added this check before it. We could potentially run it, but I’m not sure it would be helpful


Possible solutions:
- Use section: (`Elem` _ . fst)
- Use application: Elem _ . fst
Copy link
Member

Choose a reason for hiding this comment

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

This application has a different meaning as _ is now for the first argument rather than the second one.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don’t know what the user intended. In the first case, I'm suggesting the most likely option — a section. But it’s also possible that the backticks were just a typo.

Copy link
Collaborator

Choose a reason for hiding this comment

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

yeah we can't run the typechecker at this stage to know which one is the one that the user meant. I think this is fine as the user will probably try both and pick the one that works

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.

Encountered INTERNAL ERROR: Invalid input to shunting when using infix Elem and . together

5 participants