January 11, 2015
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?

January 11, 2015
On 1/11/15 1:15 PM, Walter Bright 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?

I don't know. Simplest would be to punt for now - such rare embedded comments should not be blockers. -- Andrei

January 11, 2015
On Sunday, 11 January 2015 at 21:16:41 UTC, Walter Bright 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?

Why not just move the comment to the end of the expression?
January 12, 2015
On 1/11/2015 1:31 PM, Andrei Alexandrescu wrote:
> On 1/11/15 1:15 PM, Walter Bright 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?
>
> 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.
January 12, 2015
On 1/11/15 4:37 PM, Walter Bright wrote:
> On 1/11/2015 1:31 PM, Andrei Alexandrescu wrote:
>> On 1/11/15 1:15 PM, Walter Bright 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?
>>
>> 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.

By punt i mean leave as is. -- Andrei
January 12, 2015
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.
January 12, 2015
On 1/11/2015 5:53 PM, 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.

That was quick!
January 12, 2015
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 :)
January 12, 2015
On Sunday, 11 January 2015 at 19:50:51 UTC, Andrei Alexandrescu wrote:
>> 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.
>

The usual way is to associate cost with various cesures and run something Dijkstra (or A*) like to find the best cesures.
January 12, 2015
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.