4 ms·

> the system would have to be aware of dependencies between pieces of data in order to do it correctly Yep, which is why I expect that a graph is needed to mod

> the system would have to be aware of dependencies between pieces of data in order to do it correctly Yep, which is why I expect that a graph is needed to model the validations that I picture in my mind. > so that they can opt in to discarding error messages Do you have any small examples of when you'd want to discard error messages?

catlifeonmars 5y ago
Agree, graph makes sense. Ideally, with a finite set of rules, you can traverse the entire graph, generating all possible error messages, and then filter error messages by some heuristic (such as shortest path); displaying only the filtered subset to the end user.
ivanbakel 5y ago
>Do you have any small examples of when you'd want to discard error messages? My point is more that error messages risk being discarded wherever there are nested validations (when talking about Haskell). Consider the following crude example: validate = do x <- foo -- `x` is the result of some validation bar x -- and here, it is fed into a dependent validation where bar y = do z <- baz -- `baz` is a validation, but independent of the argument foobaz y z -- `foobaz` is a validation dependent on the argument return () No part of `bar` will run if `foo` fails to validate and yield the data required to run `bar`. But running the `bar` validation involves a sub-validation `baz` that is independent of the argument passed to `bar` - so in reality, it should be possible to always run `baz` and capture any error messages from it. But the way the code is structured means that the `baz` errors are silently dropped some of the time, even when they could be captured. It's up to the programmer to decide if the extra complexity of floating `baz` to the top-level is worthwhile - and the programmer has to keep these kinds of decisions in mind constantly while writing the validation code. Reordering validations is also a possibility, and it might be available in a graph-based rules engine. But you have to take care to not introduce side-effects into any part of the validation process, otherwise you would get surprising behaviour whenever there was a re-ordering. When writing Haskell code, re-ordering is not really an option for that reason.

catlifeonmars 5y ago

Agree, graph makes sense. Ideally, with a finite set of rules, you can traverse the entire graph, generating all possible error messages, and then filter error messages by some heuristic (such as shortest path); displaying only the filtered subset to the end user.

ivanbakel 5y ago

>Do you have any small examples of when you'd want to discard error messages? My point is more that error messages risk being discarded wherever there are nested validations (when talking about Haskell). Consider the following crude example: validate = do x <- foo -- `x` is the result of some validation bar x -- and here, it is fed into a dependent validation where bar y = do z <- baz -- `baz` is a validation, but independent of the argument foobaz y z -- `foobaz` is a validation dependent on the argument return () No part of `bar` will run if `foo` fails to validate and yield the data required to run `bar`. But running the `bar` validation involves a sub-validation `baz` that is independent of the argument passed to `bar` - so in reality, it should be possible to always run `baz` and capture any error messages from it. But the way the code is structured means that the `baz` errors are silently dropped some of the time, even when they could be captured. It's up to the programmer to decide if the extra complexity of floating `baz` to the top-level is worthwhile - and the programmer has to keep these kinds of decisions in mind constantly while writing the validation code. Reordering validations is also a possibility, and it might be available in a graph-based rules engine. But you have to take care to not introduce side-effects into any part of the validation process, otherwise you would get surprising behaviour whenever there was a re-ordering. When writing Haskell code, re-ordering is not really an option for that reason.