On Sun, 11 Jan 2015 13:15:22 -0800
Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 1/11/2015 11:50 AM, Andrei Alexandrescu wrote:
> > On 1/11/15 10:48 AM, Walter Bright wrote:
> >> 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.
> 
> Consider:
> 
>      for /*comment*/ (a;
>                       b;
>                       c)
> 
> Do what with that?
> 
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.

On Sun, 2015-01-11 at 11:19 -0800, Walter Bright via Digitalmars-d wrote:
> 
[…]
> It would be in the DMD front end, so LDC and GDC would it automatically.

s/it/get it/ ?

What wouldn't be automatic would be the command line options and other surrounding bits and pieces.
> 
[…]
> The rules are always going to be wrong. But in this case, that's ok.

For someone, not everyone. For some the rules will be right or at least acceptable.
> 
[…]
> Sometimes it's better to just conform.

It depends if the grievances are small enough to ignore and/or the benefits outweight. Sometimes conformance is a "bridge too far" and non-use, or use of an alternative is the right course of action.

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

I do not see a point in opening up the debate. An official style exists, it is that which is required for Phobos. This is the style that will be implemented by dfmt.

[…]

> 
> So you decided to conform rather than not use Go.

Yes. My grievances against the enforced style are not sufficient to abandon, and the need to deal with error codes at all times is not a sufficient pain to stop me using Go. What is the counterbalance? Go routines, the use of channels, and the eshewing of any form of shared mutable memory. Go has a lot of crap, a lot of positive and negative hype, and dataflow built into the language. I find it surprising easy to ignore the crap.

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

I suspect applying gofmt to Phobos code would have interesting results ;-)

PEP-8 allows for some minor variations. It can be applied as is for official PEP-8 compliant code or you can have variation. Of course the pep8 code is only an advisor, gofmt rewrites your code. Originally the gc compiler automatically rewrote your code,  but that was seen as too fascist, so gofmt was split off as a separate tool. Now though everyone uses gofmt anyway adhering to the "one true style". Having gofmt separate is though still the right thing as there is gc and gccgo which share no code.

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

On 2015-01-12 09:11, 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.

I agree. clang-format manage to keep it in the same place.

-- 
/Jacob Carlborg

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.

Both Clang and Eclipse JDT provide API's for accessing comments.

-- 
/Jacob Carlborg

On Monday, 12 January 2015 at 01:53:20 UTC, Brian Schott wrote:
> On Saturday, 10 January 2015 at 20:18:03 UTC, Walter Bright wrote:
>> Has someone made a dfmt, like http://gofmt.com/ ?
>
> https://github.com/Hackerpilot/dfmt
>
> The above is the work of one afternoon and not well tested.

Thanks Brian, looks promising.

On 2015-01-12 03:23:28 +0000, deadalnix said:

> On Saturday, 10 January 2015 at 20:18:03 UTC, Walter Bright wrote:
>> Has someone made a dfmt, like http://gofmt.com/ ?
> 
> That is amongst the plans for libd. I'd be happy to support anyone that want to work on it :)

This is part of the reason I wanted to de-couple libd's parsing from with libd-llvm can currently handle and have separate tests for that libd.

Is this something we might be able to consider doing?  We can easily have some code and do Code->ast->fmt Code->ast as tests for libd.

-Shammah

On Monday, 12 January 2015 at 05:43:33 UTC, Zach the Mystic wrote:
> On Monday, 12 January 2015 at 00:38:20 UTC, Walter Bright wrote:
>>>>> On 1/11/15 10:48 AM, Walter Bright wrote:
>>>>>> 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.
>>>>
>>>> Consider:
>>>>
>>>>    for /*comment*/ (a;
>>>>                     b;
>>>>                     c)
>>>>
>>>> Do what with that?
>>>
>>> I don't know. Simplest would be to punt for now - such rare embedded comments
>>> should not be blockers. -- Andrei
>>
>> Normally I would agree, but deleting peoples' comments from their source code is not a good plan. It'll make them justifiably angry.
>
> This conversation reminds me of something I've thought about ever since I first studied D. D takes the C preprocessor and folds it into the regular AST. But comments still seemed like the outlier. I looked through a bunch of source code and tried to figure out the most specific place anyone could possibly put a comment. The most detailed I found were something like:
>
> enum X {
>   ONE,
>   TWO, // We need a TWO here
>   THREE
> }
>
> 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

On Monday, 12 January 2015 at 05:43:33 UTC, Zach the Mystic wrote:
> On Monday, 12 January 2015 at 00:38:20 UTC, Walter Bright wrote:
>>>>> On 1/11/15 10:48 AM, Walter Bright wrote:
>>>>>> 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.
>>>>
>>>> Consider:
>>>>
>>>>    for /*comment*/ (a;
>>>>                     b;
>>>>                     c)
>>>>
>>>> Do what with that?
>>>
>>> I don't know. Simplest would be to punt for now - such rare embedded comments
>>> should not be blockers. -- Andrei
>>
>> Normally I would agree, but deleting peoples' comments from their source code is not a good plan. It'll make them justifiably angry.
>
> This conversation reminds me of something I've thought about ever since I first studied D. D takes the C preprocessor and folds it into the regular AST. But comments still seemed like the outlier. I looked through a bunch of source code and tried to figure out the most specific place anyone could possibly put a comment. The most detailed I found were something like:
>
> enum X {
>   ONE,
>   TWO, // We need a TWO here
>   THREE
> }
>
> 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

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.

On Monday, 12 January 2015 at 15:20:24 UTC, Shammah Chancellor wrote:
> On 2015-01-12 03:23:28 +0000, deadalnix said:
>
>> On Saturday, 10 January 2015 at 20:18:03 UTC, Walter Bright wrote:
>>> Has someone made a dfmt, like http://gofmt.com/ ?
>> 
>> That is amongst the plans for libd. I'd be happy to support anyone that want to work on it :)
>
> This is part of the reason I wanted to de-couple libd's parsing from with libd-llvm can currently handle and have separate tests for that libd.
>
> Is this something we might be able to consider doing?  We can easily have some code and do Code->ast->fmt Code->ast as tests for libd.
>
> -Shammah

The lexer/parser can be used without the semantic analysis part. It should be alright for now.