Directly Relevant:

• Graph
• Graph.GraphImpl
  • want to retype adjacency maps to be something like AdjMap = Dict (Set Vertex × Exists BaseVal)
  • Using existentials breaks equality for GraphImpl's, restricting to BaseVal Vertex or a Expr Vertex + BaseVal Vertex does not
  • Don't need Monoid/Semigroup on BaseVal, can just initialize to Nothing?
• Graph.Slice
• Graph.WithGraph
  • add extra argument to new, and new return type: new :: Set Vertex -> BaseVal -> m (BaseVal Vertex)
• EvalGraph
• Primitive.Defs
  Indirectly Relevant:
• Val
• App.Fig
• Test.Util
• Test.Benchmark.Util
• Module
• Pretty

Initial Experiment:

type AdjMap = Dict (Set Vertex × ValPointer)
newtype ValPointer = ValPointer (Maybe (BaseVal Vertex))

And pushing "reasonable" additional code through the rest of GraphImpl (setting everything ValPointer related to Nothing) breaks on slicing/array/dims, things just hang.
Edit: issue seems to have been in requiring a Monoid/Semigroup instance for ValPointer. Setting it up to directly push Nothing in as initial values seems to let things work as they should.

I am currently uncertain as to how much benefit we'd get from making this an existential. When a vertex is associated with an expression (as opposed to a value), we can simply have the ValPointer point to Nothing. Perhaps further on in the experiment packing things up as an existential will become paramount.

Add BaseVal argument to new:

Cannot naively add BaseVal argument, since it creates a cycle in module dependencies between WithGraph and Val.
Options:

• Move ForeignOp and related typedefs to Primitive.Defs: doesn't work, since it creates an indirect cycle between WithGraph, Val, and Primitive.Defs
• Abstract the BaseVal argument to new, add type parameter to MonadWithGraphAlloc: seems more of an appropriate avenue, but raises more questions:
  • How to handle primitives? Every OpGraph needs to be modified, first to just do nothing with the value
    Thinking that handling stuff at this point is why we might need existentials.
  • Move the idea of the ValPointer into Graph, since both Graph.WithGraph and Graph.GraphImpl inherit from here.

I've started pushing the DVertex type through eval. One thing that has come up repeatedly is the following pattern (which I don't really like):

eval _ (Int α n) αs = Val <$> new (insert α (unDVertex αs)) (pack v) <@> v
   where
   v = V.Int n

I'm unsure how to deal with this, right now it feels a little odd to make Val's store DVertex's instead of Vertex's. Then a Val would contain a value and an existential containing that value. The above pattern doesn't appear to slow things down too much in testing, so maybe it's fine to leave as it is for now.

@rolyp do you have any thoughts on whether I should try and figure out how to solve this, or is it worth pushing the Dvertex type through other parts of graph evaluation ?

Edit: performance wise, it doesn't appear to have an impact because Newtype's only exist at compile time, internally they are just tuples. So to resolve this, I'm considering adding a modified insert function which does the unDVertexing, just to clean up the code. Then, the above case will look like this:

eval _ (Int α n) αs = Val <$> new (insert' α αs) (pack v) <@> v
   where
   v = V.Int n

Introducing the new method to the Vertices class may be more problematic than we initially thought, due to the derived instance instance (Functor f, Foldable f) => Vertices (f Vertex). This method is used on EnvExpr, Val Vertex, and ProgCxt. I'm going to try out the naive option and see

Try introducing the new method via a new typeclass Vertices', that will avoid the problem.

@JosephBond For replacing the Show constraint, I think we probably want our own type class that will define some kind of typeName method (a constant function perhaps returning a type-level string, but let’s just say a string to start with). Then we should be able to write something like:

asVal :: VertexData -> Maybe (Val Vertex)
asVal (VertexData e) = 
  -- use `typeName e` to decide whether `e` contains a value
  -- if so then `unsafeCoerce`  

Then our predicate on vertices will be some other Maybe computation which composes (monadically) with this one.

Hi @JosephBond. Before continuing with #1279, let’s get this merged into develop – that will require a careful pass to tidy up any remaining loose ends, remove any spy calls, and also a manual check that the performance of the figure on the landing page of FluidOrg is still good after @jacobpake‘s fix.