Proof of concept rtype type checker.

[Raynos]

I've added rtype support to my type checker on a branch.

https://github.com/Raynos/jsig2/tree/rtype#rtype-compatibility-branch

I've documented what is implemented, not implemented and what is missing from rtype.

So far I the main piece missing is a way to declare the types of variables or functions. TypeScript and flow have declaration syntax for this.

The other thing I observed is all of the predicate stuff with interfaces is pretty much unimplemented. As it stands interfaces in rtype have "too many features"

I've also ported an example to what I believe is idiomatic rtype ( https://github.com/Raynos/jsig2/blob/rtype/examples/2-memory-db.hjs )

[Mouvedia]

Good job!

You can find the builtins that the MVP will have here.

Is %Boolean%%Mixed related to #73?
Would you be interested in #62 or #42?

[Raynos]

@Mouvedia Correct; Boolean%%Mixed internal type is related to Boolean(Any). I use it for now until I implement mixed as a full type.

It is a type that is effectively a Boolean when used; however you can assign any type into it. It's different from Any because:

var foo: %Boolean%%Mixed = 2;
!foo; // legal
if (foo) {} // legal

foo.bar; // illegal, type Boolean does not have field bar.

[Raynos]

@Mouvedia

As for #42 I've long wanted to improve the existing parser for the type definition language. The main reason for improving is improved error messages, the current ones are quite confusing.

I'm not sure if a BNF based parser will give improved error messages, the current error messages do show line & column offset.

As for #62 The original version of jsig (before jsig2 rewrite ) had runtime checking and wrapping. This was getting really complicated and provided less value then a static type checker. For these reasons I punted on it.

What I do want to do is make sure that I can write a JSON parser helper that makes reading JSON statically type safe. this might be based on validators or based on a typed json parser itself. Statically type safe validation will solve most of my "dynamic type checking" needs.

[Mouvedia]

So you can't do var foo: %Boolean%%Mixed = new Boolean(2);?
If you see any reason to reopen #73 plz comment there.

From your "Not implemented" list Id prioritize:

• Limited builtin type support, we do not support arbitrary javascript value expressions, only strings and numbers.
• Any. One of the core principles of my type checker is correctness. Any place where Any is used we should use mixed instead. The type checker implements flow based restrictions and reflection to be able to operate on mixed.

You shouldn't work on generics just yet: it's still being discussed.

What's in progress?
What's next?

[Raynos]

@Mouvedia

https://github.com/Raynos/jsig2#progress--020-

This tracks current progress; the features I want to work on are mentioned there, including generics.

I'll need a good reason to implement Any. I think I have baseline level Builtin support but need to add:

• Symbol. Not really sure what that is yet, only have ES5 covered
• Date. Havn't written any code related to Date yet.
• Map, Promise, Proxy, Set, WeakMap, WeakSet, other features not implemented as I'm targetting ES5 at the moment
• Predicate, not implemented, don't really know how to yet.

[Mouvedia]

We need at least the "primary builtin types"* + Any and Void.

* https://github.com/ericelliott/rtype/pull/42/files#r59980276

[ericelliott]

Predicate should be relatively easy. It's just a convenient name for the type (...args: Any[]) => Boolean.

Predicate literals are MUCH harder. They pull the entire JS specification into scope. Is there a way to punt on predicate literals and still do mostly OK type checking?

[Raynos]

@ericelliott I think predicate literals are not needed for static type checker to work.

Here's a 2016 paper on adding "refinement types" to TypeScript ( http://arxiv.org/pdf/1604.02480.pdf ). I think implementing predicate / refinement / dependent types is still a research level topic.

[ericelliott]

@Raynos I agree. I'm willing to remove Predicate literals from the spec entirely, if it makes tooling easier. Do you think we should?

[ericelliott]

implementing predicate / refinement / dependent types is still a research level topic.

I think regular expressions fall into that category, but regular expressions can add significant richness to the capabilities of the runtime type checker without adding any complexity at runtime.

Come to think of it, so can predicate literals. Hmm...

Back to the question: Can static type checkers work around them? Is there any way we can add fallback types? For instance, all regular expressions can fall back to Strings, which causes a reduction in type fidelity, but should still work.

Not sure how fallbacks would work for predicate literals... ideas? Am I talking crazy?

[ericelliott]

We might be able to leverage another library (e.g. codemix/contractual) to cover our limitations.

The limitations are on the static analysis side. On the runtime side, literals just work by the magic of a fully functional javascript engine.

[Raynos]

@ericelliott regex string types are better handled as String or "a" | "b" | "c"; those are the two types of strings you can deal with in a typesystem.

Anything else where you want a regex over a string please pass in a structured tuple or object.

interface UserInstance {
  name: /\w+/,
  description?: '',
  likes?: [],
  data?: {}
}

This interface really means name: String. Your trying to put runtime validation and type checking into the same set of concerns.

The difference between runtime validation, is generally that it's done in a single place, where you get user input. Where as type checking is done every single place a type is used, at every variable assignment, at every function call, at every mutation.

[ericelliott]

@Raynos I see your point, and yes, that's how it usually works.

However, at runtime, predicate function (and by extension, regex) type checks work just fine at function call time, and I don't see a really good reason not to include those features in rtype + rfx.

I also don't see a big difference between a structural type that checks:

interface Foo: {
  'a': String,
  'b': Number
}

...and a regex that checks that a string value has one or more letters. name: /\w+/ is basically shorthand for a very large union type.

These things work as expected at runtime... the difficulty static type systems have is that static type systems seek a formal mathematical proof, and if the entire scope of a language as complex as JavaScript (or even RegEx) comes into play, you introduce the possibility of an impossible proof.

Runtime checking doesn't have the restriction of trying to prove that type errors are impossible in any permutation of the running program state. All they care about is "does the current value satisfy the conditions of this predicate right now?"

Static type systems necessarily sacrifice some expressiveness to accomplish the goal of a thorough type correctness proof.