www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Improving Compiler Error Messages

reply Walter Bright <newshound1 digitalmars.com> writes:
http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html

The next dmd update is getting the fruits of this.
May 01 2010
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, May 01, 2010 at 07:56:42PM -0700, Walter Bright wrote:

 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html



 1. quit on first error
 This certainly prevents any cascaded messages, and is adequate for a hobby 
 compiler. Professional users expect much better.


Am I strange in that this is all I really pay attention to? I generally
hit compile, look at just the first error, fix it, compile again, repeat
until it goes through.

Probably habit formed from most errors beyond the first being mostly
useless anyway, but I'd actually be perfectly ok with it stopping at the
first one.


 The next dmd update is getting the fruits of this.


Cool!

-- 
Adam D. Ruppe
http://arsdnet.net
May 01 2010
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Adam D. Ruppe wrote:

 On Sat, May 01, 2010 at 07:56:42PM -0700, Walter Bright wrote:

 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html


 

 1. quit on first error
 This certainly prevents any cascaded messages, and is adequate for a hobby 
 compiler. Professional users expect much better.


 
 Am I strange in that this is all I really pay attention to? I generally
 hit compile, look at just the first error, fix it, compile again, repeat
 until it goes through.
 
 Probably habit formed from most errors beyond the first being mostly
 useless anyway, but I'd actually be perfectly ok with it stopping at the
 first one.


Reading the first one only generally is a reaction to compilers giving nonsense 
cascaded errors afterwards. If the multiple errors really are errors, then it's 
convenient to get them fixed with one pass through the edit/compile cycle.
May 01 2010
prev sibling parent BCS <none anon.com> writes:
Hello Adam,


 On Sat, May 01, 2010 at 07:56:42PM -0700, Walter Bright wrote:
 
 Am I strange in that this is all I really pay attention to? I
 generally hit compile, look at just the first error, fix it, compile
 again, repeat until it goes through.


What about in an IDE with error highlighting? Also I often (while refactoring) 
get the same error in many places and fix them all at once. And sometimes 
if the first error doesn't point out what's wrong the following ones can 
give some clues.

-- 
... <IXOYE><
May 02 2010
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 05/01/2010 09:56 PM, Walter Bright wrote:

 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html

 The next dmd update is getting the fruits of this.


I've noticed that dmd is a lot more disciplined wrt error messages. Very 
Nice.

(I'd be enjoying this feature more, except dmd is segfaulting on me for 
some odd reason)

Anyways, kudos, and I look forward to this next release.
May 01 2010
parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 05/01/2010 11:09 PM, Ellery Newcomer wrote:

 (I'd be enjoying this feature more, except dmd is segfaulting on me for
 some odd reason)


Downs, your ctfe code sucks. <g>
May 01 2010
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Walter Bright wrote:

 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html
 
 The next dmd update is getting the fruits of this.


So cool!

About the semicolon redundancy: it has been discussed a lot of times in 
this newsgroup, but I started programming in ruby some time ago and I 
can tell you I prefer to not type thousands of those redundant 
semicolons to once in a while spend 5 or 10 seconds to understand that 
the error the interpreter is talking about is about a misinterpretation 
of what I wrote. Note that this "once in a while" might have happened 
two or three times in about seven months of work. I prefer not to type 
those many semicolons and parenthesis. :-)
May 01 2010
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Ary Borenszweig wrote:

 Walter Bright wrote:

 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html

 The next dmd update is getting the fruits of this.


 
 So cool!
 
 About the semicolon redundancy: it has been discussed a lot of times in 
 this newsgroup, but I started programming in ruby some time ago and I 
 can tell you I prefer to not type thousands of those redundant 
 semicolons to once in a while spend 5 or 10 seconds to understand that 
 the error the interpreter is talking about is about a misinterpretation 
 of what I wrote. Note that this "once in a while" might have happened 
 two or three times in about seven months of work. I prefer not to type 
 those many semicolons and parenthesis. :-)


And

3. scan till a ; is found

can be replaced with

3. scan (in a smart way) till a line end is found
May 01 2010
parent reply Nathan Tuggy <bugzilla nathan.tuggycomputer.com> writes:
On 2010-05-01 21:31, Ary Borenszweig wrote:

 Ary Borenszweig wrote:

 Walter Bright wrote:

 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html

 The next dmd update is getting the fruits of this.


 So cool!

 About the semicolon redundancy: it has been discussed a lot of times
 in this newsgroup, but I started programming in ruby some time ago and
 I can tell you I prefer to not type thousands of those redundant
 semicolons to once in a while spend 5 or 10 seconds to understand that
 the error the interpreter is talking about is about a
 misinterpretation of what I wrote. Note that this "once in a while"
 might have happened two or three times in about seven months of work.
 I prefer not to type those many semicolons and parenthesis. :-)


 And

 3. scan till a ; is found

 can be replaced with

 3. scan (in a smart way) till a line end is found


Yeah, I kind of thought that myself. It works especially well in 
languages without implicit line continuation (BASIC derivatives, mostly, 
and probably some others I'm not thinking of right now). Obviously, D 
does have implicit line continuation, which causes potential ambiguity, 
but I think it can still work fairly well.

Anyone done experiments on the effectiveness of this approach in 
C-family languages?
-- 
~ "The most likely way for the world to be destroyed, most experts 
agree, is by accident. That's where we come in; we're computer 
professionals. We cause accidents." Nathaniel Borenstein (1957 - ) ~ 
http://tagzilla.mozdev.org v0.066
May 01 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Nathan Tuggy wrote:

 Anyone done experiments on the effectiveness of this approach in 
 C-family languages?


Yes, it's done in Javascript. It doesn't work very well.
May 01 2010
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hripl9$2iie$1 digitalmars.com...

 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html

 The next dmd update is getting the fruits of this.


Very good article!
May 01 2010
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
The next dmd update is getting the fruits of this.<


Thank you for your interesting article.



Lately, the clang compiler project has revived interest in improving compiler
error diagnostic messages:<


"Competition" is useful. I have seen few other things in GCC that are
changing/moving thanks/because to the Clang competition. The recently
introduced plug-ins of GCC, and the -flto compilation switch of GCC too seem an
effect of Clang presence.



Back in the 1980's, I thought I'd do this one better and have the compiler also
emit the offending source code line with a ^ under where it went wrong, like:<
[...] >Secondly, it ate up 3 lines of valuable vertical real estate rather than
one, meaning that other useful messages got scrolled off the screen.<
The Digital Mars C and C++ compilers still do this, but I dropped it for the D
programming language compiler. Nobody remarked upon the absence of this long
standing feature, so I figured it was the right decision to abandon it.<


In 2010 people are not interested in the scrolling of text in the command line
interface, even basic editors gulp down the error messages.


In GCC 4.5 they have recently added the columns:

The -fshow-column option is now on by default. This means error messages now
have a column associated with them.<


So this is an example of error message generated on C code by GCC 4.5:
test.c:28:6: error: 'struct <anonymous>' has no member named 'seed'





The more enterprising of these folks will build their own language to prove
their point.<


You have to respect their efforts because young people have to err to learn and
become wise and because sometimes, against all odds, they are able to find
alternative solutions that can work well enough, even where wise old people
have failed finding any. Human history is full of examples of this.



The result is that it works great as long as there are no mistakes in the
source code. As soon as there is one, the error diagnostics tend to be
gibberish, the location of the error is often off by several lines, and one
mistake results in a cascade of increasingly obscure messages.<


Error messages in Python are OK. But the whole syntax of Python is designed
around the idea of no semicolons.

You have also to take into account the time wasted in D programming adding
semicolons when the compiler shows you errors caused by their absence :-)



And so the semicolon persists.<


Some of the languages developed in the last years seems to not agree with you,
Scala and Go seem to avoid semicolons.



Spell Checking This appears to have been first tried by the Clang group.<


Nope, Mathematica has had this for ages. (And seeing Mathematica I have
suggested you this feature two years ago).

-------------------

Walter Bright:


Reading the first one only generally is a reaction to compilers giving nonsense
cascaded errors afterwards. If the multiple errors really are errors, then it's
convenient to get them fixed with one pass through the edit/compile cycle.<



compilers are among the few ones that seem good enough that looking past the
first error is worth it.
GCC and (so far) dmd give error messages that usually make looking past the
first error a waste of time.



Yes, it's done in JavaScript. It doesn't work very well.<


JavaScript, like most languages, was designed too much quickly (even D, that is
several years old, in its final rush has probably introduced several warts. I
hope some of them will be fixed), and it contains some traps and design errors.

In JavaScript there is semicolon insertion:

It's implemented by the parser running along until it hits a syntax error, at
which point it rewinds a little, inserts a semicolon in a likely place, and
tries again.<


Here you can read more about this:
http://www.mozilla.org/js/language/js20-2000-07/rationale/syntax.html

This code:

return {
	JavaScript : "fantastic"
};


Is different from:

return
{
	JavaScript : "fantastic"
};


This is how JS reads that:

return; // Semicolon inserted, believing the statement has finished. Returns
undefined
{ // Considered to be an anonymous block, doing nothing
	JavaScript : "fantastic"
};// Semicolon interpreted as an empty dummy line and moved down


So programming guides for JS suggest programmers to always use the semicolon...

But even if JS has failed its design its semicolon-related feature, there are
other ways to design it, I have not read people complain much about the bugs
caused by missing semicolons in Scala.

If you just remove the semicolons from D you probably cause problems, as in
JavaScript. To make this idea work you have to adapt other parts of the syntax
to this change. And you don't have to add a semicolon as JS does. You can
interpret newlines as semicolons and introduce explicit line continuation
symbols, as in Python. In Python and Delight there are also the colon used to
denote the start of a block. This makes the syntax good enough again for both
the compiler and the eyes of the programmer (the colon is redundant but it's
there for the programmer eyes, and for some editors too).

In a program most lines of code end at the newlines, so to reduce typing and
errors it's a good idea to swap the syntax: instead of adding an explicit
syntax to end lines (semicolon) it's better to introduce a line continuation
(like \ in Python).

If semicolons are so good for the compiler, then there can be ways to fix this
small problem (I was planning in writing this bug report even before reading
this last paper of yours):
http://d.puremagic.com/issues/show_bug.cgi?id=4144

Bye,
bearophile
May 02 2010
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sun, May 02, 2010 at 05:51:48AM -0400, bearophile wrote:

 In 2010 people are not interested in the scrolling of text in the command line
interface, even basic editors gulp down the error messages.


You shouldn't speak for everyone without some solid evidence. I still find
some scroll related stuff to be annoying.
May 02 2010
next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sun, 02 May 2010 08:21:06 -0400, Adam D. Ruppe  
<destructionator gmail.com> wrote:


 On Sun, May 02, 2010 at 05:51:48AM -0400, bearophile wrote:

 In 2010 people are not interested in the scrolling of text in the  
 command line interface, even basic editors gulp down the error messages.


 You shouldn't speak for everyone without some solid evidence. I still  
 find
 some scroll related stuff to be annoying.


A bunch of (most?) editors have issues with multi-line errors. I know the  
early CUDA compiler had multi-line errors, and people had to write little  
perl adapter scripts to get it to work with Visual Studio. I mainly use  
Code::blocks and I'm fairly sure it can't handle multi-line errors by  
design.
May 02 2010
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Adam D. Ruppe wrote:

 On Sun, May 02, 2010 at 05:51:48AM -0400, bearophile wrote:

 In 2010 people are not interested in the scrolling of text in the command
 line interface, even basic editors gulp down the error messages.


 
 You shouldn't speak for everyone without some solid evidence. I still find 
 some scroll related stuff to be annoying.


I agree, since I still rely on console windows to do compiling in. Also, if 
someone is using an editor to gulp down the error messages, they will not need 
the display of source line because the editor will handle that far better.

So there is no application for the source line as part of the error message.
May 02 2010
prev sibling next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
On 05/02/2010 05:51 AM, bearophile wrote:

 You have also to take into account the time wasted in D programming adding
semicolons when the compiler shows you errors caused by their absence :-)


Quoted for truth.


 Some of the languages developed in the last years seems to not agree with you,
Scala and Go seem to avoid semicolons.


Scala's implicit semicolons aren't without problems. There have been 
several posts on the issue. Here's an example: 
http://permalink.gmane.org/gmane.comp.lang.scala.debate/1134

"As a scala newbie I find the implicit semi-colon rules in scala more a 
hinderance than a help.  Being a believer in the 80-column rule I find 
myself often pondering "where can I break this line without the compiler 
thinking I'm trying to imply a semi-colon?" This is not an easy question 
to answer for one new to the language.  Particularly when said language 
already has a complex syntax due to diverse minimization rules."



 In a program most lines of code end at the newlines, so to reduce typing and
errors it's a good idea to swap the syntax: instead of adding an explicit
syntax to end lines (semicolon) it's better to introduce a line continuation
(like \ in Python).


Makes sense to me.
May 02 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:


I find that example to count as a good argument against optional-semicolons.<


Yep, that example was optional semicolons as implemented in JavaScript. I agree
that a bad implementation of this feature is worse than not having it.



Sure, there may be ways around it, but the rules involved would be complicated,
and also difficult to get just right.<


If its rules are complicated, then in my opinion it's badly designed. See below.



AI do a lot of line-juggling, so I've always found explicit line continuation
operators to be a royal pain in the ass.<


I have written a large amount of Python code, and I use a line continuation
symbol probably every 50000 chars of code&comments, so for me it's not a pain.
From what I've seen in the Python newsgroups, this is not among the top fifteen
Python complains :-)

------------------

Jeff Nowakowski:


Scala's implicit semicolons aren't without problems. There have been several
posts on the issue. Here's an example: [...]
"As a scala newbie I find the implicit semi-colon rules in scala more a
hinderance than a help.  Being a believer in the 80-column rule I find myself
often pondering "where can I break this line without the compiler thinking I'm
trying to imply a semi-colon?" This is not an easy question to answer for one
new to the language.  Particularly when said language already has a complex
syntax due to diverse minimization rules."<<



Ary Borenszweig:


On the other hand, I just made a small test and I think Python can be improved.
[...] As you can see, when python encounters an end of line after a + is
chokes, gives an error. Ruby is smarter in that it knows that you intend to add
another operand, be it in the current line or in another line. That's what I
mean with understanding line endings in a smart way. The same goes in ruby with
many other things:<



Thank you for your answers, and thank you for that note about Scala, it seems I
was wrong, the Scala design here is not good enough.

The juxtaposition of those two comments offers me a chance to explain things
better. Design of a language can be anti-intuitive, and sometimes what looks
better is worse. Python resists strongly to such "improvements", and will
probably never "get better" in this regard.

There are two rules of the Python Zen about this:
* Special cases aren't special enough to break the rules.
* In the face of ambiguity, refuse the temptation to guess.

Python prefers to use only this to manage end of lines: the newline is the end
of the line. The exception: if you have opened a parenthesis, the line
continuation is implied until you close it.

Here Python never guesses and it's dumb. It doesn't add semicolons as
JavaScript, and and it never implies a semicolon as Scala. This makes this
feature simpler to implement, simper to understand, and about this there are
zero (or just one) questions to answer for newbies. As Sabalausky says it's not
perfect, but perfect things are rigid and boring :-)

I think this is an example where a smarter design is worse.

Bye,
bearophile
May 02 2010
parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hrkji4$2nsr$1 digitalmars.com...

 Nick Sabalausky:


AI do a lot of line-juggling, so I've always found explicit line 
continuation operators to be a royal pain in the ass.<


 I have written a large amount of Python code, and I use a line 
 continuation symbol probably every 50000 chars of code&comments, so for me 
 it's not a pain.
 From what I've seen in the Python newsgroups, this is not among the top 
 fifteen Python complains :-)


That's only natural. People who don't like it are less likely to use Python 
and hang around the Python NGs. Just like how there's very few people around 
here that have any problem with curly braces, since people who have a strong 
prefernce for, say, BASIC/Pascal-style "begin/end" blocks are unlikely to 
care enough about D to hang around here.
May 02 2010
prev sibling next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
bearophile wrote:

 Yes, it's done in JavaScript. It doesn't work very well.<


 
 JavaScript, like most languages, was designed too much quickly (even D, that
is several years old, in its final rush has probably introduced several warts.
I hope some of them will be fixed), and it contains some traps and design
errors.
 
 In JavaScript there is semicolon insertion:

 It's implemented by the parser running along until it hits a syntax error, at
which point it rewinds a little, inserts a semicolon in a likely place, and
tries again.<


 
 Here you can read more about this:
 http://www.mozilla.org/js/language/js20-2000-07/rationale/syntax.html
 
 This code:
 
 return {
 	JavaScript : "fantastic"
 };
 
 
 Is different from:
 
 return
 {
 	JavaScript : "fantastic"
 };
 
 
 This is how JS reads that:
 
 return; // Semicolon inserted, believing the statement has finished. Returns
undefined
 { // Considered to be an anonymous block, doing nothing
 	JavaScript : "fantastic"
 };// Semicolon interpreted as an empty dummy line and moved down
 
 
 So programming guides for JS suggest programmers to always use the semicolon...


(snip)

 In a program most lines of code end at the newlines, so to reduce typing and
errors it's a good idea to swap the syntax: instead of adding an explicit
syntax to end lines (semicolon) it's better to introduce a line continuation
(like \ in Python).


In ruby the same thing is true. This (to return a hash):

return {
:a => 1
}

is different from

return
{
:a => 1
}

But it's not hard to see that the compiler cannot see what is what you 
intended: to return a hash or to return and then declare a hash. If you 
program just a little in ruby you understand this.

On the other hand, I just made a small test and I think Python can be 
improved.

$ python

 1 +






   File "<stdin>", line 1
     1 +
       ^
SyntaxError: invalid syntax

 2






2


$ irb
irb(main):001:0> 1 +
irb(main):002:0* 2
=> 3


As you can see, when python encounters an end of line after a + is 
chokes, gives an error. Ruby is smarter in that it knows that you intend 
to add another operand, be it in the current line or in another line. 
That's what I mean with understanding line endings in a smart way. The 
same goes in ruby with many other things:

$ irb
irb(main):001:0> def func(a, b); a + b; end;
irb(main):002:0* func 1,
irb(main):003:0* 2
=> 3

Since I put a comma and it's a function call, it doesn't matter if the 
next argument is in the current line or the next line(s). The compiler 
is smart to know that another argument will come. (oh, and parenthesis 
are optional :-D)

So as bearophile says, to implement this in D or another 
semicolon-language is much more than just assuming a line break is a 
semicolon.
May 02 2010
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hrjhvk$pkk$1 digitalmars.com...

 You have also to take into account the time wasted in D programming adding 
 semicolons when the compiler shows you errors caused by their absence :-)


Personally, I've never found the time spent adding semicolons, or fixing 
missing-semicolon errors, to be anything more than trivial.


 This code:

 return {
 JavaScript : "fantastic"
 };


 Is different from:

 return
 {
 JavaScript : "fantastic"
 };


 This is how JS reads that:

 return; // Semicolon inserted, believing the statement has finished. 
 Returns undefined
 { // Considered to be an anonymous block, doing nothing
 JavaScript : "fantastic"
 };// Semicolon interpreted as an empty dummy line and moved down


I find that example to count as a good argument against optional-semicolons. 
Sure, there may be ways around it, but the rules involved would be 
complicated, and also difficult to get just right.


 In a program most lines of code end at the newlines, so to reduce typing 
 and errors it's a good idea to swap the syntax: instead of adding an 
 explicit syntax to end lines (semicolon) it's better to introduce a line 
 continuation (like \ in Python).


I do a lot of line-juggling, so I've always found explicit line continuation 
operators to be a royal pain in the ass. In fact, the need for them is the 
primary reason I prefer not to use newline-based-end-of-statement languages. 
True, mandatory semicolons are something that affect the programmer *all* of 
the time, however, I've never once found those to be bothersome (except 
maybe as a newbie, many many years ago). Mandatory line-continuation 
operators, on the other hand, only affect me some of the time, but it's 
still fairly often, and it's a PITA every time. Your mileage may vary, of 
course.
May 02 2010
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 Error messages in Python are OK. But the whole syntax of Python is designed
 around the idea of no semicolons.


I think there's a misunderstanding. The bit about semicolons in the article was 
not about removing statement terminators, it was about the idea that a
statement 
termination can be inferred. For example:

     import std.stdio struct S { ... }

The compiler can infer that a statement terminator belongs between stdio and 
struct, so why should the programmer have to insert one?

What Python did was use a linefeed as the statement terminator rather than the 
;. Python does not attempt to infer where they should go. The redundancy is 
still there.

Javascript is fundamentally different in that it attempts to infer the
statement 
terminator.

So why does D have ; as a statement terminator? The simple answer is because D 
is intended to have a low barrier for entry for C, C++, etc., programmers. The 
familiar look & feel makes the new language less intimidating. A personal
answer 
is that I simply like it.
May 02 2010
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  2 de mayo a las 16:27 me escribiste:

 What Python did was use a linefeed as the statement terminator
 rather than the ;. Python does not attempt to infer where they
 should go. The redundancy is still there.
 
 Javascript is fundamentally different in that it attempts to infer
 the statement terminator.
 
 So why does D have ; as a statement terminator? The simple answer is
 because D is intended to have a low barrier for entry for C, C++,
 etc., programmers. The familiar look & feel makes the new language
 less intimidating. A personal answer is that I simply like it.


You can put ; at the end of statements in Python too. You could follow
that route in D too, and new people coming from C could type all the
(optional) ; they want and feel at home.

So I think the only making sense here, is that you personally like it.

Well, to be complete, there is another catch when using \n as
a terminator, you have to add a continuation character to span
a statemente in multiple lines (or be smart as Python does when you have
a non-closed parethesis, or Ruby and Go do with ending operators).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
A heart that's full up like a landfill,
a job that slowly kills you,
bruises that won't heal.
May 02 2010
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Sun, 02 May 2010 16:27:47 -0700, Walter Bright wrote:

 So why does D have ; as a statement terminator? The simple answer is
 because D is intended to have a low barrier for entry for C, C++, etc.,
 programmers. The familiar look & feel makes the new language less
 intimidating. A personal answer is that I simply like it.


For what it's worth, I like it too. :)

I've never understood why people have a problem with the semicolons.  
They've never bothered me, not once.  In fact, they just seem to 
magically appear at the end of my statements without me thinking 
consciously about them at all.

-Lars
May 03 2010
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 5/3/10 10:01, Lars T. Kyllingstad wrote:

 On Sun, 02 May 2010 16:27:47 -0700, Walter Bright wrote:

 So why does D have ; as a statement terminator? The simple answer is
 because D is intended to have a low barrier for entry for C, C++, etc.,
 programmers. The familiar look&  feel makes the new language less
 intimidating. A personal answer is that I simply like it.


 For what it's worth, I like it too. :)

 I've never understood why people have a problem with the semicolons.
 They've never bothered me, not once.  In fact, they just seem to
 magically appear at the end of my statements without me thinking
 consciously about them at all.

 -Lars


I would say I like to have them optional. When you start using delegate 
literals it's just too much:

foo((int i) { writeln(i); });

The above is quite verbose but in this case removing the semicolons 
doesn't help that much.

/Jacob Carlborg
May 03 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-05-03 05:53:34 -0400, Jacob Carlborg <doob me.com> said:


 foo((int i) { writeln(i); });


I agree that the semicolon looks out of place for one-line function bodies.

The semicolon could be made optional for the last statement in a block. 
Just have it be a statement separator instead of a terminator. That'd 
be consistent with commas in enums, array literals, and function 
arguments.

foo((int i) { writeln(i) });

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 03 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Michel Fortin" <michel.fortin michelf.com> wrote in message 
news:hrn8f1$tv2$1 digitalmars.com...

 On 2010-05-03 05:53:34 -0400, Jacob Carlborg <doob me.com> said:


 foo((int i) { writeln(i); });


 I agree that the semicolon looks out of place for one-line function 
 bodies.

 The semicolon could be made optional for the last statement in a block. 
 Just have it be a statement separator instead of a terminator. That'd be 
 consistent with commas in enums, array literals, and function arguments.

 foo((int i) { writeln(i) });


