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.
Conversation
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
1
YES! Clear labels for the judgement forms in boxes would go a long way to reducing the overhead of reading unfamiliar rules.
2
7
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
relation check(_ : context, _ : term, _ : type).
relation synth(_ : context, _ : term, _ : type).
mode check(_ : in, _ : in, _ : in) is semidet.
mode synth(_ : in, _ : in, _ : out) is semidet.
😊
1
3
maybe we should just use Twelf or Mercury 🙃
1
More just pointing out that there are some neat things about how logic programming does things. Eg. with modes and determinism. Could possibly be a handy perspective perhaps when coming up with a general notation for this stuff, but I dunno.
Not sure if Twelf's mode checking (cs.cmu.edu/~twelf/guide-1) can let you describe all of what you want for functional dependencies though…
1
1
for sure. I have frequently considered writing my rules up in a datalog 😊
thing is, I tend to care enough about the precise structure and strategy for proof search that I don’t think I’d gain anything by that means for my typesystems’ real implementations.
1
1
Oh yeah, definitely thinking more in terms of 'high level specifications for communication' rather than an actual implementation. I definitely care about the precise proof search strategy too, however.
2
1
Show replies


