4 ms·

With OCaml type system permanently burned in my mind, I parse that error message as "there is an ` _ -> Result_set.t ` arrow type which is not compatible with t

With OCaml type system permanently burned in my mind, I parse that error message as "there is an ` _ -> Result_set.t ` arrow type which is not compatible with type `Result_set.t`". Do you think that the issue is that the arrow `->` is too hard to spot?

muglug 4y ago
Yes, I think that's the issue. I built a reasonably popular typechecker for PHP, so I have some experience with the DX for these sorts of programs. I don't think it's good for a couple of ASCII characters and line breaks to be the difference between an acceptable and an unacceptable type annotation. It requires, as you say, for the OCaml type system to be burned into people's minds for them to immediately spot the issue. In a similar context Rust will just say "function expected 5 arguments, you gave it 4" which has a very obvious remediation.
- thingification 4y ago
  I think it would be great to address this as you describe, but at the same time as somebody who has dabbled in OCaml but is still very wet behind the ears, I don't understand how this error format requires the type system to be "burned into your mind".
thingification 4y ago
I have no insight into what is hard and what is easy to implement here, but might it be feasible to break up the error into parts, the first just as you wrote? Along the lines of: 1. Error: This expression has type ('x -> Result_set.t) list but an expression was expected of type Result_set.t list 2. where 'x = (locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list The solution suggested by the parent of your post sounds desirable also, but perhaps the currying semantics of Ocaml makes that difficult or poorly-defined?
- octachron 4y ago
  Emphasizing the arrow (or in fact the most narrow error) is definitively a good idea in that case. Counting the number of arguments is in general a bit problematic: it is possible to end with an accidental functional value due to an extra argument send to a sufficiently polymorphic function for instance.
ta-ocaml_typerr 4y ago
It might help to make the difference more obvious by also showing the parts which unify properly, or introduce alias variables for complex type expressions (for instance "(int * float array) list as 'a") to move away some of the noise in the error.
- ta-ocaml_typerr 4y ago

muglug 4y ago

Yes, I think that's the issue. I built a reasonably popular typechecker for PHP, so I have some experience with the DX for these sorts of programs. I don't think it's good for a couple of ASCII characters and line breaks to be the difference between an acceptable and an unacceptable type annotation. It requires, as you say, for the OCaml type system to be burned into people's minds for them to immediately spot the issue. In a similar context Rust will just say "function expected 5 arguments, you gave it 4" which has a very obvious remediation.

thingification 4y ago
I think it would be great to address this as you describe, but at the same time as somebody who has dabbled in OCaml but is still very wet behind the ears, I don't understand how this error format requires the type system to be "burned into your mind".

thingification 4y ago

I have no insight into what is hard and what is easy to implement here, but might it be feasible to break up the error into parts, the first just as you wrote? Along the lines of: 1. Error: This expression has type ('x -> Result_set.t) list but an expression was expected of type Result_set.t list 2. where 'x = (locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list The solution suggested by the parent of your post sounds desirable also, but perhaps the currying semantics of Ocaml makes that difficult or poorly-defined?

octachron 4y ago
Emphasizing the arrow (or in fact the most narrow error) is definitively a good idea in that case. Counting the number of arguments is in general a bit problematic: it is possible to end with an accidental functional value due to an extra argument send to a sufficiently polymorphic function for instance.

ta-ocaml_typerr 4y ago

It might help to make the difference more obvious by also showing the parts which unify properly, or introduce alias variables for complex type expressions (for instance "(int * float array) list as 'a") to move away some of the noise in the error.

ta-ocaml_typerr 4y ago