You're reading the public-facing archive of the Category Theory Zulip server.
To join the server you need an invite. Anybody can get an invite by contacting Matteo Capucci at name dot surname at gmail dot com.
For all things related to this archive refer to the same person.
I would like to find a categorical models for the programming langauge feature described below, which I call symbols. This idea is discussed in Part XIII of "Practical Foundations for Programming Languages" by Robert Harper, but I don't currently know whether my formulation below is equivalent to his.
There is some countably infinite type of symbols. This type has decidable equality; there is some function which determines whether two symbols are the same. Besides this, symbols have no internal structure (i.e. no structure available to the user of the language). Since is the only primitive function available which eliminates symbols, all deterministic functions for any type should be almost-everywhere constant, i.e. constant on all but finitely many inputs.
There is a special (nondeterministic) function , which I pronounce "symbolgen". Each time is evaluated, it produces a fresh symbol (i.e. a symbol that has never been produced before). In this way, can be seen as an idealization of the process of generating a random string of bits---so idealized that it is downright impossible to generate the same symbol twice.
So...do you know of any categorical formulations of this feature or a similar one? Since it involves nondeterminism, it feels like it could be modeled by (something like) a Markov category, with interpreted as a single nondeterministic function . I am especially interested in how this feature would interact with standard programming language features, such as inductive types.
To give a bit of context of this question...there are many purposes of this feature, but one of them is to serve as an abstract account of names (e.g. names of functions in a module system) which doesn't rely on some underlying structure, such as representing names as strings. Another application is to represent capabilities and access control explicitly---possession of a given symbol by a piece of code can indicate that that code is authorized to access certain information or modify data in a certain way. This is why it's important that never yields the same symbol twice; if I generate a symbol to serve as a guard for some data I want to protect, I want to be sure that no one else will be able to generate that symbol later.
If no references seem to surface, then I'll sit down and puzzle through it myself, but I'm wondering if there is any existing work on this or a similar problem.
Maybe not quite what you're looking for, but if you haven't seen them already you should look at [[nominal sets]].
perhaps obvious, but you could implement it with a monad on top of stlc
You may be interested in @Dario Stein 's Probabilistic Programming Semantics for Name Generation and the references to Stark's -calculus given there.
Also very relevant could be Section 25 in Dario's thesis, which describes a Markov category of nominal sets.
I've been toying around a bit myself with similar ideas and constructed a different Markov category of nominal sets. I'm not sure to what extent the following is reasonable from the programming perspective, so take it as merely an idea that may or may not be worth considering further.
Let me start with some background on nominal sets. Fix an infinite set , whose elements are thought of as basic variable names. Let be its group of finite permutations. Then let's say that a pre-nominal set is simply a -set, i.e. a set together with a homomorphism from to permutations on . The idea is that could e.g. be a set of expressions in your language, where the -action keeps track of how these expressions change upon changing the names of variables. The support of an is the smallest such that for implies . If you think of as an expression in your language, then this means that the support is the set of names that actually appear in it. Now a nominal set is a pre-nominal set such that every has finite support. If is a nominal set, then for any , there is such that and have disjoint support: you can always rename the variables in an expression such that they become disjoint from those appearing in another one.
If and are nominal sets, then the same considerations also apply to functions , since these form a -set of their own. We can now define a Markov category as follows:
My hypothesis is that this Markov category provides a sensible way to talk about the sort of nondeterminism that you want to model. But I'm not sufficiently familiar with programming language theory to confidently assert this.
Hi @Tobias Fritz, curious category. I've mainly considered the Kleisli category of the name generation monad on nominal sets for this kind of name generation. So I'm wondering whether your category has different properties as a Markov category? Or is there another reason that you propose it?
At first I thought your category might be very similar to the Kleisli category of the name generation monad, but , whereas I think has many elements for your category .
Also. I tried calculating , to check whether it was equal to . I couldn't get it, but maybe I misunderstood your definition, or made a mistake. Or maybe you didn't want this?
Hi Sam! The simple reason for me to come up with this category was that I had just learned about nominal sets and hadn't heard of the name generation monad :sweat_smile: So for anyone else reading this: @Sam Staton is the real expert here on these things!
So far, I haven't thought about this category at all other than its definition, so I don't know what properties it has. I agree with your calculations though. In particular, yes, the composite is not constant false, and not even constant. So somehow this category keeps track of more fine-grained information than the Kleisli category of the name generation monad: the resulting composite morphism remembers that you had picked one fresh name, but it doesn't remember which one.
So I don't really know what to make of this category. But given that the definition is pretty simple and natural (to anyone who knows about nominal sets), I think that there has to be some sensible interpretation or operational account of it. Would you agree with this expectation?
Here's an incomplete attempt at finding such an interpretation. Think of as the set of bank notes in circulation; this set is infinite for all practical purposes, so let's formalize it as an infinite set. Then a typical morphism could be represented by something like "given a bank note , answer yes if and only if has ever passed through my wallet". Then there is a definite fact of the matter about how many notes have passed through my wallet, but no definite fact of the matter about which ones, since the morphism really is the entire orbit of such a predicate.
In general, it looks like a morphism in this category has the power to treat finitely many names as special. But for every morphism, these finitely many special names are required to be fresh (due to composition being defined in terms of disjoint support).
Thanks Tobias. It's an interesting that you can have this "intensional" model -- I haven't seen it before.
As you probably know there are two monoidal closed structures on nominal sets. You used the cartesian closed one (finitely supported functions) as part of your construction. But I think if you'd used the other one, it would have been close to the usual name generation monad.
Thanks, I didn't know this! I suppose that the "other one" is the monoidal structure called separated product, right? I'm not sure how this gives a Markov category, because there are no diagonals ?
Thanks all for the responses and discussion! The references and ideas here seem to be exactly what I was looking for. It will take me some time to absorb all the details here, but I have a few follow-up questions:
What's a finitely supported function, concretely? Or maybe before that, what's the action of permutations on functions that you consider? (Sorry for the naive question...)
If and are -sets, then the action on functions is such that a group element acts on a function by producing the new function defined by . This -set of functions is the exponential object in the category of -sets, see Proposition 3.9.
A function is finitely supported if there is finite such that if is any group element that acts like the identity outside of , then also . I think of this as saying something like "only the variable names in appear in the definition of ".
So, any equivariant function is finitely supported, since we can even take . For a non-equivariant example, any constant function is finitely supported.
Thanks! Do you mean "acts like the identity on ", or am I confused? Is it right that the point of your category is to include more morphisms than the usual equivariant maps?
I do mean "identity outside of S". If you think of S as the set of variables names that occur in f, then permuting other variable names that do not occur in f doesn't do anything, but permuting those that do occur in f will generally result in a different expression.
But yes, the idea is to include more morphisms than the equivariant ones, constructing an interesting-looking Markov category like that. The equivariant morphisms are precisely those that are deterministic in the Markov cats sense
Tobias Fritz said:
I do mean "identity outside of S". If you think of S as the set of variables names that occur in f, then permuting other variable names that do not occur in f doesn't do anything, but permuting those that do occur in f will generally result in a different expression.
Sorry for being so thick, but "permuting variable names that do not occur in f" sounds to me like being identity on . Let me explain how I'm thinking so that maybe you can pinpoint where I'm derailing.
You seem to be saying that if g only permutes variable names that do not occur in f, then
, but
only permuting variable names that do not occur in f
is the same as
leaving variable names in $$S$$ unchanged
ie
being identity on $$S$$.
Where is this wrong?!
D'oh, of course you're right, and I've been very confused :grimacing: Looks like my explanation was fine, but my statement of the condition was off. Thanks for the correction!
Oh ok! Thanks for the explanation then :big_smile: