Hacker News Reader

Comment by orf | Hacker News Reader

How is the uglify.js example correct? It replaces 'status !== 2' with '!(status>=2)'

   > needsCancelButton(2)
   false

Surely it should be:

   function needsCancelButton(n){ return 2 === n }

Also, more generally, uglify.js has no idea about the range of integers that could be passed in so how is a greater than optimization like that ever valid?

View on HN

Ah, that's my mistake! The generated Reason output got copy/pasted incorrectly. (It's correct if you click through to the Try Reason link.)

In fact, Reason generates the `>=` comparison, and it knows it can do this because it know that a value greater than 2 can never happen.

The post should be updated to reflect this in a second!

I believe this is because it takes an enum, not an integer. Perhaps Reason is communicating this to uglify?

My understanding is that Uglify is just a JS to JS transform, and there isn't a way for Reason to supply type information. At least, I don't see anything about it in the README: https://github.com/mishoo/UglifyJS

Also note that, at least with Flow and TypeScript, type information isn't guaranteed to be correct, so it's a bit dangerous to do type-based optimizations (although tools certainly could try, with the caveat that if your types are wrong, your code may break even more than it otherwise would).

I believe reason is a different flavor than typescript and friends, though I could be mistaken.

Your second paragraph is important here. Flow, TypeScript, and PureScript all have two-way interop with JavaScript code as a design goal. PureScript also has generating "fast, understandable code" as a design goal. It might be falling short on "fast" here, but it's much more understandable in isolation than the Reason output.

This explains pretty much everything the OP notices in the comparison.

Reply on news.ycombinator.com