Invalid names in `TypeDef`s about mlscript HOT 3 CLOSED

Thanks for the suggestion!

But I'm not quite sure about this.

The error-reporting philosophy currently is that we try to process as much as possible if it still kind of makes sense. The idea is to be resilient when programs are wrong, so we don't flood users with unrelated type errors. This is why we return "error" types when expressions don't make sense, but still register the binding, so it does not disturb later uses:

:e
def f (x y z) = add x y
//│ ╔══[ERROR] Unsupported pattern shape:
//│ ║  l.69: 	def f (x y z) = add x y
//│ ╙──      	       ^^^^^
//│ f: error -> int

f 1
//│ res: int

As a use-case, imagine a user applies an IDE refactoring to rename a class to an illegal lower-case name. If we suddenly refuse to register the renamed class, the user will get tons of errors all over the place, as opposed to a single error pinpointing the invalid name.

from mlscript.

Thanks for the explanation.

I thought it was causing more errors in later use cases, which could have actually been due to my typos in the tests, as I am unable to reproduce it now...

I will keep this philosophy in mind as I implement methods, e.g. in resolving field selection vs. method calls. (I'm glad I brought up this discussion, which probably saved me some rewriting had I not implemented it with this philosophy in mind.

from mlscript.

You're welcome! And I should have told you about it earlier. On the other hand, it's not a very big deal, just a minor improvement that's nice to have.

from mlscript.