Yea, that's a case of optional-semicolon that even I'd like to have (And 
I've suggested it before).
May 03 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:

 "Michel Fortin" <michel.fortin michelf.com> wrote in message 
 news:hrn8f1$tv2$1 digitalmars.com...

 On 2010-05-03 05:53:34 -0400, Jacob Carlborg <doob me.com> said:


 foo((int i) { writeln(i); });


 I agree that the semicolon looks out of place for one-line function 
 bodies.

 The semicolon could be made optional for the last statement in a block. 
 Just have it be a statement separator instead of a terminator. That'd be 
 consistent with commas in enums, array literals, and function arguments.

 foo((int i) { writeln(i) });


 
 Yea, that's a case of optional-semicolon that even I'd like to have (And 
 I've suggested it before). 


Actually that doesn't work as well as one might expect. In the Cecil 
language, the return type of a function would depend on whether it ended 
with a semicolon (void if present, something else if absent). Not very 
robust.

Andrei
May 03 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-05-03 16:07:34 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 foo((int i) { writeln(i) });


 
 Yea, that's a case of optional-semicolon that even I'd like to have 
 (And I've suggested it before).


 
 Actually that doesn't work as well as one might expect. In the Cecil 
 language, the return type of a function would depend on whether it 
 ended with a semicolon (void if present, something else if absent). Not 
 very robust.


That's an argument against returning the value of the last statement. 
It's not an argument about making the last semicolon optional, is it?

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 03 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:

 That's an argument against returning the value of the last statement. 
 It's not an argument about making the last semicolon optional, is it?


Yes, it is an argument against it. It means the semantics can vary dramatically 
depending on whether a ; is present or not.
May 03 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hrncpk$14t2$2 digitalmars.com...

 Michel Fortin wrote:

 That's an argument against returning the value of the last statement. 
 It's not an argument about making the last semicolon optional, is it?


 Yes, it is an argument against it. It means the semantics can vary 
 dramatically depending on whether a ; is present or not.


But that's only true when the language, unlike D, has implicit returns, 
right?
May 03 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hrncpk$14t2$2 digitalmars.com...

 Michel Fortin wrote:

 That's an argument against returning the value of the last statement. 
 It's not an argument about making the last semicolon optional, is it?


 Yes, it is an argument against it. It means the semantics can vary 
 dramatically depending on whether a ; is present or not.


 
 But that's only true when the language, unlike D, has implicit returns, 
 right? 



Right. But D (and C, C++) do not have implicit returns, and so this syntax is 
not right for them.
May 03 2010
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-05-03 18:05:11 -0400, Walter Bright <newshound1 digitalmars.com> said:


 Nick Sabalausky wrote:

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hrncpk$14t2$2 digitalmars.com...

 Michel Fortin wrote:

 That's an argument against returning the value of the last statement. 
 It's not an argument about making the last semicolon optional, is it?


 Yes, it is an argument against it. It means the semantics can vary 
 dramatically depending on whether a ; is present or not.


 
 But that's only true when the language, unlike D, has implicit returns, right?


 
 Right. But D (and C, C++) do not have implicit returns, and so this 
 syntax is not right for them.


Ok, so to summarize, your opinion is:

1. omitting the last semicolon looks like an implicit return
2. implicit returns are too subtle, won't add to D
3. since D has no implicit returns, omitting the last semicolon is not accepted

I disagree about 1, and thus about 3 since it derives from 1. But 
that's probably just because of our different background, so I'll leave 
it at that.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 03 2010
next sibling parent Jacob Carlborg <doob me.com> writes:
On 5/4/10 00:30, Michel Fortin wrote:

 On 2010-05-03 18:05:11 -0400, Walter Bright <newshound1 digitalmars.com>
 said:


 Nick Sabalausky wrote:

 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 news:hrncpk$14t2$2 digitalmars.com...

 Michel Fortin wrote:

 That's an argument against returning the value of the last
 statement. It's not an argument about making the last semicolon
 optional, is it?


 Yes, it is an argument against it. It means the semantics can vary
 dramatically depending on whether a ; is present or not.


 But that's only true when the language, unlike D, has implicit
 returns, right?


 Right. But D (and C, C++) do not have implicit returns, and so this
 syntax is not right for them.


 Ok, so to summarize, your opinion is:

 1. omitting the last semicolon looks like an implicit return
 2. implicit returns are too subtle, won't add to D
 3. since D has no implicit returns, omitting the last semicolon is not
 accepted

 I disagree about 1, and thus about 3 since it derives from 1. But that's
 probably just because of our different background, so I'll leave it at
 that.


I completely agree Michel Fortin.
May 04 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 5/4/10 00:30, Michel Fortin wrote:

 On 2010-05-03 18:05:11 -0400, Walter Bright <newshound1 digitalmars.com>
 said:


 Nick Sabalausky wrote:

 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 news:hrncpk$14t2$2 digitalmars.com...

 Michel Fortin wrote:

 That's an argument against returning the value of the last
 statement. It's not an argument about making the last semicolon
 optional, is it?


 Yes, it is an argument against it. It means the semantics can vary
 dramatically depending on whether a ; is present or not.


 But that's only true when the language, unlike D, has implicit
 returns, right?


 Right. But D (and C, C++) do not have implicit returns, and so this
 syntax is not right for them.


 Ok, so to summarize, your opinion is:

 1. omitting the last semicolon looks like an implicit return
 2. implicit returns are too subtle, won't add to D
 3. since D has no implicit returns, omitting the last semicolon is not
 accepted

 I disagree about 1, and thus about 3 since it derives from 1. But that's
 probably just because of our different background, so I'll leave it at
 that.


I guess D isn't created with delegate literals in mind as one of the 
most important features, like Ruby or Scala.
May 04 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-05-03 15:33:53 -0400, Michel Fortin <michel.fortin michelf.com> said:


 On 2010-05-03 05:53:34 -0400, Jacob Carlborg <doob me.com> said:
 

 foo((int i) { writeln(i); });


 
 I agree that the semicolon looks out of place for one-line function bodies.
 
 The semicolon could be made optional for the last statement in a block. 
 Just have it be a statement separator instead of a terminator. That'd 
 be consistent with commas in enums, array literals, and function 
 arguments.
 
 foo((int i) { writeln(i) });


It could even be taken a little further: make the last statement the 
implicit return value of a function:

	{ a < b } same as { return a < b; }

Adding back the semicolon would bring back the current behaviour (it's 
just like adding an empty statement):

	{ a < b; } same as { a < b; return; }

It'd be nice for functional style predicates.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 03 2010
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:

 It could even be taken a little further: make the last statement the 
 implicit return value of a function:
 
     { a < b } same as { return a < b; }
 
 Adding back the semicolon would bring back the current behaviour (it's 
 just like adding an empty statement):
 
     { a < b; } same as { a < b; return; }
 
 It'd be nice for functional style predicates.



Yes, these were all proposed for both C++0x and D, and both were rejected for 
the reason Andrei stated.
May 03 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 5/3/10 22:06, Michel Fortin wrote:

 On 2010-05-03 15:33:53 -0400, Michel Fortin <michel.fortin michelf.com>
 said:


 On 2010-05-03 05:53:34 -0400, Jacob Carlborg <doob me.com> said:


 foo((int i) { writeln(i); });


 I agree that the semicolon looks out of place for one-line function
 bodies.

 The semicolon could be made optional for the last statement in a
 block. Just have it be a statement separator instead of a terminator.
 That'd be consistent with commas in enums, array literals, and
 function arguments.

 foo((int i) { writeln(i) });


 It could even be taken a little further: make the last statement the
 implicit return value of a function:

 { a < b } same as { return a < b; }

 Adding back the semicolon would bring back the current behaviour (it's
 just like adding an empty statement):

 { a < b; } same as { a < b; return; }

 It'd be nice for functional style predicates.


It would be nice to drop the brackets also, for one line delegates.
May 04 2010
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:

 The semicolon could be made optional for the last statement in a block. 
 Just have it be a statement separator instead of a terminator. That'd be 
 consistent with commas in enums, array literals, and function arguments.
 
 foo((int i) { writeln(i) });



This has been proposed before, and it looks nice, but it's problematic.

It was also proposed and rejected for C++0x lambdas.
May 03 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 5/3/10 21:33, Michel Fortin wrote:

 On 2010-05-03 05:53:34 -0400, Jacob Carlborg <doob me.com> said:


 foo((int i) { writeln(i); });


 I agree that the semicolon looks out of place for one-line function bodies.

 The semicolon could be made optional for the last statement in a block.
 Just have it be a statement separator instead of a terminator. That'd be
 consistent with commas in enums, array literals, and function arguments.

 foo((int i) { writeln(i) });


I think I've forgot the semicolon in every one line delegate literal 
I've ever written in D.
May 04 2010
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Lars T. Kyllingstad wrote:

 I've never understood why people have a problem with the semicolons.  
 They've never bothered me, not once.  In fact, they just seem to 
 magically appear at the end of my statements without me thinking 
 consciously about them at all.


Me too. I had no difficulty learning them or using them, it was just like "oh, 
ok". I came from non-semicolon languages, too, like Basic and Fortran.

It's just a cosmetic preference, like if you prefer sugar or milk in your
coffee.

Any errors from misplaced semicolons are quickly diagnosed by the compiler and 
trivially fixed.
May 03 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Lars T. Kyllingstad:

 I've never understood why people have a problem with the semicolons.  


In real life there are all kind of errors, communication channels are noisy,
and the number of possible meanings is huge. So people are forced to try to
understand what other people meant. When people interact with computers, they
expect a bit of "basic" understanding from the machine. A language like Perl
that tries to read too much into what you meant leads to a messy design and
messy programs. But the other extrema (obligatory semicolons at the end of
lines) are often seen as excessively fussy by programming newbies (or normal
Python programmers).



I would say I like to have them optional. When you start using delegate
literals it's just too much:


foo((int i) { writeln(i); });<

If semicolons will ever became optional in D, I want the D parser to not add
them in a smart way as JavaScript does, they can be accepted only as a
replacement of ;<newline>. So even if D semicolons become optional, in that
lambda you will need to add the inner semicolon still (so Python has lambdas
but no Ruby blocks and Guido V.R. likes it this way).

Bye,
bearophile
May 03 2010
prev sibling parent reply BCS <none anon.com> writes:
Hello Lars,


 I've never understood why people have a problem with the semicolons.


People cite typing speed, but who here is actually limited by that? Everyone 
I can think of spends WAY more time thinking than typing. If you are limited 
by your typing speed then ether you type VERY slow (a one fingered typist) 
or you are already way more productive than anyone I've ever met.

-- 
... <IXOYE><
May 03 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 People cite typing speed, but who here is actually limited by that? 
 Everyone I can think of spends WAY more time thinking than typing. If 
 you are limited by your typing speed then ether you type VERY slow (a 
 one fingered typist) or you are already way more productive than anyone 
 I've ever met.


; is not even a shift character. Talking about typing speed with it suggests
one 
also has a speed problem with the . at the end of a sentence.

In any case, in 8th grade during the summer once I was bored and decided to
take 
a local typing class. It was 2 weeks, an hour a day, and we learned on old 
mechanical typewriters where you really needed to hammer the keys.

Given all the keyboarding I've done since, it's probably the most productive 
class I've ever taken :-) It makes me cringe watching people type with 2
fingers 
at high speed.
May 03 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hrmvag$ea5$1 digitalmars.com...

 BCS wrote:

 People cite typing speed, but who here is actually limited by that? 
 Everyone I can think of spends WAY more time thinking than typing. If you 
 are limited by your typing speed then ether you type VERY slow (a one 
 fingered typist) or you are already way more productive than anyone I've 
 ever met.


 ; is not even a shift character. Talking about typing speed with it 
 suggests one also has a speed problem with the . at the end of a sentence.

 In any case, in 8th grade during the summer once I was bored and decided 
 to take a local typing class. It was 2 weeks, an hour a day, and we 
 learned on old mechanical typewriters where you really needed to hammer 
 the keys.

 Given all the keyboarding I've done since, it's probably the most 
 productive class I've ever taken :-) It makes me cringe watching people 
 type with 2 fingers at high speed.


I've taken at least a couple keyboarding classes (they seem to be a fairly 
standard requirement at the high-school/junior-high level these days...or at 
least in the Cleveland area anyway...or at least they were 10-15 years ago, 
maybe it's changed since...). I passed the classes fine, but I never got to 
a point where I really felt comfortable with it. Especialy for C-style code, 
where the usual statistics for most/least-commonly-used characters go right 
out the window and you spend about as much time streching for a shifted 
punctuation and various keyboard shortcuts as you spend on the "home keys". 
But I've been able to get up to about 30 or so words per minute with the 
ad-hoc style I've been developing since I was about 7, and that's been more 
than fast enough for any coding or normal writing I've ever done. I spend 
more time than that just thinking about what I'm going to write, and it's 
not like I do any dictation. That's my experience, anyway :).

I'm also another person that finds semicolons magically appearing at the end 
of statements...even when I use a language that doesn't allow them ;)
May 03 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:

 I'm also another person that finds semicolons magically appearing at the end 
 of statements...even when I use a language that doesn't allow them ;)


It's funny how that works. I was once asked what the key command was for a 
particular operation in my text editor. I didn't know, so I started the editor 
and did the operation, watching my fingers, and reported the key command.
May 03 2010
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hrn5ft$oq2$1 digitalmars.com...

 Nick Sabalausky wrote:

 I'm also another person that finds semicolons magically appearing at the 
 end of statements...even when I use a language that doesn't allow them ;)


 It's funny how that works. I was once asked what the key command was for a 
 particular operation in my text editor. I didn't know, so I started the 
 editor and did the operation, watching my fingers, and reported the key 
 command.


I've noticed that a lot in videogames. I never know what button does what, 
but after trying a few buttons I get a "feel" for the controls, and on 
subsequent plays, I still have no idea what does what, but as soon as I grab 
the controller I can just "do" everything. I think most gamers are like this 
too.

There's been mention about this in Scientific Americam Mind recently. Don't 
remember exactly which issue or article, but there was a big thing about the 
brain's "sense of body ownership", that part of the brain responsible for 
it, the implications of it (such as how controls can become second-nature, 
such as when driving a car - the brain literally treats it as if it were 
part of the body, about the only difference is that a real limb has neurons 
that act as a "mini-brain" that can learn - that part wasn't mentioned in 
the article, but the Science Channel talked about it once), and the problems 
that can arise when this mechanism gets confused (out-of-body experience, 
phantom limbs, "disowning" limbs and in some cases assuming the limb to be 
"evil" or a communist (I'm not making that up!)).
May 03 2010
parent Jacob Carlborg <doob me.com> writes:
On 5/3/10 21:03, Nick Sabalausky wrote:

 "Walter Bright"<newshound1 digitalmars.com>  wrote in message
 news:hrn5ft$oq2$1 digitalmars.com...

 Nick Sabalausky wrote:

 I'm also another person that finds semicolons magically appearing at the
 end of statements...even when I use a language that doesn't allow them ;)


 It's funny how that works. I was once asked what the key command was for a
 particular operation in my text editor. I didn't know, so I started the
 editor and did the operation, watching my fingers, and reported the key
 command.


 I've noticed that a lot in videogames. I never know what button does what,
 but after trying a few buttons I get a "feel" for the controls, and on
 subsequent plays, I still have no idea what does what, but as soon as I grab
 the controller I can just "do" everything. I think most gamers are like this
 too.


That is called muscle memory.


 There's been mention about this in Scientific Americam Mind recently. Don't
 remember exactly which issue or article, but there was a big thing about the
 brain's "sense of body ownership", that part of the brain responsible for
 it, the implications of it (such as how controls can become second-nature,
 such as when driving a car - the brain literally treats it as if it were
 part of the body, about the only difference is that a real limb has neurons
 that act as a "mini-brain" that can learn - that part wasn't mentioned in
 the article, but the Science Channel talked about it once), and the problems
 that can arise when this mechanism gets confused (out-of-body experience,
 phantom limbs, "disowning" limbs and in some cases assuming the limb to be
 "evil" or a communist (I'm not making that up!)).
May 04 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Walter Bright wrote:


 Nick Sabalausky wrote:

 I'm also another person that finds semicolons magically appearing at the
 end of statements...even when I use a language that doesn't allow them ;)


 
 It's funny how that works. I was once asked what the key command was for a
 particular operation in my text editor. I didn't know, so I started the
 editor and did the operation, watching my fingers, and reported the key
 command.


I tend to be that way with passwords. I think that most anything typing-
related that you do a lot without thinking about it just goes into muscle 
memory. So you can constantly do it, but because you don't have to think 
about it, you have a hard time consciously remembering how to do it if you 
have to remember it to tell someone else or whatnot.

It reminds me of a post on SO (on a question relating to computer pranks 
IIRC) how someone's password wasn't working for them, but the sysadmin had 
no trouble typing it in when they were told what it was. It turns out that 
the person having trouble was not a touch typist (while the sysadmin was), 
and someone else had rearranged the keys on their keyboard. So, if you 
didn't look at the keys you were fine, but if you had to read the keys, you 
were screwed...

- Jonathan M Davis
May 06 2010
prev sibling next sibling parent BCS <none anon.com> writes:
Hello Nick,


 I passed the
 classes fine, but I never got to a point where I really felt
 comfortable with it. Especialy for C-style code, where the usual
 statistics for most/least-commonly-used characters go right out the
 window and you spend about as much time streching for a shifted
 punctuation and various keyboard shortcuts as you spend on the "home
 keys". But I've been able to get up to about 30 or so words per minute
 with the ad-hoc style I've been developing since I was about 7, and
 that's been more than fast enough for any coding or normal writing
 I've ever done.


I'm working in programming for a living and I can just barley touch type. 
As for using the home row, if I even have one it's "adfv" and ";kjn" (BTW 
I've never hand RSI problems :).


 I'm also another person that finds semicolons magically appearing at
 the end of statements...even when I use a language that doesn't allow
 them ;)


Me to; English;

-- 
... <IXOYE><
May 03 2010
prev sibling parent Pelle <pelle.mansson gmail.com> writes:
On 05/03/2010 08:21 PM, Nick Sabalausky wrote:

 I'm also another person that finds semicolons magically appearing at the end
 of statements...even when I use a language that doesn't allow them ;)


For me, that includes english;
May 03 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 Nope, Mathematica has had this for ages.


Thanks, you had told me this before, and I had forgotten.

http://www.digitalmars.com/d/archives/digitalmars/D/An_example_of_Clang_error_messages_107006.html#N107014



 (And seeing Mathematica I have suggested you this feature two years ago).


I couldn't find the posting. Can you provide a link please?
May 02 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


I couldn't find the posting. Can you provide a link please?<


I have spent something like an hour to find this (but I have not wasted this
time, because as usual while looking for this post I have found something
unrelated: two old bugs that I have shown in the D newsgroup that exist still,
so I'll add them to Bugzilla soon later), and you are right. I think I have
never written this idea in D newsgroups :-) Before giving some of my free time
for the development of D I have given similar help for Python. So my post was
there, six years ago, see point 12), sorry for my mistake:

http://groups.google.com/group/comp.lang.python/msg/93ce3e9a08f5e4c7
 
The point 12) was:

12) Mathematica's interactive IDE suggests possible spelling errors; this
feature is often useful, works with builtin name functions too, and it can be
switched off.
In[1]:= sin2 = N[Sin[2]]
Out[1]= 0.909297

In[2]:= sina2
General::"spell1": "Possible spelling error: new symbol name "sina2" is similar
to existing symbol "sin2".
Out[2]= sina2

I don't know if some Python IDEs (or IPython) do this already, but it can be
useful in Pythonwin. 

-----------------------


I think there's a misunderstanding. The bit about semicolons in the article was
not about removing statement terminators, it was about the idea that a
statement termination can be inferred.<


I see and indeed I didn't understand well here. Thank you very much for
explaining.



What Python did was use a linefeed as the statement terminator rather than the
;. Python does not attempt to infer where they should go.<


Right.
In Python you need semicolons to separate commands if they are on the same line
(but all Python style guides suggest to split this line):

x = 5; print x



The redundancy is still there.<


Well, yes, there is the line termination still. But you can see that for the
fingers of the programmer the redundancy in Python is lower.
Instead of three keys (on my keyboard I need shift for the semicolon):
<SHIFT>;<NEWLINE>
you have to type just one:
<NEWLINE>

This helps Python newbies and casual programmers (Python is often used as first
language, so this is important), reduces typing a little, removes some syntax
noise from the code, avoids missing semicolon errors (that are common in code
written by programming newbies), etc. It's good for me too despite I am not a
Python newbie.



Javascript is fundamentally different in that it attempts to infer the
statement terminator.<


Right. And it seems Scala tries to do something related (even if Scala can be
better on this too).



So why does D have ; as a statement terminator? The simple answer is because D
is intended to have a low barrier for entry for C, C++, etc., programmers. The
familiar look & feel makes the new language less intimidating.<


Note that in Python ending semicolons are optional, if you use them there are
no errors, I have personally seen several C/Java programmers write Python code
this way and this causes zero problems:
x = 5;
print x;

And a C++ programmer scared by the fact that ending semicolons are optional?
(This means such C++ programmer can write semicolons everywhere, and can find D
code written by other people with no ending semicolons). Of all the mountain of
syntactic mess the C++ is, I can't believe a normal C++ programmer can be
scared by this :-) Of all the differences introduced by D over C++ this one
seems minor.
D classes being reference values that must be allocated with a new looks like
the more frequent cause of troubles for D newbies coming from C++.



A personal answer is that I simply like it.<


OK.
My personal answer, is that I've written too many semicolons in my programming
life, I prefer languages where I can avoid semicolons at the end of lines (if
the language is well designed for this and doesn't infer anything. In
JavaScript I want to use semicolons) :-)

Thank you for your answers,
bye,
bearophile
May 02 2010
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 So why does D have ; as a statement terminator? The simple answer is
 because D is intended to have a low barrier for entry for C, C++, etc.,
 programmers. The familiar look & feel makes the new language less
 intimidating.<


 
 Note that in Python ending semicolons are optional, if you use them there are
 no errors, I have personally seen several C/Java programmers write Python
 code this way and this causes zero problems: x = 5; print x;
 
 And a C++ programmer scared by the fact that ending semicolons are optional?


Scared probably isn't the right word, though I can see you inferred that from 
"intimidating". I'd just like a C++ programmer to feel right at home using D.



 In JavaScript I want to use semicolons) :-)


