Refactor traits based on methods

[bramtayl]

All traits which semantically define whether or not a method is expected, e.g. HasShape, HasLength, HasEltype, could be refactored into a single function:

expect_method(::typeof(size), ...)
expect_method(::typeof(length), ...)
expect_method(::typeof(eltype), ...)

which need only take two typed values: True and False. This could unify many existing trait interfaces, and allow them to be more easily combined. In addition, I propose

expect_method(::typeof(getindex), ::Type{Container}, ::Type{Vararg{Int, Dimensions}})
expect_method(::typeof(setindex!), ::Type{Container}, ::Type{Element}, ::Type{Vararg{Int, Dimensions}})

etc. for any method that is required by an Abstract interface.

[yuyichao]

which need only take two typed values: True and False

It is still better to use value, not types. Working around inference limitation is strictly a problem for the caller of the function.

This could unify many existing trait interfaces, and allow them to be more easily combined.

How does this allow things to be more easily combined? It seems that this is similar to say there should be only one function and all other functions should be implemented as method for this single function,

[bramtayl]

It is still better to use value, not types

Happy to change the proposal to true and false if that makes things easier.

similar to say there should be only one function

I think its more like saying there should be only one method table...but fair point. I can imagine a macro which would make writing these definitions easier. Something like:

@add_trait size(something::MyType) = ...

[bramtayl]

Also, worth noting that I'm not proposing about adding it for every function, just every function that is required as part of an abstract interface.

[yuyichao]

Also, worth noting that I'm not proposing about adding it for every function, just every function that is required as part of an abstract interface.

In that case, I assume you mean automatic, since an opt in behavior won't be any different from what's currently available, just with a diifferent syntax.

However, if it's automatic, it'll basically be asking for a inferable version of hasmethod. And in some sense this isn't something that can be done automatic anyway or you are limited to what the type system can express and won't be able to do anything more flexiable than that.

[bramtayl]

an opt in behavior won't be any different from what's currently available, just with a diifferent syntax

yes, I am envisioning opt in behavior, and yes its just a syntax change, but syntax matters

[yuyichao]

yes its just a syntax change, but syntax matters

Sure, I agree syntax does matter. However, then the question is the claim you made initially.

and allow them to be more easily combined

which is what I asked in the first reply above.

[bramtayl]

How does this allow things to be more easily combined?

Because you can use logical operators on Bools (and typed bools provided the proper infrastructure). So you could write for example

arraylike(T) = expect_method(size, T) & expect_method(eltype, T) & expect_method(getindex, T, Vararg{Int}) & expect_method(setindex!, T, eltype(T), Vararg{Int})

[yuyichao]

Because you can use logical operators on Bools (and typed bools provided the proper infrastructure).

You can already do that now.

julia> Base.IteratorEltype([]) isa Base.HasEltype && Base.IteratorSize([]) isa Base.HasShape
true

Again, if this is just syntax change that's fine and most of the time I'll have little opinion on what the best syntax should be. However, if this is just a syntax change, then it'll be hard to say this is more flexible. It could be shorter, it could be more convinient for certain usage, but it won't allow you to do what's impossible before or in cases that it couldn't be used before.

FWIW, this is also very closed to having HasEltype(...) = true/false Looking through the usage in base, it seems that such definition make a lot of existing usage harder to implement (they are probably still possible, just with longer and different syntax) so it seems that it's more likely to be a wash on the syntax complexity for simple usage.

[bramtayl]

such definition make a lot of existing usage harder to implement

Why?

[yuyichao]

The return value carries more than two states, and some functions dispatches on particular combinations. This methods is requiring all functions to have only two states (i.e. one bit of info) so you'll need to pass on more traits in order to pass the same amount of information.

In another word, what is possible now by passing IteratorSize, you'll need to pass in sth like both expect_method(length) and expect_method(size).

[bramtayl]

You could dispatch on True and False. I thought you said that dispatch was slow anyway?

[bramtayl]

You'll need to pass in sth like both expect_method(length) and expect_method(size).

You could have a fallback method like:

expect_method(length, T) = expect_method(size, T)

[yuyichao]

You could dispatch on True and False. I thought you said that dispatch was slow anyway?

Yes, and I never say it's slow. I say it's no faster than a branch and in this case the comparison is to other dispatch and there won't be much difference.

Dispatchig on true/false does have additional problem though since you can quickly run into boolean hell with more and more traits involved all having the same value set. And it seems that you are indeed most interested in complex cases.

You could have a fallback method like:

The producer of the info isn't the problem. The consumer is. If you are implementing something that dispatches on IteratorSize in order to pick the best method,

Now you have f(::<IteratorSize>, ...), with this you need f(::<expect_method(length)>, ::<expect_method(size)>, ...). Of course each method probably only care about one value, but you have to pass both to make the dispatch work in general case.

[bramtayl]

Now you have f(::<IteratorSize>, ...), with this you need f(::<expect_method(length)>, ::<expect_method(size)>, ...).

This seems like extra flexibility, not extra complexity, to me. Also, I think something more like:

if expect_method(size, T) isa True
    ...
elseif expect_method(length, T) isa True
    ...
else
    ...
end

would be better.

[yuyichao]

This seems like extra flexibility,

It's equivalent functionality (i.e. not more flexible) and longer syntax (I'm only talking about syntax complexity in this case). I believe the latter objectively requires more argument. I'm making no argument on which one is better for this simple case, just that the complexity is higher.

if expect_method(size, T) isa True
    ...
elseif expect_method(length, T) isa True
    ...
else
    ...
end

Now this is't about syntax anymore, and no that's how you lost flexibility. It is of course a good way to implement pure logic on traits but you can't do that in general. This is exactly why we have dispatch at all and not just branching on type checks in user code. With that branch written, it is now impossible to extend the dispatch logic it creates which make it less flexible.

Also note that since you are dealing with only one type and one kind of info in this case you can easily exhaust all possible values never require this to be extended, which is exactly why this is a good way to implement pure/simple trait computation. However, as long as you have any other dispatch/logic in the branch, those logic are now bound to the branch logic and cannot be extended freely anymore. In another word, the branch is a single dispatch on one argument, which is strictly less flexible than multiple dispatch.

(edit: I have no idea why I keep typing "now" as "not"...)