Tomasz Sowinski:
> I like the version without ; but how can you tell where a block ends without braces? indents?

Where there is a de-dent.
There's a known language that's designed like this ;-)

Bye,
bearophile

On Mon, 05 May 2008 12:32:09 -0400, Tomasz Sowinski wrote:

> BCS Wrote:
> 
>> In "for(;;);" the trailing ; is a null statement.
> 
> I just did that and the compiler said: "use '{ }' for an empty statement, not a ';' "

Since putting ; at the end of statements is common writing a for (...;...;...); would be common, and so D makes this invalid, using a ; to make an empty loop, that is why it says to use {} if you want one. BCS's example is just the same as doing a while(true){} though would not compile because of the ; at the end.

Tomasz Sowinski wrote:
> BCS Wrote:
> 
>> In "for(;;);" the trailing ; is a null statement.
> 
> I just did that and the compiler said:
> "use '{ }' for an empty statement, not a ';' "

I'm very glad of that protection there. Where I used to work, an accidental semicolon on an if statement ended up causing a production bug.

Tomasz Sowinski wrote:
> BCS Wrote:
> 
> 
>>In "for(;;);" the trailing ; is a null statement.
> 
> 
> I just did that and the compiler said:
> "use '{ }' for an empty statement, not a ';' "
> 

it works in C.

Tomasz Sowinski escribió:
> Robert Fraser Wrote:
> 
>> So the end of a statement would be marked by a newline character a la Python?
> 
> yes
> 
>> I usually like to keep my lines under 80 characters long for readability, and occasionally have long statements (especially if there's a ternary operator in there somewhere), so my vote is "nay".
> 
> Maybe a breakline symbol like in Ruby or VB for long statements?
>  

Please no!

Tom;

Walter Bright Wrote:
> 
> BTW, double entry bookkeeping, invented in the middle ages, was a huge advance in accounting. It essentially made everything redundant, which helped find and correct arithmetic errors. It spawned the term "balancing the books" which is nothing more than tracking down and reconciling all the errors. Without the redundancy, there'd be no way to balance the books because there'd be no way to detect errors.

Keep in mind that alongside double entry  runs a system called single entry accounting  which can be used instead. Usually it is used for smaller enterprises and avoids the duplication of double entry. Single entry accounting is what you would use to balance your petty cash or your cheque book

Walter Bright Wrote:
> 
> BTW, double entry bookkeeping, invented in the middle ages, was a huge advance in accounting. It essentially made everything redundant, which helped find and correct arithmetic errors. It spawned the term "balancing the books" which is nothing more than tracking down and reconciling all the errors. Without the redundancy, there'd be no way to balance the books because there'd be no way to detect errors.

Keep in mind that alongside double entry  runs a system called single entry accounting  which can be used instead. Usually it is used for smaller enterprises and avoids the duplication of double entry. Single entry accounting is what you would use to balance your petty cash or your cheque book

Tomasz Sowinski wrote:
> Just another feature thought. Never gonna happen, but still...
> 
> What's the reason of having lines end with a semicolon? Anything else than a legacy issue with C/C++?
> 
> The only thing I can think of is having multiple statements in one line, but that only makes code unreadable. Wouldn't getting rid of ; improve readability?
> 
> 
> Tomek

This has been discussed before. Apparently Walter even tried it for a scripting language with not so good results.

-Joel

Tom wrote:
> Tomasz Sowinski escribió:
>> Robert Fraser Wrote:
>>
>>> So the end of a statement would be marked by a newline character a la
>>> Python?
>>
>> yes
>>
>>> I usually like to keep my lines under 80 characters long for
>>> readability, and occasionally have long statements (especially if
>>> there's a ternary operator in there somewhere), so my vote is "nay".
>>
>> Maybe a breakline symbol like in Ruby or VB for long statements?
>>
>
> Please no!

It is very successful in Ruby! But Ruby is a very different language.
Ruby allows you to separate statements with ";" in one line. And it
recognises statements that cross a line boundary like shown below:

  a +
  b
  ==> a + b

  a
  + b
  ==> a; +b (probably not what you want!)

One problem is clearly (as Walter said) that reporting syntax errors can
become hard, or very unprecise. The latter is the case in Ruby.

Regards,

  Michael

"Tomasz Sowinski" <tomeksowi@gmail.com> wrote in message news:fvmgn8$s5d$1@digitalmars.com...
> Robert Fraser Wrote:
>> I usually like to keep my lines under 80 characters long for readability, and occasionally have long statements (especially if there's a ternary operator in there somewhere), so my vote is "nay".
>
> Maybe a breakline symbol like in Ruby or VB for long statements?

I can fully appreciate the reasoning behind "optional semicolon" syntax. Ie, there's a one-to-one relationship between "line" and "statement" for most lines and statements, therefore if an extra symbol is going to be used it should be for the border case (multi-line statement) rather than the typical case (single-line statement). But, in my experience, I find that there's another practicality-related issue that ends up trumping that one:

I'm constantly readjusting statements back and forth between "all on one line" and "spanned over multiple lines" (for instance, "if" statements with lots of clauses, and functions calls/definitions with lots of arguments). Every time something changes, I rearrange to make it more readable, which often involves moving parts of a multi-line statement from one line to another, or changing a statement back and forth between single-line and multi-line. End-of-line symbols don't prevent me from doing that, but they do get in the way and make it a regular pain-in-the-ass. End of statement symbols, however, are very easy to get accustomed to, quickly become second nature, and never really get in the way.