On Thu, Feb 19, 2009 at 11:07 AM, bearophile <[email protected]> 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.
