www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dfmt 0.1.0

reply "Brian Schott" <briancschott gmail.com> writes:
dfmt is a D source code formatting tool.

https://github.com/Hackerpilot/dfmt/
https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0
Feb 19 2015
next sibling parent "MartinNowak" <code dawg.eu> writes:
On Friday, 20 February 2015 at 02:21:01 UTC, Brian Schott wrote:

 https://github.com/Hackerpilot/dfmt/
 https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0


Congrats, I found the reformatting a bit harsh from time to time, 
but it's a good opportunity to finally settle style discussions.
Feb 19 2015
prev sibling next sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Friday, 20 February 2015 at 02:21:01 UTC, Brian Schott wrote:

 dfmt is a D source code formatting tool.

 https://github.com/Hackerpilot/dfmt/
 https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0


Thanks, you should list some of the formatting changes it makes 
in the README.
Feb 19 2015
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Friday, 20 February 2015 at 05:23:45 UTC, Joakim wrote:

 On Friday, 20 February 2015 at 02:21:01 UTC, Brian Schott wrote:

 dfmt is a D source code formatting tool.

 https://github.com/Hackerpilot/dfmt/
 https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0


 Thanks, you should list some of the formatting changes it makes 
 in the README.


It doesn't do formatting changes. It wipes out the formatting 
during lexing and builds it up from scratch. The only thing that 
gets preserved is that it will look at line numbers on comments 
and try to keep them in roughly the same place. (For example, 
"//" comments that are on the end of a line instead of on the 
next line)
Feb 19 2015
next sibling parent "Joakim" <dlang joakim.fea.st> writes:
On Friday, 20 February 2015 at 05:53:32 UTC, Brian Schott wrote:

 On Friday, 20 February 2015 at 05:23:45 UTC, Joakim wrote:

 On Friday, 20 February 2015 at 02:21:01 UTC, Brian Schott 
 wrote:

 dfmt is a D source code formatting tool.

 https://github.com/Hackerpilot/dfmt/
 https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0


 Thanks, you should list some of the formatting changes it 
 makes in the README.


 It doesn't do formatting changes. It wipes out the formatting 
 during lexing and builds it up from scratch. The only thing 
 that gets preserved is that it will look at line numbers on 
 comments and try to keep them in roughly the same place. (For 
 example, "//" comments that are on the end of a line instead of 
 on the next line)


Well, you should indicate what that new formatting is in the 
README, so potential users know what to expect without having to 
run it first.
Feb 19 2015
prev sibling parent "Tourist" <gravatar gravatar.com> writes:
On Friday, 20 February 2015 at 05:53:32 UTC, Brian Schott wrote:

 On Friday, 20 February 2015 at 05:23:45 UTC, Joakim wrote:

 On Friday, 20 February 2015 at 02:21:01 UTC, Brian Schott 
 wrote:

 dfmt is a D source code formatting tool.

 https://github.com/Hackerpilot/dfmt/
 https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0


 Thanks, you should list some of the formatting changes it 
 makes in the README.


 It doesn't do formatting changes. It wipes out the formatting 
 during lexing and builds it up from scratch. The only thing 
 that gets preserved is that it will look at line numbers on 
 comments and try to keep them in roughly the same place. (For 
 example, "//" comments that are on the end of a line instead of 
 on the next line)


Several examples in the README would indeed be nice.
Feb 20 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-02-20 03:21, Brian Schott wrote:

 dfmt is a D source code formatting tool.

 https://github.com/Hackerpilot/dfmt/
 https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0


I looked at the tests, in particular "contracts.d.ref". I would expect 
an empty newline between an instance variable and a method.

-- 
/Jacob Carlborg
Feb 20 2015
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Friday, 20 February 2015 at 02:21:01 UTC, Brian Schott wrote:

 dfmt is a D source code formatting tool.

 https://github.com/Hackerpilot/dfmt/
 https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0


Great!

I've been using clang-format lately for my C++ code and it's 
really blown me away how good it is. It's not opinionated about 
how things should be, it just does whatever style you've set it 
to. The Visual Studio plugin they have just gives me a keyboard 
shortcut and when I hit it, it formats the current line or 
selection.

I waste almost no time formatting code now. I just type and hit 
the format key and move on. If it formatted something differently 
than how I would have done it I just let it be because how it 
formatted is usually almost as good anyway. I feel like it's been 
as big of boon to my coding speed as learning vim was.

 From what I understand they implemented a LaTeX style weighted 
line breaker which would explain why it works so much better than 
a typical code formatter. It's very smart about how it does line 
breaks. This seems to make all the difference.

This is all to say I hope dfmt becomes as awesome as clang-format 
is at some point. Hopefully I can find some time to contribute.
Feb 20 2015
parent "Brian Schott" <briancschott gmail.com> writes:
On Friday, 20 February 2015 at 23:00:25 UTC, Brad Anderson wrote:

 From what I understand they implemented a LaTeX style weighted 
 line breaker which would explain why it works so much better 
 than a typical code formatter. It's very smart about how it 
 does line breaks. This seems to make all the difference.


dfmt uses a weighting system for line breaks as well, though 
because this is 0.1.0 it doesn't always do what I expect it to do.
Feb 20 2015
prev sibling next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Friday, 20 February 2015 at 02:21:01 UTC, Brian Schott wrote:

 dfmt is a D source code formatting tool.

 https://github.com/Hackerpilot/dfmt/
 https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0


I just tagged 0.1.1. The only change is a bug fix for a case 
where certain long lines with parenthesis wouldn't wrap properly.
Feb 22 2015
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Sunday, 22 February 2015 at 08:48:16 UTC, Brian Schott wrote:

 On Friday, 20 February 2015 at 02:21:01 UTC, Brian Schott wrote:

 dfmt is a D source code formatting tool.

 https://github.com/Hackerpilot/dfmt/
 https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0


 I just tagged 0.1.1. The only change is a bug fix for a case 
 where certain long lines with parenthesis wouldn't wrap 
 properly.


v0.1.2 is tagged... "Move fast: things are broken", or something 
like that.
Feb 22 2015
next sibling parent "Ulrich =?UTF-8?B?S8O8dHRsZXIi?= <kuettler gmail.com> writes:
On Sunday, 22 February 2015 at 09:07:16 UTC, Brian Schott wrote:

 On Sunday, 22 February 2015 at 08:48:16 UTC, Brian Schott wrote:

 On Friday, 20 February 2015 at 02:21:01 UTC, Brian Schott 
 wrote:

 dfmt is a D source code formatting tool.

 https://github.com/Hackerpilot/dfmt/
 https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0


 I just tagged 0.1.1. The only change is a bug fix for a case 
 where certain long lines with parenthesis wouldn't wrap 
 properly.


 v0.1.2 is tagged... "Move fast: things are broken", or 
 something like that.


Just submitted a PR to include pesky braces a la
https://twitter.com/thedirtycoder/status/569339014085517312
Feb 22 2015
prev sibling parent reply "qznc" <qznc web.de> writes:
On Sunday, 22 February 2015 at 09:07:16 UTC, Brian Schott wrote:

 On Sunday, 22 February 2015 at 08:48:16 UTC, Brian Schott wrote:

 On Friday, 20 February 2015 at 02:21:01 UTC, Brian Schott 
 wrote:

 dfmt is a D source code formatting tool.

 https://github.com/Hackerpilot/dfmt/
 https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0


 I just tagged 0.1.1. The only change is a bug fix for a case 
 where certain long lines with parenthesis wouldn't wrap 
 properly.


 v0.1.2 is tagged... "Move fast: things are broken", or 
 something like that.


Congratulations to releasing. :)

For the record, I think using a D parser in dfmt is a dead end. 
Surely, for certain cases the additional information is 
necessary. However, it restricts dfmt to only format 
syntactically valid snippets. This means you cannot (in general) 
format parts of a file, e.g. within a diff or editor.

Example where parsing helps: "foo : bar" or "foo: bar" depending 
on the context. The former within import statements, the latter 
within switch statements.

Example for a snippet you cannot parse: The body of a switch 
statement without the switch. The 'case' keyword would be an 
error.

Effectively, you want to parse, but not with a normal parser. 
Great formatting seems to require a special (more flexible, less 
correct) parser. This is what clang-format does.
Feb 22 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-02-22 19:52, qznc wrote:


 Congratulations to releasing. :)

 For the record, I think using a D parser in dfmt is a dead end. Surely,
 for certain cases the additional information is necessary. However, it
 restricts dfmt to only format syntactically valid snippets. This means
 you cannot (in general) format parts of a file, e.g. within a diff or
 editor.

 Example where parsing helps: "foo : bar" or "foo: bar" depending on the
 context. The former within import statements, the latter within switch
 statements.

 Example for a snippet you cannot parse: The body of a switch statement
 without the switch. The 'case' keyword would be an error.


It depends on how the parser is implemented. For example, the Eclipse 
Java parser is very flexible when it comes to this. You can choose to 
either parse a complete file or just a fragment of code.


 Effectively, you want to parse, but not with a normal parser. Great
 formatting seems to require a special (more flexible, less correct)
 parser. This is what clang-format does.


clang-format uses the lexer with the help of the parser. It only changes 
whitespace. At least according to the talk I watched, which is a couple 
of years old.

-- 
/Jacob Carlborg
Feb 22 2015
prev sibling next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Brian Schott"  wrote in message 
news:updwbngwrilngxhunzon forum.dlang.org...


 dfmt is a D source code formatting tool.

 https://github.com/Hackerpilot/dfmt/
 https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0


Is this on code.dlang.org?  I can't find it.
Feb 22 2015
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/19/2015 6:21 PM, Brian Schott wrote:

 dfmt is a D source code formatting tool.

 https://github.com/Hackerpilot/dfmt/
 https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0


Thanks for doing this. It's an important part of the D toolchain we need to 
have. At some point I want to merge it into the official release.

I noticed it is remarkably small (1400 lines). What is its algorithm? How does 
it compare with gofmt and clang-format in how it works?
Mar 03 2015
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Tuesday, 3 March 2015 at 20:36:20 UTC, Walter Bright wrote:

 Thanks for doing this. It's an important part of the D 
 toolchain we need to have. At some point I want to merge it 
 into the official release.

 I noticed it is remarkably small (1400 lines). What is its 
 algorithm? How does it compare with gofmt and clang-format in 
 how it works?


