polybuildr
commented
7 years ago While I appreciate the reliability and tried-and-testedness of using an existing proven type inference algorithm, for a few reasons I don't want to proceed with this in 0.1.0.
Firstly, and probably most significantly, I have a lot of time consuming reading up to do on these algorithms and the background theory, which I don't want to do before this first release.
Secondly, at first glance, I feel like there will need to be some changes to the algorithms anyway, primarily because I feel like they were designed for static/strict type systems (functions can only return a certain type, no unions, variables once bound cannot change type, etc.) and if I'm right it would mean even more time consumed before this is done.
Thirdly, the current type system is really very simple. There are only two levels of types: concrete single types or the Any type. Polymorphism is basically nonexistent. Given this, I'm not sure that a more comprehensive type checking algorithm is strictly necessary as of now. (I'm even considering running the current implementation through a theorem prover just to see what happens :P)
Finally, 0.1.0 was about filling in gaps in the existing features. Type checking and inference (read: propagation) work as of now, and at the return statements, I even know the type being returned, but this does not propagate to the caller. This seems like a gap that should be bridged before 0.1.0, and hence I'd prefer just filling in the existing typechecker. Filed #26 for further investigation.
Regarding this and #24, I strongly suggest not going down the route and trying to monkey patch a type system.
Implement any of:
or some flavour thereof.