why ; ?

[Nick Sabalausky]

"Janice Caron" <caron800 at googlemail.com> wrote in message 
news:mailman.569.1210359943.2351.digitalmars-d at puremagic.com...
> On 09/05/2008, Nick Sabalausky <a at a.a> wrote:
>>  Plus, that then opens up the ability to do something like this:
>>
>>  while (a)
>>   if (b)
>>     c;
>>     d;
>>   fi // Or _if, or something else
>>  wend // or _while, or something else
>
> But my text editor can do bracket matching. With one keystroke, I can
> jump from an opening brace to the matching closing brace, or vice
> versa, and /know/ that all is correctly matched (or easily fix the
> problem if not).
>

True, but under my proposal, you usually wouldn't need to do even that . You 
would just see them there (albiet, with less detail). Also, that only works 
for one block at a time.

Example scenario: Suppose I have a function that iterates over a collection, 
and does it over and over until some condition is met. Then, I want to add 
one last bit of processing to be done as the final action on each element of 
the collection. If the last few lines of my function look like this:

            _func // (ie, an anonymous closure)
          _if
        _foreach
      _if
    _while
  _if
_func

I know at a glance to put my code right before "_foreach". But if it looks 
like this:

            }
          }
        }
      }
    }
  }
}

Then I have to jump to find the right place. And depending on the function, 
I might have to try a few braces before I get the right one. Or, I could 
scroll to the start of the desired loop, and jump down from there. But 
still, why do that, when I could just know at a mere glance where to put the 
code?

You could argue that a scenario like that is the result of an overly-large 
function that should be broken into smaller parts, and you'd probably be 
right. But, at least in my experience, it's typical for a function to start 
small, then later on, grow large and *then* get broken up as necessary. Plus 
it might not even be your function anyway.

I'm not saying that this could effectively replace bracket matching in a 
text editor. But I do think "fi"/"wend" *plus* bracket matching would be 
better than "a bunch of }'s" plus bracket matching. I think they'd 
compliment each other nicely (And the "fi"/"wend" would also be better when 
someone's not using bracket-matching).

> My text editor, however, cannot do if-to-fi matching. Under your
> scheme, I'd be giving up a valuable piece of functionality.

I'd classify that as a limitation in the editor. Most editors let you 
manually define a list of language keywords. I can't imagine it would be 
significantly more difficult for an editor that already handles both 
user-defined keywords and non-configurable bracket matching (or collapsable 
regions), to expose the tokens it uses for bracket matching as configurable. 
Ie, "(",")" as well as "{", "}", and "[","]" would already be set by 
default, and you could either remove those and/or add pairs like "if","fi", 
or "spoogystart","spoogyend".