Daniel Keep:

> But it doesn't, and I can't see how it could given how confusing it would make things.

I think that using "in" into foreach() leads to less bugs, because it's easy to not tell apart "," and a ";".
C# too uses in in such situation.
So far it was not accepted in D mostly because the compiler stages of D are meant to be very separated.


> Besides which, we shouldn't be making judgements based on possible, not planned for syntax changes at some unspecified point in the future. We have enough trouble with deciding on things as it is. :P<

I agree that the situation isn't easy, and designing a language is hard. But it's very useful to keep a long-range sight and avoid to step on our future toes, when possible and when it's a cheap thing to do.

Bye,
bearophile

On Thu, Feb 19, 2009 at 10:38 AM, bearophile <bearophileHUGS@lycos.com> wrote:
> Daniel Keep:
>
>> But it doesn't, and I can't see how it could given how confusing it would make things.
>
> I think that using "in" into foreach() leads to less bugs, because it's easy to not tell apart "," and a ";".

The semicolon does not introduce bugs.  If you don't have a semicolon, you get a simple parser error.  That is not a bug.  If you can't tell ; and , apart, get a better font.

> So far it was not accepted in D mostly because the compiler stages of D are meant to be very separated.

That has little to nothing to do with it.  'in' in a foreach loop header is unambiguous to parse.  I think it has much more to do with the fact that semicolon works fine, is already present in mounds of D code, and changing it to 'in' does not really benefit anyone except you, since you're so goddamned attached to Python's syntax.  Use Delight, ffs.

Also, "I think I don't like X" is not proper English.  Say "I don't think I like X" or just "I don't like X" instead.

Jarrett Billingsley:

This is an old discussion, and maybe it will not lead to much.


>If you don't have a semicolon, you get a simple parser error. That is not a bug.<

Wikipedia agrees with me:

http://en.wikipedia.org/wiki/Software_bug
>A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect or unexpected result).<

So a parser error is a bug too, despite the compiler will help you find it in a moment.

I have written and debugged many times "mistakes" like:

foreach (a, b, iterable)
foreach (a; b; iterable)
foreach (a; b, iterable)

And probably I am not the only one :-)


>If you can't tell ; and , apart, get a better font.<

I have already modified a good font to tell apart . and ; better when I program D:

http://www.fantascienza.net/leonardo/ar/inconsolatag/inconsolata-g_font.zip

But having a language that is more bug-prone isn't good.


>That has little to nothing to do with it.  'in' in a foreach loop header is unambiguous to parse.<

You may have missed the discussion last time, when I think Walter has explained what I have told you the problem about the compilation stages.


>and changing it to 'in' does not really benefit anyone except you, since you're so goddamned attached to Python's syntax.<

Thank you, I attach myself to things I think are good and well designed. And Python isn't the only language that uses "in" with a "for-each" :-)


>Use Delight, ffs.<

I don't know what "ffs" means, and I'm on Windows again now :-)


>Also, "I think I don't like X" is not proper English.  Say "I don't think I like X" or just "I don't like X" instead.<

Thank you very much, I'll try to remember that.

Bye,
bearophile

bearophile wrote:
> Jarrett Billingsley:
> 
> This is an old discussion, and maybe it will not lead to much.
> 
> 
>> If you don't have a semicolon, you get a simple parser error. That is not a bug.<
> 
> Wikipedia agrees with me:
> 
> http://en.wikipedia.org/wiki/Software_bug
>> A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect or unexpected result).<
> 
> So a parser error is a bug too, despite the compiler will help you find it in a moment.
> 
> I have written and debugged many times "mistakes" like:
> 
> foreach (a, b, iterable)
> foreach (a; b; iterable)
> foreach (a; b, iterable)
> 
> And probably I am not the only one :-)

Why would you do that?

Many times when writing C# loops I do foreach(x; ...) and then remember it's "in" in C#, because I'm used to writing ";" in Java. I prefer ";" because it's shorter and you write a lot of foreach loops in a program.

Maybe we should vote and see how many people make the mistake of confusing comma and semicolon in this case.

> 
> 
>> If you can't tell ; and , apart, get a better font.<
> 
> I have already modified a good font to tell apart . and ; better when I program D:
> 
> http://www.fantascienza.net/leonardo/ar/inconsolatag/inconsolata-g_font.zip
> 
> But having a language that is more bug-prone isn't good.
> 
> 
>> That has little to nothing to do with it.  'in' in a foreach loop header is unambiguous to parse.<
> 
> You may have missed the discussion last time, when I think Walter has explained what I have told you the problem about the compilation stages.
> 
> 
>> and changing it to 'in' does not really benefit anyone except you, since you're so goddamned attached to Python's syntax.<
> 
> Thank you, I attach myself to things I think are good and well designed.
> And Python isn't the only language that uses "in" with a "for-each" :-)
> 
> 
>> Use Delight, ffs.<
> 
> I don't know what "ffs" means, and I'm on Windows again now :-)
> 
> 
>> Also, "I think I don't like X" is not proper English.  Say "I don't think I like X" or just "I don't like X" instead.<

To Jarrett: why isn't it proper English? It makes sense to me.

On Thu, Feb 19, 2009 at 11:07 AM, bearophile <bearophileHUGS@lycos.com> wrote:

>>If you don't have a semicolon, you get a simple parser error. That is not a bug.<
>
> Wikipedia agrees with me:
>
> http://en.wikipedia.org/wiki/Software_bug
>>A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect or unexpected result).<
>
> So a parser error is a bug too, despite the compiler will help you find it in a moment.

The representation of a program is separate from its semantics, and the semantics are only knowable if the representation is correct. Bugs are semantic errors.  If your program cannot be compiled due to an incorrect representation, you can't tell whether the program's semantics are correct.  Therefore, an incorrect representation is not a bug.

> I have written and debugged many times "mistakes" like:
>
> foreach (a, b, iterable)
> foreach (a; b; iterable)
> foreach (a; b, iterable)
>
> And probably I am not the only one :-)
> ...
> But having a language that is more bug-prone isn't good.

And when I used C# from some internship work, I kept writing "foreach(string s; something)".  And the same with Java, which uses "for(String s : something)".  Does that mean C#'s and Java's syntaxes are wrong and they should be changed to the semicolon because I made mistakes?

The point I'm making here is it doesn't matter whether it uses 'in' or ';' or ':' or '(%)#*@' to separate the loop indices from the container expression, because there will always be people who feel that another syntax is better or more natural.  Instead of arguing over minute details like this, let's worry about the important things, like the semantics of foreach loops.

>>That has little to nothing to do with it.  'in' in a foreach loop header is unambiguous to parse.<
>
> You may have missed the discussion last time, when I think Walter has explained what I have told you the problem about the compilation stages.

I know very well what Walter is talking about when he mentions the independence of the stages of compilation.  I've written a compiler too, based on D's and with a similar staged compilation strategy.  The fact is that there is no grammar production in which 'in' can be ambiguous within the context of a foreach loop header.

foreach(something; x)

You can replace ';' with 'in' or 'out' or 'forble' or pretty much any other token, as long as it doesn't cause ambiguity with the 'something' part.  'something' is not an expression, so there is no way that the compiler could mistake 'in' for an expression there.  It doesn't require any semantic analysis to determine what 'in' means in that context.

>>and changing it to 'in' does not really benefit anyone except you, since you're so goddamned attached to Python's syntax.<
>
> Thank you, I attach myself to things I think are good and well designed. And Python isn't the only language that uses "in" with a "for-each" :-)

And D isn't the only language that _doesn't_ use 'in'.  And?  What's your point?

>>Use Delight, ffs.<
>
> I don't know what "ffs" means, and I'm on Windows again now :-)

"For f**k's sake."  It's an expression of exasperation.

On Thu, Feb 19, 2009 at 11:45 AM, Ary Borenszweig <ary@esperanto.org.ar> wrote:

