replace equalto and occursin with curried isequal, ==, and in

[JeffBezanson]

These were my silly idea, so I'll try to clean it up. I think this is nicer, frees up occursin, and easily generalizes to other functions.

This is really just currying on the second argument, but it's especially useful for comparisons since e.g. in(xs) checks whether something is in xs, and <(3) (if implemented) checks whether something is less than 3, etc. Dispatching on something like Curry2{typeof(in), ...} would be a bit obscure, so I opted for CompareTo{in, ...} instead.

[nalimilan]

Makes sense, though I still like @stevengj's proposal to use _ in x for this. My concern is that there's virtually no limit to the number of functions/operators which could be added a currying version like this (including in packages). And it will always be hard for users to remember which functions implement it and which don't.

For the bikeshedding, CompareTo sounds a bit weird for in. Even if more obscure, a general name referring only to currying could be fine. Anyway that's not exposed to most users (and it's not even exported). Maybe that type could even support any number of arguments, by wrapping a tuple to be splat rather than a single value (if there's no performance penalty).

[nalimilan]

While you're at it, "returns a function equivalent to" would be more accurate.

[nalimilan]

Not a real syntax.

[stevengj]

I think it would be a bit odd to implement this style in 1.0 and the underscore style in 1.1. Can we just make up our minds about the latter?

[piever]

As a point in favor of the underscore syntax, probably the data people would find it more familiar as at least two packages (Query and JuliaDBMeta) use it already (it was reimplemented via macros): Lazy also reimplemented it with the @_ macro.

[JeffBezanson]

I like the _ proposal but I don't see much harm in having both. isequal(x) is shorter than isequal(_,x). And the question is not whether this conflicts with _ syntax, but whether it's better than equalto and occursin.

[StefanKarpinski]

I like the in(collection) and isequal(value) currying, not sure about the Curry2 type.

[JeffBezanson]

The idea would be to share Curry2 with f(_, x) syntax in the future.

[StefanKarpinski]

Perhaps we could use _ in { } in some clever way for that?

[mbauman]

I definitely like that this makes ==(-0.0) and isequal(-0.0) clearer. I can never remember which one equalto implements.

[jw3126]

I find the proposed methods confusing and would be much more happy with only e.g. (_ == x). One reason that was mentioned yet is the following. We currently have:

+(args...) = sum(args)
*(args...) = prod(args)

This gives for example

+(3) = 3

OTOH from this proposal I would expect

+(3) = x -> x + 3

I think implicit currying is confusing in a language that also allows variable number of arguments.

[StefanKarpinski]

Triage is on board with trying this. Some observations:

1. This only makes sense for binary operations.
2. It isn't technically currying but rather partial application; accordingly it would be both clearer and more accurate to write Fix2 to indicate fixing the second argument via partial application.
3. It only reads correctly for operations where we use verb(subject, object) order, which is the case for in and < for example and for those it should always do specialization on the second argument.

So in short, I think we should limit this convention to binary verb(subject, object) functions and always do specialization on the object.

[stevengj]

Can I suggest a more general type than Curry2 or Fix2, to make this easier to generalize to underscore syntax?

In particular, how about something like struct FixFunction{N,F,i,T}; f::F; x::T; end where N is the new number of arguments, f is the function, i is an M-tuple of the positional indices of the "fixed" arguments x, and T is a tuple type of M types. So that _ < 3 becomes FixFunction{1,typeof(<),(2,),Tuple{Int}}(<,(3,)).

[mbauman]

That was considered on our call — Fix2 is really easy to type-alias to a more general form in the future. A more general form that we get wrong is much harder to patch around.

[StefanKarpinski]

After sleeping on it, triage has decided to go for this but only do this for strictly binary operators (i.e. only two-arg methods) where the second argument is the object of the verb, which limits the scope creep of this considerably and restricts the convention to cases where it is linguistically intuitive.

[stevengj]

The PR number should have been updated to 26436 here.

[ararslan]

Adjusted in #26480

[stevengj]

@mbauman, a problem here is that Fix2 has a field x that is the curried argument. Any generalization to multiple parameters will almost certainly have to change this to a tuple, at which point Fix2 won't simply be a type alias.

Can the x member be changed to a Tuple{T}? Otherwise any more general partial evaluation scheme (ala #24990) will have to introduce a breaking change in order to interact nicely with this feature.

[mbauman]

Or we add a deprecated property accessor (either via getproperty or a dedicated function) if we really want to make property access non-breaking?

[JeffBezanson]

The generalized partial application type seems so complicated to me that you might as well encode the AST in the type at that point (as prototyped by @vtjnash). We can just have a rule that f(_, x) lowers to a Fix2 and f(x, _) lowers to a Fix1, and other cases do other things.

[ararslan]

equalto and occursin should have had deprecations; this now causes UndefVarErrors for code that's already been updated to work on 0.7.

[JeffBezanson]

Ok. Can you add them?

[ararslan]

#26480

[rapus95]

was there a particular reason why you didn't add isa(T::DataType) aswell?

[StefanKarpinski]

No, that would be a good one as well.

[andyferris]

Not sure where to write this... but after getting used to isequal(x) and ==(x) I was surprised not to see isless or < (and >, <=, >=).