You're Dr. Ryan Wisnesky, eh? Are y'all familiar with Conal Elliott's "Compiling to categories" work?
> It is well-known that the simply typed lambda-calculus is modeled by any cartesian closed category (CCC). This correspondence suggests giving typed functional programs a variety of interpretations, each corresponding to a different category. A convenient way to realize this idea is as a collection of meaning-preserving transformations added to an existing compiler, such as GHC for Haskell. This paper describes such an implementation and demonstrates its use for a variety of interpretations including hardware circuits, automatic differentiation, incremental computation, and interval analysis. Each such interpretation is a category easily defined in Haskell (outside of the compiler). The general technique appears to provide a compelling alternative to deeply embedded domain-specific languages.
I'm an independent (amateur) researcher working in the space of Categorical languages (Joy, my project: http://joypy.osdn.io/ )
I sort of "backed into" the categorical aspect of Joy when implementing type inference ( http://joypy.osdn.io/notebooks/Types.html ). You can evaluate a Joy expression in the "category of values" and get a computation, or in the "category of stack effects" and get a type signature. Elliott is converting Haskell code into Joy-like point-free form and implementing several interesting Categories.
Without going into a lot of detail, I became interested in Prolog (for implementing a Joy compiler) and went down a bit of a rabbithole. ( https://hg.sr.ht/~sforman/Thun/browse/default/thun ) Now I am in some sort of transition phase between what I used to be (mostly Python programmer) to what I'm becoming, a Prolog and Joy programmer.
Anyhow, do you think it would be worthwhile for me to apply? I have a kind of patron right now, but it would be nice if he had some help.
I'm still going to get in touch, because I'm really interested in what you're doing, but maybe I'm not in the right place to apply for anything yet. (We can talk about it.)
The Joy system I'm playing with has some UI ideas inspired by the Oberon OS and Jef Raskin's "Humane Interface", but other than that I'm not sure there's anything there for you. Joy itself might be a good UI "macro" language.
I've been meaning to work with CQL to see if it can make XML-to-other-stuff data migration easier. I can picture in my mind how I want the migration to go, but/and it's always a lot of error-prone, one-off work in $work_lang.
It makes so much more sense displayed visually than a fixed incremental list. It’s possible you could generate them automatically with some NLP and hand tweaking.
It seems to me that if you added time to one of these wiring diagrams (for the recipe use case), you would have a Gantt chart. This might also be leveraged to plan parallel processes in a recipe (e.g. making the second part of a mole sauce while waiting for the chilis to soak).
For complex recipes or meals, I could also see using the wiring diagram to represent a high level flow between sub-recipes, and then drilling down into a node to view the diagram for that sub-recipe. You might be able to mock this up with "milanote".
In the past I've built a dependency diagram for a complex dinner (dishes from the Eleven Madison Park cookbook) by scanning my markdown transcription of the recipes and generating a 'dot' file for graphviz. For planning meals like this, I think a Gantt-like representation would be useful. Some components were made a day or two ahead, some same day, and some steps had to be executed at the last minute.
Here’s a wiki page for that book
But this brings up a question about concrete structures and abstract qualities of programming languages.
Looking at, say, chapter 2, you have the problem of finding the least-costly recipe for a given task mapped to the abstract monoid structure.
Now, I understand a very nice approach where you essentially go:
Concrete real-world-problem -> abstract-problem, then utilize standard-abstract-facility for solving abstract-problem. If the abstract-facility is incorporated into the language itself, this can happen "effortlessly" and nearly invisibly.
But, this happy scenario can become an unhappy scenario when you have done all that, it works well, when suddenly you find the concrete problem has qualities that are completely irregular and don't fit the abstract model at all. Suppose cost of recipes varies in some weird, ad-hoc fashion, etc.
What to do? Data behaving in a regular fashion is the font of mathematical structures and allows powerful tools. But change that regular behavior to something less regular and you may or may-not get something ammenable to further abstract manipulation.
The thing is, if you take "recipes" becoming "monoids" and have your own library for deriving a category theoretical solution, and if then what "recipes" do suddenly is less category theoretical, then you can change your library - perhaps in a way that does violence to the concepts but still happens to work. But if you take "recipes" and use the built-in language facilities for the monoidal properties of a problem, you may have a lot more trouble modifying the map between concrete problem and abstract solution. And certainly, the modified library may be a long-term terrible solution if you expect the problem to grow. But suppose you don't, suppose you can benefit from exactly this level of abstraction and ad-hoc modification and would pay a bit for a lot of abstraction.
Is there something I'm missing in this criticism?
Edit: you're missing that to formulating the hard- and software stack we already have in a category theoretical metalanguage solves that problem also - but that requires overcoming DRM and lacking tooling for software analysis.
The simple fact is that CT is not a linga franca no matter how much advocates would like it to be.
Top of p.iv, "almost no introductory material available on monoidal categories." Wait, it was all about categories, now it is suddenly monoidal ones -- what is monoidal, is that a subset of the book subject, or a more precise term? Badly need a definition when first introducing a new term.
(Actually, that just highlights the point that the term "category" has been assumed and not defined to this point -- despite the audience not being expected to know what it is.)
Lemon pie diagram: of _course_ I can grasp the basic idea, but in what sense does the diagram illustrate category theory? Where are is the category (categories?), is it the pie, the lines, the nodes? It's probably blindingly obvious _after you understand the topic_ but at the opening of the book, the point needs to be explained even if the explanation seems redundant to the author.
Top paragraph on p.v flirts with a definition but doesn't actually define anything. Is a category "structures and coherence"? One "involves" (vague) "a collection of objects, a collection of morphisms relating objects, and a formula for combining any chain of morphisms into a morphism" and OK, here is a hint of familiar ground: this sounds a lot like category theory might be a generalization of classes, instances and methods, and functional composition, of software engineering. But the sentence about chains of chains ending in a happy "That's it!" doesn't really seem to follow. Onward.
Bottom of page 1, we finally get to some substance, although I really don't like the "Y is a meter" explanation because that whole paragraph kind of bodges the distinction between italic-capital-letter X and Y, which I am kinda sure you intend to represent classes or domains, with the word "object" which my prior training really wants to confine to singular instances of a domain. So what comes out of the map isn't a "meter Y" but "the reading displayed by the meter Y" but that doesn't work either.
Anyway, very shortly you drop in another new notation, "functions f from big-R to big-R" What does the big-R mean here? I'm casting about -- real-world-objects? set of Real numbers? Probably real numbers because the following features are about arithmetic comparisons and operations. But say it, dammit.
Order-preserving, ok, but -- why "metric-preserving"? How is absolute-difference a "metric"? But... this is an exercise and a challenging one, and I'm intrigued. Later.
I think that the best way forward in your case is simply googling terms that the writers took for granted and which you don't understand (a monoid, for example), because the book material is one of the best I've seen on category theory.
I recall that my personal experience of learning about CT was unnecessarily difficult due to being thrown into a bunch of definitions way to soon. (Which is understandable since there isn’t much else to it.) but I needed to un-learn my preconceptions about what information the theory encodes first, which was rally hard. Understanding that objects and morphisms are really _only_ about composability and _nothing else_ is challenging when your mind desperatly wants to see concrete thing like sets or numbers or what have you in those objects. Definition don’t help much until you can shed that urge. (To new learners I suggest to think of “objects” as the number of dots on domino tiles, or the poles of magnets, they describe where things may, or may not, compose, nothing more. category theory is just about naming patterns and rules of composition)
In particular even knowing the existence of monoidal categories is a distraction when getting to grips with how catgories as such generalize and abstracts monoids.
I had a similar experience. Luckily, due to reading many definitions of the basic things (such as monoids), I reached a more complete? intuition of the concept if you will. I think that given enough definitions, people will converge to the same intuition of abstract concepts.
> To new learners I suggest to think of “objects” as the number of dots on domino tiles, or the poles of magnets, they describe where things may, or may not, compose, nothing more
Wouldn't a simpler intuition of circles and arrows be easier?
Categories might be drawn using arrows and circles. But that’s just notation.