Leandro Lucarella Wrote [...]

I also suggest to take a look at the well designed Scala language, I think it has optional ;

Bye,
bearophile

On 07/05/2008, Leandro Lucarella <llucax@gmail.com> wrote:
> Even so, making them *optional* it's maybe possible.
> <snip>
> Everybody should be happy, except from Walter, who has to touch the
> parser =)

Absolutely not. I deeply, deeply want semicolons to remain compulsory.

Lose that, and you lose redundancy.
Lose redundancy and you lose meaningful error messages.

Leandro Lucarella:

An example of Scala code:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=meteor&lang=scala&id=4

More examples can be found near that one...

Bye,
bearophile

"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.547.1210179260.2351.digitalmars-d@puremagic.com...
> On 07/05/2008, Leandro Lucarella <llucax@gmail.com> wrote:
>> Even so, making them *optional* it's maybe possible.
>> <snip>
>> Everybody should be happy, except from Walter, who has to touch the
>> parser =)
>
> Absolutely not. I deeply, deeply want semicolons to remain compulsory.
>
> Lose that, and you lose redundancy.
> Lose redundancy and you lose meaningful error messages.

It always seems funny that your opinions are exactly the same as Walter's. I mean, I think that's almost word-for-word what he said.

As I explained about my experience making semicolons optional in MiniD, I haven't run into any situations where skipping semicolons has been a problem.  The compiler still gives fine error messages.  They're unneccessary in virtually every case.  In the (one!) case where there's an ambiguity (though there might be a couple more in D), the compiler doesn't silently choose one, unintuitively; it gives a reasonable error.

I'd be interested to know your views on the issue if Walter was ambivalent on the issue or if he was for it.

Janice Caron, el  7 de mayo a las 17:54 me escribiste:
> On 07/05/2008, Leandro Lucarella <llucax@gmail.com> wrote:
> > Even so, making them *optional* it's maybe possible.
> > <snip>
> > Everybody should be happy, except from Walter, who has to touch the
> > parser =)
> 
> Absolutely not. I deeply, deeply want semicolons to remain compulsory.
> 
> Lose that, and you lose redundancy.
> Lose redundancy and you lose meaningful error messages.

No you don't, \n is your redundancy. So you still get meaningful messages.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
When I was a child
I caught a fleeting glimpse
Out of the corner of my eye.
I turned to look but it was gone
I cannot put my finger on it now
The child is grown,
The dream is gone.
I have become comfortably numb.

On 08/05/2008, Leandro Lucarella <llucax@gmail.com> wrote:
> No you don't, \n is your redundancy. So you still get meaningful messages.

That would be true IF AND ONLY IF we were forced to escape newlines that didn't mean end-of-statement. e.g.

    auto a = b \
    (c)

I wasn't aware that requiring me to escaping newlines was part of the suggestion. If it was, then I'm even more against it.

Besides which, how would that work with statements like

    if (a == b) { ++i; ++j } else { --i; --j }

If newlines were to take over the role of semicolons, then that would turn into

    if (a == b) { ++i
    ++j } else { --i
    --j }

Yuk.

"Janice Caron" <caron800@googlemail.com> wrote in message news:mailman.550.1210220618.2351.digitalmars-d@puremagic.com...
> Besides which, how would that work with statements like
>
>    if (a == b) { ++i; ++j } else { --i; --j }
>
> If newlines were to take over the role of semicolons, then that would turn into
>
>    if (a == b) { ++i
>    ++j } else { --i
>    --j }

Not that I'm advocating any "non-compulsory semicolon" syntax, but couldn't the first one work fine by saying "Newline and semicolon are BOTH interpreted as end-of-statement"? (aside from the issue of "with or without a continue-on-next-line symbol"). Or am I just taking the discusion in a circle?

2008/5/8 Nick Sabalausky <a@a.a>:
>  Not that I'm advocating any "non-compulsory semicolon" syntax, but couldn't
>  the first one work fine by saying "Newline and semicolon are BOTH
>  interpreted as end-of-statement"? (aside from the issue of "with or without
>  a continue-on-next-line symbol"). Or am I just taking the discusion in a
>  circle?

Yeah, we're going round and round. If I break a line because it's too long, I absolutely do not want the compiler assuming that means "end of statement". As numerous examples have shown, it is perfectly possible for the compiler to misinterpret the programmers intent, and produce code that does completely the wrong thing.

There are only two ways to avoid this problem:
(1) require semicolons at end of statement
(2) require line breaks which are not end-of-statement to be escaped

Since I don't like (2), I must support (1).

Walter Bright wrote:
> 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.

Implicitly declared variables are probably the greatest of all false economies in the programming world.

bugs(no variable declarations) > 100 * bugs(dangling pointers).

> Yeah, we're going round and round. If I break a line because it's too long, I absolutely do not want the compiler assuming that means "end of statement". As numerous examples have shown, it is perfectly possible for the compiler to misinterpret the programmers intent, and produce code that does completely the wrong thing.
> 
> There are only two ways to avoid this problem:
> (1) require semicolons at end of statement
> (2) require line breaks which are not end-of-statement to be escaped
> 
> Since I don't like (2), I must support (1).
In Python, nearly every time you need a long line, there are already parentheses in the expression, so you don't need to escape the new line.
Using Python
aVeryLongFunctionName(
    argument1,
    argument2,