SigMod

Not that SIGMOD

Mari gave me a lift into town earlier for a Dr's appt. We arrived early so waited in the car for a while. Phones out.

Among the more recent of the 1987 Chrome tabs I had open ¹ was DSPy. It'd buzzed my radar on some previous occasion, when I only did the most cursory of skims. Today it reappeared from a different direction so I had a better look. A line in the page made me laugh out loud.

I'm sure you're familiar with :

There are only two hard things in Computer Science: cache invalidation and naming things.

- Phil Karlton (Martin Fowler has backstory & variants)

I've struggled a lot with naming in my #:transmissions pipeliney-thing subproject. The fine line between getting the correct term semantically but without using a term that is so heavily overloaded as to confuse. A good example was Service, which I started with for a particular kind of unit of code. It worked ok for these fairly independent little nodejs chunks that act as processing nodes in the s/pipeline/graph Transmission. But although these things might be implemented as eg. microservices, that term brought the potential implication that some remote-calling protocol (like HTTP) had to be involved (they are identified with URIs, another layer of misdirection). Going in the other direction, Function was another candidate. The shape is y = f(x). But that's rather a no-no in a language where it's already a reserved word, not to mention that most won't be pure functions, hell to pay from the Church.

These things appear in the current and only implementation of #:transmissions as a single function wrapped in a class inside an EcmaScript module. But they have a single object as input, a single transformed object as output (not really, but ok as first approx, the rest is tangential). Their purpose (first approx) is to process a message. Name I settled on Process.

I've been working on #:transmissions for about a year now. The initial motivation was that I had a variety of things to build, they all shared (at a suitable level of abstraction) the same pipeliney structure. I roughed something out, first just for a static site generator. In the process bringing LLMs into my workflow, serendipity kicked in. It turned out to be fairly optimal for what you can get in an LLM's context window. The Transmission at the planning level, and individual Processes are all at a level of complexity that the LLM can handle comfortably. It's also humanly-checkable, programming best practices, testable etc. The structural, nuts & bolts bits of #:transmissions do go beyond. I have actually had to think about things myself there (boo!). Still not nailed down enough to proclaim a v1.0.0, still loads in flux.

Going back to the naming. So a Process has an input (message) and output (message) as well as internal behaviour. To be able to collaborate with the LLM on these things (and for any future use) there needs to be some #:LingueFranche to describe these things. A quasi-formal language, perhaps. I started with a comment block in the code (so it'd work with JSDoc), since going much more RDF (because WWW). I've still not got the details ironed out, but early on I settled on a name for these descriptions of process modules, things in a space not quite Contracts, but different from OO/service Interfaces : Signature.

Imagine my delight on finding this line in the DSPy docs :

For every AI component in your system, you specify input/output behavior as a signature and select a module to assign a strategy for invoking your LM.

Yeah, I laughed out loud. The context is only slightly different (major overlaps), but I love that I, and the folks behind this had converged on pretty much the same vocab.