-3

Please give a precise description of the Hack language's type system. It doesn't seem to exist online -- all I can find are examples sprinkled throughout the docs -- so please describe it in great detail in your answer.

For example, I would like to know how subtyping is defined in Hack, and what notion of assignment compatibility is used in the various Hack type-checking / static-analysis modes (strict, partcial, decl).

Ken White
  • 123,280
  • 14
  • 225
  • 444
ntc2
  • 11,203
  • 7
  • 53
  • 70
  • The question is clearly off-topic according to the [help/on-topic] (see the numbered list): Questions asking us to find or recommend tools, libraries, or favorite off-site resources are off-topic at StackOverflow. Note "find" and "off-site resources", which would include asking us to find links to documentation. – Ken White Jul 23 '14 at 23:16
  • @KenWhite: thanks. I had not actually read the definition of "off topic", I just wrongly assumed it meant "won't help me write programs". I'll update the question accordingly. – ntc2 Jul 23 '14 at 23:32
  • Rephrased nicely. :-) Thanks. (I retracted my close vote; I wasn't a downvoter, so I can't help with that part.) – Ken White Jul 23 '14 at 23:38

1 Answers1

3

If you're asking for a formal language spec for Hack, there isn't one right now, though it's something we think would be good to have around eventually. If you're asking for inference rules and formal proofs about the language, well, we've focused much more on making a pragmatic language than we have on sitting down and actually taking the time to prove it sound. :) (That said, code that's 100% strict should be sound, i.e., no runtime type errors, and if not that's a bug; we're just never going to sit down and formally prove that.)

So, the docs you link to are the best there are unless you want to start digging into the typechecker source. For that, you may be interested in the gritty details of our unification code, our subtyping relation, and general typechecking to begin with. (There's lots and lots more, but if you are the sort of person who wants to dig through the gritty details of how we implement unification I trust that you can find the rest yourself :))

If you have specific questions about the implementation, feel free to ask them here on SO with the "hacklang" tag if they are on topic, and in general I'm happy to chat in #hhvm on Freenode during working hours in US Pacific time.

Josh Watzman
  • 7,060
  • 1
  • 18
  • 26
  • Thanks! No, not looking for proofs, just a spec (but I assume that would include inference rules in some format). I'm actually more interested in the intentionally unsound non-strict modes, where I don't expect there'd be much interesting formal meta theory to be done. I'm trying to compare with Dart's intentionally unsound type system. – ntc2 Jul 24 '14 at 20:18
  • Then the first unification rule is probably most interesting to you -- `Tany` unifies with anything: https://github.com/facebook/hhvm/blob/master/hphp/hack/src/typing/typing_unify.ml#L21 The type `Tany` is the type assigned when a parameter, function return, or member variable doesn't have a type annotation. It's the "trust me" type, and that unification rule is the basis for its unsoundness. There's certainly other things that go on in partial mode; you can grep the codebase for where we look at the modes (they are an ocaml variant defined somewhere). – Josh Watzman Jul 25 '14 at 03:37