>>> Also, "I think I don't like X" is not proper English.  Say "I don't think I like X" or just "I don't like X" instead.<
>
> To Jarrett: why isn't it proper English? It makes sense to me.

Andrei did a pretty good job of explaining indirectly why it's wrong ;)

If you say "I think <something about myself>", it sounds very strange, because it sounds like you don't know what's going on in your own brain.  "I think X" often means "I'm not sure of X", so saying that you're unsure of what you do or don't like sounds odd indeed.

Ary Borenszweig wrote:
> bearophile wrote:
>> Jarrett Billingsley:
>>
>> This is an old discussion, and maybe it will not lead to much.
>>
>>
>>> If you don't have a semicolon, you get a simple parser error. That is not a bug.<
>>
>> Wikipedia agrees with me:
>>
>> http://en.wikipedia.org/wiki/Software_bug
>>> A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect or unexpected result).<
>>
>> So a parser error is a bug too, despite the compiler will help you find it in a moment.
>>
>> I have written and debugged many times "mistakes" like:
>>
>> foreach (a, b, iterable)
>> foreach (a; b; iterable)
>> foreach (a; b, iterable)
>>
>> And probably I am not the only one :-)
> 
> Why would you do that?
> 
> Many times when writing C# loops I do foreach(x; ...) and then remember it's "in" in C#, because I'm used to writing ";" in Java. I prefer ";" because it's shorter and you write a lot of foreach loops in a program.
> 
> Maybe we should vote and see how many people make the mistake of confusing comma and semicolon in this case.

Not confusing me. I'll note that if "in" were used, you could write:

foreach (a in b in c) {}

Now try explaining that one :o).


Andrei

Jarrett Billingsley wrote:
> The point I'm making here is it doesn't matter whether it uses 'in' or
> ';' or ':' or '(%)#*@' to separate the loop indices from the container
> expression, because there will always be people who feel that another
> syntax is better or more natural.  Instead of arguing over minute
> details like this, let's worry about the important things, like the
> semantics of foreach loops.

I agree. One thing that ranges still don't address is binding multiple values to them:

foreach (a, b, c; range) statement

Steve promoted the idea that the code above is translated to:

{
    T1 a;
    T2 b;
    T3 c;
    auto __r = range;
    for (; !__r.empty; __r.next)
    {
        __r.head(a, b, c);
        statement
    }
}

It's a good idea, and I'd favor e.g. a discussion around it as opposed to one on whether ";" is the proper separator.

Oh, there was another wrinkle: if you have a container, how do you obtain a range from it? I suggested container.all, but then people said that's a step backwards from opApply. I think [] should be used for accessing all of a range. Something that is already a range simply returns "this" from opSlice(). So the code above with this other proposal tucked in becomes:

{
    T1 a;
    T2 b;
    T3 c;
    auto __r = range[];
    for (; !__r.empty; __r.next)
    {
        __r.head(a, b, c);
        statement
    }
}


Andrei

On Thu, 19 Feb 2009 10:45:44 -0500, Jarrett Billingsley wrote:

> Also, "I think I don't like X" is not proper English.  Say "I don't think I like X" or just "I don't like X" instead.

Of course its proper English.

"I think I don't like X" means that I'm undecided about whether or not I like X but I probably do not like it.

"I don't think I like X" means that I *know* that I don't like X, there is no uncertainty.


-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

On Thu, Feb 19, 2009 at 4:06 PM, Derek Parnell <derek@psych.ward> wrote:
> On Thu, 19 Feb 2009 10:45:44 -0500, Jarrett Billingsley wrote:
>
>> Also, "I think I don't like X" is not proper English.  Say "I don't think I like X" or just "I don't like X" instead.
>
> Of course its proper English.
>
> "I think I don't like X" means that I'm undecided about whether or not I like X but I probably do not like it.
>
> "I don't think I like X" means that I *know* that I don't like X, there is no uncertainty.

See, it's funny, because I would think "I don't think I like X" means that I'm undecided about whether or not I like X but I probably don't; and that "I don't like X" means that I know that I don't like it.  "I think I don't X" just sounds very unnatural to me.