That's a really cool idea. It will be really interesting to see what our implicit interfaces are determined to be.
On Tue, Jul 8, 2014 at 7:22 PM, Jameson Nash <[email protected]> wrote: > As an experiment, I had recently started work on implementing the reverse > of this (extracting the implicit interface given a type) in a pull request > for astrieanna's TypeCheck.jl package: > > > https://github.com/vtjnash/TypeCheck.jl/commit/b0ebcac4c2a9a3daccd1eeb1b28030b90ae5e2c9 > > > On Tue, Jul 8, 2014 at 5:56 PM, Tobias Knopp <[email protected]> > wrote: > >> Abraham, you might also be interested in the prototype that I have >> prepared in https://github.com/JuliaLang/julia/pull/7025 >> >> While I am also looking forward that anything like this lands in Julia, >> this is mainly about getting better error messages and code organization. >> Julia is perfectly usable even with its implicit interfaces that are >> available now. >> >> By the way, in the Base Graphics module there is a "mustimplement" macro >> that also can be used to define interfaces. >> >> Am Dienstag, 8. Juli 2014 22:02:52 UTC+2 schrieb Stefan Karpinski: >>> >>> Definitely a missing piece. Here's the relevant issue: >>> https://github.com/JuliaLang/julia/issues/6975. It's largely a question >>> of design and implementation. >>> >>> >>> On Tue, Jul 8, 2014 at 12:56 PM, Abraham Egnor <[email protected]> >>> wrote: >>> >>>> I'm very new to Julia, so my apologies for the bits I inevitably get >>>> wrong. >>>> >>>> As far as I can tell, Julia has no notion of interface, i.e. "if you >>>> declare your data type a subtype of Foo, you also must/should implement >>>> these functions on the type". This seems like a pretty significant lack to >>>> me - it turns the (otherwise quite lovely) type system into essentially >>>> tagged duck typing. >>>> >>>> There are a few packages that implement their own version of interfaces >>>> (and it speaks well of Julia that this is possible!), but they do so with >>>> very different semantics and don't expose any sort of general >>>> interface-construction machinery. >>>> >>>> Are there any proposals for an interface framework as part of the >>>> standard library? >>>> >>> >>> >
