"bearophile" <bearophileHUGS@lycos.com> wrote in message news:fvnk34$m27$1@digitalmars.com...
> 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 ;-)

Oh man, now you've got me started on one of my pet peeves...

Semantically-meaningful indentation: That is exactly the reason I truly, truly hate Python (Well, that and a complete lack of variable declarations. Hello, hidden bugs!).

Python's semantically-meaningful indentation was intended to fix the problem of poorly-indented code by enforcing proper indentation in the language and compiler. But the problem is, it *doesn't* actually enforce it. In fact, it *can't* enforce it because it doesn't have enough information to enforce it. All it really does (and all it's able to do) is run around *assuming* your code is properly indented while silently drawing semantic conclusions from those (obviously not always correct) assumptions.

In fact it's really the same root problem as "no variable declarations". In both cases, the compiler does nothing but assume that what you wrote is what you meant, thus silently introducing hidden bugs 1. Whenever you didn't *really* want the new variables "my_reponse" and "my_responce" in additon to "my_response" (VB/VBScript coders use "option explicit" *for a reason*), and 2. Whenever you didn't *really* want to break out of that loop/conditional.

Nick Sabalausky wrote:
> "bearophile" <bearophileHUGS@lycos.com> wrote in message news:fvnk34$m27$1@digitalmars.com...
>> 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 ;-)
> 
> Oh man, now you've got me started on one of my pet peeves...
> 
> Semantically-meaningful indentation: That is exactly the reason I truly, truly hate Python (Well, that and a complete lack of variable declarations. Hello, hidden bugs!).
> 
> Python's semantically-meaningful indentation was intended to fix the problem of poorly-indented code by enforcing proper indentation in the language and compiler. But the problem is, it *doesn't* actually enforce it. In fact, it *can't* enforce it because it doesn't have enough information to enforce it. All it really does (and all it's able to do) is run around *assuming* your code is properly indented while silently drawing semantic conclusions from those (obviously not always correct) assumptions.
> 
> In fact it's really the same root problem as "no variable declarations". In both cases, the compiler does nothing but assume that what you wrote is what you meant, thus silently introducing hidden bugs 1. Whenever you didn't *really* want the new variables "my_reponse" and "my_responce" in additon to "my_response" (VB/VBScript coders use "option explicit" *for a reason*), and 2. Whenever you didn't *really* want to break out of that loop/conditional. 

I like Python, but I agree the whitespace structure thing is at best a wash.  Not having to type braces does make the code look cleaner, but causes other problems.  If there were such a thing as curly-brace Python, I'd probably use that.

--bb

Tomasz Sowinski wrote:
> Can you give some examples of the difficulties?
> I'm not into parsing issues really, so maybe I'll learn a thing or two.

How should:

   f()
   *g()

parse?

Robert Fraser wrote:
> Where I used to work, an accidental semicolon on an if statement ended up causing a production bug.

I've seen people waste several hours trying to figure out why their loop bodies would execute exactly once.

Nick Sabalausky wrote:
> Python's semantically-meaningful indentation was intended to fix the problem of poorly-indented code by enforcing proper indentation in the language and compiler. But the problem is, it *doesn't* actually enforce it. In fact, it *can't* enforce it because it doesn't have enough information to enforce it. All it really does (and all it's able to do) is run around *assuming* your code is properly indented while silently drawing semantic conclusions from those (obviously not always correct) assumptions.
> 
> In fact it's really the same root problem as "no variable declarations". In both cases, the compiler does nothing but assume that what you wrote is what you meant, thus silently introducing hidden bugs 1. Whenever you didn't *really* want the new variables "my_reponse" and "my_responce" in additon to "my_response" (VB/VBScript coders use "option explicit" *for a reason*), and 2. Whenever you didn't *really* want to break out of that loop/conditional. 

That goes back to the point that a language needs redundancy in order to detect errors. Having semantically-meaningful indentation, removing redundant semicolons, and implicitly declaring variables all remove redundancy at the (high) cost of inability to detect common bugs.

Those things are fine for scripting language programs that are fairly short (like under a screenful). It gets increasingly bad as the size of the program increases.

; also works in Python as a line separator:

print "a" ; print "b"

and it gives quite good syntax error messages

Personally I'm more in favor of the Python style code as opposed to C style code, because while you might need a \ line break char for some code, it is very much the exception to the rule - saving quite an amount of hassle.

:-) Dan

Michael Neumann wrote:
> 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

On 07/05/2008, Daniel Giddings <daniel.giddings@gmail.com> wrote:
> while you might need a \ line break char for some code, it is very much the exception to the rule

Not if you are obliged (against your will) to write maximum-80-column code, it isn't. In that circumstance, wrapping lines is very, very common.

You are also forgetting that any statement block { ... } is effectively a single statement, and that, if (...) { ... } else { ... } is also a single statement. And within any statement, passing a delegate literal to a function - e.g foo(delegate int(int x){ ... }); is still a single expression. In fact the whole concept of what is or is not a "single statement" is really quite nebulous.

I suppose you could always make indentation significant too. But here's an idea - how about, let's not.

Please let's keep our semicolons.

Janice Caron Wrote:

> I suppose you could always make indentation significant too. But here's an idea - how about, let's not.

:-D

Tomasz Sowinski Wrote:

> I was just curious about those "other various arguments".
It's an important feature of C family languages which improves readability and user experience (look and feel).

Janice Caron, el  7 de mayo a las 05:22 me escribiste:
> On 07/05/2008, Daniel Giddings <daniel.giddings@gmail.com> wrote:
> > while you might need a \ line break char for some code, it is very much the exception to the rule
> 
> Not if you are obliged (against your will) to write maximum-80-column code, it isn't. In that circumstance, wrapping lines is very, very common.

Only if you make a lot of steps in the same line or use incredibly long variables or have a very deep nesting of blocks. Avoiding that usually improves code readability and maintainability.

> You are also forgetting that any statement block { ... } is effectively a single statement, and that, if (...) { ... } else { ... } is also a single statement. And within any statement, passing a delegate literal to a function - e.g foo(delegate int(int x){ ... }); is still a single expression. In fact the whole concept of what is or is not a "single statement" is really quite nebulous.

*This* is the real problem with making ';' and '{}' optional and why I stop suggesting this change myself =)

I think Python syntax is way much more elegant and readable than C-like syntax, but D has some constructions that are very dependant on '{}' and ';'.

Even so, making them *optional* it's maybe possible. You can mark blocks with indentation *or* '{}', let's say:

void main()
	auto x = some_func((int i) { return i + 5 }) // {} are mandatory for delegates
	while (x)
		x = 0
		{ auto x = 1; writefln("this is a new block") }

A statement is parsed until ';' *or* EOL, a block is defined either by
deeper indentation *or* '{}'. Some constructs have mandatory block
delimitation using '{}'. This syntax should not be hard to parse,
you can give meaningfull errors, and you get backward compatibility.

Everybody should be happy, except from Walter, who has to touch the parser =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Cada movimiento que no se hace, es un movimiento que se pierde. Y cada movimiento que se pierde, se transforma en una mochila. Y las mochilas nos alejan, de nuestros amigos y nuestras amigas. Y nuestros amigos se transforman, en enemigos y en enemigas. Cada movimiento que se hace, es una mochila que se deja.