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

Function composition operator mixup #1267

Open
axch opened this issue Apr 4, 2023 · 1 comment
Open

Function composition operator mixup #1267

axch opened this issue Apr 4, 2023 · 1 comment

Comments

@axch
Copy link
Collaborator

axch commented Apr 4, 2023

def (>>>)(f:(a) -> b, g:(b) -> c) -> (a) -> c given (a, b, c) = \x. g(f(x))

The parser still has a precedence for the >>> operator, so I tried to revive it as above. But when I tried running the result, I got this:

3.0 | (exp >>> sq)
> Type error:Wrong number of arugments provided. Expected 2 but got 3
>
> 3.0 | (exp >>> sq)
> ^^^^^^^^^^^^^^^^^^

Why? Because the subexpression in parens parsed as (>>>)(exp, sq), and then the | operator turned it into (>>>)(exp, sq, 3.0). But the error message was not helpful in figuring this out. Do we want a function composition operator, or should we just not bother for now?

@dougalm
Copy link
Collaborator

dougalm commented Apr 4, 2023

I'd be happy to get rid of the function composition operator. We're leaning into a more pointful style anyway.

But it's a bad error regardless. I think we shouldn't do the arg-extension-via-pipe trick if the application is an infix binary application. Those are syntactically binary, after all.

We should also consider not doing the arg extension when the application is in parens.

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

No branches or pull requests

2 participants