I haven't read the source to either of those programs, so I'm not 
sure how it compares.

dfmt works by re-using my existing lexer and parser. The parser 
is run on the code first so that the formatting step knows a few 
things like the difference between the binary and unary forms of 
"*". Line splitting is figured out using a badly mangled version 
of A*.
Mar 03 2015
next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Tue, 2015-03-03 at 23:03 +0000, Brian Schott via Digitalmars-d-announce =
wrote:

=20


[=E2=80=A6]

 dfmt works by re-using my existing lexer and parser. The parser  is=20
 run on the code first so that the formatting step knows a few =20
 things like the difference between the binary and unary forms of =20
 "*". Line splitting is figured out using a badly mangled version  of=20
 A*.


Does this mean dfmt uses the same parser as the D D compiler?

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 03 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 4 March 2015 at 07:43:44 UTC, Russel Winder wrote:

 On Tue, 2015-03-03 at 23:03 +0000, Brian Schott via 
 Digitalmars-d-announce wrote:

 


 […]

 dfmt works by re-using my existing lexer and parser. The 
 parser  is run on the code first so that the formatting step 
 knows a few  things like the difference between the binary and 
 unary forms of  "*". Line splitting is figured out using a 
 badly mangled version  of A*.


 Does this mean dfmt uses the same parser as the D D compiler?


No. https://github.com/Hackerpilot/libdparse
Mar 04 2015
parent reply Russel Winder via Digitalmars-d-announce writes:
On Wed, 2015-03-04 at 14:21 +0000, Dicebot via Digitalmars-d-announce
wrote:
[=E2=80=A6]

=20
 No. https://github.com/Hackerpilot/libdparse


Well this a bit not efficient, one D parser written in D for the
compiler and a separate D parser written in D for the code formatter.
What can go wrong.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 04 2015
parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 4 March 2015 at 14:53:22 UTC, Russel Winder wrote:

 On Wed, 2015-03-04 at 14:21 +0000, Dicebot via 
 Digitalmars-d-announce
 wrote:
 […]

 
 No. https://github.com/Hackerpilot/libdparse


 Well this a bit not efficient, one D parser written in D for the
 compiler and a separate D parser written in D for the code 
 formatter.
 What can go wrong.


All Brian tools use the same libdparse. Those include DCD, 
DScanner, dfix, dfmt and probably some others I am not aware of. 
It was also proposed for inclusion into Phobos a while ago but 
review pressure was too high.

I hope it will eventually replace the legacy lexer/parser 
converted from DMD C sources - it is much more pleasant to work 
with.

(there is no such thing as "one D parser written in D for the 
compiler")
Mar 04 2015
parent reply Russel Winder via Digitalmars-d-announce writes:
On Wed, 2015-03-04 at 15:04 +0000, Dicebot via Digitalmars-d-announce
wrote:
[=E2=80=A6]

 All Brian tools use the same libdparse. Those include DCD,=20
 DScanner, dfix, dfmt and probably some others I am not aware of.=20
 It was also proposed for inclusion into Phobos a while ago but=20
 review pressure was too high.


I try to use DCD when working with Emacs for D code, but I keep
forgetting to start the server :-( I would certainly be happy to commit
to using dfmt just as I use gofmt in Emacs. As long as the variation
from my preferred style is not to much I can live with a "One True
Style" (*).


 I hope it will eventually replace the legacy lexer/parser=20
 converted from DMD C sources - it is much more pleasant to work=20
 with.
=20
 (there is no such thing as "one D parser written in D for the=20
 compiler")


There ought to be for the compiler/formatter toolchain otherwise there
will be problems. And if there is a D parser as library and it works why
would anyone want another parser?



(*) The exception is of course Phobos style which I find so annoying I
can't read code formatted that way.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 04 2015
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Wednesday, 4 March 2015 at 15:26:51 UTC, Russel Winder wrote:

 I try to use DCD when working with Emacs for D code, but I keep
 forgetting to start the server :-( I would certainly be happy 
 to commit
 to using dfmt just as I use gofmt in Emacs. As long as the 
 variation
 from my preferred style is not to much I can live with a "One 
 True
 Style" (*).


That means that the Emacs plugin needs to start it automatically.


 There ought to be for the compiler/formatter toolchain 
 otherwise there
 will be problems. And if there is a D parser as library and it 
 works why
 would anyone want another parser?


Implementing a separate parser based on the language spec has 
helped to find problems with the language spec. Having "One True 
Implementation" can lead to problems as well.

https://issues.dlang.org/show_bug.cgi?id=10233


 (*) The exception is of course Phobos style which I find so 
 annoying I
 can't read code formatted that way.


By default dfmt tries to output Phobos style code. There is an 
option to use a different brace style and another one to use tabs.
Mar 04 2015
parent reply Russel Winder via Digitalmars-d-announce writes:
On Wed, 2015-03-04 at 21:22 +0000, Brian Schott via Digitalmars-d-announce =
wrote:

 [=E2=80=A6]
=20
 That means that the Emacs plugin needs to start it automatically.


Is this something on your todo list, or do you need a pull request?


 Implementing a separate parser based on the language spec has =20
 helped to find problems with the language spec. Having "One True =20
 Implementation" can lead to problems as well.
=20
 https://issues.dlang.org/show_bug.cgi?id=3D10233


I just wonder if it is wise to have a single two chain with two=20
distinct parsers which have separate lifecycles?


 (*) The exception is of course Phobos style which I find so=20
 annoying I
 can't read code formatted that way.


=20
 By default dfmt tries to output Phobos style code. There is an =20
 option to use a different brace style and another one to use tabs.


Since using Go and working on a couple of fairly old C++ codebases,=20
all of which use tab for indent, I have come to rather like it.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 05 2015
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Thursday, 5 March 2015 at 09:02:25 UTC, Russel Winder wrote:

 Since using Go and working on a couple of fairly old C++ 
 codebases,
 all of which use tab for indent, I have come to rather like it.


You probably feel that way because tabs are better. dfmt only 
defaults to spaces because that's what's in the Phobos style 
guide.
Mar 05 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/5/2015 7:15 PM, Brian Schott wrote:

 You probably feel that way because tabs are better. dfmt only defaults to
spaces
 because that's what's in the Phobos style guide.


Spaces are used in Phobos because no two tools agree on what the tab size
should be.
Mar 06 2015
next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Fri, 2015-03-06 at 01:37 -0800, Walter Bright via Digitalmars-d-announce
wrote:

 On 3/5/2015 7:15 PM, Brian Schott wrote:

 You probably feel that way because tabs are better. dfmt only 
 defaults to spaces
 because that's what's in the Phobos style guide.


 
 Spaces are used in Phobos because no two tools agree on what the tab 
 size should be.


That is the whole point of using tabs for indent, you can chose the 
indent amount: I tend to use 20ex.

Remember a tab is not a number of spaces, it is semantic markup. Using 
spaces is a low-level hack founded on a lack of separation of concerns 
and abstraction.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 06 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/6/2015 2:31 AM, Russel Winder via Digitalmars-d-announce wrote:

 Remember a tab is not a number of spaces, it is semantic markup.


All I can say is good luck with that. ASCII is not a markup language, and
trying 
to reinvent it as one is doomed to failure.

I can also say from experience that removing tabs from Phobos source has
removed 
a lot of irritation with messed up code rendering and wasted effort arguing 
about it. We're not going back :-)
Mar 06 2015
parent reply Russel Winder via Digitalmars-d-announce writes:
On Fri, 2015-03-06 at 18:21 -0800, Walter Bright via
Digitalmars-d-announce wrote:

 On 3/6/2015 2:31 AM, Russel Winder via Digitalmars-d-announce wrote:

 Remember a tab is not a number of spaces, it is semantic markup.


=20
 All I can say is good luck with that. ASCII is not a markup language, and=


 trying=20

 to reinvent it as one is doomed to failure.


I try to use Unicode (UTF-8 encoded) languages, restricting to ASCII is
very 1970s.

The use of tab as the indent character is far from failing. Many C++
projects are returning to it, Go enforces it if you let it, many Python
projects are starting to use it in spite of PEP-8. OK so Go enforced
format does alignment as well on the assumption of monospace font. I
dislike that so just carry on with proportional fonts.

ASCII per se is not a markup language, and it retains all the quirks of
teletypes, but that should not stop progress. Unicode replacing ASCII is
one step forward. Rethinking old established rules is always worthwhile:
just because a thing has always been done some way does not make it the
right way, nor should it hinder change.

=20
 I can also say from experience that removing tabs from Phobos source has =


removed=20

 a lot of irritation with messed up code rendering and wasted effort argui=


ng=20

 about it. We're not going back :-)


And I am not going to work on Phobos for exactly the same reasons. My
loss, not yours.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 06 2015
parent reply FG <home fgda.pl> writes:
On 2015-03-07 at 07:51, Russel Winder via Digitalmars-d-announce wrote:

 Many C++ > projects are returning to it, Go enforces it if you let it,
 many Python projects are starting to use it in spite of PEP-8.


Now, that you mentioned Python, it was one of the main reasons why I moved away
from tabs. I was used to tab-completion in the shell and Python's interactive
interpreter (and didn't want to rebind that feature to some key combination on
every system that I worked with). Whenever I copied chunks of tab-indented
source code into the interpreter, it got screwed up, because the indentations
had vanished, so eventually I switched to using spaces only and had no problems
ever since.


 I can also say from experience that removing tabs from Phobos source has
removed
 a lot of irritation with messed up code rendering and wasted effort arguing
 about it. We're not going back :-)


 And I am not going to work on Phobos for exactly the same reasons. My
 loss, not yours.


You must be joking. :)

If at all, the problem with Phobos' style isn't with horizontal spacing but
vertical space.
Consider the waste of space below. Too much scrolling and I lose focus. Now,
*that* is really irritating. ;)


     struct Boo
     {
         int a;
     }

     struct Foo
     {
         int a;
         auto opAssign(Foo foo)
         {
             assert(0);
         }
         auto opEquals(Foo foo)
         {
             return a == foo.a;
         }
     }

     X calculate(Range)(Range r)
     {
         static if (something)
         {
             import whatever;

             auto result = xxx();

             size_t i;
             foreach (e; r)
             {
                 doSomething(result[i], e);
                 ++i;
             }
             return result;
         }
         else
         {
             auto a = blah();
             foreach (e; r)
             {
                 a.put(e);
             }
             return a.data;
         }
     }
Mar 07 2015
parent Russel Winder via Digitalmars-d-announce writes:
On Sat, 2015-03-07 at 12:28 +0100, FG via Digitalmars-d-announce wrote:
[=E2=80=A6]

=20
 If at all, the problem with Phobos' style isn't with horizontal spacing b=


ut vertical space.

 Consider the waste of space below. Too much scrolling and I lose focus. N=


ow, *that* is really irritating. ;)
[=E2=80=A6]

This is definitely one of the major reasons I cannot bear to read Phobos
formatted code. Others seems to like it, it's a world full of acceptable
differences of opinion.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 07 2015
prev sibling next sibling parent Ben Boeckel via Digitalmars-d-announce writes:
On Fri, Mar 06, 2015 at 10:31:29 +0000, Russel Winder via
Digitalmars-d-announce wrote:

 That is the whole point of using tabs for indent, you can chose the 
 indent amount: I tend to use 20ex.
 
 Remember a tab is not a number of spaces, it is semantic markup. Using 
 spaces is a low-level hack founded on a lack of separation of concerns 
 and abstraction.


The problem with tabs, IMO, are the following:

  - don't look right in patches (notice the different alignment of
    indented lines versus lines without any):

