Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error messages generated too eagerly #85

Closed
jstolarek opened this issue Oct 20, 2016 · 0 comments · Fixed by #346
Closed

Error messages generated too eagerly #85

jstolarek opened this issue Oct 20, 2016 · 0 comments · Fixed by #346
Assignees

Comments

@jstolarek
Copy link
Contributor

When working on #43 I noticed that function generating error messages (a.k.a. gripers in typeSugar module) are called several times even though only one error message gets printed. @slindley says this is caused by unification doing backtracking: error messages are generated and thrown as exceptions, they get caught and another attempt at unification is made. It would be much better to generate error messages lazily, ie. only when they are actually going to get printed.

@jstolarek jstolarek self-assigned this Jun 15, 2018
jstolarek added a commit that referenced this issue Jun 15, 2018
Unification wrapper in typeSugar is now separated into:

  * unification function returning a data type indicating success
    or failure
  * worker for raising an error
  * wrapper around the above two functions that restores previous
    behaviour of unify wrapper
  * unifyOr combinator that tries to unify first pair of types and if
    that fails it tries the second pair, without generating an error
    message for the first failed unification

This partially fixes #85.  build_tyvar_names is still called too eagerly
to generate variable names that are not getting displayed.  Reason
remains to be investigated.
jstolarek added a commit that referenced this issue Jun 26, 2018
Generate error messages lazily. Fixes #85.

Unification wrapper in typeSugar is now separated into:

  * unification function returning a data type indicating success
    or failure
  * worker for raising an error
  * wrapper around the above two functions that restores previous
    behaviour of unify wrapper
  * unifyOr combinator that tries to unify first pair of types and if
    that fails it tries the second pair, without generating an error
    message for the first failed unification
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant