On Sat, Feb 03, 2018 at 06:25:26PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Saturday, 3 February 2018 at 17:20:35 UTC, H. S. Teoh wrote:
> > I got sick of just whining about, and decided to do something about it instead:
> 
> Whelp, g'luck. I've tried to null out the macro before, maybe this approach will work better.

This approach is more likely to be accepted. ;-)


> The stupid thing should just be killed entirely though. It was never of any legitimate value.

Shh! The plan is, after this PR gets merged, it becomes easier to turn off the behaviour by default as part of a PR to improve the default ddoc stylesheet. Once it's off by default, we can delete the code as "dead code". ;-P


T

-- 
The easy way is the wrong way, and the hard way is the stupid way. Pick one.

On 2/2/18 7:10 PM, Walter Bright wrote:
> On 2/1/2018 6:09 AM, Steven Schveighoffer wrote:
>> On 1/31/18 9:58 PM, Walter Bright wrote:
>>> On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
>>>> Where it breaks down is when you have many nested tags, and you end with )))))
>>>
>>> Long ago, I adjusted my text editor so that when the cursor is placed on ), the matching ( is found. Ditto for { }, [ ], < >, and #if/#elif/#else/#endif (!). It's been incredibly convenient.
>>
>> This has literally been in vim since I started using it, what, 15 years ago? It doesn't matter.
> 
> The #if too?

Yes. http://vim.wikia.com/wiki/Moving_to_matching_braces

>> When I'm reviewing a PR, I don't see the matching as easily.
> 
> True, but that applies to anything with a block structure.

Sure, I also have a difficult time with loads of parentheses in function calls too.

I don't have a hard time with braces. It tends to be worse with parentheses. Generally these are indented properly, and not }}}}} all on one line.

Note: if there are brace issues, the auto-tester fails it. Why did that example I posted not catch the extra closing paren? Can we have it do so?

-Steve

On Sun, Feb 04, 2018 at 02:34:31PM -0500, Steven Schveighoffer via Digitalmars-d wrote: [...]
> I don't have a hard time with braces. It tends to be worse with parentheses.  Generally these are indented properly, and not }}}}} all on one line.

Wait till you see Lisp code. :-P


> Note: if there are brace issues, the auto-tester fails it. Why did that example I posted not catch the extra closing paren? Can we have it do so?
[...]

Ddoc does complain about it, though it seems it's not treated as a compile error.  It's probably just a matter of making the autotester parse the compiler output to look for these error/warning messages, and forcing a test failure if found.


T

-- 
Without geometry, life would be pointless. -- VS

On Monday, 5 February 2018 at 06:27:02 UTC, H. S. Teoh wrote:
> On Sun, Feb 04, 2018 at 02:34:31PM -0500, Steven Schveighoffer via Digitalmars-d wrote: [...]
>> I don't have a hard time with braces. It tends to be worse with parentheses.  Generally these are indented properly, and not }}}}} all on one line.
>
> Wait till you see Lisp code. :-P
>
>
>> Note: if there are brace issues, the auto-tester fails it. Why did that example I posted not catch the extra closing paren? Can we have it do so?
> [...]
>
> Ddoc does complain about it, though it seems it's not treated as a compile error.  It's probably just a matter of making the autotester parse the compiler output to look for these error/warning messages, and forcing a test failure if found.

Yeah DMD emits those warnings and until recently -w with warnings didn't even result in DMD terminating with a non-zero exit code, though we finally fixed that a few weeks ago and 2.079 will finally behave as expected:

https://github.com/dlang/dmd/pull/7440

Also note that you can't check-in any code in the core repositories with failing Ddoc messages.
This was checked for Phobos for a long time, while again for DMD and druntime that was only added recently, e.g.:

https://github.com/dlang/dmd/pull/7432

On 2/4/2018 11:34 AM, Steven Schveighoffer wrote:
> On 2/2/18 7:10 PM, Walter Bright wrote:
>> On 2/1/2018 6:09 AM, Steven Schveighoffer wrote:
>>> On 1/31/18 9:58 PM, Walter Bright wrote:
>>>> On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
>>>>> Where it breaks down is when you have many nested tags, and you end with )))))
>>>>
>>>> Long ago, I adjusted my text editor so that when the cursor is placed on ), the matching ( is found. Ditto for { }, [ ], < >, and #if/#elif/#else/#endif (!). It's been incredibly convenient.
>>>
>>> This has literally been in vim since I started using it, what, 15 years ago? It doesn't matter.
>>
>> The #if too?
> 
> Yes. http://vim.wikia.com/wiki/Moving_to_matching_braces

So I see. I wonder when that was added to vim. I put it in MicroEmacs in the late 1980s, and vi definitely didn't have it then. I didn't put in Pascal begin/end, because I didn't care for Pascal :-)

On 2/5/18 2:53 AM, Walter Bright wrote:
> On 2/4/2018 11:34 AM, Steven Schveighoffer wrote:
>> On 2/2/18 7:10 PM, Walter Bright wrote:
>>> On 2/1/2018 6:09 AM, Steven Schveighoffer wrote:
>>>> On 1/31/18 9:58 PM, Walter Bright wrote:
>>>>> On 1/31/2018 5:37 PM, Steven Schveighoffer wrote:
>>>>>> Where it breaks down is when you have many nested tags, and you end with )))))
>>>>>
>>>>> Long ago, I adjusted my text editor so that when the cursor is placed on ), the matching ( is found. Ditto for { }, [ ], < >, and #if/#elif/#else/#endif (!). It's been incredibly convenient.
>>>>
>>>> This has literally been in vim since I started using it, what, 15 years ago? It doesn't matter.
>>>
>>> The #if too?
>>
>> Yes. http://vim.wikia.com/wiki/Moving_to_matching_braces
> 
> So I see. I wonder when that was added to vim. I put it in MicroEmacs in the late 1980s, and vi definitely didn't have it then. I didn't put in Pascal begin/end, because I didn't care for Pascal :-)

I should clarify -- the matching parentheses feature has been in vim forever (note -- vim didn't exist in the last 80s, straight vi I think doesn't have these features). I don't know how long the matching #if/#endif feature has been there, I haven't used it much.

A nice feature of this is that the "jump to match" command is like any other move command in vim -- you can hook it to copy/pasting, deleting, formatting, etc. It's very useful.

But this is a bit off topic :)

