←back to thread

Parse, don't validate (2019)

(lexi-lambda.github.io)
398 points declanhaigh | 1 comments | 07 Mar 23 08:47 UTC | HN request time: 0s | source
Show context
bruce343434 ◴[07 Mar 23 10:54 UTC] No.35053912[source]▶
Note that this basically requires your language to have ergonomic support for sum types, immutable "data classes", pattern matching.

The point is to parse the input into a structure which always upholds the predicates you care about so you don't end up continuously defensively programming in ifs and asserts.

replies(12): >>35054046 #>>35054070 #>>35054386 #>>35054514 #>>35054901 #>>35054993 #>>35055124 #>>35055230 #>>35056047 #>>35057866 #>>35058185 #>>35059271 #
Thaxll ◴[07 Mar 23 13:08 UTC] No.35054901[source]▶
You're describing deserialization in a strong typing language, sometimes it's not enough, ok your email went to an empty string which is useless.
replies(2): >>35054943 #>>35055012 #
Kinrany ◴[07 Mar 23 13:14 UTC] No.35054943[source]▶
You can have a ValidEmail type that performs all the checks on construction.
replies(1): >>35055657 #
Thaxll ◴[07 Mar 23 14:25 UTC] No.35055657[source]▶
OP said to not validate.
replies(3): >>35055815 #>>35056190 #>>35060605 #
1. gnulinux ◴[07 Mar 23 20:19 UTC] No.35060605[source]▶
You're misunderstanding. Validation looks like

  validateEmail : String -> String -- post-condition: String contains valid email
whereas parse looks like:

  parseEmail : String -> Either EmailError ValidEmail
There is no problem using `ValidEmail` abstraction. The problem is type stability, when your program enters a stronger state at runtime (i.e. certain validations are performed at runtime) it's best to enter a strong state at compile time (stronger types) so that compiler can verify these conditions. If you remain at String, these validations (that a string is valid email) have no compile-time counterpart so there is no way for compiler to verify. So use `ValidEmail` instead.