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

Refactor the code printing explanation for unification errors #1496

Merged
merged 1 commit into from Dec 1, 2017

Conversation

Projects
None yet
3 participants
@Armael
Contributor

Armael commented Nov 29, 2017

This patches refactor explanation/has_explanation to avoid duplicating the pattern matches, the first time to check if there is an explanation, and the second time to actually get it. Instead, explanation now returns a (Format.formatter -> unit) option; in the Some case one can call the closure to compute and print the explanation.

@Octachron

This comment has been minimized.

Show comment
Hide comment
@Octachron

Octachron Nov 29, 2017

Contributor

The changes look ok.

However, in term of refactoring, I would rather go one step further: define a concrete type for unification explanations, and split explanation into a find_explanation: … -> explanation option function and an associated printer pp_explanation: Format.formatter -> explanation -> unit.

Contributor

Octachron commented Nov 29, 2017

The changes look ok.

However, in term of refactoring, I would rather go one step further: define a concrete type for unification explanations, and split explanation into a find_explanation: … -> explanation option function and an associated printer pp_explanation: Format.formatter -> explanation -> unit.

@gasche

gasche approved these changes Nov 30, 2017

See minor Changes comment, but otherwise the patch is fine and I approve of it.

Florian's proposal is reasonable but it also sounds like a lot more work (because the author of the patch would have to understand each explanation and painfully track its data dependencies). I will follow what @Armael thinks is best here, but I would be of the opinion that we could merge this now, and consider this major rewrite as a separate step.

Show outdated Hide outdated Changes Outdated
@Armael

This comment has been minimized.

Show comment
Hide comment
@Armael

Armael Nov 30, 2017

Contributor

Indeed, @Octachron proposition means the explanation would be computed earlier (when checking if there is one), and one would have to check that this does not interferes with code that happens between the current has_explanation and explanation. All in all I'm in favor of just merging this now :-).

Contributor

Armael commented Nov 30, 2017

Indeed, @Octachron proposition means the explanation would be computed earlier (when checking if there is one), and one would have to check that this does not interferes with code that happens between the current has_explanation and explanation. All in all I'm in favor of just merging this now :-).

@gasche

This comment has been minimized.

Show comment
Hide comment
@gasche

gasche Nov 30, 2017

Member

You may have done something unexpected while rebasing your branch to fix the Change entry because the current patchset shown by Github is not at all what I would expect.

Member

gasche commented Nov 30, 2017

You may have done something unexpected while rebasing your branch to fix the Change entry because the current patchset shown by Github is not at all what I would expect.

@Armael

This comment has been minimized.

Show comment
Hide comment
@Armael

Armael Nov 30, 2017

Contributor

Oops, sorry. Should be fixed now.

Contributor

Armael commented Nov 30, 2017

Oops, sorry. Should be fixed now.

Show outdated Hide outdated Changes Outdated

@gasche gasche merged commit b616061 into ocaml:trunk Dec 1, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment