Could ergonomics for simple use cases be improved?

[benhutchison]

I came to Parsely because I was noticing a proliferation of different libraries that do some kind of parsing, and many seem to be subsets of what Parsely can do. I thought, if I'm going to invest time, let's just learn the general parser combinator approach rather than lots of little DSLs that each invent their own abstraction that's really a parser.

And overall it's been a good experience in that I succeeded in getting Parsely to do what I need.

But. Feels there are definitely ways that Parsely could make simple DSL tasks more ergonomic and require half, or a quarter, the setup code.

In my case, Im parsing a series of lines which are commands. Basically, I have whitespace separators, some soft-keywords, commas, and everything else I want to treat as captured strings (identifiers).

That requires fiddling around with a lexer, but there's only one that comes out of the box, with heaps of dials, and by default it won't recognise any identifiers. I found that disappointing... what about some common, sensible defaults?

  val nameDesc = NameDesc.plain.copy(
      identifierStart = Basic(_.isLetter),
      identifierLetter = Basic(_.isLetter),
    )
  val lexer = new parsley.token.Lexer(parsley.token.descriptions.LexicalDesc.plain.copy(nameDesc = nameDesc))

When you're new, this kind of know-how is expensive to acquire, and honestly, I don't want to become any sort of expert on lexing yet. Just give me something that will (probably) work, preconfigured at a simple name.

[j-mie6]

Thanks for the comment!

Yes, at some point I'd like to build a few out of the box XDescs that might be useful for stuff like this. Perhaps NameDesc.alphaNumeric...

As a teacher I'm always a bit torn about this, because while you're right that parsley does pretty much everything out of the box, I run a compilers project where Scala+parsley is one of many combinations of tooling, the teacher half of me needs to make sure parsley doesn't run away with it and become unfair on the others (but statistically speaking, 95% of the students are now using Scala anyway) -- this is always at odds with the library maintainer half of me 🙂

[benhutchison]

There will always be a significant gap between the needs of education vs industry for a library like this, I feel.

I guess education wants to teach from first principles and have all the mechanisms visible.

Industry wants to solve applied problems with a minimum of code and complexity, and often would like the details packaged away where industrial users can ignore them when not required.

One potential way to cater to both audiences would be via layering. Have a second module or library with more pre-fab parsers and configurations for common situations, that builds atop the foundational parsley library.