[gsoc] graph library

[Joseph Rushton Wakeling]

Hello Vasyl and everyone,

On Friday, 22 March 2019 at 10:43:05 UTC, Seb wrote:
> I think the best person to ask would be Joseph Wakeling 
> (https://github.com/WebDrake) as he's the author of Dgraph [1] 
> and was a GSoC mentor in the past.

In principle I would love to, but I really don't have the time 
right now, and I don't think that is going to change by the time 
GSoC 2019 goes live :-(

A few thoughts on the more general idea:

I think the idea of a more fully featured graph library is great, 
but I don't think we should build a `std.graph`, as the standard 
library is not really the best place for something like this.

For a graph library to really be useful, it will need a much 
broader range of functionality than is appropriate for a standard 
library (look at pretty much any of the major graph frameworks 
used in science, e.g. igraph, or NetworkX, and they are BIG 
codebases).  It will also need to be flexible: it's likely that 
any such library will want to be flexible in how it revises its 
internal data structures over time, as needs and use-cases change.

So I would recommend that we focus on creating a good library, 
and forget getting anything into phobos.

In terms of design inspiration: it's been a long while since I 
last looked at Boost::Graph but my memory is of a template horror 
that seemed far more complex than it needed to be, and yet whose 
internal data structures were probably not the most efficient.  
Don't take my word on this, I might be wrong (or just out of 
date), but it didn't seem like the best design concept to build 
from.  YMMV, of course ;-)

I also don't see the point in reproducing or closely mimicking a 
C++ API when the degree of C++ support is getting so much better. 
  Why not just use the existing library, or fix any blockers to 
doing so?

So, if we are going to do this, I would recommend:

   * implementing good underlying data structures before focusing 
on the user
     facing API

   * trying to create a friendly, idiomatic D API that does not 
too strongly mimic
     anything from other languages

   * ensuring friendly interop with Python, as a lot of people 
working in science
     will be using Python for their scripting, data science, and 
glue code

Lastly, regarding a remark in the proposal summary: who says 
DGraph is unmaintained? :-)  I'm not actively adding new features 
to it, as I don't have a personal use case, but if anyone has 
bugfixes or PRs, I would happily take a look.

Anyway, hope that helps, and apologies that I can't be of more 
active assistance,

All the best,

      -- Joe