Check alternative operators for "here be dragons"

[hauleth]

Poll about the operator to be used (just click on the option you like, and your vote will be counted, it will not bring you to the poll site):

[ityonemo]

__PIPE__ is also a possibility, maybe also __

[baldwindavid]

@ityonemo I was also thinking about __, but didn't know if that was a possibility.

[hauleth]

Well, it is possible to use __. The problem though is that in theory it is currently available token that someone could use. It is much less common to use ... as a name for a thing. But __PIPE__ is also interesting approach, however I do not know if I like it's loudness.

About pros and cons of each approach:

• ... is pretty straightforward, and for me it looks like "I will continue sentence", but can be lost in the visual noise of the operators
• ^_ looks like kind of an arrow pointing up, the problem is that ^ already has meaning that has (almost) nothing to do with function calling, this can be confusing
• &_ has the problem that it has lower priority than most of the operators, which can cause problems if in future we would like to support syntax like &_ + 1 as it will be interpreted as &(_ + 1) which is nonsensical instead of (&_) + 1 is it would be expected
• __ has similar problem as ..., but it may be much easier to find a code it would brake than with ...
• __PIPE__ do not have any of the problems above, but is LOUD and I could find it confusing in situations like foo() |> bar(__MODULE__, __PIPE__)

[baldwindavid]

I gravitate to some of the options with _ because it looks like a placeholder. A few other ideas:

• Was thinking of something similar to |> where one of the characters is replaced with underscore like |_ or _>.
• Or rather than pointing up with ^, there could be "back" with <_ if concerned about the existing meaning of ^.
• Perhaps it might be hard to see __. Adding another underscore for ___ is another option.

[hauleth]

@baldwindavid the problem is that all <_, |_, and _> would require changes to the parser and cannot be implemented as a simple macro. Adding more operators to the language is something that I would like to avoid (and I think that Core Team agree with me on this).

Adding more underscores would not change a thing IMHO, unless it is _____________________ (or any other absurdly long sequence) then it will still have the same problems as ... (especially as ___ and ... have the same length on monospace fonts which are used my most people when programming).

[baldwindavid]

@hauleth Thanks for the explanation. Regarding the underscores, I just meant that ___ may be less likely to be confused by a reader with _ than __.

Regardless, I'm content with any of the options in the poll to the extent that it eventually supports the same use cases as elixir-capture_pipe

[ityonemo]

Unless my understanding of elixir is wrong, would __ break anything? For starters, you're in a macro, so it never gets past the ast stage as anything that the user could have bound to. Likewise, it never binds anything. And even if we're talking conceptual breakage as in "breaking my brain", the user would not have bound anything to __ because the compiler emits a warning since it's an underscore variable. it's extremely unlikely to be a local zero-arity function since the compiler will warn on calling a zero-arity function without the parens. So the only likely situation is where someone uses pipe and has later or earlier code where they are pattern matching to __, and using it as a throwaway. I'm not sure this is such a big deal since you can reuse _ in matches and it's special cased to not require exact matching anyways.

[Will-W]

I'm not a fan of ... because I come from a C background so my expectation is that multiple arguments could be substituted in.

I also don't really like any of the options involving underscores because everywhere else in Elixir underscores read to me as 'ignore this thing'. I'm interested that that isn't other people's first reaction. I voted for ^_ though because it seemed the least bad.

Is there something more fundamentally surprising and different that we can do? I don't know the limitations of what's available - I presume it's tokens already available in Elixir AST? In an ideal world I think I'd use the @ symbol.

[hauleth]

I presume it's tokens already available in Elixir AST?

Yes, Elixir do not allow using otherwise illegal syntax in macros.

In an ideal world I think I'd use the @ symbol.

Which we cannot use, as @ is unary operator, so it requires suffix.

[ityonemo]

I just realized one could borrow a page from matchspecs and use :_, or :"$_", :"$$"

[hauleth]

@ityonemo the problem with using :_ is that it is commonly used in match specs, so stuff like:

tid
|> :ets.select({:_, [], [:"$"])

Could became hard to read with such placeholder, especially if we would like to allow non-root level matches.

[baldwindavid]

Another one I don't think has been mentioned is &1_, which is closer to the original aim of https://elixirforum.com/t/a-simple-macro-to-allow-bare-captures-in-pipes/32516 though assume this suffers from the same issues due to the &.

[hauleth]

Closing as poll (and I) decided that ... is the best option (and &_ is not possible to use).