Z008/5/8 Gilles G. <schaouette@free.fr>:
>  > 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.
>  >
>  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.

So if I mistype, and accidently fail to match parenthesis, the compiler can't detect it, and instead goes ploughing on, tying to compile through the next few statements. When it finally reaches a point where it can't parse any more, it will have no idea exactly where it got lost in the first place.

Janice Caron, el  8 de mayo a las 05:23 me escribiste:
> 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.

Yes, in my suggestion you need to escape false-newline-end-of-statement in some few cases, like in Python.

What you written (which doesn't make any sense, I don't know what's the point of putting shitty and unreal examples to prove a point) need a escape at the end of the line, but this (more realistic) version doesn't:

auto a = b(
    c)

Because when you don't expect a statement to finish until the closing ) is found (which is *exactly* the same behavior you get now, so please don't bring the "meaningful errors" argument again =).

I have a Python project with 6482 LOC and I have just 39 lines with line
continuation. I think adding an extra character (\) to 0.6% of the lines is
pretty acceptable if you get rid of the extra character (;) at the end of
the line in the other 99.4% =)

Really. You are telling me that is ugly to have a '\' in 0.6% lines of code but is pretty to have ';' in 100% of them??? It doesn't makes any sense to me...

> 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.

Is *that* hard to read the entire message? I said ';' is OPTIONAL (and that's the key for backward compatibility). So you can perfectly write:

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

"Yuk."

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Dentro de 30 años Argentina va a ser un gran supermercado con 15
changuitos, porque esa va a ser la cantidad de gente que va a poder
comprar algo.
	-- Sidharta Wiki

2008/5/8 Leandro Lucarella <llucax@gmail.com>:
> I don't know what's the
>  point of putting shitty and unreal examples to prove a point

You won't win any arguments by calling examples "shitty". All that will achieve is that people who don't want to be insulted will stop debating with you, and D won't change.

Janice Caron wrote:
> 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

 (3) "Intelligent Parser"

    a +
    b

Here the parser knows that something has to follow.

    f(1, 2, 3,
      4, 5, 6)

Here again the parser knows that something has to follow.

Etc.

It works perfectly well in Ruby, and I've never found a bug according to
a wrongly placed newline during the last ~10 years writing some multiple
10k LoC in Ruby, while I often get nerved by the C/C++ compiler due to
missing semicolons.

Actually, IMHO any C-style syntax has much more sever problems leading
to hard to find bugs:

    if (a)
      s1;
    s2;

  vs.

    if (a)
    {
      s1;
      s2;
    }

  vs. in Ruby (Eiffel/Ada/Modula-style syntax)

    if a
      s1
      s2
    end


Another example which leads to hard to read code and potential
bugs is (ignoring compiler warnings):

    class A
    {
      int i;

      //
      // add some 25 lines of code here
      //

      void foo(int i)
      {
        // what is "i" here?
      }
    }

This is solved in Ruby by using a separate namespace for instance
variables ("@i" for instance variable "i", and "i" for local variable
"i"). I regard this as one of the most important features found in Ruby
to prevent such issues and increase readability (and no, "@" has nothing
to do with the "@" used by Perl :).

I wouldn't suggest to remove semicolons from D, as the syntax it uses
makes it somewhat harder than the syntax used by Ruby (Python etc.).
But I'd suggest to introduce @variable as a synonym to this.variable.

Regards,

  Michael

Don wrote:
> 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).

Is that your own experience? Only practice tells the truth!

Would you say that Smalltalk is a scripting language? See where it is
used, and notice the size of the applications written in it.

I am sure every C program includes more errors than the worst
Ruby/Python program you can ever write. Not so sure about other
scripting language... :)

Regards,

  Michael

On Thu, 08 May 2008 15:51:27 +0100, Janice Caron wrote:

> 2008/5/8 Leandro Lucarella <llucax@gmail.com>:
>> I don't know what's the
>>  point of putting shitty and unreal examples to prove a point
> 
> You won't win any arguments by calling examples "shitty". All that will achieve is that people who don't want to be insulted will stop debating with you, and D won't change.

I should point out that your argument was a little flawed, the suggestion is to use new lines to mark the end of statement not replace ;

In my thoughts I will just say I don't want the compiler to define rules based on white-space.

"Michael Neumann" <mneumann@ntecs.de> wrote in message news:48231B20.1080009@ntecs.de...
> Actually, IMHO any C-style syntax has much more sever problems leading to hard to find bugs:
>
>     if (a)
>       s1;
>     s2;
>

I can't say I've ever found that to be a problem. But maybe that's just me.

Nick Sabalausky Wrote:

> > to hard to find bugs:
> >
> >     if (a)
> >       s1;
> >     s2;
> >
> 
> I can't say I've ever found that to be a problem. But maybe that's just me.

Programmer, who got used to one language finds it difficult to switch to another language, because different languages require different styles of thinking. Thus for C programmer it's difficult to understand block statement without braces :) and for basic programmer it's difficult to delimit block statement with braces.

Michael Neumann Wrote:

> Another example which leads to hard to read code and potential
> bugs is (ignoring compiler warnings):
> 
>      class A
>      {
>        int i;
> 
>        //
>        // add some 25 lines of code here
>        //
> 
>        void foo(int i)
>        {
>          // what is "i" here?
>        }
>      }
> 
> This is solved in Ruby by using a separate namespace for instance variables ("@i" for instance variable "i", and "i" for local variable "i").

In C family languages this is ruled out by naming convention.

> Programmer, who got used to one language finds it difficult to switch to another language, because different languages require different styles of thinking. Thus for C programmer it's difficult to understand block statement without braces :) and for basic programmer it's difficult to delimit block statement with braces.

Ah yes - that's probably true.

I wonder if it's possible to write a standalone tool that doesn't know or care about language grammar (except maybe some general rules about what constitutes a quote or a comment), that can freely convert between

    Lorem ipsum (dolor sit amet)
    {
        consectetur!(adipisicing)(elit, sed);
        do
        {
            eiusmod tempor incididunt;
            ut labore;
            et dolore;
        }
        magna(aliqua);
    }

and

    Lorem ipsum (dolor sit amet):
        consectetur!(adipisicing)(elit, sed)
        do:
            eiusmod tempor incididunt
            ut labore
            et dolore
        magna aliqua

If so, we can have not only D-in-Python-style (which I'd never use),
but also Python-in-D-style (which I actually might). It sounds like it
ought to be feasible.