
Tyre – Typed regular expressions - dwc
https://drup.github.io/2016/08/12/tyre/
======
yawaramin
See also an interesting typed regex implementation by Gabriel Gonzalez:
[https://github.com/Gabriel439/slides/blob/master/regex/regex...](https://github.com/Gabriel439/slides/blob/master/regex/regex.md)

~~~
mchaver
Is there any advantage to using regex over a parser combinator?

~~~
gergoerdi
Depends on the parser combinator library.

Real regexes can be matched in time linear in the input size; you'll need to
use an applicative parser combinator like regex-applicative
([https://hackage.haskell.org/package/regex-
applicative](https://hackage.haskell.org/package/regex-applicative)) to get
that kind of asymptotic complexity. A monadic one like Parsec is impossible to
analyze statically to turn into a finite automaton.

~~~
mchaver
Interesting. Attoparsec is usually my preferred parsing library, but regex-
applicative looks very useful for smaller, less complicated parsers.

------
kukx
It's an interesting experiment and an inspiring one.

However, I don't think this solution will help too much with regexes. To me
it's overly complex and less readable than regex strings.

~~~
Drup
Hi, author here!

I didn't invented the combinators for regex, that was already in ocaml-re
(which is used as backend for tyre). The combinator approach has many
advantages:

\- You don't need to remember _which_ regex syntax the library is using. Is it
using the emacs one ? The perl one ? The javascript one ? The bash one ?! (
_shudder_ ) ...

\- It's "self documenting". Your combinators are just functions, so you just
expose them and give them type signatures, and the usual
documentation/autocompletion/whatevertooling works.

\- It composes better. You don't have to mash string together to compose your
regex, you can name intermediary regexs with normal variables, etc.

\- Related to the point above: No string quoting hell.

Now, tyre doesn't really improve any of that. If anything, combinators are
simpler in ocaml-re[1]. What tyre gives you is the automatic extraction and
casting of matching groups into the desired datatype (and the reverse
direction, but that's almost free bonus). No need to select groups manually
and transform into an integer, no need to reconstruct tuples/lists/records,
tyre will do that for you (and handle conversion failures cleanly).

[1]: [https://github.com/ocaml/ocaml-
re/blob/master/lib/re.mli#L20...](https://github.com/ocaml/ocaml-
re/blob/master/lib/re.mli#L207-L277)

~~~
hyperpallium
Hi, your homepage "unparsing" link goes to _#evaluating_ , but the anchor on
the docs page has _id= "eval"_

Also, how flexible is the unparsing? Does it have to be the same regular
expression? [Sorry, I haven't read in detail and I'm only slightly familiar
with ocaml - I'm interested from an academic perspective.]

~~~
Drup
If I understand your question correctly, no, it doesn't. Actually, the thing
that you "unparse" doesn't even have to come from a regex matching to begin
with. As long as the type matches, everything is fine.

If you are interested by unparsing, I would advise you to read the (famous)
paper functional unparsing by Danvy[1]. The module Printf and Format of the
OCaml standard library are basically this paper on steroid. I recently wrote a
blog on part of the implementation technique[2].

Hope that helps. :)

[1]: [http://www.brics.dk/RS/98/12/BRICS-
RS-98-12.pdf](http://www.brics.dk/RS/98/12/BRICS-RS-98-12.pdf)

[2]:
[https://drup.github.io/2016/08/02/difflists/](https://drup.github.io/2016/08/02/difflists/)

[Printf]: [http://caml.inria.fr/pub/docs/manual-
ocaml/libref/Printf.htm...](http://caml.inria.fr/pub/docs/manual-
ocaml/libref/Printf.html)

[Format]: [http://caml.inria.fr/pub/docs/manual-
ocaml/libref/Format.htm...](http://caml.inria.fr/pub/docs/manual-
ocaml/libref/Format.html)

~~~
hyperpallium
Ah, thanks. I think one needs (structural) type transformation for the
flexibility I had mind, things like swapping sum operands, re-ordering
concantenation operands.

Uh... did you see my bug report on your webpage (first sentence above)? That
link still doesn't work properly.

------
aslakhellesoy
Slightly related, Cucumber will soon support a typed expression format called
Cucumber Expressions: [https://docs.cucumber.io/cucumber-
expressions/](https://docs.cucumber.io/cucumber-expressions/)

It's a standalone library and may well be used outside of Cucumber.

It's currently implemented in JavaScript, Java and Ruby.

------
1_player
A minor nitpick: wrong syntax highlighting is worse than no syntax
highlighting at all.

The example in the home page is hard to parse and understand.

------
Graphon1
What could anyone _possibly_ do to improve Regular Expressions ?

~~~
adrusi
Perl6 made a lot of improvements
[https://docs.perl6.org/language/regexes](https://docs.perl6.org/language/regexes)

Technically not regular expressions since they are appropriate for matching
much more than regular grammars, but that's true for almost any programming
language's "regular expressions".

~~~
cyphar
> Perl6 made a lot of improvements
> [https://docs.perl6.org/language/regexes](https://docs.perl6.org/language/regexes)

IMO the word "improvements" should be in quotes. Pathological regular
expressions are an issue because of things like back references and look-
behind matching. If Perl hadn't enshrined the idea of "a regular expression
for every problem" people would probably be less skeptical of regular
expressions in code.

~~~
berntb
So why not use grammars, if regexps are too complex...?
[https://docs.perl6.org/language/grammars](https://docs.perl6.org/language/grammars)

(The extensions to regexps in Perl 5 (and presumably now also in PCRE?) have
made it possible to write them more like grammars than anything else. But you
would probably not approve. :-) )

