for lexing there's already dscanner we could use (while we wait for perhaps a autogenerated lexer); so I think priority is on the autogenerated parser (dscanner has one but hand designed), where it's still unknown what will work well.
On Mon, Nov 4, 2013 at 2:43 AM, Dmitry Olshansky <dmitry.o...@gmail.com>wrote: > 04-Nov-2013 12:28, Robert Schadek пишет: > >> On 11/04/2013 06:48 AM, Philippe Sigaud wrote: >> >>> On Sun, Nov 3, 2013 at 7:08 PM, Timothee Cour >>> <thelastmamm...@gmail.com <mailto:thelastmamm...@gmail.com>> wrote: >>> >>> >>> On Sun, Nov 3, 2013 at 1:13 AM, Philippe Sigaud >>> <philippe.sig...@gmail.com <mailto:philippe.sig...@gmail.com>>wrote: >>> >>> >>> >>> My current plan is to write different engines, and letting >>> either the user select them at compile-time, or to have the >>> parser decide which one to use, depending on the grammar. I'm >>> pretty sure the 'Type 3' parts of a grammar (regular >>> expressions) could be bone by using std.regex, for example. >>> >>> >>> even lexing can't be done with regex, eg nesting comments : /+ ... +/ >>> Also, although it may seem cleaner at first to combine lexing and >>> parsing in 1 big grammar (as done in pegged), it usually is faster >>> do feed a (separate) lexer output into parser. >>> >>> >>> Lexing, yes. I was imprecise: even in a context-free grammar, some >>> rules are regular and could use std.regex (the ct part) as the >>> underlying engine, just for that rule. >>> >> Lexing can not be done with regex. Think myArray[1. ] ! What is next a >> dot or a number. >> > > You could use lookahead extension ;) > > In general I would not recommend ATM to use std.regex for > performance-critical lexer if only because it wasn't tuned for such a use > case yet. > > I have plans for extending std.regex capabilities in many directions, > lexing being one important use case. > > -- > Dmitry Olshansky >