You should - the inference bit is just bad.
May 02 2010
prev sibling parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bearophile wrote:

 My personal answer, is that I've written too many semicolons in
 my programming life, I prefer languages where I can avoid semicolons
 at the end of lines (if the language is well designed for this
 and doesn't infer anything. In JavaScript I want to
 use semicolons) :-)


Anybody who's serious about programming needs to learn to touch type.
The semicolon is right there under your little finger and using it takes
far less time than trying to remember arbitrary and arcane rules about
what is the end of a statement.

Actually typing the code & documentation is just a tiny fraction of the
amount of time that I spend programming, but the layout and how it looks
is extremely important. The shape and the spacing of my code allows me
to navigate quickly to what I'm looking for.

This is why I really hate programming in Python, it really annoys me not
being about to lay my code out my way. As far as I'm concerned the
inventor of Python should be beaten to death with a sock full of tab
keys. Making white space significant is the most heinously evil decision
I've ever come across.

(and for the people without a sense of humour: YMMV, put away the socks)

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFL3rpeT9LetA9XoXwRAk5KAJ45/CmyXcyricVD6oqSjkFgiu713QCgrp5l
Q/dH9I/jDoa+jiEksGlNJ3g=
=T5ZE
-----END PGP SIGNATURE-----
May 03 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
div0:


 Anybody who's serious about programming needs to learn to touch type.
 The semicolon is right there under your little finger and using it takes
 far less time than trying to remember arbitrary and arcane rules about
 what is the end of a statement.


