Closed jpfairbanks closed 4 years ago
I'm OK with something like @program
.
That name works for me.
In keeping with your goal of decoupling the macros from the underlying implementations. Maybe https://github.com/epatters/Catlab.jl/blob/c1c2999f6e921028c942011c4e985559c9316ccf/src/programs/JuliaPrograms.jl#L241
should return a Catlab.Programs.Program
object that you then convert to a wiring diagram with to_wiring_diagram
. I could see some utility in having a representation of the program as an AST that you could manipulate before conversion to a WD. And then on they way back to code the compile_expr
could take a WD and return a Program
. Maybe Expr
is the right data structure for this and we don't need to introduce a Program
struct. This might be out of scope for a simple renaming issue, but I think "What is the best datastructure for storing 'catlab program notation'?" is worth thinking about.
Can we pick a shorter name for
@parse_wiring_diagram
? I have been putting presentations and wiring diagrams in slides and the name is kinda long. It would be better to have it be something short like@diagram
or@program
. I don't think the word parse needs to be there because the fact that it is a macro indicates that it operates on the expression that follows. And we only have one kind of diagram in Catlab, so I don't think it needs wiring either.If in the future, we want to have a macro for specifying commutative diagrams, then we could call that
@cd
like tikz-cd.