Conversation

I wonder how we could improve it. part of the issue is the tension between concision and completeness, I think. as indecipherable as judgment rules &c can be at first, I don't think people would prefer, like, 10 pages of English text thoroughly explaining the mechanism.
3
7
maybe part of it is just consistency. seems like many authors like to use slightly different notation, so you have to be careful to read their specific flavor notes prior to engaging with the material. maybe we need a PL standards office 😂
2
I mean, when you’re defining classes of judgements you could do worse than just label them clearly. [ Γ ⊢ x ⇐ T ] checking … [ Γ ⊢ x ⇒ T ] synthesis … would go a long way, without requiring people adhere to any particular notation or whatever.
1
13
I still also think we could somehow work on making the distinction between bits of 'syntax' and 'non-terminals' clearer. Like `_⊢_⇒_` vs `Γ`, `e`, `t`. Perhaps making a more uniform notation, like `synth(_, _, _)` would help with reducing the mental overhead?
2
4
I actually give mixfix signatures for sequents/judgements in my notes a lot like that, most of the time. Only with types, too: _ ⊢ _ ⇐ _ : (Context, Term, Type) (tupled because it’s a relation rather than a function in general, tho I use -> à la fundeps for pure outputs.)
3
4
yes, I was definitely winging it with that. I had blanked entirely on notation, and recalled that “a finitary relation is a set of n-tuples…”
3
1
What you have is good for Haskellers or DB people, but I'm used to input/output modes from logic programming (& Twelf, Coq typeclasses, ...); unsure the two are equally expressive. Neither notation is "obvious", & I have no experience presenting either for real.
2
1
I know that Mercury's modes are less expressive than what you might want - I've I think I remember Peter Stuckey saying he'd recommended some sort of 'dependent modes' for Mercury at one point but I don't know if that went anywhere, and if that is somehow related?
1