Provide useful backtraces

[timholy]

By annotating the function body with the source location, we can get nice backtraces when our trait functions throw errors. Unfortunately, this does not yet seem to be enough to get accurate code coverage of trait functions (which is actually why I did this). But the useful error messages are nice.

Example:

using SimpleTraits

@traitdef IsInteger{X}

@traitimpl IsInteger{Integer}

@traitfn foo{X;  IsInteger{X}}(A::X) = error("oops 1")
@traitfn foo{X; !IsInteger{X}}(A::X) = error("oops 2")

julia> foo(1)
ERROR: oops 1
 in foo at /tmp/testbt.jl:7 [inlined]
 in foo at /home/tim/.julia/v0.5/SimpleTraits/src/SimpleTraits.jl:163 [inlined]
 in foo(::Int64) at /home/tim/.julia/v0.5/SimpleTraits/src/SimpleTraits.jl:169

Without this, you don't get that first all-important line.

This only works on julia 0.5, but it doesn't break julia 0.4.

[mauro3]

Cool! I don't know anything about this, so, I'll assume this is good. (Actually, is this documented somewhere?)

[mauro3]

BTW: how is SimpleTraits working for you so far?

[timholy]

(Actually, is this documented somewhere?)

Barely: http://docs.julialang.org/en/latest/devdocs/ast/?highlight=push_loc. That's all I can find.

BTW: how is SimpleTraits working for you so far?

Seems fine so far, in that I was able to get what I need working.

I'd say that compared to manually writing out the trait-dispatch, the "win" is not enormous, but it is a little nicer. The fact that coverage doesn't register properly is a bit of a bummer (it would if I wrote out the traits manually). That's probably a julia bug, though.

[mauro3]

With "coverage" you mean the code-coverage tools, right?

Do you think adding a Traitor-like syntax would increment the "win"? Do you think SimpleTraits would help packages future-proofing, for the time when Julia gets traits, in the sense that updating to proper ones would be easier?

[timholy]

With "coverage" you mean the code-coverage tools, right?

Right

Do you think adding a Traitor-like syntax would increment the "win"?...

I'm slowly coming to the conclusion that the "real" answer is to simply add it to Base. There are a couple of things that might be easier if you just do it in the C code (and perhaps there isn't a way to do it in pure julia).

So I'm not sure that it's worth you working a lot on this trying to make it more like Traitor. Not that I'm promising to work on it in Base, but I do think that's the right place to do this.

[mauro3]

Oh, yes, I only see this as a stop-gap until traits are in Base. But if Stefan's time-line is accurate, people on not-master, will wait for them at least another 2 years, until Julia 2.0 is out. So, maybe it's worth providing something easy to use until then.

[timholy]

Not that I'm promising to work on it in Base,

I'm not promising to not work on it in Base, either 😉. I think Stefan's statement means "Stefan and Jeff don't plan on implementing this for 1.0." If someone else provides a good solution (me, you, someone else, ...), then I think it's extremely likely that it will be merged.

At JuliaCon I grabbed a bunch of folks and discussed the API for traits; Traitor is what came out of that discussion, and when Jeff was asked, "does this pass the Jeff test?" he said "basically, yes." But for it to be acceptable, I am certain that it will have to be integrated into src/gf.c---anything else will not pass the Jeff test (for very good reasons).

[mauro3]

Fingers crossed that you find some time then! I'm not the right person for the job, I didn't even know of gf.c's existence... but I would be very happy to help where I can, e.g. with testing and ideas. Hopefully, the type-overhaul gets merged soon, that would make a better foundation to build this on.

[timholy]

If you know C and are comfortable with a debugger like gdb, gf.c is actually quite hackable (be patient and plan to spend several hours getting to know your way around). If you don't know C, then that would be a barrier...

Curiously, I am not entirely certain that Traits will need to be integrated into the type system; it might be more of a method-system thing. If it's the latter, then some good news is that one can probably do most of the work independently of Jeff's work on the type system.

[mauro3]

Whilst traits would work fine without inclusion in the type system by leveraging your trick (or otherwise). We'd end up in the situation again in which we currently are: method signatures are more expressive than type-tuples (which is one of the main issues the type-overhaul addresses, as far as I understand). Thus ideally traits would integrate with types, but maybe they needn't; at least not in their first iteration.

[timholy]

It definitely would be a good thing to be able to describe a "full type" including the traits. No argument there.

[mauro3]

Thanks for the chat! Keep me posted, and let me know when you need this package registered.