You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, PR #37 of DiagrammaticEquations.jl added support for a Match-Replacement approach. This silos imperative pointer-manipulation logic, and provides a declarative interface. “Matches” can be Symbols or Decapodes, and can be replaced with “Replacement” Symbols or Decapodes:
RHS =@decapodebegin
y ==∘(⋆,d,⋆)(X)
endreplace_op1!(MyDecapode, :div, RHS)
So, we should establish a library of definitions in DiagrammaticEquations.jl, and use that functionality in the Decapodes compiler.
The text was updated successfully, but these errors were encountered:
DiagrammaticEquations.jl PR 37 implemented a rewrite system (see e.g. Bonchi et al. for an overview), specialized to the case in which signatures are of arity 1 (corresponding to our Op1s) or arity 2 (corresponding to our Op2s) and are all of co-arity 1.
When I say "a Match-Replacement approach", I mean a term rewrite system. When I say "establish a library of definitions", I mean define a collection of rewrite rules.
Currently, each operator that can be expanded into its definition is expanded with bespoke operations on Decapodes:
However, PR #37 of DiagrammaticEquations.jl added support for a Match-Replacement approach. This silos imperative pointer-manipulation logic, and provides a declarative interface. “Matches” can be Symbols or Decapodes, and can be replaced with “Replacement” Symbols or Decapodes:
So, we should establish a library of definitions in DiagrammaticEquations.jl, and use that functionality in the Decapodes compiler.
The text was updated successfully, but these errors were encountered: