5 ms·

This still sounds like validation but with extra steps. (or less?)

plesiv 5y ago
The post is saying: - don't drop the info gathered from checks while validating, but keep track of it - if you do this, you'll effectively be parsing - parsing is more powerful that validating "Extra steps" would be keeping track of info gathered from checks.
- bruce343434 5y ago
  Right. My takeaway was "verify and validate once, then put it in a specially marked datastructure, or if your language allow it make the typesystem guarantee some conditions of the data, then work with that from there". Where does parsing come in the picture?
  - justinpombrio 5y ago
    You understand it. It's using the word "parse" metaphorically, to mean "validate, then put it in a specially marked data structure". For example, `parse_int :: string -> maybe int` is a parsing function, and it "validates that the string is an integer, then puts it in a specially marked data structure called int". However, the post uses the word "parse" not only for true parsing functions (that convert text into a data structure), but also for conversions from data structure to data structure. I also find this a confusing use of the word "parse", and it's not explained in the post, and I think "parse, don't validate" is a poor slogan as a result. The traditional slogan is "make illegal states unrepresentable", though that's a bit narrower of a concept.
    - b3morales 5y ago
      I don't think this is the same as "make illegal states unrepresentable"; it's a corollary (or the converse maybe): "Make assertions of legal states representable"
      - joshuamorton 5y ago
        They're sort of the same. If you have str and safestr, and safestr is known to confiorm to some invariant, the illegal state of a, say str where validate hasn't been called, isn't representable.
  - vvillena 5y ago
    Well, ain't that it? If you validate a string so that it contains some angle bracket tags at the beginning and the end, ensure that both the tag values contain the same string (except for one extra marker in the end tag), and store the tag name and the string within the tags in a purpose-made data structure, you can call it whatever you want. Some will call that a rudimentary XML parser.
  - kortex 5y ago
    > verify and validate once, then put it in a specially marked datastructure Not to steal vvillena's thunder, but that's pretty much the dictionary definition of "parsing" > analyze (a string or text) into logical syntactic components, typically in order to test conformability to a logical grammar. Parsing is taking some collection of symbols, and emitting some other structure that obeys certain rules. Those symbols need not be text, they can be any abstract "thing". A symbol could be a full-blown data structure - you can parse a List into a NotEmptyList, where there's some associated grammar with the NEL that's a stricter version of the List grammar.
    - justinpombrio 5y ago
      Haha, "Those symbols need not be text", you say, right after quoting a definition that says they need to be "a string or text"! There's a field of study called "parsing", which studies "parsers". Hundreds of papers. Very well defined problem: turning a list of symbols into a tree shaped parse tree (or data structure). The defining aspect of parsing, that makes it difficult and an interesting thing to study, is that you're starting with a list and ending with a tree. If you're converting tree to tree (that is, a typical data structure to a typical data structure), all the problems vanish (or change drastically) and all the parsing techniques are inapplicable. I'm kind of annoyed that people are starting to use the word "parse" metaphorically. Bit by bit, precise words turn fuzzy. Alas, it will be a lost battle.
      - kortex 5y ago
        > Haha, "Those symbols need not be text", you say, right after quoting a definition that says they need to be "a string or text"! Ha yeah nice catch, that's why I added that in there. In this case the dictionary is slightly wrong. > The defining aspect of parsing, that makes it difficult and an interesting thing to study, is that you're starting with a list and ending with a tree. Ah, I didn't know that! Great bit to learn. In that case, I will say that the "increase a data structure's rules" is a bit ambiguous. I think my statement is still correct in that "a symbol could be a data structure," right? Like you could take a list of dicts and emit a tree of dicts. But wait, a list is a kind of tree, or rather, there is a parse tree of recursive head/tail branches. So I think you could still argue List->NotEmptyList is a Parse because NEL requires a nonzero "head" and zero or one NEL as "tail."
dgb23 5y ago
It's more like putting the "extra steps" at the right place in the code.
kortex 5y ago
Validation is checking if something looks like a data structure. Parsing is smashing data into a data structure, and failing out if you can't do it. At the end of parsing, you have a structure with a type. After validation, you may or may not have a structure with that type, depending on how you chose to validate. But I think the big win is, parsers are usually much easier to compose (since they themselves are structured functions) and so if you start with the type first, you often get the "validation" behavior aspect of parsing for "free" (usually from a library). Maybe title should have been "Parse, don't manually validate." But if your type doesn't catch all your invariants, yeah it does feel kinda just like validation.

