D parsing

Dmitry Olshansky dmitry.olsh at gmail.com
Mon Nov 4 02:43:58 PST 2013


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
>> <thelastmammoth at gmail.com <mailto:thelastmammoth at gmail.com>> wrote:
>>
>>
>>     On Sun, Nov 3, 2013 at 1:13 AM, Philippe Sigaud
>>     <philippe.sigaud at gmail.com <mailto:philippe.sigaud at 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


More information about the Digitalmars-d mailing list