Abstract vs concrete?

[st--]

Hi, I came across the POMDPs.jl Software paper and it reminded me of a point I had thought of before - what should "AbstractGP.jl" be? From the name, I had imagined it as a way of defining the "interface" of what GPs should look like in Julia - similar to what POMDPs.jl does, with concrete implementations in other packages (see https://github.com/JuliaPOMDP/). However, despite the name, there are lots of concrete implementations in here. What's the motivation for having them in here (rather than, for example, providing a "base GP" package implementing the AbstractGP interface)? Splitting it up that way might help encourage both more exploration by the community (trying out new ways of implementing the same interface) as well as increasing cohesion/interoperability by those. Right now, even though it's called "AbstractGP", it doesn't seem clear to someone coming from the outside that they really ought to fit their GP work in this interface. What are your thoughts on this?

[willtebbutt]

That's a fair point.

The intention was certainly that all of the stuff in here would be pure interface stuff.

My feeling was that you probably do want to bundle some standard functionality in with the interface. Perhaps we would benefit from decomposing stuff further? Or maybe we just need better documentation?

I agree that there is a surprisingly long list of things in this package for something that claims to be an interface package when compared to ChainRulesCore, for example.

[willtebbutt]

Actually yeah, looking through our documentation, we've really not properly highlighted the fact that we've defined an interface. At the very least we should refactor the README to make it clear that we

1. provide theAbstractGP interface + testing functionality, and
2. provide a couple of basic implementations of this interface.

[willtebbutt]

I believe that this was resolved a while ago