Γ is typically used to denote the context, or the type environment for an expression. It is a mapping from variables to types. for example we could have
Γ = x:A, y:B, z:C
then
Γ |- y: B
is a typing judgment. Means "In the context of Γ, y has type B."
Type derivation is a process where you start with an expression and an empty context and then figure out what the type of that expression is by building it up from scratch using typing rules. It's what compilers do to figure out whether your program is correct.
What's the easiest way to actually learn how the correspondence works? It always feels like there's some kind of background they're assuming I have, that my pure maths ass doesn't.
I'll give you a fast-forward of the subjects you need to study to actually learn this stuff (with links). Many of these are part of typical computer science curriculums. However, most will exclude at least some of this to its fullest. Note that it's a lot of knowledge, you might find it frustrating to just deep dive into it on your own, don't take it the wrong way, maybe follow an actual course and you will be guided into all of this. Maybe I'll also try to give a run-down, skipping the preupedeitic knowledge... later... if I have time.
P.s.: to get the general feeling you don't really need to know all of this tho. Just skim it. And dive deeper if you like it.
Read the semantics part. You don't need everything, but you must understand what it means for a Formula to be a logic consequence of a set of formulas
Read a bit the deductive systems part. I find "natural deduction" (in detail here https://en.wikipedia.org/wiki/Natural_deduction) easier to understand (more... Natural) however, your mileage may vary, many people find it confusing, hence why "sequent calculus" was invented. We'll use the sequent calculus later
You can learn it on its own, but it fits better as part of a "foundations of computer science" course. I don't have a link for that.
You also need to know a bit of programming in basically any strongly-typed language. This will give you some kind of general idea of what types and type systems are.
Yeah, understanding proof assistants would be the big practical thing. I can read a short proof in Lean, but a lot of it just feels like magic right now.
It looks like I was mainly missing sequent calculus (I learned all in the Hilbert style of deduction) and the convention that gamma is the whole context. I'd see the notation and wonder if I missed something. Thank you for the effort you put in on this!
Yeah, I also only learned natural deduction, until I got to the languages course and the professor told us "this is similar to natural deduction, but different".
Personally I don't like lean, I prefer coq. But that's mostly the vibes, both are actually fine. Lean doesn't do constructive logic, it does classic logic, but you have to give up program extraction for that. That's why mathematicians are head over heels for lean.
8 Comments
Beanie@programming.dev · 12 pts · 44d
god dammit this is actually good ðŸ˜. i literally did semantics of programming languages last term too
davidgro@lemmy.world · 6 pts · 44d
Would you be up for explaining it please?
renzhexiangjiao@piefed.blahaj.zone · 14 pts · 44d
Γ is typically used to denote the context, or the type environment for an expression. It is a mapping from variables to types. for example we could have
Γ = x:A, y:B, z:C
then
Γ |- y: B
is a typing judgment. Means "In the context of Γ, y has type B."
Type derivation is a process where you start with an expression and an empty context and then figure out what the type of that expression is by building it up from scratch using typing rules. It's what compilers do to figure out whether your program is correct.
edinbruh@feddit.it · 3 pts · 44d
https://feddit.it/comment/20528152
edinbruh@feddit.it · 2 pts · 44d
CanadaPlus@lemmy.sdf.org · 2 pts · 44d
What's the easiest way to actually learn how the correspondence works? It always feels like there's some kind of background they're assuming I have, that my pure maths ass doesn't.
edinbruh@feddit.it · 2 pts · 44d
I'll give you a fast-forward of the subjects you need to study to actually learn this stuff (with links). Many of these are part of typical computer science curriculums. However, most will exclude at least some of this to its fullest. Note that it's a lot of knowledge, you might find it frustrating to just deep dive into it on your own, don't take it the wrong way, maybe follow an actual course and you will be guided into all of this. Maybe I'll also try to give a run-down, skipping the preupedeitic knowledge... later... if I have time.
P.s.: to get the general feeling you don't really need to know all of this tho. Just skim it. And dive deeper if you like it.
CanadaPlus@lemmy.sdf.org · 1 pts · 36d
Yeah, understanding proof assistants would be the big practical thing. I can read a short proof in Lean, but a lot of it just feels like magic right now.
It looks like I was mainly missing sequent calculus (I learned all in the Hilbert style of deduction) and the convention that gamma is the whole context. I'd see the notation and wonder if I missed something. Thank you for the effort you put in on this!
edinbruh@feddit.it · 1 pts · 35d
Yeah, I also only learned natural deduction, until I got to the languages course and the professor told us "this is similar to natural deduction, but different".
Personally I don't like lean, I prefer coq. But that's mostly the vibes, both are actually fine. Lean doesn't do constructive logic, it does classic logic, but you have to give up program extraction for that. That's why mathematicians are head over heels for lean.