-int foo(int bar) {
-	return bar;
-}

    versus (assuming 8 space indents):

-int foo(int bar) {
-        return bar;
-}

  - I have yet to see an editor properly do tab-for-indent with proper
    space-for-alignment without manual management:

	int my_long_function_name(int bar,
	                          int baz)
^__tab_^^_______spaces___________^

By the way, this is *wrong* because tabs now have a defined size (8
here) which defeats the only (tangible[1]) advantage they have:

	int my_long_function_name(int bar,
				  int baz)
^__tab_________________________^

--Ben

[1]File size savings are negligible.
Mar 06 2015
prev sibling next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Fri, 2015-03-06 at 09:54 -0500, Ben Boeckel via
Digitalmars-d-announce wrote:

 On Fri, Mar 06, 2015 at 10:31:29 +0000, Russel Winder via Digitalmars-d-a=


nnounce wrote:

 That is the whole point of using tabs for indent, you can chose the=20
 indent amount: I tend to use 20ex.
=20
 Remember a tab is not a number of spaces, it is semantic markup. Using=




=20

 spaces is a low-level hack founded on a lack of separation of concerns=




=20

 and abstraction.


=20
 The problem with tabs, IMO, are the following:
=20
   - don't look right in patches (notice the different alignment of
     indented lines versus lines without any):
=20
 -int foo(int bar) {
 -	return bar;
 -}
=20
     versus (assuming 8 space indents):
=20
 -int foo(int bar) {
 -        return bar;
 -}


Is your point that in this case they have rendered identically?


   - I have yet to see an editor properly do tab-for-indent with proper
     space-for-alignment without manual management:
=20
 	int my_long_function_name(int bar,
 	                          int baz)
 ^__tab_^^_______spaces___________^


But, for me anyway, the fundamental flaw here is the idea of alignment.
Find a style that eliminates all this alignment malarkey.

I really dislike the Go obsession with block style alignment of
declarations.

The core problem here is teletype, monospace font thinking. Using a
proper proportional font for you code and you rapidly lose the need for
all this alignment stuff.

<Real point but expressed as a bit of a troll, mostly to expose that
this is likely a bikeshed issue.>



 By the way, this is *wrong* because tabs now have a defined size (8
 here) which defeats the only (tangible[1]) advantage they have:
=20
 	int my_long_function_name(int bar,
 				  int baz)
 ^__tab_________________________^


In a real editor there is no hard line break, no need for this form of
indentation. Should a line be too long for the rendering area either
viewport or syntax directed soft line wrap are used. Having overflow is
mixing content with rendering.


 --Ben
=20
 [1]File size savings are negligible.


Indeed, no argument with that point.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 06 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/6/2015 11:55 AM, Russel Winder via Digitalmars-d-announce wrote:

 The core problem here is teletype, monospace font thinking. Using a
 proper proportional font for you code and you rapidly lose the need for
 all this alignment stuff.

 <Real point but expressed as a bit of a troll, mostly to expose that
 this is likely a bikeshed issue.>


Unlike english prose, code follows patterns. With a monospace font, one can
line 
up those patterns which makes for easier visual checking for errors.
Mar 06 2015
parent reply Russel Winder via Digitalmars-d-announce writes:
On Fri, 2015-03-06 at 18:31 -0800, Walter Bright via
Digitalmars-d-announce wrote:
[=E2=80=A6]

=20
 Unlike english prose, code follows patterns. With a monospace font, one c=


an line=20

 up those patterns which makes for easier visual checking for errors.


That works for you fine, but it doesn't work for me. I find monospace
fonts and alignment of code gets in the way of reading and comprehending
code.

The difficulty here is turning a personal preference into a social
orthodoxy.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 06 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/6/2015 10:43 PM, Russel Winder via Digitalmars-d-announce wrote:

 The difficulty here is turning a personal preference into a social
 orthodoxy.


A consistent style is necessary for Phobos. For your own projects, D doesn't 
dictate any particular style.
Mar 07 2015
prev sibling next sibling parent reply Ben Boeckel via Digitalmars-d-announce writes:
On Fri, Mar 06, 2015 at 19:55:10 +0000, Russel Winder via
Digitalmars-d-announce wrote:

 On Fri, 2015-03-06 at 09:54 -0500, Ben Boeckel via
 Digitalmars-d-announce wrote:

 -int foo(int bar) {
 -	return bar;
 -}
 
     versus (assuming 8 space indents):
 
 -int foo(int bar) {
 -        return bar;
 -}


 
 Is your point that in this case they have rendered identically?


Well it is now more apparent with more quoting. It now appears that the
first block is using 3-space indents while the bottom looks just fine
even with the quote markers.


   - I have yet to see an editor properly do tab-for-indent with proper
     space-for-alignment without manual management:
 
 	int my_long_function_name(int bar,
 	                          int baz)
 ^__tab_^^_______spaces___________^


 
 But, for me anyway, the fundamental flaw here is the idea of alignment.
 Find a style that eliminates all this alignment malarkey.


Well, when that means you're going to have absurdly long lines to deal
with in anything other than your definition "real" editors (and I've
never seen one which fits your definition).


 I really dislike the Go obsession with block style alignment of
 declarations.


I won't say I'm a fan of it indiscriminently, but if it's that or
200+-character lines, I'll chop argument lists up a bit to fit something
more reasonable.


 The core problem here is teletype, monospace font thinking. Using a
 proper proportional font for you code and you rapidly lose the need for
 all this alignment stuff.
 
 <Real point but expressed as a bit of a troll, mostly to expose that
 this is likely a bikeshed issue.>


And I find that monospace fonts tend to make it much easier to tell the
difference between 'l', '1', and 'I'. Not so important in English, but
it can be all the difference in code.


 In a real editor there is no hard line break, no need for this form of
 indentation. Should a line be too long for the rendering area either
 viewport or syntax directed soft line wrap are used. Having overflow is
 mixing content with rendering.


You're making assumptions about the features of your users' editors.
These features are not trivial to implement and this basically requires
things like pygments and other tools used to render code to the web with
all kinds of logic to handle dynamic viewports of the shown code. IMO,
it is even worse than putting #vim:, #kate:, or emacs formatting
directives in your code since it is implicit.

Personally, I use Vim because it works similarly for all uses. I don't
know what I'd do if I had to work with a different editor for each
language I work with.

--Ben
Mar 06 2015
next sibling parent reply "Kagamin" <spam here.lot> writes:
On Friday, 6 March 2015 at 20:22:42 UTC, Ben Boeckel wrote:

 And I find that monospace fonts tend to make it much easier to 
 tell the
 difference between 'l', '1', and 'I'. Not so important in 
 English, but
 it can be all the difference in code.


http://abload.de/img/tmpr3uv6.png I see no less difference than 
in monospace font.
Mar 07 2015
next sibling parent "Kagamin" <spam here.lot> writes:
In fact, I failed to find good monospace font for source code, it 
used to be Courier New 9pt, but it works well only on displays no 
bigger than 1024*768.
Mar 07 2015
prev sibling parent Russel Winder via Digitalmars-d-announce writes:
On Sat, 2015-03-07 at 12:57 +0000, Kagamin via Digitalmars-d-announce
wrote:

 On Friday, 6 March 2015 at 20:22:42 UTC, Ben Boeckel wrote:

 And I find that monospace fonts tend to make it much easier to=20
 tell the
 difference between 'l', '1', and 'I'. Not so important in=20
 English, but
 it can be all the difference in code.


=20
 http://abload.de/img/tmpr3uv6.png I see no less difference than=20
 in monospace font.


That will be because it is a reasonably designed font.

I have to admit though, the glyph widths are a bit large in the example
font. I guess I prefer something a bit more condensed.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 07 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 6 March 2015 at 20:22:42 UTC, Ben Boeckel wrote:

 You're making assumptions about the features of your users' 
 editors. These features are not trivial to implement


Implementation of three different word wrapping algorithms in 
Scintilla took 52 lines of code. For comparison: a rudimentary D 
lexer is only modest 400 lines.


 requires things like pygments and other tools used to render 
 code to the web with all kinds of logic to handle dynamic 
 viewports of the shown code.


You think too web 2.0, browsers wrap text since the beginning, 
tools only need to stop fight with them.
Mar 07 2015
prev sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Fri, 2015-03-06 at 15:22 -0500, Ben Boeckel via
Digitalmars-d-announce wrote:
[=E2=80=A6]

=20
 Well it is now more apparent with more quoting. It now appears that the
 first block is using 3-space indents while the bottom looks just fine
 even with the quote markers.


But there is no semantic difference in the code and it is all being
replaced anyway. I think the fact that a codebase should have a
formatter run over any change before being committed, to enforce the
rules of the codebase, will get round the issue anyway. Pythons pep-8,
gofmt, dfmt,=E2=80=A6 the use of such a tool, enforcing the standard of the
codebase is a good thing.

[=E2=80=A6]

 Well, when that means you're going to have absurdly long lines to deal
 with in anything other than your definition "real" editors (and I've
 never seen one which fits your definition).


Such editors were being researched and created in the 1980s but
computers were a bit too slow for the necessary infrastructure and, more
importantly, a vocal section of the development community screamed,
these things are wasteful of resources, and we must have ASCII encoded
files as the storage of our code. This attitude has, in my view, been
the biggest stumbling block to progress in software development for the
last 30 years.

Now with suitably fast processors and graphics, we are seeing all the
technology of the 1980s reentering the arena, but instead of doing it
right, IDEs are having to spend huge resources continually
reconstructing AST data from the flat file input. Some of them do it
better than others, but if only it had been accepted that AST is the
correct unit of editing in the 1980s we would be a lot further forward
today.


 I really dislike the Go obsession with block style alignment of
 declarations.


=20
 I won't say I'm a fan of it indiscriminently, but if it's that or
 200+-character lines, I'll chop argument lists up a bit to fit something
 more reasonable.


There is more than one way of chopping things up, and even aligning
them. Stepping away from monospace fonts, and the obsession with 2D
rendering of 1D data, gives a different view on chopping up which ends
up no better, but no worse.

[=E2=80=A6]

=20
 And I find that monospace fonts tend to make it much easier to tell the
 difference between 'l', '1', and 'I'. Not so important in English, but
 it can be all the difference in code.


Important point. Fonts are context dependent. A font for easy reading of
plain English novels, may not be appropriate for other uses exactly
because the different uses and contexts of the characters mean the
glyphs must have different relationships. But this is a font design
thing and monospace versus proportional is not the major determinant.


 In a real editor there is no hard line break, no need for this form of
 indentation. Should a line be too long for the rendering area either
 viewport or syntax directed soft line wrap are used. Having overflow is
 mixing content with rendering.


=20
 You're making assumptions about the features of your users' editors.
 These features are not trivial to implement and this basically requires
 things like pygments and other tools used to render code to the web with
 all kinds of logic to handle dynamic viewports of the shown code. IMO,
 it is even worse than putting #vim:, #kate:, or emacs formatting
 directives in your code since it is implicit.
=20
 Personally, I use Vim because it works similarly for all uses. I don't
 know what I'd do if I had to work with a different editor for each
 language I work with.


I do not disagree. The problem is that Emacs, VIM, IntelliJ IDEA,
Eclipse, Netbeans, are editors based fundamentally on a 1970s view of
editing and resources and the world has changed. Fortunately, I am
hearing that some of the ideas of the SOE and AST editors of the 1980s
are being re-raised, now with the resources to deal with it. Should this
go forward, I can see VIM dying, Emacs dying or being rewritten, and
IntelliJ IDEA, Eclipse, Netbeans, etc. losing at least half their code
or more. The IDEs with all their "refactoring support" are almost
reproducing what comes for free with SOE and AST focused editors.=20

As actors, dataflow, CSP were rejected by programmers in the 1970s and
1980s because they had processes and threads and really enjoyed
shared-memory multi-threaded programming (*), SOE and AST based editors
of the 1980s are effectively being recreated by the IDEs of the 2010s.
They are hamstrung by the continued obsession with the text file as the
primary unit of editing. As soon as they and programmer users get over
this, the sooner we can get on with better UX for development. (**)


(*) OK so operating system developers are allowed to do this stuff
because they have to, but applications people should not be doing any
such thing.

(**) And yes the very foundation of version control will have to change
as well.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 06 2015
parent "Stefan Koch" <uplink.coder googlemail.com> writes:
On Saturday, 7 March 2015 at 07:20:01 UTC, Russel Winder wrote:


 They are hamstrung by the continued obsession with the text 
 file as the
 primary unit of editing. As soon as they and programmer users 
 get over
 this, the sooner we can get on with better UX for development.


I agree.
Mar 07 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-03-04 16:26, Russel Winder via Digitalmars-d-announce wrote:


 There ought to be for the compiler/formatter toolchain otherwise there
 will be problems. And if there is a D parser as library and it works why
 would anyone want another parser?


The DMD front end is not really designed to be used as a library for 
tooling.

-- 
/Jacob Carlborg
Mar 04 2015
next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Thu, 2015-03-05 at 08:17 +0100, Jacob Carlborg via Digitalmars-d-announc=
e wrote:

 On 2015-03-04 16:26, Russel Winder via Digitalmars-d-announce wrote:
=20

 There ought to be for the compiler/formatter toolchain otherwise=20
 there will be problems. And if there is a D parser as library and=20
 it works why would anyone want another parser?


=20
 The DMD front end is not really designed to be used as a library for=20
 tooling.


It would be good if the D implemented D parser were though. Parsing to=20
create an AST is needed for many things. If each tool in the tool=20
chain implements it's own=E2=80=A6 it just seems wrong.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 05 2015
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/5/2015 1:04 AM, Russel Winder via Digitalmars-d-announce wrote:

 It would be good if the D implemented D parser were though. Parsing to
 create an AST is needed for many things. If each tool in the tool
 chain implements it's own… it just seems wrong.


