4 ms·

> Everyone uses regexes; using a lexer generator should (in my opinion) be as easy as using a one-off regex. I think the key is to make the lexer generator an e

by eco 13y ago

> Everyone uses regexes; using a lexer generator should (in my opinion) be as easy as using a one-off regex. I think the key is to make the lexer generator an embeddable library like regex libraries are. There actually is a really powerful parser generator for D by Philippe Sigaud: https://github.com/PhilippeSigaud/Pegged https://github.com/PhilippeSigaud/Pegged It's much more pleasant to use than something like Boost Spirit. Somewhat relatedly, D's standard library has a compile time regex engine that compiles regular expressions down at compile-time resulting in some of the fastest regular expressions in the world.

haberman 13y ago
That's cool, though "some of the fastest regular expressions in the world" might be a bit of hyperbole: it would be comparable to any compile-time generator like Flex, Ragel, or a JIT generator like PCRE-sljit. And since D is a memory-safe language, I would expect the guards on buffer access to cause measurable overhead compared with C or C++ generated code.
- eco 13y ago
  By that I meant it is in the same league as the fastest regular expression engines in the world. I should have worded that better. It comes out around the same performance as V8's and Boost Xpressive.
- pjmlp 13y ago
  > And since D is a memory-safe language, I would expect the guards on buffer access to cause measurable overhead compared with C or C++ generated code. The typical C FUD being spread against memory safe languages since the early 80's. Most optimizing compilers are able to remove bounds checking if dataflow analysis can prove the code stays within bounds. For the cases where the compiler is not that smart, and the programmer has proven with help of profilers that bounds checking are indeed a problem, most compilers offer the possibility to disable bounds checking either at module or code region level. So one gets the memory safety by default, but if really really really required, it is still possible to rescue those extra ms. The thing is, in these languages one needs to ask permission to shot our foots off, instead of being able to do it in every code line.

by eco 13y ago

haberman 13y ago

That's cool, though "some of the fastest regular expressions in the world" might be a bit of hyperbole: it would be comparable to any compile-time generator like Flex, Ragel, or a JIT generator like PCRE-sljit. And since D is a memory-safe language, I would expect the guards on buffer access to cause measurable overhead compared with C or C++ generated code.

eco 13y ago
By that I meant it is in the same league as the fastest regular expression engines in the world. I should have worded that better. It comes out around the same performance as V8's and Boost Xpressive.
pjmlp 13y ago
> And since D is a memory-safe language, I would expect the guards on buffer access to cause measurable overhead compared with C or C++ generated code. The typical C FUD being spread against memory safe languages since the early 80's. Most optimizing compilers are able to remove bounds checking if dataflow analysis can prove the code stays within bounds. For the cases where the compiler is not that smart, and the programmer has proven with help of profilers that bounds checking are indeed a problem, most compilers offer the possibility to disable bounds checking either at module or code region level. So one gets the memory safety by default, but if really really really required, it is still possible to rescue those extra ms. The thing is, in these languages one needs to ask permission to shot our foots off, instead of being able to do it in every code line.