Trait inheritance

[AriMKatz]

Hi,

Great package!

What's your thinking on trait inheritance?

I'd like to be able to make a trait hierarchy where I can have a fallback dispatch on general traits and then overloads for traits returning more refined subtypes. Would this lead to too many method ambiguities in non trivial code when combining multiple of these ?

[schlichtanders]

Thanks @AriMKatz for your suggestion. In general your intuition is right that method ambiguities can become a difficulty.

@traits helps you in making a nested set of two dispatch functions clean and extendable. Without traits you would not even have the possibility of extending the inner function. That is important to keep in mind. I.e. having the possibility of adding new traits and hence raising method ambiguities is actually one of the features of the macro if you want so.

Now to your example.
I imagine you want a dispatch like

@traits f(a) where {general(a)) = 1
@traits f(a) where {morespecialized(a)) = 2
@traits f(a) where {evenmorespecialized(a)) = 3
@traits f(a) where {unbelievablyspecific(a)) = 4

That would indeed give you a lot of method ambiguities when written like this, as it is translated to plain dispatch on 4 boolean, and if all are true (as in the unbelievablyspecific case), every single function of the four above could be the right one to pick.

The issue is however simple to solve.

@traits f(a) where {general(a)) = 1
@traits f(a) where {general(a), morespecialized(a)) = 2
@traits f(a) where {general(a), morespecialized(a), evenmorespecialized(a)) = 3
@traits f(a) where {general(a), morespecialized(a), evenmorespecialized(a), unbelievablyspecific(a)) = 4

written this way, the dispatch now reflects the inner hierarchy and if something fulfils all 4 traits, now the last function is actually written for exactly this and hence no method ambiguity is raised.

One could think of adding special support for such patterns, by automatically extracting a hierarchy in some way, but I bet this would make the macro more magic and hence more vulnerable to unintuitive behaviour.
As of just now it seems to me that replicating the hierarchy yourself as in the example above is the cleanest way of using hierarchy of traits.

---

Just thinking on a side track, you can of course also define your own type. Julia types are made for modelling hierarchies. So maybe standard Julia dispatch is actually more suited for what you have in mind. You can also dispatch on such using traits, it would something like this

abstract type General end
abstract type Specific <: General
howspecificisit(a) = General
@traits g(a) where {howspecificisit(a) <: General} = 1
@traits g(a) where {howspecificisit(a) <: Specific} = 2

I hope this can help you on implementing trait inheritance
Or have I misunderstood your question? Please clarify if so

[AriMKatz]

That's exactly what I had in mind. Using normal inheritance sounds good, but is dispatching on returning an abstract type type stable? I plan to experiment later this week.

Could also make a concrete Singleton type at every level of the hierarchy.

[AriMKatz]

@schlichtanders we're having a discussion about traits, Julia's philosophy on method typing, your package and some other ones here: https://julialang.zulipchat.com/#narrow/stream/237432-ml-ecosystem-coordination/topic/Better.20error.20messages

Would be great to get your input!