Experiments with Type module

[jmagaram]

The Type module seemed like it could use some love. Here are some ideas and issues. This is a draft/experiment for feedback. I'm happy to clean up the Type module, add docs, etc. after getting feedback on this. Trying to be mindful of @glennsl feedback that we don't want to build full opinionated parsing here.

• Flatten it out; I don't think Classify should be a sub-module with a single classify function in it
• Don't use toString for classifying, use typeof
• Explicit unknown type which should be used as output from Object.get
• Helper functions around classify like toString and toBool to make it easier to extract values safely without having to write the switch statements
• Support bigInt
• Use Symbol.t since we've got a type for this now
• Various isNull helpers
• classify checks for null objects and returns Null not Object

Issues and questions

• How to get the output of an object into the Object module. I couldn't figure out how to type it. Before it used an abstract object type defined just in this module.
• Are accessors, safe and unsafe, useful?

[zth]

Thank you for exploring this. However, this is unlikely to receive attention anytime soon. As stated before, documentation in the form of docstrings is what's important right now, and we'll do an absolute minimum of changes before that's in place for all modules, doc extraction works, and the editor integration has been worked through. So, if you're interested in contributing, please focus on documentation for the foreseeable future.

[glennsl]

I think this is a significant improvement. But I also agree that it's not very time-sensitive.

[glennsl]

Sorry, this isn't what I meant. These are now all just aliases of Obj.magic, and wherever these are used internally you can just substitute with Obj.magic directly.

If you want to export them, then the externals are better because the implementation won't be hidden by the interface and consequently add a function call on every use to what should be a no-op at runtime.

[jmagaram]

I see the problem. I looked at the javascript and there are all these wrappers and we want it to be completely compiled away. I went back to using external %identity in both the resi and the res because that results in less Js output. I find it very weird that the resi file has implementation details like external. If the resi just says let toBoolUnsafe: 'a => bool then this is the output...

function toBoolUnsafe(prim) {
  return prim;
}

In a perfect world wouldn't you be able to only use external in the implementation?