I was able to write a very succinct parser for woodworking (using imperial fractions) in around 38 lines of commented code. It parses strings like 0.25 or 2 or 1/4 or 1/4" or 1' 2 3/4" and pops out an integer or float in inches.
I had never used a parser combinator library before but I have written many recursive descent parsers over the years. I was a little surprised when I added the `debug: true` option and saw the shear amount of code it generated. That probably could be reduced by refactoring my combinators.
I left out “design” after woodworking. I’m building an online 3D DIY design and instructional app where you can customize plans by entering dimensions in a form (https://plansformer.com/).
head = 0x00
piece = <<0x01, 0x01, 0x01, 0x01, 0x01>>
<< head, # When a variable is already referenced it must be equal for the pattern to match
piece, # Match a string
rest :: binary >> # You can mix matching variables and assigning new variables.
it should have ^head, and ^piece (the term is "pinning"). Unlike in erlang, elixir will happily "reassign" variables to the new content on whatever is on a right side of the match.
I sometimes ponder, how much effort it would take to make a similar matching interface not for binaries but for regexps and/or something grammar-like. After structured matching of binaries regexps in elixir just feel awkward.
It wouldn't work well with other matching constructs, though, if matching is baked into beamvm itself as a core instruction for speed or something. Guess I have something to investigate this evening.
F#'s active patterns allow you to extend the built-in pattern matching to other things, and in this case, you can have patterns that return regular expression matches.
https://hexdocs.pm/nimble_parsec/NimbleParsec.html
I was able to write a very succinct parser for woodworking (using imperial fractions) in around 38 lines of commented code. It parses strings like 0.25 or 2 or 1/4 or 1/4" or 1' 2 3/4" and pops out an integer or float in inches.
I had never used a parser combinator library before but I have written many recursive descent parsers over the years. I was a little surprised when I added the `debug: true` option and saw the shear amount of code it generated. That probably could be reduced by refactoring my combinators.