On 1/10/15, weaselcat via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Saturday, 10 January 2015 at 20:18:03 UTC, Walter Bright wrote:
>> Has someone made a dfmt, like http://gofmt.com/ ?
>
> Uncrustify claims D support. http://uncrustify.sourceforge.net/

Yes, and the author is responsive whenever a new D-related bug is filed.

I've used Uncrustify successfully with D for many years. It would be nice to have an implementation in D (purely to be able to more easily hack on the tool and configure it to our own liking), but as far as having a tool that works right now - uncrustify is exactly that tool.

"Jacob Carlborg"  wrote in message news:m8thr2$pag$1@digitalmars.com...

> Ideally the dmd front end should be available as a library then dfmt should be a separate tool that uses the same front end library as dmd. But I know that we're not there yet.

Well, some of it is.  If somebody wants to work on adding the necessary lexer/parser/etc features on the C++ side I'm happy to help get ddmd ready to be used for this.

> It's always nice if a tool is built as a library with a with executable on top. This allows for other tools to be built using this library.

Agreed. 

I'm  powerful writing a parser-generator, that will be able to transform the generated parse-tree back into source automatically.
writing a rule-based formatter should be pretty doable.

On 1/11/2015 9:45 AM, Stefan Koch wrote:
> I'm  powerful writing a parser-generator, that will be able to transform the
> generated parse-tree back into source automatically.
> writing a rule-based formatter should be pretty doable.

Formatting the AST into text is straightforward, dmd already does that for .di file generation.

The main problem is what to do about comments, which don't fit into the grammar.

A secondary problem is what to do when the line length limit is exceeded, such as for long expressions.

On 1/11/2015 4:47 AM, Russel Winder via Digitalmars-d wrote:
>> Next question - standalone tool, or built in to dmd (like Ddoc)?
> Also why in DMD and not in LDC or GDC?

It would be in the DMD front end, so LDC and GDC would it automatically.


>> 1. people expect this sort of thing these days
>
> Thanks to Python PEP-8 and Go, yes. Personalized code formatting is
> increasingly a thing of the past, programming languages are now
> opinionated and fascist when it comes to formatting. Even if the rules
> are wrong.

The rules are always going to be wrong. But in this case, that's ok.


>> 2. it tends to end bikeshedding arguments about the right way to
>> format things
> Except when the tool implements the wrong style.

Sometimes it's better to just conform.


>> 3. it'll help standardize the format of D code in the D repositories
> Even if it is the wrong formatting standard?
>
> I have to admit that the Phobos format rules make the code look
> appallingly ugly to me, sufficiently so that I really do not want to
> work on that codebase. I guess I am biased towards K&R C (which I use
> to drive my C++ style), Java and Go.

Really? Like what? After many years of arguing about formatting myself, I decided that I had better things to waste my time on.


>> 4. it's simply nice and convenient!
> Working with Go in Emacs or LiteIDE is a bit of a joy as you get full
> reformatting on save. Fortunately I only have two main gripes with the
> Go formatting style, but no-one has a choice, use the Go style as
> dictated by the Go team at Google or do not use Go.

So you decided to conform rather than not use Go.

(Anyhow, I suggest that gofmt is only mandatory if you wish to contribute to offical Go code, not for your own projects.)

On 1/11/2015 5:11 AM, Dicebot wrote:
> I would love to see DDOC implemented that way too.

Ddoc makes use of semantic info, not just an AST. For semantic info, you pretty much need a real compiler.

On 2015-01-11 20:20, Walter Bright wrote:

> Ddoc makes use of semantic info, not just an AST. For semantic info, you
> pretty much need a real compiler.

I've been thinking of that the last couple of days. It should be pretty straightforward to copy-paste the driver part of DMD, i.e the part contains the main function and handling of the command line arguments. Then remove everything that's not needed for Ddoc.

-- 
/Jacob Carlborg

On Sun, 11 Jan 2015 12:47:41 +0000
Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> > I don't think it'll be hard to do as a builtin feature of dmd.
> 
> It should be a separate tool not a part of one of the three compilers.
i can't see anything wrong with built-in tool. even if it can't be configured to one's tastes, it's still good for occasional contributors, who can stop worrying about code formatting and just write that code.

and if it will be configurable (which is not that hard to do -- to some extent), it will be usable for many more people. besides, being part of the compiler this tool has a good chances of being always up-to-date.

as there is already .di emitter, i believe that is can be customised further to do full code formatting. the only thing left to solve is comments (not a small one, though). i.e. compiler already has most of the work done, why not reuse it?

On 2015-01-11 19:48, Walter Bright wrote:

> The main problem is what to do about comments, which don't fit into the
> grammar.
>
> A secondary problem is what to do when the line length limit is
> exceeded, such as for long expressions.

clang-format seems to do a pretty good job with both of these. Comments seem to be intact unless they're too long, then they're wrapped. It seems to wrap at a space or other non-identifier character. Same thing with expressions that are too long.

You should download it [1] a give it a try on some C++ code.

[1] http://llvm.org/releases/download.html

-- 
/Jacob Carlborg

On 1/11/15 10:48 AM, Walter Bright wrote:
> On 1/11/2015 9:45 AM, Stefan Koch wrote:
>> I'm  powerful writing a parser-generator, that will be able to
>> transform the
>> generated parse-tree back into source automatically.
>> writing a rule-based formatter should be pretty doable.
>
> Formatting the AST into text is straightforward, dmd already does that
> for .di file generation.
>
> The main problem is what to do about comments, which don't fit into the
> grammar.

In the first version comments might go through unchanged.

> A secondary problem is what to do when the line length limit is
> exceeded, such as for long expressions.

I think that's problem #1.


Andrei