Some Abstract types are used within Julia base (e.g. AbstractTime, AbstractArray, AbstractToken). Others are in use through substantive packages (e.g. AbstractInterval, AbstractTimeSeries, AbstractModel). It seems to me that package ecosystem interworkings would be advanced were Julia to export (maybe from Base.Abstractions) specific Abstract terms for abstractions of wide interest or deep reliance.
I think more important would be some “standard function names” set as blank which can be imported and extended. That would lessen the need for *Base packages.
2 Likes
Though this has to be carefully done. It seems
function plot end
would make sense because lots of packages seem to use it and step over each other. However, if type-piracy rules were enforced, the APIs would have to be completely changed.
1 Like
Now is the best time to introduce better ways because later is too late.
4 Likes
I have been missing AbstractComposite, in order to code functions that work with composite types (having fieldnames), vs e.g. Vectors. But It would require, that all composite types are an AbstractComposite (presently their supertype is Any).
My present workaround is
if length(fieldnames(arg))>0
dosomethingwithfields(arg)
else
dosomethingwithelements(arg)
end
2 Likes
Consider abstract type AbstractTimeSeries end
and also abstract type AbstractTimeSeries{TimeType} end
Whichever the community prefer, choosing one and having that be available to all with import Abstract: AbstractTimeSeries would do more to let various time series related modules just work or interwork or intrasubstitute. The alternative is to have a package that is very facile with aspect A of time series operations and another package that handles aspect B well – where the use of both together becomes a bridge too far.
I think more important would be some “standard function names” set as blank which can be imported and extended. That would lessen the need for *Base packages.
Personally, I’d like that as well, but I asked this question somewhere concerning the function name update!. I didn’t get the feeling there was any sympathy towards that POV.
I think one of the obstacles to doing something like this is that abstract types often imply a specific interface, and currently there is no way to enforce this. Even if there were, doing so on lots of abstract types that aren’t actually used in Base would be sacrificing a great deal of flexibility.
I think a better solution would be to allow for some sort of standard way of allowing package developers to declare functions of the same name without producing errors or warnings and without referring to each others packages. For example, plot was mentioned, and everyone knows lots of packages export this function. It seems a bit silly to declare it in Base just because it’s a common word, but having something like
@coexist plot(p) = do_stuff(p)
would be nice. I don’t actually think this is possible in v0.6, but I may be wrong. I don’t know what compilation issues this would cause, if any. Perhaps one way of doing this would be to have a CommonFunctions module that only stores blank function declarations and gets recompiled whenever a packages using one of these functions is included.
Julia’s protocols provide us with the technology to specify, convey, enact, and validate specification conformance for apis and other flexibly refocusable capabilities.
(delivery this Fall, if it happen then)
I don’t think Base would be the right place for something like that. An option for frequently occurring function names might to create a package that just defines all those function names, possibly even with a suggested usage pattern, respectively order, type and purpose of arguments.
Other packages could pull that package as dependency and extend with their own methods.
If that common package is not going into Base, then it can also be updated and evolve independently and possibly faster. Also, this would make it somewhat independent from Julia versions it is used with.
For instance something like
"""
Module `Commons` provides function prototypes and proposes
canonical usage patterns for commonly defined function names.
Implementations are to be provided by packages that want to
adhere to these patterns.
"""
module Commons
export update!
"""
update!(x, ...)
Common function to update an object. The specific arguments
depend on the package providing the implementation of both
the object `x` and the method it is dispatched to.
"""
function update! end
end # module
I can imagine something similar for more generic abstract types, which is probably much more difficult to agree upon. Still, having those as an independent package could also allow a faster evolution, in particular if the type tree needs to be extended, say to insert a branch at some level inbetween.
In both cases some of the more popular packages would need to be willing to make such an effort to make it an accepted community standard.
that is good thinking – (for clarity, I had considered only the Abstract type declarations being available with Julia … I agree that more than that is too much)
as is the case with import Base.Dates:AbstractTime
I do not want to remember where each major Abstract type resides to import it.
If there were a Package, CommonAbstractTypes.jl that exported AbstractTime, AbstractInterval, … without any more specification than the single line declarations, might that fly?