-Steve

On 2/5/18 1:27 AM, H. S. Teoh wrote:
> On Sun, Feb 04, 2018 at 02:34:31PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> [...]
>> I don't have a hard time with braces. It tends to be worse with
>> parentheses.  Generally these are indented properly, and not }}}}} all
>> on one line.
> 
> Wait till you see Lisp code. :-P

I still have nightmares from my scheme class in college... Literally the professor would be up at the whiteboard scribbling a scheme function, and at the end, he would draw a whole bunch of closing parentheses in a row, reciting the opening parentheses for each one "car, cdr, ..."

I also have seen people's code who DID put all their closing braces on one line. It was... awful.

-Steve

On Mon, Feb 05, 2018 at 09:50:38AM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> On 2/5/18 1:27 AM, H. S. Teoh wrote:
> > On Sun, Feb 04, 2018 at 02:34:31PM -0500, Steven Schveighoffer via Digitalmars-d wrote: [...]
> > > I don't have a hard time with braces. It tends to be worse with parentheses.  Generally these are indented properly, and not }}}}} all on one line.
> > 
> > Wait till you see Lisp code. :-P
> 
> I still have nightmares from my scheme class in college... Literally the professor would be up at the whiteboard scribbling a scheme function, and at the end, he would draw a whole bunch of closing parentheses in a row, reciting the opening parentheses for each one "car, cdr, ..."
> 
> I also have seen people's code who DID put all their closing braces on one line. It was... awful.
[...]

Apparently it's a prevailing style for Lisp and Lisp dialects like Scheme.  Random example (this is in Guile, a Scheme dialect, quoted from open source code):

	(define (match-predicate obj alist)
	  (if (null? alist)
	      "Unknown type"
	      (if (apply (caar alist) obj)
		  (cdar alist)
		  (match-predicate obj (cdr alist)))))

The only way I can keep my sanity while editing this sort of code is vim's jump-to-match feature.


T

-- 
"If you're arguing, you're losing." -- Mike Thomas

On Monday, 5 February 2018 at 15:27:56 UTC, H. S. Teoh wrote:
> On Mon, Feb 05, 2018 at 09:50:38AM -0500, Steven Schveighoffer via Digitalmars-d wrote:
>> On 2/5/18 1:27 AM, H. S. Teoh wrote:
>> > On Sun, Feb 04, 2018 at 02:34:31PM -0500, Steven Schveighoffer via Digitalmars-d wrote: [...]
>> > > I don't have a hard time with braces. It tends to be worse with parentheses.  Generally these are indented properly, and not }}}}} all on one line.
>> > 
>> > Wait till you see Lisp code. :-P
>> 
>> I still have nightmares from my scheme class in college... Literally the professor would be up at the whiteboard scribbling a scheme function, and at the end, he would draw a whole bunch of closing parentheses in a row, reciting the opening parentheses for each one "car, cdr, ..."
>> 
>> I also have seen people's code who DID put all their closing braces on one line. It was... awful.
> [...]
>
> Apparently it's a prevailing style for Lisp and Lisp dialects like Scheme.  Random example (this is in Guile, a Scheme dialect, quoted from open source code):
>
> 	(define (match-predicate obj alist)
> 	  (if (null? alist)
> 	      "Unknown type"
> 	      (if (apply (caar alist) obj)
> 		  (cdar alist)
> 		  (match-predicate obj (cdr alist)))))
>
> The only way I can keep my sanity while editing this sort of code is vim's jump-to-match feature.
>
>
> T

It's common in Scheme/Racket to use square brackets for nested terms:

(let ([x (random 4)]
      [o (random 4)])
  (cond
    [(> x o) "X wins"]
    [(> o x) "O wins"]
    [else "cat's game"]))

I find code written like your example (which is unfortunately quite common) to be no different from poorly-written Perl code. Properly indented and square bracketed Scheme code is easy to read.

One of the nice things about D IMO is that you have to work harder to write ugly code. Atrocities like chaining a bunch of function calls together don't look bad in D.

On Monday, 5 February 2018 at 14:50:38 UTC, Steven Schveighoffer wrote:
> On 2/5/18 1:27 AM, H. S. Teoh wrote:
>> On Sun, Feb 04, 2018 at 02:34:31PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
>> [...]
>>> I don't have a hard time with braces. It tends to be worse with
>>> parentheses.  Generally these are indented properly, and not }}}}} all
>>> on one line.
>> 
>> Wait till you see Lisp code. :-P
>
> I still have nightmares from my scheme class in college... Literally the professor would be up at the whiteboard scribbling a scheme function, and at the end, he would draw a whole bunch of closing parentheses in a row, reciting the opening parentheses for each one "car, cdr, ..."
>
> I also have seen people's code who DID put all their closing braces on one line. It was... awful.
>
When I programmed AutoLISP extension in AutoCAD I would use parentheses in the exact same way as I use { } in C. So not at the end of a line but vertically at the level of indentation;

    (defun xy
      (car
         (cdr
            (cons a b)
         )
      )
    )

This made it much better to handle.