4 ms·

The website seems like it needs an explanation of what this is for and when you’d want to use it; right now it leaves quite a lot to the imagination. (Also, the

The website seems like it needs an explanation of what this is for and when you’d want to use it; right now it leaves quite a lot to the imagination. (Also, the GitHub link in the corner (a) requires JavaScript for some reason instead of just being a normal link, and (b) goes to an empty repo so it doesn’t seem to be possible to use this thing.) A big part of my confusion, I think, is that I’m not sure why you’d want to write code without type annotations. I can see a use for autogenerating them from code that doesn’t have any, but the first example on the page infers the return type of hello() as “t547061|string” which is rather more opaque than I’d prefer from a diagnostic. A big part of why I use TypeScript is because of the type annotations: both so future readers can understand my intent, and also to give the type checker hints about what I was thinking so it can point to exactly where I went wrong instead of going “this over here doesn’t work with that thing over there, I dunno, there’s probably something in the middle that’s not right.” So I’m curious what your thoughts are on why you dislike annotations and how to make type errors clear without leaning on them for support.

pyrolistical 4y ago
I think this would be useful for writing rules for eslint. For example, let's say we want to ensure object types don't change for their entire lifecycle. const foo = { answer: 42 } // change values but not type is OK foo.answer = 69; // creating a new object is OK const bar = { baz: foo } // disallow adding/removing fields, IE changing type // ERROR, expected type of foo to be {answer: number}, unexpected field reply: string foo.reply = "nice";
jiangmy 4y ago
Thanks for your reply, and sorry for the confusion! 1. I replaced the GitHub link with a direct link now. Because it is still in the very early stage, the repo is only open for discussions like feature requests, using feedback, etc. 2. The main point is to do type check & annotation generation all automatically without one single line of additional code needed, which both flow nor typescript cannot achieve at present. 3. I'd like annotations to tip me on the type and to let the editor give me code suggestions based on them; however, I do not want to write them manually. 4. As for how to get type errors clear enough without learning, I'm doing it by avoiding using PL/type-system-related terms during the entire process. For example, `let a = 1; a = '1';` will raise an error that says `expecting number but got string.` to tell the user with easy to understand the sentence. For more complicated situations, like overloading mismatch, please experiment by the playground at the bottom of the homepage. (very sorry, I do not know how to write markdown on HN). Any feedback or thoughts on that is very welcome! 5. For the inferring result like `t547061|string` you pointed out. Yes, I agree that it's annoying. I will simplify the outcomes for the sake of readability over strictly correctness. But the top priority is still to add more ES6+ features if I think correctly. Thank you again for the detailed feedback, and I apologize for any unclear caused. It's still early, and feedback like this is more than welcome. Thank you!
- wolfgang42 4y ago
  > avoiding using PL/type-system-related terms...tell the user with easy to understand the sentence. What I meant by “making type errors clear” wasn’t so much the text of the error messages, but rather making the cause of the error more obvious. Here’s a very simplified example of the sort of thing I mean: function foo() {return '1.2'} const bar = foo() + 1 const baz = bar.toFixed() ESInfer complains on line 2, and TypeScript on line 3 (I guess it understands that `+` will coerce the type), but from my perspective the mistake is on line 1, where I forgot parseFloat(). Without annotations, the problem manifests as individual errors somewhere downstream of every call site; if I annotate foo() as returning a number, the type checker will immediately point me at the problem. In fact when I get a type error from tsc that I don’t immediately understand, my first step is usually to start scattering annotations around to help it narrow down where its take on the situation differs from mine. Basically, neither ESInfer nor TypeScript give me great diagnostics for this code as-is, but TS lets me have a ‘conversation’; it has the tools I need to help it help me find the problem. ESInfer (in my admittedly cursory understanding) seems like it’s missing that ability; I can imagine a heuristics that would help it better explain the situation (e.g. showing the entire data flow that lead to a mismatch, rather than claiming the error is at a single point) but I haven’t thought about it very much so I was wondering if you had any particular ideas around this situation. (Incidentally, you can find the syntax for HN comments at <https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc>. It’s linked from the FAQ, which is itself linked at the bottom of the page, though that’s not very obvious.)
  - jiangmy 4y ago
    foo() + 1 ESInfer complains about this because you are adding a string with a number, which sometimes will result in an unexpected value in runtime, and you hardly find it out. So ESInfer, on purpose, disallows this kind of type casting automatically. As for the error message: > expecting possible candidates all failed: candidate number failed: expecting number but got string. candidate string failed: expecting string but got number. but got number. It's saying two possible situations: #1 number + number and #2 string + string are all failed, which is precisely the error. However, this may be a lack of readability if someone is the first time using ESInfer. I'll write some wikis on how to read error messages efficiently as a starting point and, finally and hopefully, evolve a better error reporting system. So if you ask me how to deal with this kind of code with ESInfer, I'd suggest making the compiler happy by converting the string to a number or the number to a string. (BTW, try to use the format as suggested, hope it works :D)

pyrolistical 4y ago

I think this would be useful for writing rules for eslint. For example, let's say we want to ensure object types don't change for their entire lifecycle. const foo = { answer: 42 } // change values but not type is OK foo.answer = 69; // creating a new object is OK const bar = { baz: foo } // disallow adding/removing fields, IE changing type // ERROR, expected type of foo to be {answer: number}, unexpected field reply: string foo.reply = "nice";

jiangmy 4y ago

Thanks for your reply, and sorry for the confusion! 1. I replaced the GitHub link with a direct link now. Because it is still in the very early stage, the repo is only open for discussions like feature requests, using feedback, etc. 2. The main point is to do type check & annotation generation all automatically without one single line of additional code needed, which both flow nor typescript cannot achieve at present. 3. I'd like annotations to tip me on the type and to let the editor give me code suggestions based on them; however, I do not want to write them manually. 4. As for how to get type errors clear enough without learning, I'm doing it by avoiding using PL/type-system-related terms during the entire process. For example, `let a = 1; a = '1';` will raise an error that says `expecting number but got string.` to tell the user with easy to understand the sentence. For more complicated situations, like overloading mismatch, please experiment by the playground at the bottom of the homepage. (very sorry, I do not know how to write markdown on HN). Any feedback or thoughts on that is very welcome! 5. For the inferring result like `t547061|string` you pointed out. Yes, I agree that it's annoying. I will simplify the outcomes for the sake of readability over strictly correctness. But the top priority is still to add more ES6+ features if I think correctly. Thank you again for the detailed feedback, and I apologize for any unclear caused. It's still early, and feedback like this is more than welcome. Thank you!

wolfgang42 4y ago
> avoiding using PL/type-system-related terms...tell the user with easy to understand the sentence. What I meant by “making type errors clear” wasn’t so much the text of the error messages, but rather making the cause of the error more obvious. Here’s a very simplified example of the sort of thing I mean: function foo() {return '1.2'} const bar = foo() + 1 const baz = bar.toFixed() ESInfer complains on line 2, and TypeScript on line 3 (I guess it understands that `+` will coerce the type), but from my perspective the mistake is on line 1, where I forgot parseFloat(). Without annotations, the problem manifests as individual errors somewhere downstream of every call site; if I annotate foo() as returning a number, the type checker will immediately point me at the problem. In fact when I get a type error from tsc that I don’t immediately understand, my first step is usually to start scattering annotations around to help it narrow down where its take on the situation differs from mine. Basically, neither ESInfer nor TypeScript give me great diagnostics for this code as-is, but TS lets me have a ‘conversation’; it has the tools I need to help it help me find the problem. ESInfer (in my admittedly cursory understanding) seems like it’s missing that ability; I can imagine a heuristics that would help it better explain the situation (e.g. showing the entire data flow that lead to a mismatch, rather than claiming the error is at a single point) but I haven’t thought about it very much so I was wondering if you had any particular ideas around this situation. (Incidentally, you can find the syntax for HN comments at <https://news.ycombinator.com/formatdoc https://news.ycombinator.com/formatdoc>. It’s linked from the FAQ, which is itself linked at the bottom of the page, though that’s not very obvious.)
- jiangmy 4y ago
  foo() + 1 ESInfer complains about this because you are adding a string with a number, which sometimes will result in an unexpected value in runtime, and you hardly find it out. So ESInfer, on purpose, disallows this kind of type casting automatically. As for the error message: > expecting possible candidates all failed: candidate number failed: expecting number but got string. candidate string failed: expecting string but got number. but got number. It's saying two possible situations: #1 number + number and #2 string + string are all failed, which is precisely the error. However, this may be a lack of readability if someone is the first time using ESInfer. I'll write some wikis on how to read error messages efficiently as a starting point and, finally and hopefully, evolve a better error reporting system. So if you ask me how to deal with this kind of code with ESInfer, I'd suggest making the compiler happy by converting the string to a number or the number to a string. (BTW, try to use the format as suggested, hope it works :D)