Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics comma complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration finite foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).
    • CommentRowNumber1.
    • CommentAuthoratmacen
    • CommentTimeDec 12th 2019

    Trying to write down a(nother) set of typing rules.

    v1, current

    • CommentRowNumber2.
    • CommentAuthoratmacen
    • CommentTimeDec 12th 2019

    That’s it for the rules. Trying to add some links now.

    diff, v5, current

    • CommentRowNumber3.
    • CommentAuthoratmacen
    • CommentTimeDec 12th 2019

    Fixed example.

    diff, v6, current

    • CommentRowNumber4.
    • CommentAuthorMike Shulman
    • CommentTimeDec 12th 2019

    Change \Box to \boxtimes.

    diff, v8, current

    • CommentRowNumber5.
    • CommentAuthorMike Shulman
    • CommentTimeDec 12th 2019

    (\boxtimes works fine for me, does it not show up for you or something?)

    • CommentRowNumber6.
    • CommentAuthorMike Shulman
    • CommentTimeDec 12th 2019

    Can you give some example judgments, so I can get a feel of what you’re going for?

    Also, what is the intended semantic meaning of your judgment UΓt:TUΓU \subseteq \Gamma \vdash t\,:\,T\,\boxtimes\,U' \subseteq \Gamma'?

    • CommentRowNumber7.
    • CommentAuthoratmacen
    • CommentTimeDec 12th 2019

    \boxtimes is working. I thought I tested it, but I guess I messed up.

    UΓt:TUΓU \subseteq \Gamma \vdash t\,:\,T\,\boxtimes\,U' \subseteq \Gamma' should basically mean ((ΓΓ)U)(TU)((\Gamma \mapsto \Gamma')U) \multimap (T \otimes U'), where the usage sets get considered as multisets of types and tensored up.

    You have:

    {x,y}x:A,y:B,z:C(y,x):BA{}x:A,y:B,z:C\{x,y\} \subseteq x:A,y:B,z:C \vdash (y,x)\,:\,B \otimes A\,\boxtimes\,\{\} \subseteq x:A,y:B,z:C

    or

    {x,y,z}x:A,y:B,z:C(y,x):BA{z}x:A,y:B,z:C\{x,y,z\} \subseteq x:A,y:B,z:C \vdash (y,x)\,:\,B \otimes A\,\boxtimes\,\{z\} \subseteq x:A,y:B,z:C

    from \otimes intro and two variable rules. Is that the kind of example you want?

    {x,z}x:A,y:B,z:C(y,x)\{x,z\} \subseteq x:A,y:B,z:C \vdash (y,x)

    fails, since yy is not available.

    • CommentRowNumber8.
    • CommentAuthoratmacen
    • CommentTimeDec 12th 2019

    Since my judgment form is intended to be a fancier version of the one in Allais’ paper, it might help to read explanations from there. Allais writes my Γ\Gamma as γ\gamma, and my UU and UU' as Γ\Gamma and Δ\Delta. He leaves γ\gamma implicit, since it can be inferred from the type of his Γ\Gamma. The new features in my judgment form are Γ\Gamma' and scope delimiters.

    • CommentRowNumber9.
    • CommentAuthoratmacen
    • CommentTimeDec 12th 2019
    Oh right: and Allais has multiple judgments for bidirectional checking, and I don’t. But the contexts/usage gets handled the same in all his judgment forms.
    • CommentRowNumber10.
    • CommentAuthorMike Shulman
    • CommentTimeDec 12th 2019

    Does that mean the types in ΓU\Gamma\setminus U are meaningless? What is the difference between

    {x,y}x:A,y:B,z:C(y,x):BA{}x:A,y:B,z:C\{x,y\} \subseteq x:A,y:B,z:C \vdash (y,x)\,:\,B \otimes A\,\boxtimes\,\{\} \subseteq x:A,y:B,z:C

    and

    {x,y}x:A,y:B(y,x):BA{}x:A,y:B\{x,y\} \subseteq x:A,y:B \vdash (y,x)\,:\,B \otimes A\,\boxtimes\,\{\} \subseteq x:A,y:B

    ? Also it seems wrong to have Γ\Gamma' on the right-hand side of the \vdash, since according to ((ΓΓ)U)(TU)((\Gamma \mapsto \Gamma')U) \multimap (T \otimes U') it is actually saying something about the domain of the morphism. How is this judgment different from just giving ((ΓΓ)U)Ut:T((\Gamma\mapsto \Gamma')U) \setminus U' \vdash t:T together with a list UU' of extra types?

    • CommentRowNumber11.
    • CommentAuthoratmacen
    • CommentTimeDec 12th 2019

    Well the resources in ΓU\Gamma \setminus U cannot be used in the term you’re checking. Normally you’d fire up these rules with UU having all of Γ\Gamma, so as you go along, ΓU\Gamma \setminus U is the resources that have already been used.

    What is the difference between…

    Those are basically the same, semantically. The first can be obtained from the second by weakening. Allais says “weakening” for adding to the contexts, and “framing” for adding to the usage sets without affecting the contexts.

    Also it seems wrong to have Γ\Gamma' on the right-hand side of the \vdash,

    For understanding the design of the rules, you should think of a UΓU \subseteq \Gamma together as a state. UΓU \subseteq \Gamma on the left is the initial state; UΓU' \subseteq \Gamma' on the right is the final state. It doesn’t need to match up perfectly with the semantics. Formally, UΓt:TUΓU \subseteq \Gamma \vdash t\,:\,T\,\boxtimes\,U' \subseteq \Gamma' is a six-place relation.

    How is this judgment different from just giving ((ΓΓ)U)Ut:T((\Gamma\mapsto \Gamma')U) \setminus U' \vdash t:T together with a list UU' of extra types?

    I don’t understand the question.

    • CommentRowNumber12.
    • CommentAuthoratmacen
    • CommentTimeDec 12th 2019

    I suppose you could think of (ΓΓ)UUt:T(\Gamma \mapsto \Gamma')U \setminus U' \vdash t\,:\,T as the same six-place relation, written differently. I prefer my notation.

    There’s another paper where they did actually put the output context in between a \setminus and the \vdash. (They actually used a different symbol than turnstile.) That paper doesn’t keep a separate usage set. I tried that first, but those last two hairy rules seem to need it.

    • CommentRowNumber13.
    • CommentAuthoratmacen
    • CommentTimeDec 13th 2019

    I guess it would be pretty insane to actually interpret a term as a morphism of type ((ΓΓ)U)(TU)((\Gamma \mapsto \Gamma')U) \multimap (T \otimes U') like I said. It’s probably important that this morphism equals fid Uf \otimes id_{U'} where f:((ΓΓ)UU)Tf\,:\,((\Gamma \mapsto \Gamma')U \setminus U') \multimap T. So you really want to just deal with that ff.

    • CommentRowNumber14.
    • CommentAuthorMike Shulman
    • CommentTimeDec 13th 2019

    I was not thinking of (ΓΓ)UU(\Gamma\mapsto\Gamma')U\setminus U' as syntax but as an operation performed on these contexts. What do you gain by decomposing the context of the term t:Tt:T into “(ΓΓ)UU(\Gamma\mapsto\Gamma')U\setminus U'”? Why do you bother keeping track of “resources that have already been used” if you can’t use them any more?

    • CommentRowNumber15.
    • CommentAuthorMike Shulman
    • CommentTimeDec 13th 2019

    From my perspective it looks like you’re describing the domain of a morphism in a hugely overcomplicated way: start with a list of objects (UU), write down another list of objects that you aren’t going to use at all but you decided you wanted to write down anyway for some reason (ΓU\Gamma\setminus U), add to the first list another list of objects that for some reason you neglected to include the first time (ΓΓ\Gamma'\setminus \Gamma), and then remove some objects from the second list that you changed your mind about and aren’t going to use after all (UU'). Why all the detours?

    • CommentRowNumber16.
    • CommentAuthorMike Shulman
    • CommentTimeDec 13th 2019

    What do you mean by referring to my system as “not-especially-algorithmic”? What sort of algorithm are you looking for? I did describe a type-checking algorithm, didn’t I?

    • CommentRowNumber17.
    • CommentAuthoratmacen
    • CommentTimeDec 13th 2019
    • (edited Dec 13th 2019)

    Re #14:

    Well there are two questions, I guess. One is “Why not just Γt:TΓ\Gamma \vdash t:T \boxtimes \Gamma'?” and the other is “Why not just (ΓΓ)t:T(\Gamma \setminus \Gamma') \vdash t:T?”. The second is easier to answer: Γ\Gamma is an input to the algorithm while Γ\Gamma' is an output. How would you find ΓΓ\Gamma \setminus \Gamma' otherwise?

    As for the first question, the problem is that projections get added to the context. That is Γ\Gamma' can have projections not in Γ\Gamma. Suppose one of them is used. For example:

    {x}x:Af (1)(x):B{f (2)(x)}x:A,f (1)(x):B,f (2)(x):C\{x\} \subseteq x:A \vdash f_{(1)}(x)\,:\,B\,\boxtimes\,\{f_{(2)}(x)\} \subseteq x:A,f_{(1)}(x):B,f_{(2)}(x):C

    I want to know that the resources used by the term are {x,f (1)(x)}\{x,f_{(1)}(x)\}. This is (ΓΓ)UU(\Gamma \mapsto \Gamma')U \setminus U'. If I try to avoid usage sets, I suppose I might have:

    x:Af (1)(x):Bf (2)(x):Cx:A \vdash f_{(1)}(x)\,:\,B\,\boxtimes\,f_{(2)}(x):C

    But now how do I tell what I’ve used? ΓΓ\Gamma \setminus \Gamma' is just xx. Well maybe I don’t really need to know. But there’s an example where it helps to know: g (1)(f (1) u())g_{(1)}(f^u_{(1)}()) should be OK, I think, with appropriately-typed generators. You don’t need another label for the application of gg. But the only thing f (1) u()f^u_{(1)}() uses is itself. If that doesn’t count, the rules would require another label for gg.

    • CommentRowNumber18.
    • CommentAuthoratmacen
    • CommentTimeDec 13th 2019
    • (edited Dec 13th 2019)

    Re #16: You sketched a proof, using a combination of rules and English, that an algorithm exists that is essentially implementing your rules. I would say one can not just read off a type checker from your rules, which is what I expect for algorithmic rules. BTW, I’m aware that my rules are a different algorithm from yours. edit: Even once you remove \multimap.

    • CommentRowNumber19.
    • CommentAuthorMike Shulman
    • CommentTimeDec 13th 2019

    I assume that in your example

    {x}x:Af (1)(x):B{f (2)(x)}x:A,f (1)(x):B,f (2)(x):C\{x\} \subseteq x:A \vdash f_{(1)}(x)\,:\,B\,\boxtimes\,\{f_{(2)}(x)\} \subseteq x:A,f_{(1)}(x):B,f_{(2)}(x):C

    the generator ff has type A(B,C)A \to (B,C). But according to the principle ((ΓΓ)UU)T((\Gamma \mapsto \Gamma')U \setminus U') \to T this judgment should be describing a morphism (A,B)B(A,B) \to B. How do you get such a morphism from f:A(B,C)f:A \to (B,C)?

    • CommentRowNumber20.
    • CommentAuthorMike Shulman
    • CommentTimeDec 13th 2019

    Re #18, it’s true that the algorithm has to make two passes, first to calculate which types are active. But I think it’s misleading to describe the entire system as “not especially algorithmic” just because the algorithm is a bit more complicated.

    • CommentRowNumber21.
    • CommentAuthoratmacen
    • CommentTimeDec 13th 2019

    Re #20: If the rules were algorithmic, and the algorithm has two passes, then the rules would have two passes. To me it seems clear cut that your rules are not themselves an algorithm. But you can change the page.

    • CommentRowNumber22.
    • CommentAuthoratmacen
    • CommentTimeDec 13th 2019

    Re #19: Good point. So I guess my #13 is all wet. As you can see, I haven’t given the semantics as much thought. My reason for confidence in these rules is that I think all the terms that are well typed by them can be translated to well typed ordinary MILL.

    • CommentRowNumber23.
    • CommentAuthoratmacen
    • CommentTimeDec 13th 2019

    Re #19: So my first guess, that the interpretation has type ((ΓΓ)U)(TU)((\Gamma \mapsto \Gamma')U) \to (T \boxtimes U'), says (A,B,C)(B,C)(A,B,C) \to (B,C), which is also wrong. I should try and actually figure this out. But guess three is U(TU)U \to (T \boxtimes U'). :)

    • CommentRowNumber24.
    • CommentAuthorMike Shulman
    • CommentTimeDec 13th 2019

    Tried to clarify the idea section.

    diff, v10, current

    • CommentRowNumber25.
    • CommentAuthorMike Shulman
    • CommentTimeDec 13th 2019

    I could understand UTUU \to T\boxtimes U' as saying that the algorithm typechecks a term t:Tt:T in context UU and deduces along the way the other terms UU' that “should” occur in it but don’t. But I don’t follow the argument in #17 for why you want the extra unused stuff in Γ\Gamma and Γ\Gamma' as well.

    • CommentRowNumber26.
    • CommentAuthoratmacen
    • CommentTimeDec 14th 2019

    Corrected(?) the motivation behind the “\boxtimes” symbol.

    diff, v11, current

    • CommentRowNumber27.
    • CommentAuthoratmacen
    • CommentTimeDec 14th 2019

    Re #25: I don’t know a justification other than what I said in #17 about figuring out when a label is needed. But Allais also has a difference between the context and usage. It’s similar to how, in your mode theory stuff with Licata and Riley, there’s a difference between the context and the “context descriptor”, which is a term in the mode theory.

    In Allais, the handling of the plain context is entirely standard for fully structural intuitionistic logic. Usage is propagated left to right, rather than (I assume) leaves to root for a context descriptor.

    In my setup, the context is also updated, going from left to right, to add projections. This is meant to correspond to realizing we’re inside the implicit tensor match expressions.

    • CommentRowNumber28.
    • CommentAuthoratmacen
    • CommentTimeDec 14th 2019

    It’s starting to seem very plausible to me that guess three (UTUU \to T \boxtimes U') is actually right. You want to compose these in the same roughly left-to-right order the rules use, and then it should fit. This was not intuitive to me because it’s not using most of the extra information the algorithm maintains, and it’s intuitively a very asymmetrical approach to constructing the morphism, where we’ve arbitrarily attributed a generator instance to its textually leftmost appearance.

    • CommentRowNumber29.
    • CommentAuthoratmacen
    • CommentTimeDec 14th 2019

    Oh wait, no, it probably isn’t. Consider the example from the page: λx:A.((λy:B.(y,f (1)(x))),f (2)(x))\lambda x:A.((\lambda y:B.(y,f_{(1)}(x))),f_{(2)}(x))

    The f (1)(x)f_{(1)}(x) subexpression gets checked in the usage and context {x};x:A;y:B\{x\} \subseteq ;x:A;y:B. The result is {x};x:A;y:Bf (1)(x):C{f (2)(x)};x:A,f (1)(x):C,f (2)(x):D;y:B\{x\} \subseteq ;x:A;y:B \vdash f_{(1)}(x)\,:\,C\,\boxtimes\,\{f_{(2)}(x)\} \subseteq ;x:A,f_{(1)}(x):C,f_{(2)}(x):D;y:B.

    Guess three would be to interpret this as a morphism A(C,D)A \to (C,D). Such a morphism would need to involve the application f(x)f(x). But this is wrong. That was the whole point of the example: the application has to happen outside the λy\lambda y.

    It seems you cannot compositionally interpret a term as just a morphism in my system. I should enhance the rules into elaboration rules that put in the tensor matches. Assuming the interpretation of ordinary MILL is compositional, this elaboration should also indicate how to interpret.

    • CommentRowNumber30.
    • CommentAuthorMike Shulman
    • CommentTimeDec 15th 2019

    Huh. I have to say that sounds to me like a death knell for usability as an internal language of symmetric monoidal categories.

    • CommentRowNumber31.
    • CommentAuthoratmacen
    • CommentTimeDec 15th 2019
    How come?
    • CommentRowNumber32.
    • CommentAuthorMike Shulman
    • CommentTimeDec 16th 2019

    If I can’t figure out what morphism a term represents without translating it into match syntax, then what good is it to have a syntax without matches?

    • CommentRowNumber33.
    • CommentAuthoratmacen
    • CommentTimeDec 16th 2019

    But you can figure out what morphism a term represents without translating it into match syntax. It’s just that this process is perfectly analogous to translating it to match syntax. In other words, the translation is a representative special case of interpretation.

    The match syntax is the “true” syntax, and we’re both cheating to use projections. You cheated one way; I’m proposing another way of cheating. Don’t be too fussy.

    • CommentRowNumber34.
    • CommentAuthorMike Shulman
    • CommentTimeDec 16th 2019

    I don’t see any kind of cheat about my approach, or any reason to believe that the match syntax is “truer”.

    When you have a complete syntax with a rigorous and clearly explained interpretation into symmetric monoidal categories, then I’ll be happy to look at it again and see whether I think it is useful.

    • CommentRowNumber35.
    • CommentAuthoratmacen
    • CommentTimeDec 16th 2019
    I’m not going to do that. I’ll do elaboration rules if that might be sufficient for you to understand the interpretation. Should I?
    • CommentRowNumber36.
    • CommentAuthoratmacen
    • CommentTimeDec 17th 2019

    In Idea section: incomplete -> unverified

    “Incomplete” makes it sound like one cannot attempt to use the system as is. But one could use it as a type checker, and I think it works.

    diff, v13, current

    • CommentRowNumber37.
    • CommentAuthoratmacen
    • CommentTimeDec 17th 2019

    π\pi function is redundant.

    diff, v14, current

    • CommentRowNumber38.
    • CommentAuthorMike Shulman
    • CommentTimeDec 17th 2019

    Well, I don’t have a lot of time to try to puzzle it out, and I’m not optimistic that it’ll work, but if you do I’ll have a look at it.

    • CommentRowNumber39.
    • CommentAuthoratmacen
    • CommentTimeDec 17th 2019

    Re #34: Let me try to summarize what I think are the similarities and differences of our approaches:

    We both start with approximately the same system of raw terms.

    My system is syntax-directed, yours is not.

    In your system, derivations represent PROP morphisms; in my system, derivations don’t themselves seem to have categorical significance.

    So it seems like your approach is to have the derivation rules stay close to the semantics, whereas my approach is to have the derivation rules stay close to the syntax.

    It seems that neither of us manage a compositional interpretation of terms into morphisms. You have a compositional interpretation of derivations. It sounds like you know a way to make your rules syntax-directed, but this change might mess up the compositionality of the interpretation.

    This is why I say we’re both cheating. With match expressions in the raw syntax, the whole process from syntax to semantics could be compositional. Maybe “true” was a bad choice of word for matching syntax. I meant that it corresponds most closely to the categorical operations you have by assumption in the semantics.

    • CommentRowNumber40.
    • CommentAuthoratmacen
    • CommentTimeDec 17th 2019
    I think that if I work out the elaboration version of my system right, the derivations can be interpreted as PROP morphisms after all. I don’t know what equations you’d need.
    • CommentRowNumber41.
    • CommentAuthorMike Shulman
    • CommentTimeDec 17th 2019
    • (edited Dec 17th 2019)

    Apparently by “syntax-directed” you mean “requires only one pass to type-check”? That’s a strange usage. But anyway, the whole point of how I set things up is so that terms in my system have unique derivations, so they do compositionally interpret into morphisms as well. No cheating.

    Match expressions arguably correspond most closely to the categorical operations in a symmetric multicategory. But the operations in my syntax correspond most closely to the categorical operations in a prop.

    • CommentRowNumber42.
    • CommentAuthorMike Shulman
    • CommentTimeDec 17th 2019

    FWIW, I think there is an alternative version of my system that only requires one pass and dispenses with the activeness annotations, by requiring generators to be applied as late as possible instead of as early as possible. I’ve put up a brief sketch here (link not long-term stable). In hindsight, probably this is simpler overall and I should just do it this way, unless there is some obstacle that I’m not seeing right now.

    • CommentRowNumber43.
    • CommentAuthorTodd_Trimble
    • CommentTimeDec 17th 2019

    But anyway, the whole point of how I set things up is so that terms in my system have unique derivations, so they do compositionally interpret into morphisms as well.

    That is a very useful comment; thanks.

    • CommentRowNumber44.
    • CommentAuthoratmacen
    • CommentTimeDec 17th 2019
    • (edited Dec 17th 2019)

    Apparently by “syntax-directed” you mean “requires only one pass to type-check”? That’s a strange usage.

    That’s definitely not what I meant by “syntax-directed”. I don’t know what I meant in hindsight; I misused it. What I think it usually means is that the correct rule to apply to a goal can be chosen by a shallow examination of the inputs. What I was getting at though is that the tree structure of your derivations is very different from that of the terms. (And this is at least unusual for syntax-directed rules.)

    …terms in my system have unique derivations, so they do compositionally interpret into morphisms as well. No cheating.

    I did say you have a compositional interpretation of derivations. I attempted to explain why I consider it cheating anyway, and it seems I was entirely unsuccessful. One more time: the interpretation of terms is not compositional. (At least not in a strong sense that I probably shouldn’t’ve brought up.)

    I have been trying to say that we have two different ways of dealing with this.

    Match expressions arguably correspond most closely to the categorical operations in a symmetric multicategory. But the operations in my syntax correspond most closely to the categorical operations in a prop.

    Match expressions are raw term formers. For an apples-to-apples comparison, you’d be saying that your raw term formers, like projecting an individual component of a generator instance, correspond to categorical operations in a prop. But unless I’m completely confused, that is totally false.

    edit: I realize that your operations on derivations correspond well to prop operations. This is a goal for my elaboration rules.

    Re #42, I’ll take a look.

    • CommentRowNumber45.
    • CommentAuthoratmacen
    • CommentTimeDec 17th 2019
    Wait a sec. You’re saying you do consider your interpretation of terms compositional? What do you mean by that?
    • CommentRowNumber46.
    • CommentAuthoratmacen
    • CommentTimeDec 17th 2019

    Re #42:

    I like this better. I think you should not require σ\sigma to preserve the relative order of Θ\Theta. And you have too many derivations of (|)(|), since the main rule can also derive that.

    It still seems virtually impossible to add type constructors.

    • CommentRowNumber47.
    • CommentAuthoratmacen
    • CommentTimeDec 17th 2019

    Oh darn, were you testing me? Now I don’t think it works at all. Consider something like (g(f (1)(x)),f (2)(x)|)(g(f_{(1)}(x)),f_{(2)}(x) |) The rule doesn’t allow passing through f (2)(x)f_{(2)}(x).

    • CommentRowNumber48.
    • CommentAuthorMike Shulman
    • CommentTimeDec 17th 2019

    Match expressions are raw term formers. For an apples-to-apples comparison, you’d be saying that your raw term formers, like projecting an individual component of a generator instance, correspond to categorical operations in a prop.

    That’s not the right comparison. It may seem like the right comparison, but only because we’re more used to thinking about type theories in which a morphism is characterized by a single term. The role played by terms in ordinary MILL (for instance) is played in my system by lists of terms: in each case it is a raw syntactic notion that, when well-typed, suffices to characterize a derivation and hence a morphism in a free category. It’s an accident that my “lists of terms” are lists of things each of which individually has some formal similarity to MILL terms; the proper thing to look at when comparing them is the role that they play in the type theory. Is particular, the proper question to ask is whether the operations on lists of terms correspond compositionally to categorical operations in a prop, and they do: as I showed, composition in a prop corresponds to substitution of lists of terms, and so on. Similarly, the tree structure of derivations maps straightforwardly onto the tree (“forest”?) structure of lists of terms.

    Consider something like (g(f (1)(x)),f (2)(x)|)(g(f_{(1)}(x)),f_{(2)}(x) |) The rule doesn’t allow passing through f (2)(x)f_{(2)}(x).

    Yes, you’re right, that’s a problem. I’ll have to think about whether there’s a way to solve it.

    Having too many derivations of (|):()(|):() should be easy to solve, just require in the main rule that there is at least one generator or variable. But why do you say σ\sigma shouldn’t preserve the order of Θ\Theta? Note that ΘΓ\Theta\subseteq\Gamma need not be order-preserving.

    • CommentRowNumber49.
    • CommentAuthorMike Shulman
    • CommentTimeDec 17th 2019

    I think there is a one-pass algorithm that does what I want, but I’m not sure right away how to write it as inference rules. Just look at the list of terms and peel off those that include all the components of a given generator application, leaving alone those that are missing some of the components.

    • CommentRowNumber50.
    • CommentAuthorMike Shulman
    • CommentTimeDec 17th 2019

    that the correct rule to apply to a goal can be chosen by a shallow examination of the inputs.

    Ah, yes, I think I see what you mean now. That is, you match the inputs against some pattern and that determines the rule to be fired; if that rule then fails the entire typechecking fails, without any need or possibility to “backtrack”. (Perhaps this means the algorithm is, in some sense, a simple application of the induction principle for the raw syntax?) So, for instance, ordinary dependent type theory doesn’t have this property, because you can’t guess when to apply the conversion rule; but a bidirectional form of it might be.

    At the moment, it seems unlikely to me that any set of rules for directly typechecking the terms I have in mind could have this property. Consider for instance

    x:A,y:A(f (1)(x),g(f (2)(x),f (1)(y)),f (2)(y)):(B,D,C) x:A, y:A \vdash (f_{(1)}(x), g(f_{(2)}(x),f_{(1)}(y)), f_{(2)}(y)) : (B,D,C)

    where f:A(B,C)f:A \to (B,C) and g:(C,B)Dg:(C,B) \to D. The only way to typecheck this is to peel off gg first and then afterwards both ff’s. But I don’t see any way you could deduce from a shallow pattern-match that you have to do that versus, for instance, considering the initial f (1)(x)f_{(1)}(x) and the final f (2)(y)f_{(2)}(y) as two components of a single application of ff, which seems initially plausible from the fact that their head-symbols f (1)f_{(1)} and f (2)f_{(2)} match the co-binary nature of the generator ff.

    The system I wrote in my paper solves this problem by first traversing the terms to calculate depths, and then requiring the terms of greatest depth (i.e. the “active” ones) to be dealt with first. Another alternative might be to assign labels to all generator applications, not just the nullary ones, producing for instance

    x:A,y:A(f (1)(x),g(f (2)(x),f (1)(y)),f (2)(y)):(B,D,C) x:A, y:A \vdash (f'_{(1)}(x), g(f'_{(2)}(x),f''_{(1)}(y)), f''_{(2)}(y)) : (B,D,C)

    in which you can tell from shallow analysis that f (1)(x)f'_{(1)}(x) and f (2)(y)f''_{(2)}(y) don’t match because they have different labels. The labels on positive-ary generator applications could then be left off in practice and calculated by a preliminary traversal, like the depths/activeness. At the moment I don’t see much reason to prefer one approach over the other.

    • CommentRowNumber51.
    • CommentAuthoratmacen
    • CommentTimeDec 17th 2019

    Having too many derivations of (|):()(|):() should be easy to solve,

    Agreed.

    But why do you say σ\sigma shouldn’t preserve the order of Θ\Theta?

    Oh I see. You’re right. The order of Θ\Theta is obtained from the list of terms, using the constraint.

    • CommentRowNumber52.
    • CommentAuthoratmacen
    • CommentTimeDec 18th 2019

    you match the inputs against some pattern and that determines the rule to be fired … without any need or possibility to “backtrack”

    Yeah, I think so. I’m fuzzy on what exactly should count as “shallow examination”. For example, nonlinear pattern matching performs deep equality tests. I implicitly use deep equality to test whether a projection is in the context.

    (Perhaps this means the algorithm is, in some sense, a simple application of the induction principle for the raw syntax?)

    Technically no, I don’t think so. That would imply the algorithm always terminates, which isn’t necessary for syntax-directedness.

    At the moment, it seems unlikely to me that any set of rules for directly typechecking the terms I have in mind could have this property…

    I think you’re over-thinking it. Once you know you can peel off gg, you know you have to use your non-base-case rule. Whether you need deep equality tests at all is another issue. You do. So even if it turns out you need equality just to pick a rule, I don’t care.

    • CommentRowNumber53.
    • CommentAuthoratmacen
    • CommentTimeDec 18th 2019

    That’s not the right comparison.

    Maybe it’s not the right comparison to make your point, but it is the right one to make mine, which is simply that MILL provides a compositional interpretation of its terms, whereas your system doesn’t provide a compositional interpretation of its terms, as I understand it. But I’m hoping for a reply to #45 to clarify.

    I’m not talking about compositionality of derivations or the gadgets they’re about. I already knew about that.

    It’s an accident that my “lists of terms” are lists of things each of which individually has some formal similarity to MILL terms;

    But as I understand, one of the main selling points of your system is that it supports tensor projections in the raw syntax. You can’t say the raw syntax is both a selling point and an accident. If it’s an accident, I can replace it with something easier and you’re not allowed to complain. But I already asked about that in the last thread and you seemed insistent on keeping your raw syntax. It seems like a worthwhile point whether this syntax is interpreted compositionally.

    My system keeps roughly the same raw terms as yours and completely changes the derivations. This subthread was started by a certain observation about something our systems had in common (they “cheat”), setting them apart from MILL, so no wonder it was about raw terms.

    • CommentRowNumber54.
    • CommentAuthoratmacen
    • CommentTimeDec 18th 2019

    Re #49: OK I think I get it. Yeah, I don’t know a cute way to express that. For the actual implementation, you’d want a clever-ish loop over the list of terms that figures out the set of indexes to peel and the permutation. I suppose you can put all the variables back in the base case.

    • CommentRowNumber55.
    • CommentAuthorMike Shulman
    • CommentTimeDec 18th 2019

    That would imply the algorithm always terminates

    That’s one of the things I meant to encompass by “in some sense”. E.g. you can define it in Agda by a simple pattern-match if you turn off the termination-checker. (-:

    Maybe it’s not the right comparison to make your point, but it is the right one to make mine, which is simply that MILL provides a compositional interpretation of its terms, whereas your system doesn’t provide a compositional interpretation of its terms, as I understand it.

    My point is that your point is the wrong one to make. (-: This is my reply to #45: my interpretation of lists of terms is compositional, and that’s what you should want. Lists of terms are the “raw syntax” in my theory. That they are what they are is not an accident. What I was calling an accident is the fact that because a list-of-terms is defined as a list of some things that are called ’terms’, you can get confused and think of these individual “terms” as if they were the “raw syntax” that ought to be interpreted compositionally. But that’s wrong: it’s the entire list that should be, and is, interpreted compositionally.

    • CommentRowNumber56.
    • CommentAuthoratmacen
    • CommentTimeDec 18th 2019

    E.g. you can define it in Agda by a simple pattern-match if you turn off the termination-checker. (-:

    I still don’t think so. What about bidirectional type checking? I think that’s syntax-directed, even if you don’t split the syntax into two classes to match the two judgment forms. Also, I think the part about weak head normalization is also syntax-directed although it’s nothing like a simple induction on terms.

    This “informula” summarizes how I think of it:

    structural recursion \subsetneq pure functional \subseteq syntax-directed \subsetneq logic programming \subsetneq proof search

    (And meanwhile: pure functional \subsetneq object-oriented \subseteq imperative)

    • CommentRowNumber57.
    • CommentAuthoratmacen
    • CommentTimeDec 18th 2019

    OK, well I think there is a reason why it’s harder to design a type system based on tensor projections, and I think it’s because they’re noncompositional. But I give up trying to convince you.

    Thank you for answering #45. It sounds like the compositionality you’re claiming is just a way of thinking about the operations and properties in your paper. In #30 you said:

    Huh. I have to say that sounds to me like a death knell for usability as an internal language of symmetric monoidal categories.

    I assume this was in response to:

    It seems you cannot compositionally interpret a term as just a morphism in my system.

    from #29. But I think this might’ve been a miscommunication. I’ve tried to explain why your system also doesn’t compositionally interpret terms in that sense. So the question is: Did you think my system would not have some analogue of the operations and properties that make your system compositional?

    • CommentRowNumber58.
    • CommentAuthoratmacen
    • CommentTimeDec 19th 2019
    • (edited Dec 19th 2019)

    Re #54: It looks like you fooled me again. How does #49 reject (f (1)(x))(f_{(1)}(x)) instead of infinite looping?

    edit: Oh, maybe it works to just check that you’ve made progress. If not, it had better be the base case.

    • CommentRowNumber59.
    • CommentAuthorMike Shulman
    • CommentTimeDec 22nd 2019

    Sorry, I think I assumed that in #29 you were saying you can’t interpret all the terms appearing in a judgment compositionally as a morphism, since it was obvious to me that no one would ever imagine you could interpret a single term as a morphism in a system like this. But maybe you were just expressing the latter fact.

    • CommentRowNumber60.
    • CommentAuthoratmacen
    • CommentTimeDec 23rd 2019

    Yeah, I guess I was roughly just expressing the latter fact, because it seems like I came close. If it weren’t for lambdas, the (UTUU \to T \boxtimes U') guess might’ve worked. That seems hard to believe though, so maybe there’s something else wrong with it.