The post is saying: - don't drop the info gathered from checks while validating, but keep track of it - if you do this, you'll effectively be parsing - parsing is more powerful that validating "Extra steps" would be keeping track of info gathered from checks.

bruce343434 5y ago
Right. My takeaway was "verify and validate once, then put it in a specially marked datastructure, or if your language allow it make the typesystem guarantee some conditions of the data, then work with that from there". Where does parsing come in the picture?
- justinpombrio 5y ago
  You understand it. It's using the word "parse" metaphorically, to mean "validate, then put it in a specially marked data structure". For example, `parse_int :: string -> maybe int` is a parsing function, and it "validates that the string is an integer, then puts it in a specially marked data structure called int". However, the post uses the word "parse" not only for true parsing functions (that convert text into a data structure), but also for conversions from data structure to data structure. I also find this a confusing use of the word "parse", and it's not explained in the post, and I think "parse, don't validate" is a poor slogan as a result. The traditional slogan is "make illegal states unrepresentable", though that's a bit narrower of a concept.
  - b3morales 5y ago
    I don't think this is the same as "make illegal states unrepresentable"; it's a corollary (or the converse maybe): "Make assertions of legal states representable"
    - joshuamorton 5y ago
      They're sort of the same. If you have str and safestr, and safestr is known to confiorm to some invariant, the illegal state of a, say str where validate hasn't been called, isn't representable.
- vvillena 5y ago
  Well, ain't that it? If you validate a string so that it contains some angle bracket tags at the beginning and the end, ensure that both the tag values contain the same string (except for one extra marker in the end tag), and store the tag name and the string within the tags in a purpose-made data structure, you can call it whatever you want. Some will call that a rudimentary XML parser.
- kortex 5y ago
  > verify and validate once, then put it in a specially marked datastructure Not to steal vvillena's thunder, but that's pretty much the dictionary definition of "parsing" > analyze (a string or text) into logical syntactic components, typically in order to test conformability to a logical grammar. Parsing is taking some collection of symbols, and emitting some other structure that obeys certain rules. Those symbols need not be text, they can be any abstract "thing". A symbol could be a full-blown data structure - you can parse a List into a NotEmptyList, where there's some associated grammar with the NEL that's a stricter version of the List grammar.
  - justinpombrio 5y ago
    Haha, "Those symbols need not be text", you say, right after quoting a definition that says they need to be "a string or text"! There's a field of study called "parsing", which studies "parsers". Hundreds of papers. Very well defined problem: turning a list of symbols into a tree shaped parse tree (or data structure). The defining aspect of parsing, that makes it difficult and an interesting thing to study, is that you're starting with a list and ending with a tree. If you're converting tree to tree (that is, a typical data structure to a typical data structure), all the problems vanish (or change drastically) and all the parsing techniques are inapplicable. I'm kind of annoyed that people are starting to use the word "parse" metaphorically. Bit by bit, precise words turn fuzzy. Alas, it will be a lost battle.
    - kortex 5y ago
      > Haha, "Those symbols need not be text", you say, right after quoting a definition that says they need to be "a string or text"! Ha yeah nice catch, that's why I added that in there. In this case the dictionary is slightly wrong. > The defining aspect of parsing, that makes it difficult and an interesting thing to study, is that you're starting with a list and ending with a tree. Ah, I didn't know that! Great bit to learn. In that case, I will say that the "increase a data structure's rules" is a bit ambiguous. I think my statement is still correct in that "a symbol could be a data structure," right? Like you could take a list of dicts and emit a tree of dicts. But wait, a list is a kind of tree, or rather, there is a parse tree of recursive head/tail branches. So I think you could still argue List->NotEmptyList is a Parse because NEL requires a nonzero "head" and zero or one NEL as "tail."

dgb23 5y ago

It's more like putting the "extra steps" at the right place in the code.

kortex 5y ago

Validation is checking if something looks like a data structure. Parsing is smashing data into a data structure, and failing out if you can't do it. At the end of parsing, you have a structure with a type. After validation, you may or may not have a structure with that type, depending on how you chose to validate. But I think the big win is, parsers are usually much easier to compose (since they themselves are structured functions) and so if you start with the type first, you often get the "validation" behavior aspect of parsing for "free" (usually from a library). Maybe title should have been "Parse, don't manually validate." But if your type doesn't catch all your invariants, yeah it does feel kinda just like validation.