In my keyboard it's <SHIFT><COMMA>, and regarding rules...
for (int i; i < 10; i++) <= why is semicolon not accepted in D here? (I know
the answer)
Newlines and semicolons probably have less rules in Python compared to D :-)

Bye,
bearophile
May 03 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 03 May 2010 08:17:17 -0400, bearophile <bearophileHUGS lycos.com>  
wrote:


 div0:


 Anybody who's serious about programming needs to learn to touch type.
 The semicolon is right there under your little finger and using it takes
 far less time than trying to remember arbitrary and arcane rules about
 what is the end of a statement.


 In my keyboard it's <SHIFT><COMMA>, and regarding rules...


What is under your right pinky?  On my keyboard it is semicolon, or colon  
if you use the shift key

If the character on that key is not as important, you may want to swap  
keycodes with the semicolon.

On my keyboard, shift-comma is the < character.  I agree it is used less  
than the semicolon, but it's a pretty common character in D, and I've  
never noticed it to be a burden to use it.


 for (int i; i < 10; i++) <= why is semicolon not accepted in D here? (I  
 know the answer)
 Newlines and semicolons probably have less rules in Python compared to D  
 :-)


That's not the same thing.  Technically, the semicolon is accepted there  
by the grammar.  And as far as I know, that's the only weird rule.

And as far as newlines, there are no rules.  They are considered the same  
as space/tab.  So one rule in D compared to how many in Python?  (I  
honestly don't know, I don't use python)

-Steve
May 03 2010
next sibling parent reply Pelle <pelle.mansson gmail.com> writes:
On 05/03/2010 02:53 PM, Steven Schveighoffer wrote:

 What is under your right pinky? On my keyboard it is semicolon, or colon
 if you use the shift key


On your typical swedish keyboard, it's ö. { is on right_alt+7 or 
something like that.

I recommend, however, to always use the american keyboard layout for 
coding, since it works, well, way better.
May 03 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Pelle wrote:

 On 05/03/2010 02:53 PM, Steven Schveighoffer wrote:

 What is under your right pinky? On my keyboard it is semicolon, or colon
 if you use the shift key


 
 On your typical swedish keyboard, it's ö. { is on right_alt+7 or 
 something like that.
 
 I recommend, however, to always use the american keyboard layout for 
 coding, since it works, well, way better.


Back 20 years ago, there was a lot of talk about how clumsy it was to program C 
on nonstandard keyboards. Hence the development of C's digraphs and alternate 
keywords.

However, experience shows that nobody uses them. At ACCU, I talked to many 
foreigners about how they dealt with language issues. They all said they CODE
IN 
ENGLISH, with english identifier names, comments, etc. The office technical 
talk, though, was in their native tongue.

The upshot of that is:

1. ASCII has won, at least for source code.

2. There's no realistic reason to support anything other than ASCII for source 
code other than string literals and comments, in particular, no reason to 
support the unicode alpha characters in identifiers.

