4 ms·

Great, but why do you need a library for this? I just write classes with a falliable static parse method and a private constructor. It looks like this library

by twic 5y ago

Great, but why do you need a library for this? I just write classes with a falliable static parse method and a private constructor. It looks like this library was written by someone labouring under the mistaken belief that it's better to build and use a DSL to create the illusion of declarativity than to just write a line or two of normal code (eg the focusedParse stuff). Also, i demur somewhat at calling this parsing. It's tracking validation using typestate.

mixedCase 5y ago
You'll want to read on "parser combinator" as a concept. A parser combinator library can provide a good repertoire of primitives, standard interfaces for defining and using the parsers, and utilities for working with those interfaces. User-friendly error reporting comes to mind.
- slver 5y ago
  This only matters when you parse complex syntax. Most input isn’t.
  - mixedCase 5y ago
    Boring Line-of-Business Applications have their bread and butter by parsing JSON and treating it with more meaning than what `string | number | boolean | object` can express. Therefore, they can benefit from parsers. If you think JSON primitives are "enough to express most input" then you missed the point; because of course you can, but no person who has learnt to use types to their advantage would want to write error-prone code and an unnecessary amount of unit tests that deal with ambiguous behavior for no good reason.
    - slver 5y ago
      Parsing JSON with various slightly specialized string fields like "email" or "url" and so on is precisely what I had in mind by simple input. There's absolutely nothing there for "parser combinators" to do. JSON parsing is a standalone step, and the values retrieved from it can be passed to another EXISTING (mind you) validators to handle the rest. I live and breath this every day as I deal with forms and APIs for a living. And I never was like "oh man this is hard, if I only had parser combinators". > If you think JSON primitives are "enough to express most input" then you missed the point Unclear why you're trying to put words in my mouth, but JSON is enough to describe the composition of input (in terms of lists, dictionaries and leaf scalar values). Which as simple as it is, turns out to be a very significant part of the task. Of course you have additional constraints on top of that. But no need for "parser combinators". To JSON, a string is a string. Any additional operations performed on that string happen AFTER it's decoded from a JSON string format to an in-memory native string literal. Those are entirely independent steps. A simple function composition would do i.e. json => string => email. And that's more or less how I parse arbitrary data input. All of which is simple to parse. Relative to, you know, say parsing a full programming language.
Iazel 5y ago
If that style works for you, please be my guest! As usual, this library is just a tool, it may or may not fit your use case, and that's fine ;) By no means we want to pass the message that you have to use this library to benefit from the "Parse, don't validate" pattern. What we want is to make the pattern more mainstream and provide a nice set of functionalities out of the box :) Also I would like to encourage everyone to get as much as you need from this library. If you don't like `focusedParse`, please don't use it! xD
Iazel 5y ago
Talking about "parsing", I see that different people have a different understanding of it. I will fix this point by writing in the README what we mean when we way "parsing" :) Allow me to disagree with the "tracking validation using typestate" bit. This is just one way, but using Parsix you can also go from a String to a more complex type like Email(local: Local, domain: Domain), where Local and Domain can also be other complex types. The point is, you should parse as much or as little as you need in your domain. That's why we call it "general-purpose parsing" ;)

by twic 5y ago

mixedCase 5y ago

You'll want to read on "parser combinator" as a concept. A parser combinator library can provide a good repertoire of primitives, standard interfaces for defining and using the parsers, and utilities for working with those interfaces. User-friendly error reporting comes to mind.

slver 5y ago
This only matters when you parse complex syntax. Most input isn’t.
- mixedCase 5y ago
  Boring Line-of-Business Applications have their bread and butter by parsing JSON and treating it with more meaning than what `string | number | boolean | object` can express. Therefore, they can benefit from parsers. If you think JSON primitives are "enough to express most input" then you missed the point; because of course you can, but no person who has learnt to use types to their advantage would want to write error-prone code and an unnecessary amount of unit tests that deal with ambiguous behavior for no good reason.
  - slver 5y ago
    Parsing JSON with various slightly specialized string fields like "email" or "url" and so on is precisely what I had in mind by simple input. There's absolutely nothing there for "parser combinators" to do. JSON parsing is a standalone step, and the values retrieved from it can be passed to another EXISTING (mind you) validators to handle the rest. I live and breath this every day as I deal with forms and APIs for a living. And I never was like "oh man this is hard, if I only had parser combinators". > If you think JSON primitives are "enough to express most input" then you missed the point Unclear why you're trying to put words in my mouth, but JSON is enough to describe the composition of input (in terms of lists, dictionaries and leaf scalar values). Which as simple as it is, turns out to be a very significant part of the task. Of course you have additional constraints on top of that. But no need for "parser combinators". To JSON, a string is a string. Any additional operations performed on that string happen AFTER it's decoded from a JSON string format to an in-memory native string literal. Those are entirely independent steps. A simple function composition would do i.e. json => string => email. And that's more or less how I parse arbitrary data input. All of which is simple to parse. Relative to, you know, say parsing a full programming language.

Iazel 5y ago

If that style works for you, please be my guest! As usual, this library is just a tool, it may or may not fit your use case, and that's fine ;) By no means we want to pass the message that you have to use this library to benefit from the "Parse, don't validate" pattern. What we want is to make the pattern more mainstream and provide a nice set of functionalities out of the box :) Also I would like to encourage everyone to get as much as you need from this library. If you don't like `focusedParse`, please don't use it! xD

Iazel 5y ago

Talking about "parsing", I see that different people have a different understanding of it. I will fix this point by writing in the README what we mean when we way "parsing" :) Allow me to disagree with the "tracking validation using typestate" bit. This is just one way, but using Parsix you can also go from a String to a more complex type like Email(local: Local, domain: Domain), where Local and Domain can also be other complex types. The point is, you should parse as much or as little as you need in your domain. That's why we call it "general-purpose parsing" ;)