Digital Mars - digitalmars.D.announce - template based parser generator gets major speed boost

↑ ↓ ← → BCS <ao pathlink.com> writes:

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.

Mar 13 2008

↑ ↓ ← → jcc7 <technocrat7 gmail.com> writes:

== 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

Mar 14 2008

↑ ↓ ← → BCS <ao pathlink.com> writes:

Reply to jcc7,

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


 http://www.dsource.org/projects/scrapple/browser/trunk/dparser/dparse.
 d
 


Err.. Thanks

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

Mar 14 2008

↑ ↓ ← → BCS <ao pathlink.com> writes:

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)

Mar 16 2008

↑ ↓ ← → BCS <ao pathlink.com> writes:

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?

Mar 31 2008

↑ ↓ ← → Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

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 ;).

Apr 01 2008

↑ ↓ ← → BCS <BCS pathlink.com> writes:

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: ~#$%^&_-=\<>,.

Apr 01 2008

↑ ↓ ← → Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

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 :).

Apr 01 2008

↑ ↓ ← → BCS <BCS pathlink.com> writes:

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

Apr 01 2008

↑ ↓ ← → Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

BCS wrote:
 Frits van Bommel wrote:
 BCS wrote:

 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 :(


Perhaps you should fix that then :P.

Apr 01 2008

↑ ↓ ← → BCS <BCS pathlink.com> writes:

Frits van Bommel wrote:
 BCS wrote:
 
 Frits van Bommel wrote:

 BCS wrote:

 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 :(


 
 Perhaps you should fix that then :P.


It can't be. The structure of the system can't work that way and would 
have to be rebuilt to make it work.

Apr 01 2008

↑ ↓ ← → Russell Lewis <webmaster villagersonline.com> writes:

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?


PERL regular expressions have lookahead (and negative lookahead):

(?=pattern)
	Matches pattern, but doesn't include pattern in the result
(?!pattern)
	Will only succeed if pattern does *not* match.

Apr 01 2008

↑ ↓ ← → BCS <BCS pathlink.com> writes:

Russell Lewis 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?


 
 PERL regular expressions have lookahead (and negative lookahead):
 
 (?=pattern)
     Matches pattern, but doesn't include pattern in the result
 (?!pattern)
     Will only succeed if pattern does *not* match.


I /knew/ I saw that someplace! However the "=" doesn't work as a suffix. 
Oh well. Thanks.

Apr 01 2008