I have committed a few major and minor changes to dparse

Some of these are breaking changes but shouldn't be that bad as it's just a change in the code line used to generate a parser.

The major reason for these changes is speed. Compile times for my "big" grammar went from (IIRC) 17 min to 1 min 22 sec.

== Quote from BCS (ao@pathlink.com)'s article
> I have committed a few major and minor changes to dparse

Here's a link for anyone not familiar with dparse: http://www.dsource.org/projects/scrapple/browser/trunk/dparser/dparse.d

Reply to jcc7,

> == Quote from BCS (ao@pathlink.com)'s article
> 
>> I have committed a few major and minor changes to dparse
>> 
> Here's a link for anyone not familiar with dparse:
> http://www.dsource.org/projects/scrapple/browser/trunk/dparser/dparse.
> d
> 

Err.. Thanks

--BCS, aka "The Shumk", aka "The Forgetfull One" aka ...

Small bug found (and I have a fix but it's at home):

Rule's with a name that have spaces between them and the ':' don't work.

I'll fix it ASAP

Reply to BCS,

> Small bug found (and I have a fix but it's at home):
> 
> Rule's with a name that have spaces between them and the ':' don't
> work.
> 
> I'll fix it ASAP
> 

done

also the grammar file used for the unittest has been added (BTW, the file doesn’t work as it is left recursive)

I'm planing on adding "!" as a "not" suffix in dparse (if "Blah" can be parsed, fail, else continue from the same place) and I'm wondering if anyone would find the reverse useful (try to parse a "Foo", if it works, drop it, back up to where we started and continue, else fail). Also is there any suggestions as to what suffix to use?

BCS wrote:
> I'm planing on adding "!" as a "not" suffix in dparse (if "Blah" can be parsed, fail, else continue from the same place) and I'm wondering if anyone would find the reverse useful (try to parse a "Foo", if it works, drop it, back up to where we started and continue, else fail). Also is there any suggestions as to what suffix to use?

Wouldn't that be equivalent to '!!'?
At least, from what I understand "Foo!!" would mean: if "Foo!" can be parsed then fail, otherwise succeed (matching the empty string).
The first should happen if "Foo" can't be parsed, the second one happens if it can.

It's not the most intuitive operator, of course ;).

Frits van Bommel wrote:
> BCS wrote:
> 
>> I'm planing on adding "!" as a "not" suffix in dparse (if "Blah" can be parsed, fail, else continue from the same place) and I'm wondering if anyone would find the reverse useful (try to parse a "Foo", if it works, drop it, back up to where we started and continue, else fail). Also is there any suggestions as to what suffix to use?
> 
> 
> Wouldn't that be equivalent to '!!'?
> At least, from what I understand "Foo!!" would mean: if "Foo!" can be parsed then fail, otherwise succeed (matching the empty string).
> The first should happen if "Foo" can't be parsed, the second one happens if it can.
> 
> It's not the most intuitive operator, of course ;).

I was kidna hoping for a single char as it make the parsing of the BNF simpler.

Thinking about it, the only reasonable chars I have left are: ~#$%^&_-=\<>,.

BCS wrote:
> Frits van Bommel wrote:
>> BCS wrote:
>>
>>> I'm planing on adding "!" as a "not" suffix in dparse (if "Blah" can be parsed, fail, else continue from the same place) and I'm wondering if anyone would find the reverse useful (try to parse a "Foo", if it works, drop it, back up to where we started and continue, else fail). Also is there any suggestions as to what suffix to use?
>>
>>
>> Wouldn't that be equivalent to '!!'?
>> At least, from what I understand "Foo!!" would mean: if "Foo!" can be parsed then fail, otherwise succeed (matching the empty string).
>> The first should happen if "Foo" can't be parsed, the second one happens if it can.
>>
>> It's not the most intuitive operator, of course ;).
> 
> I was kidna hoping for a single char as it make the parsing of the BNF simpler.

Well, this would make (the implmentation of) the parsing simpler; just implement '!' and you get the other one for free! :P

> Thinking about it, the only reasonable chars I have left are: ~#$%^&_-=\<>,.

Hmmm... I could see '&'; it's the bash command-postfix for starting a process in the background. Also, both the operand _&_ the rest of the expression must match :).

Frits van Bommel wrote:
> BCS wrote:
> 
>> Frits van Bommel wrote:
>>
>>> BCS wrote:
>>>
>>>> I'm planing on adding "!" as a "not" suffix in dparse (if "Blah" can be parsed, fail, else continue from the same place) and I'm wondering if anyone would find the reverse useful (try to parse a "Foo", if it works, drop it, back up to where we started and continue, else fail). Also is there any suggestions as to what suffix to use?
>>>
>>>
>>>
>>> Wouldn't that be equivalent to '!!'?
>>> At least, from what I understand "Foo!!" would mean: if "Foo!" can be parsed then fail, otherwise succeed (matching the empty string).
>>> The first should happen if "Foo" can't be parsed, the second one happens if it can.
>>>
>>> It's not the most intuitive operator, of course ;).
>>
>>
>> I was kidna hoping for a single char as it make the parsing of the BNF simpler.
> 
> 
> Well, this would make (the implmentation of) the parsing simpler; just implement '!' and you get the other one for free! :P
> 

Given that I have no nested constructs, I !! doesn't "just work", it just fails to parse :(

>> Thinking about it, the only reasonable chars I have left are: ~#$%^&_-=\<>,.
> 
> 
> Hmmm... I could see '&'; it's the bash command-postfix for starting a process in the background. Also, both the operand _&_ the rest of the expression must match :).

Good argument. Thanks