> On Dec 20, 2016, at 3:45 PM, Alexis King <lexi.lam...@gmail.com> wrote: > >> On Dec 20, 2016, at 07:54, Alex Knauth <alexan...@knauth.org> wrote: >> >> Oooh, that's pretty cool. Much better than my super-slow attempt. >> >> Should you make this into a package (I would certainly use it a lot) >> or would it make more sense to add in a pull request to the existing >> `match-string` package? > > I probably won’t take the time to turn it into a package, if only > because I’m not sure I’d really want that behavior for anything “real”; > I find that most of the time, when using regular expressions, (.*) is > not what you want. In this very example, the code invokes string->number > on one of the captured strings, which implies the pattern your actually > want is: > > ^(.*)--(\d+) (.*) end$ > > In reality, my experience is that you often want to use negated > character ranges instead of “.”, so the first capture group would be > ([^-]*) instead.
This could be expressed with a restricted syntax of `and` patterns. For example `(and str-pat id)` would turn into a group containing a regexp-ified str-pat but bind the result of the group to the id. If you make a pull request to add this as a separate module to my `match-string` package, I can work to try to combine the two in ways like this. > At this point, in order to use regular expressions and > have the constraints affect parsing, you need to compile the constraints > into the patterns themselves, not apply them post-hoc. For that reason, > you’d probably effectively want a s-expression regular expression > syntax. Would this be closer to what we would want then? https://docs.racket-lang.org/automata/index.html#%28part._re%29 <https://docs.racket-lang.org/automata/index.html#(part._re)> It allows regular expressions to be written on lists of tokens instead of just strings, and it allows them to be combined with s-expression operations like complement, union, intersection, and star. Alex Knauth > Personally, I’d just write this: > > [(regexp #px"^([^-]*)--(\\d+) (.*) end$" > (list _ a b c)) > ...] > > If you want to add something like it to your match-string package for > simple cases like this one, though, I won’t have any problem with that, > of course. I’ve just found that, most of the time, once I have something > that gets too complicated to read as an inline regular expression, it’s > easier for me to switch to full-fledged parser combinators rather than > try and prettify regexps. > > (Admittedly, though, this has made me realize I should probably enhance > megaparsack to cooperate with match in some way.) -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
