As Catlab matures and is used more seriously outside of our organization, we should start to think about exposing the some of the de-facto DSLs that we have "inside" Catlab to be usable via a "thinwaisted" connection to Catlab. Specifically, we should start thinking about entire modeling workflows which are not "run arbitrary Julia code that references Catlab", and are more abstracted and parameterized. And we should also think about how to expose Catlab to arbitrary Julia in such a way that we can change internals more easily. I.e., we right now expose most functionality because our "users" are other AlgebraicJulia packages, but we should think about what functionality we want to hide from the end-user so that when Catlab goes into production, we can change some internal details.
As Catlab matures and is used more seriously outside of our organization, we should start to think about exposing the some of the de-facto DSLs that we have "inside" Catlab to be usable via a "thinwaisted" connection to Catlab. Specifically, we should start thinking about entire modeling workflows which are not "run arbitrary Julia code that references Catlab", and are more abstracted and parameterized. And we should also think about how to expose Catlab to arbitrary Julia in such a way that we can change internals more easily. I.e., we right now expose most functionality because our "users" are other AlgebraicJulia packages, but we should think about what functionality we want to hide from the end-user so that when Catlab goes into production, we can change some internal details.