3. There's no realistic reason to avoid using ASCII characters like {.
May 03 2010
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 So one rule in D compared to how many in Python?  (I  
 honestly don't know, I don't use python)


It's hard to answer similar questions in an objective way.
In Python 2.x the line continuation is implicit if you are inside a parenthesis:
print (x +
 5)

Bye,
bearophile
May 03 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 It's hard to answer similar questions in an objective way.
 In Python 2.x the line continuation is implicit if you are inside a
parenthesis:
 print (x +
  5)


The trouble with that, from a language perspective, is what does the grammar 
look like? Since the newline is significant to parsing, it should be a token. 
But inside ( ), there's a problem with it being a token, because now the
grammar 
is messed up by needing to accept an optional newline token in between any
other 
two tokens - but only if inside ( ).

The obvious technical solution is to turn off recognition of newline tokens 
inside of ( ). This is characterized as "smart" parsing, but I have a less kind 
word for it - "hack" - because it means there's not a clean way to separate the 
lexer from the parser, and not a clean way to express the grammar.

 From a language user's perspective this probably doesn't matter, but these 
kinds of things have a way of biting back in unanticipated nasty ways in the 
future. For example, C++'s use of < > for templates is a similar hack in the 
grammar. The C++ committee was warned at the time it was a very bad idea that 
would cause all kinds of problems, but they went ahead anyway because they 
thought it wouldn't affect users.

Turns out it did affect them, and it has caused a lot of grief over the years. 
There's another hack in C++0x in an attempt to paper over the problem.
May 03 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


 This is characterized as "smart" parsing, but I have a less kind 
 word for it - "hack"


That feature is handy, computer languages are designed for humans first.
Python is now almost twenty years old (appeared in 	1991) and in the meantime
that feature has not caused disasters :-)

Bye,
bearophile
May 03 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 Walter Bright:
 

 This is characterized as "smart" parsing, but I have a less kind 
 word for it - "hack"


 
 That feature is handy, computer languages are designed for humans first.
 Python is now almost twenty years old (appeared in 	1991) and in the meantime
that feature has not caused disasters :-)


The problems may or may not be obvious to the user, but they can show up in 
buggy third party tools, and fewer third party tools, that must parse the
source 
code, such as refactorers, IDEs, pretty printers, source code analyzers, etc.
May 03 2010
parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 05/03/2010 01:47 PM, Walter Bright wrote:

 bearophile wrote:

 Walter Bright:


 This is characterized as "smart" parsing, but I have a less kind word
 for it - "hack"


 That feature is handy, computer languages are designed for humans first.
 Python is now almost twenty years old (appeared in 1991) and in the
 meantime that feature has not caused disasters :-)


 The problems may or may not be obvious to the user, but they can show up
 in buggy third party tools, and fewer third party tools, that must parse
 the source code, such as refactorers, IDEs, pretty printers, source code
 analyzers, etc.


Gratuitously ambiguous grammars produce the same effect, only more severely.
May 03 2010
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hrn1vj$ild$1 digitalmars.com...

 bearophile wrote:

 It's hard to answer similar questions in an objective way.
 In Python 2.x the line continuation is implicit if you are inside a 
 parenthesis:
 print (x +
  5)


 The trouble with that, from a language perspective, is what does the 
 grammar look like? Since the newline is significant to parsing, it should 
 be a token. But inside ( ), there's a problem with it being a token, 
 because now the grammar is messed up by needing to accept an optional 
 newline token in between any other two tokens - but only if inside ( ).

 The obvious technical solution is to turn off recognition of newline 
 tokens inside of ( ). This is characterized as "smart" parsing, but I have 
 a less kind word for it - "hack" - because it means there's not a clean 
 way to separate the lexer from the parser, and not a clean way to express 
 the grammar.

 From a language user's perspective this probably doesn't matter, but these 
 kinds of things have a way of biting back in unanticipated nasty ways in 
 the future. For example, C++'s use of < > for templates is a similar hack 
 in the grammar. The C++ committee was warned at the time it was a very bad 
 idea that would cause all kinds of problems, but they went ahead anyway 
 because they thought it wouldn't affect users.

 Turns out it did affect them, and it has caused a lot of grief over the 
 years. There's another hack in C++0x in an attempt to paper over the 
 problem.


Standard C++ design seems to be to paper over problems. That's probably the
May 03 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:

 Standard C++ design seems to be to paper over problems. That's probably the 



C++0x has introduced some new hacks, which I complained about to the committee, 
but got no traction. Whatever, back to D <g>.
May 03 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 In my keyboard it's <SHIFT><COMMA>, and regarding rules...


C is meant for a standard keyboard, there's no question about that.
May 03 2010
parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Walter Bright wrote:

 bearophile wrote:

 In my keyboard it's <SHIFT><COMMA>, and regarding rules...


=20
 C is meant for a standard keyboard, there's no question about that.


	No, C is meant for an American keyboard. Other people have other
standards...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
May 03 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Jérôme M. Berger wrote:

 Walter Bright wrote:

 C is meant for a standard keyboard, there's no question about that.


 
 	No, C is meant for an American keyboard. Other people have other
 standards...


Ok, I should have said US standard keyboard.
May 03 2010
prev sibling next sibling parent Gareth Charnock <gareth.tpc gmail.com> writes:
 As far as I'm concerned the inventor of Python should be beaten to 


death with a sock full of tab

 keys. 


That mental image just made my day! :)
May 03 2010
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
div0 wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 bearophile wrote:

 My personal answer, is that I've written too many semicolons in
 my programming life, I prefer languages where I can avoid semicolons
 at the end of lines (if the language is well designed for this
 and doesn't infer anything. In JavaScript I want to
 use semicolons) :-)


 
 Anybody who's serious about programming needs to learn to touch type.
 The semicolon is right there under your little finger


Depends on your keyboard layout.

  and using it takes

 far less time than trying to remember arbitrary and arcane rules about
 what is the end of a statement.


Arbitrary arcane runes? An end of line or a semicolon are the end of a 
statement.


 
 Actually typing the code & documentation is just a tiny fraction of the
 amount of time that I spend programming, but the layout and how it looks
 is extremely important. The shape and the spacing of my code allows me
 to navigate quickly to what I'm looking for.


The shape of the code looks much better without semicolons and 
parentehesis everywhere.


 
 This is why I really hate programming in Python, it really annoys me not
 being about to lay my code out my way. As far as I'm concerned the
 inventor of Python should be beaten to death with a sock full of tab
 keys. Making white space significant is the most heinously evil decision
 I've ever come across.


You should try Ruby, it doesn't care about tab characters and correct 
indentation.
May 03 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:hrn1bo$hds$1 digitalmars.com...

 div0 wrote:

 This is why I really hate programming in Python, it really annoys me not
 being about to lay my code out my way. As far as I'm concerned the
 inventor of Python should be beaten to death with a sock full of tab
 keys. Making white space significant is the most heinously evil decision
 I've ever come across.


 You should try Ruby, it doesn't care about tab characters and correct 
 indentation.


This sort of goes back to some of the talk in other branches of this thread 
about compilers allowing things to be optional when it can infer them:

There's a webapp project I'm working on for a client that involves a number 
of different Haxe/PHP and Haxe/Flash apps, and a bunch of misc command-line 
tools. I dislike a number of things about Python, and I *hate* makefiles, so 
I used Ruby Rake to handle the build process. I definitely like the freeform 
whitespace (for the same reasons Ary mentioned). But Ruby allows a lot of 
syntax to be omitted in certain cases (more than just semicolons), and 
standard Ruby (and particularly Rake) style seem to take heavy advantage of 
that leniency. The result is, I find the lack of that explicit syntax makes 
it incredibly difficult to visually parse the code properly and be confident 
about what exactly my code says. Which, in turn, makes it that much harder 
to really learn the language, especially by looking at examples.
May 03 2010
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:hrn5p8$ph2$1 digitalmars.com...

 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
 news:hrn1bo$hds$1 digitalmars.com...

 div0 wrote:

 This is why I really hate programming in Python, it really annoys me not
 being about to lay my code out my way. As far as I'm concerned the
 inventor of Python should be beaten to death with a sock full of tab
 keys. Making white space significant is the most heinously evil decision
 I've ever come across.


 You should try Ruby, it doesn't care about tab characters and correct 
 indentation.




...

 I definitely like the freeform whitespace (for the same reasons Ary 
 mentioned).


Errm, div0, rather.
May 03 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Walter Bright Wrote:


 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html
 
 The next dmd update is getting the fruits of this.


Is anyone else having trouble with accessing drdobbs lately? I had to accept
some kind of "unrecognized certificate" in Firefox, and still couldn't access
the website. I get a "connection reset".

Btw, about the semicolon talk:

