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

Expand failure tracking in NonDet #261

Open
michaelpj opened this issue Oct 22, 2024 · 4 comments
Open

Expand failure tracking in NonDet #261

michaelpj opened this issue Oct 22, 2024 · 4 comments

Comments

@michaelpj
Copy link
Contributor

NonDets ability to track where you hit empty is quite nice, and helps with a classic problem of non-deterministic searches: knowing why you failed to find a solution.

However, the current approach only gives you call stacks. It would be nice in many cases to give a human-readable message or error.

I'm not really sure what the right design here is. The current version requires altering the calls to empty, which is a bit awkward and requires writing custom versions of Alternative functions. I wonder if we could do something like:

  • Add extra failure context to Empty.
  • empty sets empty failure context
  • Users can use interpose to add failure context to any failures within a lexical scope
@arybczak
Copy link
Member

arybczak commented Oct 22, 2024

A somewhat simpler approach: since call stacks from empty are more or less useless and you have to use emptyEff, perhaps it would be enough if emptyEff (and hence Empty) took a String as an argument and runNonDet returned Either (CallStack, String) a?

I guess hardcoded Stringas a type could be limiting.

@michaelpj
Copy link
Contributor Author

Yeah, I guess it would be neat if you effectively had an "error" type associated with it that got "thrown" from empty. That's what's happening under the hood anyway.

I guess the thing that would be neat would be if there was a mapError equivalent, so empty could throw some default member of the error type and then you could modify it outside, e.g.

g <- mapError (const "Failed to pick a thing") $ afromList things

@ocharles
Copy link

Which starts looking a lot like <?> from parser combinators 😄

@arybczak
Copy link
Member

Somewhat related: haskell/core-libraries-committee#301

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants