core.typed

large hashmaps: failure to discover subtype and error-output to complex to understand

Details

  • Type: Defect Defect
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Environment:
    core.typed 0.2.25

Description

I am applying core.typed to a project that processes sequences of fairly large hash-maps. I run into two issues:
1. The error output is to large to be interpreted by a human (4k per error)
2. The reported error seems to be incorrect as the expected-type and actual type seem to match.

I came to this conclusion by writing a function that compared the expected type and the actuals type. This function is included too and might be an example of how to produce more compact and readible output for errors on large hash-maps.

The longOutput.clj contains the function that fails (derive-sms_msg-fmt-fail ..) and the nearly similar function (derive-sms_msg-fmt ..) that passes (check-ns).

The file also contains function (show-error) which prints a copy of the type-error and subsequently analyses the derived type with the expected type. The derived type is a union of the expected type and some derivatives based on the inclusion of optional keys. So I as far as I can see the union is subtype of the expected type and the reported error is incorrect.

An example of the error-analysis is included in the file show-error.output.

  1. longOutput.clj
    02/Feb/14 10:18 AM
    12 kB
    Cees van Kemenade
  2. show-error.output
    02/Feb/14 10:18 AM
    4 kB
    Cees van Kemenade

Activity

Hide
Cees van Kemenade added a comment -

PS: I could imagine that the current (show-error ..) could service as a basis for more compact error-messages on large hashmaps (using length of output as a criterium to decide whether the current error-format or the diffence-analysis results in the most compact error-report).

PS: I strongly believe in the big advantages of a static type-checker. But with the current error-messages it is nearly impossible to migrate a project involving large hash-maps due to the volumunuous error-output.

Show
Cees van Kemenade added a comment - PS: I could imagine that the current (show-error ..) could service as a basis for more compact error-messages on large hashmaps (using length of output as a criterium to decide whether the current error-format or the diffence-analysis results in the most compact error-report). PS: I strongly believe in the big advantages of a static type-checker. But with the current error-messages it is nearly impossible to migrate a project involving large hash-maps due to the volumunuous error-output.
Cees van Kemenade made changes -
Field Original Value New Value
Description I am applying core.typed to a project that processes sequences of fairly large hash-maps. I run into two issues:
  1. The error output is to large to be interpreted by a human (4k per error)
  2. The reported error seems to be incorrect as the expected-type and actual type seem to match.

I came to this conclusion by writing a function that compared the expected type and the actuals type. This function is included too and might be an example of how to produce more compact and readible output for errors on large hash-maps.

The longOutput.clj contains the function that fails (derive-sms_msg-fmt-fail ..) and the nearly similar function (derive-sms_msg-fmt ..) that passes (check-ns).

The file also contains function (show-error) which prints a copy of the type-error and subsequently analyses the derived type with the expected type. The derived type is a union of the expected type and some derivatives based on the inclusion of optional keys. So I as far as I can see the union is subtype of the expected type and the reported error is incorrect.

An example of the error-analysis is included in the file show-error.output.
I am applying core.typed to a project that processes sequences of fairly large hash-maps. I run into two issues:
  1. The error output is to large to be interpreted by a human (4k per error)
  2. The reported error seems to be incorrect as the expected-type and actual type seem to match.

I came to this conclusion by writing a function that compared the expected type and the actuals type. This function is included too and might be an example of how to produce more compact and readible output for errors on large hash-maps.

The longOutput.clj contains the function that fails (derive-sms_msg-fmt-fail ..) and the nearly similar function (derive-sms_msg-fmt ..) that passes (check-ns).

The file also contains function (show-error) which prints a copy of the type-error and subsequently analyses the derived type with the expected type. The derived type is a union of the expected type and some derivatives based on the inclusion of optional keys. So I as far as I can see the union is subtype of the expected type and the reported error is incorrect.

An example of the error-analysis is included in the file show-error.output.

Hide
Ambrose Bonnaire-Sergeant added a comment -

Hi Cees,

Thanks for the detailed report, it really helps. I'll look into this.

Show
Ambrose Bonnaire-Sergeant added a comment - Hi Cees, Thanks for the detailed report, it really helps. I'll look into this.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated: