On Monday, 12 January 2015 at 15:30:42 UTC, qznc wrote:
>> So I started conceiving of a language in which even the *comments* were part of the AST. For, me this would be the aesthetic ideal. It just seemed like the next step in total AST integration.
>
> The clang-format approach is to make decisions based on the AST,
> but edit the byte array. AST nodes contain exact positions: line
> and column numbers. Sometimes more of them. For example, an
> if-statement needs to know the position of 'else' as well.
>
> Here is another example: void setX(int position /* inches */);
> However, I think it should really be wrapped into a struct
> instead to get type checker's approval.
>
> Initially, clang-format only did whitespace changes. I am not
> sure if they weakened this already. For example, stripping parens
> in expressions (((((x)))) => x) would be acceptable for me.
>
>
> btw +1 for https://github.com/Hackerpilot/dfmt

Last time I checked, it work on the lexer rather than the AST.

On Mon, 12 Jan 2015 19:17:47 +0000
deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Monday, 12 January 2015 at 08:11:27 UTC, ketmar via Digitalmars-d wrote:
> > it's easy: put it before `for`.
> >
> >   /*comment*/
> >   for (...)
> >
> > or just ignore it. and i must confess that i've never seen
> > comment like
> > this in my lifetime.
> 
> You can't ignore. That is why building such tool in not that easy.
by "ignore" i meant "live it where it was". if somebody is so smart that he writes such comments... oh, well, then he is smart enough to reformat the source manually. and if this is some other person's source... i'd say "don't use it, that person is sick".

On Monday, 12 January 2015 at 15:30:34 UTC, qznc wrote:
> The clang-format approach is to make decisions based on the AST, but edit the byte array.

dfix uses a similar approach. It uses the AST location information to make decisions while iterating through the token array. I think I will end up doing the same thing with dfmt.

On 10/01/2015 22:11, Walter Bright wrote:
> On 1/10/2015 12:17 PM, Walter Bright wrote:
>
> 2. it tends to end bikeshedding arguments about the right way to format
> things

No, it wouldn't. The tool would have to support formatting options, not just one style (or the tool would be crap). And even then, people could argue about what the default formatting should be...

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 10/01/2015 20:17, Walter Bright wrote:
> Has someone made a dfmt, like http://gofmt.com/ ?

With the DDT parser, it would be fairly easy to add such functionality, but it never has been high priority.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On Tue, 13 Jan 2015 12:37:22 +0000
Bruno Medeiros via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 10/01/2015 22:11, Walter Bright wrote:
> > On 1/10/2015 12:17 PM, Walter Bright wrote:
> >
> > 2. it tends to end bikeshedding arguments about the right way to format things
> 
> No, it wouldn't. The tool would have to support formatting options, not just one style (or the tool would be crap). And even then, people could argue about what the default formatting should be...
default should be one that used in Phobos.

On 11/01/2015 18:48, 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.
>

It's not that hard to do that once you have a parser that preserves the source range of all AST nodes. With that you can write a formatting algorithm than *modifies* the original source, assisted by AST info, instead of trying to recreate the whole source from the AST info alone. This way you can reformat without losing comment data, even if the AST doesn't have store comments.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On Saturday, 10 January 2015 at 20:18:03 UTC, Walter Bright wrote:
> Has someone made a dfmt, like http://gofmt.com/ ?

I with one my good student have started project coDewife 1,5 month ago. It based on some interesting theoretical approach (something like FSM, but with essential differences). It is being in very raw state by now, but has possibility to configure many good configuration. For example we can manipulate with underscore in decimal literal. I have benchmarked this decimal formatter a little, and it shows nod bad result: approximately 5 usec by one codeunit. We in active codding phase by now, but I can't predict terms of first useful release yet.


And by the way I have a question. When I read http://dlang.org/lex.html#integerliteral I understand that 0b, 0x or 0x_ isn't valid, but that compiles. Is that bug or spoiled documentations?

On Tuesday, 13 January 2015 at 12:43:05 UTC, ketmar via Digitalmars-d wrote:
> On Tue, 13 Jan 2015 12:37:22 +0000
> Bruno Medeiros via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> On 10/01/2015 22:11, Walter Bright wrote:
>> > On 1/10/2015 12:17 PM, Walter Bright wrote:
>> >
>> > 2. it tends to end bikeshedding arguments about the right way to format
>> > things
>> 
>> No, it wouldn't. The tool would have to support formatting options, not just one style (or the tool would be crap). And even then, people could argue about what the default formatting should be...
> default should be one that used in Phobos.

phobos is very APIish, most of business logic do not look like that.

On Fri, 16 Jan 2015 02:05:09 +0000
deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Tuesday, 13 January 2015 at 12:43:05 UTC, ketmar via Digitalmars-d wrote:
> > On Tue, 13 Jan 2015 12:37:22 +0000
> > Bruno Medeiros via Digitalmars-d <digitalmars-d@puremagic.com>
> > wrote:
> >
> >> On 10/01/2015 22:11, Walter Bright wrote:
> >> > On 1/10/2015 12:17 PM, Walter Bright wrote:
> >> >
> >> > 2. it tends to end bikeshedding arguments about the right
> >> > way to format
> >> > things
> >> 
> >> No, it wouldn't. The tool would have to support formatting options, not just one style (or the tool would be crap). And even then, people could argue about what the default formatting should be...
> > default should be one that used in Phobos.
> 
> phobos is very APIish, most of business logic do not look like that.
that's why formatter must have alot of options to tune. but *default* set must be one that used in Phobos. just to end any converstion like this with "'cause it's used in Phobos. period."