Open bramtayl opened 1 year ago
Hmm, I'm mildly encouraged by the lack of dislikes?
EDIT: nvm lol
@bramtayl I feel like we're going very similar routes (compare my https://github.com/JuliaLang/julia/issues/38713#issuecomment-1188977419), would you like to talk about our both approaches via Slack or Discord (Humans of Julia) and have a look if we can find common ground we can push forward together?
I guess the primary difference between our approaches is using _
for each argument and have them be linearly non-repeating (so no rearrangement or duplication of arguments) in my case and not restricting that in your case.
Sure! I'm not sure we'll get anywhere but
I dont have an account on either so let me know where to make an account
Here is YAAFSP: yet another anonymous function syntax proposal. I'm opening as an issue rather than a PR because I have no idea how to start implementing this, but if someone has some tips to get me started I could try.
It might be nice to not have to give explicit names to the arguments to anonymous functions. This is simply because, very often, these names will never get used again.
Consider:
x -> x + 1
The variable
x
here is only used once, so there is no need to give it an explicit name. Moreover, if we had a list of the "default" argument names, we could syntactically figure out how many arguments there are, just by looking at the surface level expression (assuming the last argument actually gets used at some point).Suppose that we will always call the first argument
_
, the second argument__
(two underscores), the third argument___
(three underscores), etc. These are names are somewhat arbitrary. Perhaps it is difficult to distinguish the number of underscores, so something like_1
,_2
,_3
might work too; proposals welcome.Then, by looking at the body of the anonymous function, we could automatically figure out how many arguments there are:
_ + 1
has 1 argument, because a single underscore appears._ + __
has two arguments, because both a single and double underscore appear.1 + __
has two arguments. The first, a single underscore, isn't used, but the second, a double underscore, is used.abs
has no arguments written. This is a bit of a corner case. We can assume that the expression itself returns a function (in this case,abs
). Alternatively, you might think that it means something like() -> abs
, which is perhaps a bit more consistent, but maybe not as useful.This is great, but we still need a marker to determine where the boundary of the anonymous function is. Instead of some sort of arbitrary rule, I'm proposing an explicit marker. In particular, I'm proposing "unary"
|>
(again, this is symbol is somewhat arbitrary, so other proposals welcome).So
|> _ + 1
gets lowered to something likex -> x + 1
.|> _ + __
gets lowered to something like(x, y) -> x + y
|> 1 + __
gets lowered to something like(x, y) -> 1 + y
|> abs
gets lowered toabs
.The cool thing about unary
|>
is that we can extend it for use in chaining, that is, "binary"|>
.So
1 |> _ + 1
would get lowered to something like1 |> (x -> x + 1)
.Existing chains would continue to work. This is because of the "corner case" above of no arguments. In
1 |> abs
,abs
would remain unchanged.So pros and cons:
Pros:
|>
currently errors. Binary|>
with underscores throws errors due to underscores banned as r-values, and if there are no underscores, nothing changes anyway.will be much shorter:
Cons:
|>
should be. Ideally, something like the following would work without any additional parentheses:Notes: