• Brian Schott (11/11) Oct 30 2013 Stop modifying the language without also modifying the language
• Timothee Cour (5/15) Oct 30 2013 actually the author of Dscanner would probably feel the same:
• Dicebot (3/8) Oct 30 2013 Just in case : Brian is the author of Dscanner ;)
• Michael (6/6) Oct 30 2013 We need to go deeper...
• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (3/5) Oct 30 2013 Agreed. Your tool should be incorporated into the build (or release) ste...
• Ary Borenszweig (2/7) Oct 31 2013 As well as every other tool that uses D.
• Dicebot (4/5) Oct 31 2013 It has been already discussed as impractical. While easy CI for D
• Ary Borenszweig (6/10) Oct 31 2013 I wasn't serious.
• Brian Schott (2/9) Oct 31 2013 I'm not sure how it would be useful there.
• =?UTF-8?B?QWxpIMOHZWhyZWxp?= (7/18) Oct 31 2013 I imagined using it as a tool to make sure that the new dmd will not
• Kagamin (2/2) Nov 01 2013 Scintilla has lexer tests which work by marking up the output and

"Brian Schott" <briancschott gmail.com> writes:

Stop modifying the language without also modifying the language 
spec.

Seriously.

Stop it.

Pull requests that modify the parser should be rejected unless 
they also have the corresponding changes to the language grammar.

I spend a decent amount of my spare time on D development tooling 
and I'm getting sick of the "Your parser rejects X", "X isn't in 
the language spec", "DMD accepts X" cycle.

The current situation is that the only REAL documentation on D's 
syntax is the front-end source code, and this is ridiculous.

Timothee Cour <thelastmammoth gmail.com> writes:

actually the author of Dscanner would probably feel the same:
I've reported a number of issues that were due to mismatch bw D spec and
dmd:
https://github.com/Hackerpilot/Dscanner/issues?state=open


On Wed, Oct 30, 2013 at 12:04 PM, Brian Schott <briancschott gmail.com>wrote:

 Stop modifying the language without also modifying the language spec.

 Seriously.

 Stop it.

 Pull requests that modify the parser should be rejected unless they also
 have the corresponding changes to the language grammar.

 I spend a decent amount of my spare time on D development tooling and I'm
 getting sick of the "Your parser rejects X", "X isn't in the language
 spec", "DMD accepts X" cycle.

 The current situation is that the only REAL documentation on D's syntax is
 the front-end source code, and this is ridiculous.

"Dicebot" <public dicebot.lv> writes:

On Wednesday, 30 October 2013 at 20:00:00 UTC, Timothee Cour 
wrote:
 actually the author of Dscanner would probably feel the same:
 I've reported a number of issues that were due to mismatch bw D 
 spec and
 dmd:
 https://github.com/Hackerpilot/Dscanner/issues?state=open

Just in case : Brian is the author of Dscanner ;)

"Michael" <pr m1xa.com> writes:

We need to go deeper...
That is recursive reference...
It's not stoppable...

Real guys write binary code directly and then source code as 
documentation.

;)

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 10/30/2013 12:04 PM, Brian Schott wrote:

 Pull requests that modify the parser should be rejected unless they also
 have the corresponding changes to the language grammar.

Agreed. Your tool should be incorporated into the build (or release) steps.

Ali

Ary Borenszweig <ary esperanto.org.ar> writes:

On 10/30/13 6:09 PM, Ali Çehreli wrote:
 On 10/30/2013 12:04 PM, Brian Schott wrote:

  > Pull requests that modify the parser should be rejected unless they also
  > have the corresponding changes to the language grammar.

 Agreed. Your tool should be incorporated into the build (or release) steps.

 Ali

As well as every other tool that uses D.

"Dicebot" <public dicebot.lv> writes:

On Thursday, 31 October 2013 at 16:57:24 UTC, Ary Borenszweig 
wrote:
 As well as every other tool that uses D.

It has been already discussed as impractical. While easy CI for D 
projects is important, it should be in separate test suite.

Ary Borenszweig <ary esperanto.org.ar> writes:

On 10/31/13 2:15 PM, Dicebot wrote:
 On Thursday, 31 October 2013 at 16:57:24 UTC, Ary Borenszweig wrote:
 As well as every other tool that uses D.

 It has been already discussed as impractical. While easy CI for D
 projects is important, it should be in separate test suite.

I wasn't serious.

What I'm saying, the solution isn't "DScanner should be incorporated 
into the build step".

The simplest solution is to go slower, paying attention to these details 
and maintaining consistency in the language and the specs.

"Brian Schott" <briancschott gmail.com> writes:

On Wednesday, 30 October 2013 at 21:09:09 UTC, Ali Çehreli wrote:
 On 10/30/2013 12:04 PM, Brian Schott wrote:

 Pull requests that modify the parser should be rejected

 unless they also
 have the corresponding changes to the language grammar.

 Agreed. Your tool should be incorporated into the build (or 
 release) steps.

 Ali

I'm not sure how it would be useful there.

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 10/31/2013 11:46 AM, Brian Schott wrote:> On Wednesday, 30 October 
2013 at 21:09:09 UTC, Ali Çehreli wrote:
 On 10/30/2013 12:04 PM, Brian Schott wrote:

 Pull requests that modify the parser should be rejected

 unless they also
 have the corresponding changes to the language grammar.

 Agreed. Your tool should be incorporated into the build (or release)
 steps.

 Ali

 I'm not sure how it would be useful there.

I imagined using it as a tool to make sure that the new dmd will not 
break existing parsing or language spec. Although I am not sure what 
kind of test can verify that, the idea would be to notice that some 
perhaps implicit spec is about to be changed.

Ali

"Kagamin" <spam here.lot> writes:

Scintilla has lexer tests which work by marking up the output and 
comparing with etalon string.