True, but on the other hand, a D lexer and parser are pretty simple.
Mar 06 2015
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Friday, 6 March 2015 at 09:39:13 UTC, Walter Bright wrote:

 True, but on the other hand, a D lexer and parser are pretty 
 simple.


Did you mean "simple compared to C++"? I remember having to 
report/fix a LOT of bugs in the language specification and 
explore the DMD front end source code to get to where I am now.
Mar 06 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/6/2015 1:54 AM, Brian Schott wrote:

 On Friday, 6 March 2015 at 09:39:13 UTC, Walter Bright wrote:

 True, but on the other hand, a D lexer and parser are pretty simple.


 Did you mean "simple compared to C++"?


It's simple in both absolute terms and relative to C++ terms. It's not as
simple 
as Java's.



 I remember having to report/fix a LOT of
 bugs in the language specification and explore the DMD front end source code to
 get to where I am now.


True, but there have been very few bugs in the lexer/parser itself. My laziness 
in being pedantically correct in writing the specification is an orthogonal
issue.
Mar 06 2015
prev sibling parent reply "Stefan Koch" <uplink.coder googlemail.com> writes:
On Friday, 6 March 2015 at 09:39:13 UTC, Walter Bright wrote:

 On 3/5/2015 1:04 AM, Russel Winder via Digitalmars-d-announce 
 wrote:

 It would be good if the D implemented D parser were though. 
 Parsing to
 create an AST is needed for many things. If each tool in the 
 tool
 chain implements it's own… it just seems wrong.


 True, but on the other hand, a D lexer and parser are pretty 
 simple.


I'd like to hear your definition of simple.
Mar 06 2015
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/6/2015 2:47 AM, Stefan Koch wrote:

 I'd like to hear your definition of simple.


It's easy to understand, and one could write one from scratch over a weekend.

I haven't done any statistics, but I'd bet that that parse.c & lexer.c are
among 
the most stable parts of dmd judging by change history.
Mar 06 2015
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jacob Carlborg"  wrote in message news:md8vu6$hc1$1 digitalmars.com...


 The DMD front end is not really designed to be used as a library for 
 tooling.


It isn't, but it's slowly getting better.  eg You can now build the lexer as 
a library without pulling everything else in.  It's quite possible that in a 
couple of years it will be in a state where it's reasonable to build tools 
on top of it.
Mar 05 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-03-05 13:10, Daniel Murphy wrote:


 It isn't, but it's slowly getting better.  eg You can now build the
 lexer as a library without pulling everything else in.


Yes, that is absolute fantastic as a first step.


 It's quite possible that in a couple of years it will be in a state where it's
 reasonable to build tools on top of it.


That would be awesome. You're doing a great job, keep it up.

-- 
/Jacob Carlborg
Mar 06 2015
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/3/2015 3:03 PM, Brian Schott wrote:

 dfmt works by re-using my existing lexer and parser. The parser is run on the
 code first so that the formatting step knows a few things like the difference
 between the binary and unary forms of "*". Line splitting is figured out using
a
 badly mangled version of A*.


How are comments handled?
Mar 06 2015
parent reply "Brian Schott" <briancschott gmail.com> writes:
On Friday, 6 March 2015 at 09:40:07 UTC, Walter Bright wrote:

 How are comments handled?


The source code makes a DC 15 wisdom save, if it fails then the 
comments get distributed randomly.

The serious answer is that there's a lot of special casing that 
I'm still trying to figure out.
Mar 06 2015
next sibling parent Russel Winder via Digitalmars-d-announce writes:
On Fri, 2015-03-06 at 09:48 +0000, Brian Schott via Digitalmars-d-announce
wrote:

 On Friday, 6 March 2015 at 09:40:07 UTC, Walter Bright wrote:

 How are comments handled?


 
 The source code makes a DC 15 wisdom save, if it fails then the  
 comments get distributed randomly.


But with a d4, d6, d8, d10, d12, d20, d100?


 The serious answer is that there's a lot of special casing that  I'm 
 still trying to figure out.


I prefer the previous answer :-)
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 06 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/6/2015 1:48 AM, Brian Schott wrote:

 The serious answer is that there's a lot of special casing that I'm still
trying
 to figure out.


Ah. I had thought that maybe there was an obvious algorithm I didn't think of!
Mar 06 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Tue, 03 Mar 2015 12:35:44 -0800, Walter Bright wrote:


 On 2/19/2015 6:21 PM, Brian Schott wrote:

 dfmt is a D source code formatting tool.

 https://github.com/Hackerpilot/dfmt/
 https://github.com/Hackerpilot/dfmt/releases/tag/v0.1.0


=20
 Thanks for doing this. It's an important part of the D toolchain we need
 to have. At some point I want to merge it into the official release.
=20
 I noticed it is remarkably small (1400 lines). What is its algorithm?
 How does it compare with gofmt and clang-format in how it works?


i bet dfmt parses the source and then regenerates it from scratch using=20
AST it built. with all the work Brian put into his D parsing libraries,=20
the main driver can be relatively small, i think.=
Mar 03 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 07 Mar 2015 13:03:06 +0000, Kagamin wrote:


 In fact, I failed to find good monospace font for source code, it used
 to be Courier New 9pt, but it works well only on displays no bigger than
 1024*768.


terminus rocks.=
Mar 07 2015