I think it's possible to get around typing the semicolon, but it would require
some editor customizations. For example, you could define a behavior where a
semicolon gets automatically added at the end of a statement if there is an
extra space at the end of the line. 
Or you could do it vice-versa, where the semicolon gets added automatically at
EOL unless you add a space character before you hit enter. Well, you can
potentially have all kinds of smart editing features really.
May 02 2010
prev sibling next sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-05-01 22:56:42 -0400, Walter Bright <newshound1 digitalmars.com> said:


 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html
 
 The next dmd update is getting the fruits of this.


	test.d(4): Error: undefined identifier wrietln, did you mean template 
writeln(T...)?

It'd be nice if output like that was be a machine readable. This way, 
an editor could display misspelled words with a red underline and you 
could automatically use the suggestion by right-clicking and selecting 
it (just like spell checking in word processing apps, or in Eclipse). 
But to do that you'd need the column coordinates of the word too... too 
bad DMD doesn't track this.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 02 2010
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sun, May 02, 2010 at 08:50:31AM -0400, Michel Fortin wrote:

 	test.d(4): Error: undefined identifier wrietln, did you mean 
 	template writeln(T...)?
 
 It'd be nice if output like that was be a machine readable. This way, 
 an editor could display misspelled words with a red underline and you 
 could automatically use the suggestion by right-clicking and selecting 
 it (just like spell checking in word processing apps, or in Eclipse). 
 But to do that you'd need the column coordinates of the word too... too 
 bad DMD doesn't track this.


You could code up something to do it with the current message. A regexp
along these lines or similar:

undefined identifier ([a-zA-Z0-9_])+, did you mean (.*)?

Then in the given line, do a plain search for $1 and offer to replace it.
Probably not 100% accurate, but I suspect it would be close enough for
most practical purposes.
May 02 2010
prev sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
 But to do that you'd need the column coordinates of the word too... too
 bad DMD doesn't track this.


with or without counting tabs? :-)
May 02 2010
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-05-02 09:57:29 -0400, dennis luehring <dl.soluz gmx.net> said:


 But to do that you'd need the column coordinates of the word too... too
 bad DMD doesn't track this.


 
 with or without counting tabs? :-)


Just count tabs as one character, like clang.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
May 02 2010
prev sibling next sibling parent reply Bernard Helyer <b.helyer gmail.com> writes:
On 02/05/10 14:56, Walter Bright wrote:

 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html

 The next dmd update is getting the fruits of this.


http://www.reddit.com/r/programming/comments/bz6h/improving_compiler_error_messages/

I really enjoyed the article; I submitted it to reddit.
May 02 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bernard Helyer wrote:

 On 02/05/10 14:56, Walter Bright wrote:

 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html

 The next dmd update is getting the fruits of this.


 
 http://www.reddit.com/r/programming/comments/bz6h/improving_comp
ler_error_messages/ 
 
 
 I really enjoyed the article; I submitted it to reddit.


Thank you, but the link doesn't work?
May 02 2010
parent reply Bernard Helyer <b.helyer gmail.com> writes:
On 03/05/10 11:16, Walter Bright wrote:

 Bernard Helyer wrote:

 On 02/05/10 14:56, Walter Bright wrote:

 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html

 The next dmd update is getting the fruits of this.


 http://www.reddit.com/r/programming/comments/bz6h/improving_compiler_error_messages/


 I really enjoyed the article; I submitted it to reddit.


 Thank you, but the link doesn't work?


http://www.reddit.com/r/programming/comments/bz6hm/improving_compiler_error_messages/

Try that.   :o
May 02 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Bernard Helyer wrote:

 On 03/05/10 11:16, Walter Bright wrote:

 Bernard Helyer wrote:

 On 02/05/10 14:56, Walter Bright wrote:

 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html

 The next dmd update is getting the fruits of this.


 http://www.reddit.com/r/programming/comments/bz6h/improving_comp
ler_error_messages/ 



 I really enjoyed the article; I submitted it to reddit.


 Thank you, but the link doesn't work?


 
 http://www.reddit.com/r/programming/comments/bz6hm/improving_comp
ler_error_messages/ 
 
 
 Try that.   :o


That one works, but it does not show up in the "new" listings of the
programming 
subreddit. I wonder what is going on.
May 02 2010
prev sibling next sibling parent reply Marianne Gagnon <auria.mg gmail.com> writes:
 6. propagate error productions
 
 [...]
 
 This can be done in a compiler by replacing every production that produces an
error with an error production (i.e. a NaN) and then propagate them. For
example, for the expression:
 
 z = x + y;
 
  if y is undefined, print the error message about y, then replace y in the
syntax tree with:
 
 z = x + _error_;



This is probably quite nice; I believe GCC does that. There is however one
thing I don't like about the way GCC does that, and I'd like to raise it :

In GCC, let's say I have code above, with "z" being assigned type "error".
If my code contains :

foo(z);
bar(z);
foobar(x, y, z);

then GCC will spew something like :

error: no matching call for foo( type_error )
error: no matching call for bar( type_error )
error: no matching call for foobar( type_error )

I think that if you indeed have as goal to reduce useless cascading error
messages, then it would be great to avoid that; I would tend to say it'd work
to just plain ignore any line using "z" after that, or avoid checking the type
of "z" if we know it's an error. That'd spare lots of useless error messages :)
May 02 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Marianne Gagnon wrote:

 If my code contains :
 
 foo(z); bar(z); foobar(x, y, z);
 
 then GCC will spew something like :
 
 error: no matching call for foo( type_error ) error: no matching call for
 bar( type_error ) error: no matching call for foobar( type_error )
 
 I think that if you indeed have as goal to reduce useless cascading error
 messages, then it would be great to avoid that; I would tend to say it'd work
 to just plain ignore any line using "z" after that, or avoid checking the
 type of "z" if we know it's an error. That'd spare lots of useless error
 messages :)


You're right, gcc has an incomplete implementation of this. The idea is that 
there will be no further error messages if any part of those messages would 
contain the "error" production.

dmd partially does that, and it's definitely the direction we want to push it.
May 02 2010
prev sibling next sibling parent Don <nospam nospam.com> writes:
Walter Bright wrote:

 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html
 
 The next dmd update is getting the fruits of this.


Another benefit which you didn't mention in the article is that turning 
bugs into __error in this way makes the compiler simpler and more robust.

If you follow the strategy of guessing what the programmer intended, and 
  ploughing on, you can end up with some very bizarre nonsensical 
situations, which are otherwise impossible. The compiler has to deal 
with that nasty mess.  But, the way to supress cascading errors is by 
short-circuiting semantic analysis.

At least a dozen of the compiler faults which I have patched were caused 
by this. I think a likely side-effect of these changes will be to fix 
bugs which haven't been discovered yet.
May 03 2010
prev sibling next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 02.05.2010 04:56, schrieb Walter Bright:

 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html

 The next dmd update is getting the fruits of this.


do you think that something like this is also doable to the syntax 
analyse phase - so that parts of the parsed file can be syntax-correct

something like that combined with the json output-feature could help 
alot in developing code-completion,.. etc. in ide-s like descent or visual d
May 04 2010
prev sibling parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
Walter Bright wrote:


 http://www.drdobbs.com/blog/archives/2010/05/improving_compi.html
 
 The next dmd update is getting the fruits of this.


Actually, at this point, the biggest improvement to dmd's error messages 
that I'd like to see is for it to stop complaining about phobos modules when 
I have compile errors. Ideally, the errors would point to the lines in my 
code which are using the phobos code incorrectly rather than complaining 
about the phobos code. This seems to happen most frequently with 
std.algorithm and std.range - at least, that's where I've seen them the 
most, but I use those two module heavily. Regardless however, it would be 
nice if it didn't happen at all.

- Jonathan M Davis
May 11 2010
parent reply Walter bright <Newshound digitalmars.com> writes:
I agree with you and a couple of examples would  be most helpful.
May 12 2010
parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Walter bright wrote:


 I agree with you and a couple of examples would  be most helpful.


Well, unfortunately, I've generally been in enough of a hurry when coding 
that I haven't saved examples of it as I've been coding. I'll have to watch 
out for it more and get small examples from that. However, one example which 
I have would be


import std.algorithm;

void main(string[] args)
{
    auto result = args.find('h');
}


Instead of complaining that I'm using the wrong type with find(), it results 
in the error

/path/to/dmd2/linux/bin/../../src/phobos/std/algorithm.d(1763): Error: no 
property 'empty' for type 'char'


findAmong() and findAmongSorted() do not have the same problem, so I guess 
that they do things differently enough to avoid it.

- Jonathan M Davis
May 16 2010