www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Semicolons: mostly unnecessary?

reply "AJ" <aj nospam.net> writes:
Why not eliminate the requirement for semicolon statement terminators 
(unless there are multiple statements per line)? Less typing is "more"! 
Oct 21 2009
next sibling parent BCS <none anon.com> writes:
Hello aJ,

 Why not eliminate the requirement for semicolon statement terminators
 (unless there are multiple statements per line)? Less typing is
 "more"!
 
For the same reason error correction bits are not removed from transmission lines; that is because the redundancy has some very nice effects when it comes to detecting and dealing with errors. Also, having a language that is whitespace aware has issues and in this cases the upside is to small.
Oct 21 2009
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wed, Oct 21, 2009 at 05:05:04PM -0500, AJ wrote:
 Why not eliminate the requirement for semicolon statement terminators 
 (unless there are multiple statements per line)? Less typing is "more"! 
It looks wrong, breaks habit, opens up bizarre parsing corner cases, and makes error messages uglier. Next thing you know someone will propose eliminating braces and just using whitespace to denote blocks. It's utter madness. -- Adam D. Ruppe http://arsdnet.net
Oct 21 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Why not eliminate the requirement for semicolon statement terminators (unless
there are multiple statements per line)?<
Probably mostly because both some part of D language, some part of the mind of D developers, and some of the D programmers are "old school" and like to do things as they were in the past. I can list you twenty examples of this. Breaking old habits is not easy. ----------------- Adam D. Ruppe:
 It looks wrong,
To me semicolons everywhere look wrong, even if I've programmed enough with languages that require a semicolon at the ends.
 breaks habit,
It breaks a negative habit.
 opens up bizarre parsing corner cases,
 and makes error messages uglier.
I have yet to see a proof of this.
 Next thing you know someone will propose eliminating braces and just
 using whitespace to denote blocks. It's utter madness.
Even "worse", someone may even implement such alternative D syntax, and the sky will fall on your head: http://delight.sourceforge.net/ Bye, bearophile
Oct 21 2009
next sibling parent reply BCS <none anon.com> writes:
Hello bearophile,

 opens up bizarre parsing corner cases,
 and makes error messages uglier.
I have yet to see a proof of this.
Just off hand for parsing issues: - it allows long code lines to be folded - it acts as a bug check on reformat: origonal code MyType t; // result of -t and opSub_r(int) are lvalues auto a = 5 -t = 3 MyType t; auto a = 5 -t = 3 //reformat and forgot to add ';' Oops
Oct 21 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
BCS:

 - it allows long code lines to be folded
This is not a problem, when you have optional semicolons, you add some syntax to fold long lines. Python uses \ Mathematica uses \\ and so on. Languages like Scala, Boo, Genie, etc seem able to survive.
 - it acts as a bug check on reformat:
 
 origonal code
 
 MyType t; // result of -t and opSub_r(int) are lvalues
 auto a = 5
 -t = 3
 
 MyType t;
 auto a = 5     -t = 3   //reformat and forgot to add ';' Oops
I've written enough Python code to fill few books, and this doesn't happen often, something like few times in a year. I think this is one of those things that you have to try for real for few hours in a row to be able to judge them a little. Bye, bearophile
Oct 21 2009
parent reply BCS <none anon.com> writes:
Hello bearophile,

 BCS:
 
 - it allows long code lines to be folded
 
This is not a problem, when you have optional semicolons, you add some syntax to fold long lines. Python uses \ Mathematica uses \\ and so on. Languages like Scala, Boo, Genie, etc seem able to survive.
The only one of those in common use is Python and its not a good date point because of all the other whitespace stuff it does (it's in a category all its own). Also line continuation Is just ugly. (And before you ask, no, I don't think semicolons are ugly)
 - it acts as a bug check on reformat:
 
 origonal code
 
 MyType t; // result of -t and opSub_r(int) are lvalues
 auto a = 5
 -t = 3
 MyType t;
 auto a = 5     -t = 3   //reformat and forgot to add ';' Oops
I've written enough Python code to fill few books, and this doesn't happen often, something like few times in a year. I think this is one of those things that you have to try for real for few hours in a row to be able to judge them a little.
I'll grant the only white space aware languages I've used much are basic (a long time ago) and the C preprocessor. As for CPP the whitespace issues like one bit)
Oct 21 2009
next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Wed, Oct 21, 2009 at 4:07 PM, BCS <none anon.com> wrote:
 Hello bearophile,

 BCS:

 - it allows long code lines to be folded
This is not a problem, when you have optional semicolons, you add some syntax to fold long lines. Python uses \ Mathematica uses \\ and so on. Languages like Scala, Boo, Genie, etc seem able to survive.
The only one of those in common use is Python and its not a good date point because of all the other whitespace stuff it does (it's in a category all its own).
Well, there's Javascript too which is used a fair amount. Walter even wrote a parser for it once, you might have heard him mention it. So I would guess that when he says parsers for languages with optional semi-colons are more complicated, he probably knows what he's talking about. Doesn't mean his word is the final word on the subject*, but it certainly counts more than those of who have not implemented parsers for both varieties of syntax. --bb * He might have just not figured out the trick of it. I know I've written code for things which I thought were devilishly complex only to later see someone else's take on the problem that made all the complexity just melt away.
Oct 21 2009
prev sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
BCS wrote:
 Hello bearophile,
=20
 BCS:

 - it allows long code lines to be folded
This is not a problem, when you have optional semicolons, you add some=
 syntax to fold long lines. Python uses \ Mathematica uses \\ and so
 on. Languages like Scala, Boo, Genie, etc seem able to survive.
=20 The only one of those in common use is Python and its not a good date=20 point because of all the other whitespace stuff it does (it's in a=20 category all its own). =20
Ruby?
 Also line continuation Is just ugly. (And before you ask, no, I don't=20
 think semicolons are ugly)
=20
I think both semicolons and line continuation are ugly. However,=20 when you have mandatory semicolons they are *everywhere*. OTOH line=20 continuations are very rare, especially since in Python they are=20 only needed in case of ambiguity so you can write: some_long_function_name (some_long_argument_name, some_other_long_argument_name) Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Oct 22 2009
parent BCS <none anon.com> writes:
Hello Jérôme,

 BCS wrote:
 
 Hello bearophile,
 
 This is not a problem, when you have optional semicolons, you add
 some syntax to fold long lines. Python uses \ Mathematica uses \\
 and so on. Languages like Scala, Boo, Genie, etc seem able to
 survive.
 
The only one of those in common use is Python and its not a good date point because of all the other whitespace stuff it does (it's in a category all its own).
Ruby?
Wasn't on the list.
Oct 22 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
BCS wrote:
 Hello bearophile,
 
 opens up bizarre parsing corner cases,
 and makes error messages uglier.
I have yet to see a proof of this.
Just off hand for parsing issues: - it allows long code lines to be folded
If you don't have semicolons this is also true, for example a = somefunc( first_param, second_param) b = something_else I can insert a line break there without confusing the parser because the parser is expecting the function call to end
 - it acts as a bug check on reformat:
 
 origonal code
 
 MyType t; // result of -t and opSub_r(int) are lvalues
 auto a = 5
 -t = 3
 
 MyType t;
 auto a = 5     -t = 3   //reformat and forgot to add ';' Oops
Why would the formatter do that? The line break is acting as a semicolon, it won't remove it.
Oct 21 2009
next sibling parent BCS <none anon.com> writes:
Hello Ary,

 BCS wrote:
 
 Hello bearophile,
 
 opens up bizarre parsing corner cases,
 and makes error messages uglier.
I have yet to see a proof of this.
Just off hand for parsing issues: - it allows long code lines to be folded
If you don't have semicolons this is also true, for example a = somefunc( first_param, second_param) b = something_else I can insert a line break there without confusing the parser because the parser is expecting the function call to end
but in some cases this can't be checked. (or needs tons of lookahead)
 - it acts as a bug check on reformat:
 
 origonal code
 
 MyType t; // result of -t and opSub_r(int) are lvalues
 auto a = 5
 -t = 3
 MyType t;
 auto a = 5     -t = 3   //reformat and forgot to add ';' Oops
Why would the formatter do that? The line break is acting as a semicolon, it won't remove it.
I'm not talking about a formatting tool. I'm talking about a person.
Oct 21 2009
prev sibling parent "AJ" <aj nospam.net> writes:
"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:hbo40c$2rdb$1 digitalmars.com...
 BCS wrote:
 Hello bearophile,

 opens up bizarre parsing corner cases,
 and makes error messages uglier.
I have yet to see a proof of this.
Just off hand for parsing issues: - it allows long code lines to be folded
If you don't have semicolons this is also true, for example a = somefunc( first_param, second_param) b = something_else I can insert a line break there without confusing the parser because the parser is expecting the function call to end
I wonder though if that isn't getting "too sophisticated/clever" as opposed to requiring some kind of long-line-continuation-character (?).
Oct 21 2009
prev sibling parent reply language_fan <foo bar.com.invalid> writes:
Wed, 21 Oct 2009 18:29:37 -0400, bearophile thusly wrote:

Why not eliminate the requirement for semicolon statement terminators
(unless there are multiple statements per line)?<
Probably mostly because both some part of D language, some part of the mind of D developers, and some of the D programmers are "old school" and like to do things as they were in the past. I can list you twenty examples of this. Breaking old habits is not easy. ----------------- Adam D. Ruppe:
 It looks wrong,
To me semicolons everywhere look wrong, even if I've programmed enough with languages that require a semicolon at the ends.
 breaks habit,
It breaks a negative habit.
 opens up bizarre parsing corner cases, and makes error messages uglier.
I have yet to see a proof of this.
 Next thing you know someone will propose eliminating braces and just
 using whitespace to denote blocks. It's utter madness.
Even "worse", someone may even implement such alternative D syntax, and the sky will fall on your head: http://delight.sourceforge.net/
Relax, bearophile. It seems there are some things you cannot change in this world. It will not suffice that you prove them wrong. I think I'll just give up on D. The development model is too stagnant. The author (SML) unless someone is kind enough to spend whole day explaining the features to him. That's a sick basis for developing new languages. Large part of the community shares this mindset. The more I think about it, the more I realize this language is not for me. I apologize my arrogance. Bye.
Oct 21 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
language_fan:

 It will not suffice that you prove them wrong.<
Usually I am not able to prove things, I mostly just give suggestions.
The development model is too stagnant.<
D is now quite alive, Andrei seems interested in changing something basic of D every day :-) Bye, bearophile
Oct 21 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
language_fan wrote:
 Relax, bearophile. It seems there are some things you cannot change in 
 this world. It will not suffice that you prove them wrong. I think I'll 
 just give up on D. The development model is too stagnant. The author 

 (SML) unless someone is kind enough to spend whole day explaining the 
 features to him. That's a sick basis for developing new languages. Large 
 part of the community shares this mindset. The more I think about it, the 
 more I realize this language is not for me. I apologize my arrogance. Bye.
Stagnant? Most people complain it is changing too fast!
Oct 21 2009
prev sibling next sibling parent div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

language_fan wrote:
 The more I think about it, the 
 more I realize this language is not for me. I apologize my arrogance. Bye.
That's the best news I've heard since that last tedious whiner buggered off. I really hope it's true. - -- 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/ iD8DBQFK4K0uT9LetA9XoXwRAsd7AKC5ysH+4fp2W52Nrxe19SHl9GkHdgCePRd4 QhapP0if8KxhUTWibfKSeXw= =AaUE -----END PGP SIGNATURE-----
Oct 22 2009
prev sibling parent grauzone <none example.net> writes:
language_fan wrote:
 Wed, 21 Oct 2009 18:29:37 -0400, bearophile thusly wrote:
 
 Why not eliminate the requirement for semicolon statement terminators
 (unless there are multiple statements per line)?<
Probably mostly because both some part of D language, some part of the mind of D developers, and some of the D programmers are "old school" and like to do things as they were in the past. I can list you twenty examples of this. Breaking old habits is not easy. ----------------- Adam D. Ruppe:
 It looks wrong,
To me semicolons everywhere look wrong, even if I've programmed enough with languages that require a semicolon at the ends.
 breaks habit,
It breaks a negative habit.
 opens up bizarre parsing corner cases, and makes error messages uglier.
I have yet to see a proof of this.
 Next thing you know someone will propose eliminating braces and just
 using whitespace to denote blocks. It's utter madness.
Even "worse", someone may even implement such alternative D syntax, and the sky will fall on your head: http://delight.sourceforge.net/
Relax, bearophile. It seems there are some things you cannot change in this world. It will not suffice that you prove them wrong. I think I'll just give up on D. The development model is too stagnant. The author
It was always so slow. D is how old? 10 years now?

 (SML) unless someone is kind enough to spend whole day explaining the 
 features to him. That's a sick basis for developing new languages. Large 
 part of the community shares this mindset. The more I think about it, the 
 more I realize this language is not for me. I apologize my arrogance. Bye.
What language is "for you"?
Oct 22 2009
prev sibling next sibling parent reply "AJ" <aj nospam.net> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.222.1256163114.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 05:05:04PM -0500, AJ wrote:
 Why not eliminate the requirement for semicolon statement terminators
 (unless there are multiple statements per line)? Less typing is "more"!
It looks wrong, breaks habit, opens up bizarre parsing corner cases, and makes error messages uglier. Next thing you know someone will propose eliminating braces and just using whitespace to denote blocks. It's utter madness.
Not "whitespace aware", but rather "newline aware". "Newlines" are already at the end of a line, so a semicolon is redundant. IOW, the default statement terminator can be the newline. struct something { int x1 long x2 } vs. struct something { int x1; long x2; }; First one is definitely "cleaner". The less the eye has to bring in to be deciphered by the brain, the better. void somefunc() Is the above a declaration or start of a definition? Still though, only 1 char of lookahead needed to determine. Maybe one can't fully appreciate semicolon terminators until one tries to implement a language without them. (Because apparently no one has written that article or paper (?)).
Oct 21 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"AJ" <aj nospam.net> wrote in message news:hbo2up$2pb5$1 digitalmars.com...
 "Adam D. Ruppe" <destructionator gmail.com> wrote in message 
 news:mailman.222.1256163114.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 05:05:04PM -0500, AJ wrote:
 Why not eliminate the requirement for semicolon statement terminators
 (unless there are multiple statements per line)? Less typing is "more"!
It looks wrong, breaks habit, opens up bizarre parsing corner cases, and makes error messages uglier. Next thing you know someone will propose eliminating braces and just using whitespace to denote blocks. It's utter madness.
Not "whitespace aware", but rather "newline aware". "Newlines" are already at the end of a line, so a semicolon is redundant. IOW, the default statement terminator can be the newline. struct something { int x1 long x2 } vs. struct something { int x1; long x2; }; First one is definitely "cleaner". The less the eye has to bring in to be deciphered by the brain, the better. void somefunc() Is the above a declaration or start of a definition? Still though, only 1 char of lookahead needed to determine. Maybe one can't fully appreciate semicolon terminators until one tries to implement a language without them. (Because apparently no one has written that article or paper (?)).
I've spent a lot of time with languages that use EOL as a statement terminator (along with the special line-continuation token that approach necessitates), and I've found editing code in those languages to be a royal pain in the ass. Also, referring to your second struct example above, D never has semicolons directly after a closing curly-brace.
Oct 21 2009
parent reply "AJ" <aj nospam.net> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:hbop11$110n$1 digitalmars.com...
 "AJ" <aj nospam.net> wrote in message 
 news:hbo2up$2pb5$1 digitalmars.com...
 "Adam D. Ruppe" <destructionator gmail.com> wrote in message 
 news:mailman.222.1256163114.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 05:05:04PM -0500, AJ wrote:
 Why not eliminate the requirement for semicolon statement terminators
 (unless there are multiple statements per line)? Less typing is "more"!
It looks wrong, breaks habit, opens up bizarre parsing corner cases, and makes error messages uglier. Next thing you know someone will propose eliminating braces and just using whitespace to denote blocks. It's utter madness.
Not "whitespace aware", but rather "newline aware". "Newlines" are already at the end of a line, so a semicolon is redundant. IOW, the default statement terminator can be the newline. struct something { int x1 long x2 } vs. struct something { int x1; long x2; }; First one is definitely "cleaner". The less the eye has to bring in to be deciphered by the brain, the better. void somefunc() Is the above a declaration or start of a definition? Still though, only 1 char of lookahead needed to determine. Maybe one can't fully appreciate semicolon terminators until one tries to implement a language without them. (Because apparently no one has written that article or paper (?)).
I've spent a lot of time with languages that use EOL as a statement terminator (along with the special line-continuation token that approach necessitates),
Which?
 and I've found editing code in those languages to be a royal pain in the 
 ass.
Why?
 Also, referring to your second struct example above, D never has 
 semicolons directly after a closing curly-brace.
Isn't that ironic!
Oct 21 2009
parent "Danny Wilson" <bluezenix gmail.com> writes:
Op Thu, 22 Oct 2009 07:44:44 +0200 schreef AJ <aj nospam.net>:

 Also, referring to your second struct example above, D never has
 semicolons directly after a closing curly-brace.
Isn't that ironic!
Kinda far fetched to call that ironic. The struct decleration was already ended by '}'. I don't end my sentences with ;. either.
Oct 22 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Adam D. Ruppe wrote:
 On Wed, Oct 21, 2009 at 05:05:04PM -0500, AJ wrote:
 Why not eliminate the requirement for semicolon statement terminators 
 (unless there are multiple statements per line)? Less typing is "more"! 
It looks wrong, breaks habit, opens up bizarre parsing corner cases, and makes error messages uglier. Next thing you know someone will propose eliminating braces and just using whitespace to denote blocks. It's utter madness.
Yay, Ruby! (almost) I started to use it some days ago and I feel in love with it.
Oct 21 2009
parent =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Ary Borenszweig wrote:
 Adam D. Ruppe wrote:
 On Wed, Oct 21, 2009 at 05:05:04PM -0500, AJ wrote:
 Why not eliminate the requirement for semicolon statement terminators=
=20
 (unless there are multiple statements per line)? Less typing is "more=
"!=20
 It looks wrong, breaks habit, opens up bizarre parsing corner cases,
 and makes error messages uglier.

 Next thing you know someone will propose eliminating braces and just
 using whitespace to denote blocks. It's utter madness.
=20 Yay, Ruby! (almost) =20 I started to use it some days ago and I feel in love with it.
Well, Python! (no almost about it ;) Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Oct 22 2009
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 21 Oct 2009 18:05:04 -0400, AJ <aj nospam.net> wrote:

 Why not eliminate the requirement for semicolon statement terminators
 (unless there are multiple statements per line)? Less typing is "more"!
It has been said in the past that having semicolons makes parsing easier. I don't know how true this is, but Walter said it, so it probably is pretty important. You also forget about statements that span multiple lines, functions with 15 args are much easier to read when they are separated into multiple lines IMO. To all those guys who want no semicolons: get over it. Use another language if you don't want semicolons. There are some out there. D isn't going to to change one of it's most fundamental constructs because it's "less typing". -Steve
Oct 21 2009
parent reply "AJ" <aj nospam.net> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.u159p8uaeav7ka localhost.localdomain...
 On Wed, 21 Oct 2009 18:05:04 -0400, AJ <aj nospam.net> wrote:

 Why not eliminate the requirement for semicolon statement terminators
 (unless there are multiple statements per line)? Less typing is "more"!
It has been said in the past that having semicolons makes parsing easier. I don't know how true this is, but Walter said it, so it probably is pretty important.
Walter, do you write at all? If so, why not take a breather and write an article about this, given that you have direct experience in addition to opinion on the topic? :)
 You also forget about statements that span multiple lines, functions with 
 15 args are much easier to read when they are separated into multiple 
 lines IMO.
They are the exception though. So it would make more sense to require something for the exceptional case (in this case, a line continuation character) rather than imposing on the common case with semicolons.
 To all those guys who want no semicolons: get over it.
Oh, I thought I was on to something novel!
 Use another  language if you don't want semicolons.  There are some out 
 there.  D isn't  going to to change one of it's most fundamental 
 constructs because it's  "less typing".
Well it's more than "less typing". The biggest boon is time to comprehend (the mind can parse less symbols faster). Semicolons may be like that page that is a photocopy of a photocopy of a photocopy... the result is a page with many extraneous marks having nothing to add to, and even DISTRACTS from, the comprehensibility of the message text on the page. And does EVERY itsy-bitsy thread have to be about D (or D 2009 vs. DDD 2020)? Can't general language design issues be discussed here and be useful/interesting? I wasn't proposing changing D, but rather trying to find the rationale for semicolons (i.e., Would I have chosen that if I was creating a language?).
Oct 21 2009
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wed, Oct 21, 2009 at 06:53:27PM -0500, AJ wrote:
 Well it's more than "less typing". The biggest boon is time to comprehend 
 (the mind can parse less symbols faster).
o rly i find dat xtremly ulikly it seems 2 me dat symbols r actually very useful in figuring out what ends where but hey the mind can parse less symbols faster b/c aj says so so he shouldnt have any problem reading this message at all am i rite And does EVERY itsybitsy thread have to be about D or D 2009 vs DDD 2020 Cant general language design issues be discussed here and be usefulinteresting I wasnt proposing changing D but rather trying to find the rationale for semicolons ie Would I have chosen that if I was creating a language No not at all lots of threads go off topic and they are a lot of fun but it is the default assumption that messages here are about d if you want to just talk general design u should prolly just let us know in the subject or the body of the message somewhere --------- If the point isn't plain obvious from the above, fewer symbols most certainly does NOT mean a language is necessarily easier to parse. Symbols give us a parsing anchor - periods in a sentence aren't strictly necessary - we could put one per line, or just figure out where they belong by parsing the context. But that's fairly obviously much harder than using periods to follow where you are. Semicolons are the same thing. -- Adam D. Ruppe http://arsdnet.net
Oct 21 2009
next sibling parent reply "AJ" <aj nospam.net> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.224.1256169777.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 06:53:27PM -0500, AJ wrote:
 Well it's more than "less typing". The biggest boon is time to comprehend
 (the mind can parse less symbols faster).
o rly i find dat xtremly ulikly it seems 2 me dat symbols r actually very useful in figuring out what ends where but hey the mind can parse less symbols faster b/c aj says so so he shouldnt have any problem reading this message at all am i rite
That's silly. Source code is written mostly one statement per line rather than like text in a book. Shame on you.
 And does EVERY itsybitsy thread have to be about D or D 2009 vs DDD
 2020 Cant general language design issues be discussed here and be
 usefulinteresting I wasnt proposing changing D but rather trying to find
 the rationale for semicolons ie Would I have chosen that if I was
 creating a language

 No not at all lots of threads go off topic and they are a lot of fun but
 it is the default assumption that messages here are about d if you want
 to just talk general design u should prolly just let us know in the 
 subject
 or the body of the message somewhere
Apparently it is NOT off-topic (someone else said: "hey, all you guys who don't want semicolons: find another language or create your own!"). While I wasn't proposing to change D, I wasn't NOT suggesting it, necessarily, for consideration in some version down the line (or what D could maybe morph into).
 ---------

 If the point isn't plain obvious from the above, fewer symbols most 
 certainly
 does NOT mean a language is necessarily easier to parse.
Your "point" isn't, though. Your "point" is like an incorrectly suggested metaphor.
 Symbols
The OP was not about "symbols". It was specifically about semicolons as statement terminators on single-statement lines.
 give us
 a parsing anchor - periods in a sentence aren't strictly necessary - we 
 could
 put one per line, or just figure out where they belong by parsing the 
 context.
 But that's fairly obviously much harder than using periods to follow where
 you are.

 Semicolons are the same thing.
Well, if they were "the same thing", they wouldn't be something else, now would they?
Oct 21 2009
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wed, Oct 21, 2009 at 08:42:31PM -0500, AJ wrote:
	The OP was not about "symbols"
	It was specifically about semicolons as statement terminators on \
	single-statement lines
		Your defending argument was 
			Well its more than less typing
			The biggest boon is time to comprehend the mind can \
			parse less symbols faster
		That argument just doesnt hold water

	 Well, if they were "the same thing", they wouldn't be something else \
	 , now would they?
	 	The point is that symbols serve as both a visual anchor and \
		a parsing anchor for the compiler
		You can quickly scan longer statements for a semicolon ( \
		or a period in prose) to see where it ends
		Periods and semicolons might be different symbols, but \
		they serve exactly the same purpose
		Whitespace simply doesn't do a very good job

-- 
Adam D. Ruppe
http://arsdnet.net
Oct 21 2009
parent reply "AJ" <aj nospam.net> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.227.1256176484.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 08:42:31PM -0500, AJ wrote:
 The OP was not about "symbols"
 It was specifically about semicolons as statement terminators on \
 single-statement lines
 Your defending argument was
 Well its more than less typing
 The biggest boon is time to comprehend the mind can \
 parse less symbols faster
 That argument just doesnt hold water

 Well, if they were "the same thing", they wouldn't be something else \
 , now would they?
 The point is that symbols serve as both a visual anchor and \
 a parsing anchor for the compiler
 You can quickly scan longer statements for a semicolon ( \
 or a period in prose) to see where it ends
 Periods and semicolons might be different symbols, but \
 they serve exactly the same purpose
 Whitespace simply doesn't do a very good job
That's not D source code. Why do you keep trying to use English text as an example? If you're trying to make a case for the use of semicolons as statement terminators on single-statement lines, you're actually destroying your own case! That you say "whitespace" instead of "newline" hurts your argument also.
Oct 21 2009
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English text as an 
 example? 
The logic behind all the arguments you make, except for one, should apply equally well to English as it does to D. Cons: 1. Makes source code less comprehensible. Based on what? Because you say so? I say punctuation makes English less comprehensible, therefore periods should be removed from the language. (See below for a more concrete code example.) 2. Is redundant with the newline designator. This one doesn't actually apply to English, but is obviously false, unless you specifically require a line continuation character: a = b + c If the newline alone could take the semi-colon's job, that would be two statements: a = b+; c; and should raise a compiler error. In the first language with optional colons that comes to mind, Javascript, that isn't a compiler error. It does some magic (parses it and continues if the statement is incomplete) to determine if the newline is indeed a semicolon. A newline and a semicolon are not redundant unless you specifically define a statement as being one and only one line. (One language that actually does this is assembly, and I'm perfectly fine with it there. There are no long assembly instructions that you'd want to spread across lines anyway.) Back to the magic of above though. What if you rewrote it: a = b +c Now what is it? Is it a = b+c;? Or a=b;+c;? a=b; is a perfectly reasonable statement. It isn't terribly difficult to read ahead and see if the next token makes sense as the beginning of a statement, but here's the rub: Suppose I actually meant to write a=b; ++c; but merely made a typo on the second line! Now, the magic rule made my stupid error go completely unnoticed. The compiler accepts it and moves on. That's not cool - hence, the semicolon's job as an anchor telling the compiler what I really meant to catch things like that. 3. Is more typing. So are periods and a lot of vowels. But nobody (sane) argues that we should all start using IM and txt-speak in all writing. The logic fails comparison again. Moreover, how long does it take to type a semicolon anyway? It is a trivial key to hit (on EN-US anyway), and besides, actual typing probably isn't the number one eater of time when coding: it's probably debugging, instead. How much time would you spend tracking down that a=b; ++c; typo in something like javascript? If that happens to you once, your entire career, you just wasted more time than you would ever spend typing semicolons. -- Adam D. Ruppe http://arsdnet.net
Oct 21 2009
next sibling parent reply "AJ" <aj nospam.net> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English text as 
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you specifically define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
    +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
 3. Is more typing.
<snipped inappropriate context reference>>
  how long does it take to type a semicolon anyway?
Typing unnecessary semicolons (if they are unnecessary) is "dumb".
Oct 21 2009
parent reply KennyTM~ <kennytm gmail.com> writes:
On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com>  wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you specifically define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
     +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
 3. Is more typing.
<snipped inappropriate context reference>>
   how long does it take to type a semicolon anyway?
Typing unnecessary semicolons (if they are unnecessary) is "dumb".
Oct 21 2009
parent reply "AJ" <aj nospam.net> writes:
"KennyTM~" <kennytm gmail.com> wrote in message 
news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com>  wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you specifically 
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
     +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not? Whether c is declared as a variable or a function, it still looks wrong to me. A statement can't begin with a +.
 3. Is more typing.
<snipped inappropriate context reference>>
   how long does it take to type a semicolon anyway?
Typing unnecessary semicolons (if they are unnecessary) is "dumb".
Oct 21 2009
parent reply KennyTM~ <kennytm gmail.com> writes:
On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com>  wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com>   wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
      +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);. Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
 3. Is more typing.
<snipped inappropriate context reference>>
    how long does it take to type a semicolon anyway?
Typing unnecessary semicolons (if they are unnecessary) is "dumb".
Oct 22 2009
next sibling parent reply "AJ" <aj nospam.net> writes:
"KennyTM~" <kennytm gmail.com> wrote in message 
news:hbpa89$27si$1 digitalmars.com...
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com>  wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com>   wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English text 
 as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
      +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
I don't think it should.
 Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That's not ambiguous, it's erroneous. The passage means: auto t = s // fine .a = 1 // can't have .a without something on the left of the dot // or else remove the dot
Oct 22 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"AJ" <aj nospam.net> wrote in message news:hbpb1b$29uc$1 digitalmars.com...
 "KennyTM~" <kennytm gmail.com> wrote in message 
 news:hbpa89$27si$1 digitalmars.com...
 OK.

 struct S { int a }
 int a

 void main () {
   S s
   auto t = s
   .a = 1       // ambiguity: Note that .sth means global scope.
 }
That's not ambiguous, it's erroneous. The passage means: auto t = s // fine .a = 1 // can't have .a without something on the left of the dot // or else remove the dot
Wrong. Read the D docs.
Oct 22 2009
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
AJ wrote:
 "KennyTM~" <kennytm gmail.com> wrote in message 
 news:hbpa89$27si$1 digitalmars.com...
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com>  wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com>   wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English text 
 as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
      +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
I don't think it should.
 Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That's not ambiguous, it's erroneous. The passage means: auto t = s // fine .a = 1 // can't have .a without something on the left of the dot // or else remove the dot
In D you use the dot like that to access globals, cf. the comment in KennyTM~s example. -Lars
Oct 22 2009
parent reply "AJ" <aj nospam.net> writes:
"Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
news:hbpcjk$2cl6$1 digitalmars.com...
 AJ wrote:
 "KennyTM~" <kennytm gmail.com> wrote in message 
 news:hbpa89$27si$1 digitalmars.com...
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com>  wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com>   wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English 
 text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
      +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);.
I don't think it should.
 Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That's not ambiguous, it's erroneous. The passage means: auto t = s // fine .a = 1 // can't have .a without something on the left of the dot // or else remove the dot
In D you use the dot like that to access globals, cf. the comment in KennyTM~s example.
So much for attracting C++ users by not making D foreign to them.
Oct 22 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"AJ" <aj nospam.net> wrote in message news:hbqaiq$1fnl$1 digitalmars.com...
 "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> wrote in message 
 news:hbpcjk$2cl6$1 digitalmars.com...
 In D you use the dot like that to access globals, cf. the comment in 
 KennyTM~s example.
So much for attracting C++ users by not making D foreign to them.
You're right. It should have been made exactly like C++, no differences. Making a new language like that wouldn't be pointless at all.
Oct 22 2009
prev sibling parent "Joel C. Salomon" <joelcsalomon gmail.com> writes:
AJ wrote:
 So much for attracting C++ users by not making D foreign to them. 
If you want C++, you know where to find it. —Joel Salomon
Oct 22 2009
prev sibling parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
KennyTM~ wrote:
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com>  wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com>   wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English 
 text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
      +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);. Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That clearly means the global int a is set to one, and the local t has type S.
Oct 22 2009
parent reply KennyTM~ <kennytm gmail.com> writes:
On Oct 22, 09 19:03, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com> wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com> wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English
 text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
 +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);. Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That clearly means the global int a is set to one, and the local t has type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't insert a statement break there.
Oct 22 2009
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
KennyTM~ wrote:
 On Oct 22, 09 19:03, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com> wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com> wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English
 text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
 +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);. Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That clearly means the global int a is set to one, and the local t has type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't insert a statement break there.
But without semicolons the line break becomes the new semicolon. That's what most people here don't understand. There's no ambiguity: if you have a line break and a semicolon would have been good in that place, then that line break becomes the semicolon.
Oct 22 2009
parent reply KennyTM~ <kennytm gmail.com> writes:
On Oct 22, 09 21:12, Ary Borenszweig wrote:
 KennyTM~ wrote:
 On Oct 22, 09 19:03, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com> wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com> wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English
 text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
 +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);. Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That clearly means the global int a is set to one, and the local t has type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't insert a statement break there.
But without semicolons the line break becomes the new semicolon. That's what most people here don't understand. There's no ambiguity: if you have a line break and a semicolon would have been good in that place, then that line break becomes the semicolon.
So auto t = s. a = 1 would now become a syntax error?
Oct 22 2009
parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
KennyTM~ wrote:
 On Oct 22, 09 21:12, Ary Borenszweig wrote:
 KennyTM~ wrote:
 On Oct 22, 09 19:03, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com> wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com> wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English
 text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you 
 specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
 +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);. Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That clearly means the global int a is set to one, and the local t has type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't insert a statement break there.
But without semicolons the line break becomes the new semicolon. That's what most people here don't understand. There's no ambiguity: if you have a line break and a semicolon would have been good in that place, then that line break becomes the semicolon.
So auto t = s. a = 1 would now become a syntax error?
Yes. Do you use this particular style of coding often?
Oct 22 2009
parent reply KennyTM~ <kennytm gmail.com> writes:
On Oct 22, 09 21:36, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 21:12, Ary Borenszweig wrote:
 KennyTM~ wrote:
 On Oct 22, 09 19:03, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com> wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com> wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English
 text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you
 specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
 +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);. Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That clearly means the global int a is set to one, and the local t has type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't insert a statement break there.
But without semicolons the line break becomes the new semicolon. That's what most people here don't understand. There's no ambiguity: if you have a line break and a semicolon would have been good in that place, then that line break becomes the semicolon.
So auto t = s. a = 1 would now become a syntax error?
Yes. Do you use this particular style of coding often?
auto s = "No, but you've just broken " ~ "some other perfectly working " ~ "D codes." writeln(s)
Oct 22 2009
parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
KennyTM~ wrote:
 On Oct 22, 09 21:36, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 21:12, Ary Borenszweig wrote:
 KennyTM~ wrote:
 On Oct 22, 09 19:03, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com> wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com> wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English
 text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you
 specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
 +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);. Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That clearly means the global int a is set to one, and the local t has type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't insert a statement break there.
But without semicolons the line break becomes the new semicolon. That's what most people here don't understand. There's no ambiguity: if you have a line break and a semicolon would have been good in that place, then that line break becomes the semicolon.
So auto t = s. a = 1 would now become a syntax error?
Yes. Do you use this particular style of coding often?
auto s = "No, but you've just broken " ~ "some other perfectly working " ~ "D codes." writeln(s)
Maybe true, but not ambigous.
Oct 22 2009
parent reply KennyTM~ <kennytm gmail.com> writes:
On Oct 22, 09 21:51, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 21:36, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 21:12, Ary Borenszweig wrote:
 KennyTM~ wrote:
 On Oct 22, 09 19:03, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com> wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com> wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use
 English
 text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you
 specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
 +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);. Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That clearly means the global int a is set to one, and the local t has type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't insert a statement break there.
But without semicolons the line break becomes the new semicolon. That's what most people here don't understand. There's no ambiguity: if you have a line break and a semicolon would have been good in that place, then that line break becomes the semicolon.
So auto t = s. a = 1 would now become a syntax error?
Yes. Do you use this particular style of coding often?
auto s = "No, but you've just broken " ~ "some other perfectly working " ~ "D codes." writeln(s)
Maybe true, but not ambigous.
Great, now how should I fix the old D syntax that concatenates over multiple lines? auto s = localizeStr("This won't work because ") ~ localize("the unary ~ is ") // compile error for AJ ~ localize("the bitwise-not operator.") // compile error for AJ Anyway, my point is that, if you want to eliminate the semicolon, you have to change the D syntax and break old code. And if all you need is a re-syntax-ized D with optional semicolon, there is already one here. It's called Delight.
Oct 22 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
KennyTM~:

Please people, let's edit emails a little, so you don't carry around 30 KB of
useless text :-)

 And if all you need is a 
 re-syntax-ized D with optional semicolon, there is already one here. 
 It's called Delight.
annotation: http://stackoverflow.com/questions/461739/f-should-i-learn-with-or-without-light The Vala compiler accepts, with a compilation switch, the Genie code too (Genie for Vala is like Delight for D). No one is using Delight, because it's too far away, it needs an extra install, etc. If DMD will start accepting Delight code too, then some people will probably use such alternative syntax (beside syntax, Delight introduces few other things). Bye, bearophile
Oct 22 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Thu, Oct 22, 2009 at 9:44 AM, bearophile <bearophileHUGS lycos.com> wrote:
 KennyTM~:

 Please people, let's edit emails a little, so you don't carry around 30 KB of
useless text :-)

 And if all you need is a
 re-syntax-ized D with optional semicolon, there is already one here.
 It's called Delight.
annotation: http://stackoverflow.com/questions/461739/f-should-i-learn-with-or-without-light
Actually, the light syntax is the default in the most recent version http://msdn.microsoft.com/en-us/library/dd233199%28VS.100%29.aspx --bb
Oct 22 2009
prev sibling parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
KennyTM~ wrote:
 On Oct 22, 09 19:03, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com> wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com> wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English
 text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
 +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);. Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That clearly means the global int a is set to one, and the local t has type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't insert a statement break there.
Try an editor that shows you where the line breaks are.
Oct 22 2009
parent reply KennyTM~ <kennytm gmail.com> writes:
On Oct 22, 09 21:17, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 19:03, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com> wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com> wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English
 text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
 +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);. Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That clearly means the global int a is set to one, and the local t has type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't insert a statement break there.
Try an editor that shows you where the line breaks are.
By whitespace I mean spaces (U+0020), tabs (U+0009), newlines (U+000A) and other space characters (U+000B, U+000C, U+000D).
Oct 22 2009
parent reply =?UTF-8?B?UGVsbGUgTcOlbnNzb24=?= <pelle.mansson gmail.com> writes:
KennyTM~ wrote:
 On Oct 22, 09 21:17, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 19:03, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com> wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com> wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English
 text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you 
 specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
 +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);. Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That clearly means the global int a is set to one, and the local t has type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't insert a statement break there.
Try an editor that shows you where the line breaks are.
By whitespace I mean spaces (U+0020), tabs (U+0009), newlines (U+000A) and other space characters (U+000B, U+000C, U+000D).
You can obviously not have newlines as whitespace and remove semicolon. That would, as you have demonstrated, not work. I think we all knew that.
Oct 22 2009
parent KennyTM~ <kennytm gmail.com> writes:
On Oct 22, 09 21:35, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 21:17, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 19:03, Pelle MÃ¥nsson wrote:
 KennyTM~ wrote:
 On Oct 22, 09 13:57, AJ wrote:
 "KennyTM~"<kennytm gmail.com> wrote in message
 news:hbopns$125k$1 digitalmars.com...
 On Oct 22, 09 12:29, AJ wrote:
 "Adam D. Ruppe"<destructionator gmail.com> wrote in message
 news:mailman.228.1256181155.20261.digitalmars-d puremagic.com...
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English
 text as
 an
 example?
The logic behind all the arguments you make,
That would be "all fine and dandy", but I'm not arguing about anything. (So you must be arguing? About what?).
 except for one, should apply
 equally well to English as it does to D.
That's silly. There is no need to use the text of Shakespeare's tragedies to allude to source code. There is no need and it is entirely inappropriate to expand the context of the issue to other realms. The context is (currently): semicolons as statement terminators for single-statement lines.
 Cons:

 1. Makes source code less comprehensible.

 Based on what? Because you say so?
It's more to digest when it's not necessary. It's easier to identify something when it's in less intricate (read, plain) surroundings. <snipped inappropriate context reference>
 2. Is redundant with the newline designator.
<snipped inappropriate context reference>
 is obviously false,
If I put it on the list, it wasn't obvious at all, even if it is incorrect (though I think it is correct).
 unless
 you specifically require a line continuation character:

 a = b +
 c
Without semicolon requirement: a=b+ // this is an error c // this is OK With semicolon requirement: a=b+; // this is an error c; // this is OK What's the diff?
 A newline and a semicolon are not redundant unless you
 specifically
 define
 a statement as being one and only one line.
A semicolon is redundate with newline for single-statement lines. Oh, you say that a lot of constructs are inherently single statements but written on multiple lines? Well, that may be just the kind of examination I was looking for (ironic that _I_ had to bring it up, huh): if(true) dothis() That situation has to be evaluated: is parsing at the construct level too much effort or is it desireable? (ParseIfStatement()). Statement-level parsing better/worse than line-level parsing?
 Back to the magic of above though. What if you rewrote it:
 a = b
 +c
Without semicolon requirement: a=b // OK +c // error With semicolon requirement: a=b; // OK +c; // error What's the diff?
a=b +c(d) // no error
Why not?
Good question. Because the compiler accepts a=b;+c(d);. Whether c is declared as a variable or a function, it still looks
 wrong to me. A statement can't begin with a +.
OK. struct S { int a } int a void main () { S s auto t = s .a = 1 // ambiguity: Note that .sth means global scope. }
That clearly means the global int a is set to one, and the local t has type S.
No, s(lots of whitespace).a is a valid expression. You shouldn't insert a statement break there.
Try an editor that shows you where the line breaks are.
By whitespace I mean spaces (U+0020), tabs (U+0009), newlines (U+000A) and other space characters (U+000B, U+000C, U+000D).
You can obviously not have newlines as whitespace and remove semicolon. That would, as you have demonstrated, not work. I think we all knew that.
I meant s\n\n\n.a is a valid expression in the current D syntax. Sorry my context is not clear enough.
Oct 22 2009
prev sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Adam D. Ruppe wrote:
 On Wed, Oct 21, 2009 at 09:25:34PM -0500, AJ wrote:
 That's not D source code. Why do you keep trying to use English text a=
s an=20
 example?=20
=20 The logic behind all the arguments you make, except for one, should app=
ly
 equally well to English as it does to D.
=20
  Cons:
=20
  1. Makes source code less comprehensible.
=20
 Based on what? Because you say so? I say punctuation makes English less=
 comprehensible, therefore periods should be removed from the language.
=20
 (See below for a more concrete code example.)
=20
OTOH: Based; on; what? Because; you; say; so? I; say; punctuation;=20 makes; English; less; comprehensible, therefore; periods; should;=20 be; removed; from; the; language. Oh, yeah that's readable!
=20
  2. Is redundant with the newline designator.
=20
 This one doesn't actually apply to English, but is obviously false, unl=
ess
 you specifically require a line continuation character:
=20
 	a =3D b +
 	c
=20
 If the newline alone could take the semi-colon's job, that would be two=
 statements: a =3D b+; c; and should raise a compiler error.
=20
It's an error in Python.
=20
 Back to the magic of above though. What if you rewrote it:
 	a =3D b
 	   +c
=20
 Now what is it? Is it a =3D b+c;? Or a=3Db;+c;? a=3Db; is a perfectly r=
easonable
 statement.
=20
Again, that's an error (because Python uses indentation for=20 blocks). The following however is correct: a =3D b +c and is equivalent to a=3Db;+c;
  3. Is more typing.
=20
 So are periods and a lot of vowels. But nobody (sane) argues that we sh=
ould
 all start using IM and txt-speak in all writing. The logic fails compar=
ison
 again.
=20
OTOH, nobody sane argues that we should add extra punctuation=20 between words when there is already a space. So *your* logic fails=20 comparison too... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Oct 22 2009
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thu, Oct 22, 2009 at 08:33:44PM +0200, "Jérôme M. Berger" wrote:
 	OTOH, nobody sane argues that we should add extra punctuation 
 between words when there is already a space. So *your* logic fails 
 comparison too...
The difference is that a semicolon in D isn't analogous to a space at all. It is, however, directly analogous to a period in English; indeed, even to a semicolon. A period separates one statement from the next, just like D's semicolon. Spaces separate individual components of it - words in English, variable names in D. The next level up is the paragraph, which is analogous to the braced block in code. -- Adam D. Ruppe http://arsdnet.net
Oct 22 2009
parent =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Adam D. Ruppe wrote:
 On Thu, Oct 22, 2009 at 08:33:44PM +0200, "J=E9r=F4me M. Berger" wrote:=
 	OTOH, nobody sane argues that we should add extra punctuation=20
 between words when there is already a space. So *your* logic fails=20
 comparison too...
=20 The difference is that a semicolon in D isn't analogous to a space at a=
ll.
 It is, however, directly analogous to a period in English; indeed, even=
to
 a semicolon.
=20
 A period separates one statement from the next, just like D's semicolon=
=2E
 Spaces separate individual components of it - words in English, variabl=
e
 names in D.
=20
The difference is that there is rarely more than one statement per=20 line in D, whereas it is common in English to have sentence endings=20 in the middle of a line. Nobody said that you could do without any separation between=20 statements, but when there already is a clear separation then adding=20 an extra punctuation is just visual noise.
 The next level up is the paragraph, which is analogous to the braced bl=
ock
 in code.
=20
Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Oct 22 2009
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 21 Oct 2009 21:42:31 -0400, AJ <aj nospam.net> wrote:

 Apparently it is NOT off-topic (someone else said: "hey, all you guys who
 don't want semicolons: find another language or create your own!").  
 While I
 wasn't proposing to change D, I wasn't NOT suggesting it, necessarily,  
 for
 consideration in some version down the line (or what D could maybe morph
 into).
Your suggestion that you were not proposing to change the D language is either supremely misleading, or flat out lying. The original post said "Why not eliminate the requirement for semicolon statement terminators." If you didn't mean D, then what the hell are you talking about? And why on the D newsgroup? This is a very very old argument. It's been argued about 5 times on this newsgroup alone. And one more time isn't going to change anyone's mind. Find another topic. -Steve
Oct 21 2009
parent reply "AJ" <aj nospam.net> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.u16ild2leav7ka localhost.localdomain...
 On Wed, 21 Oct 2009 21:42:31 -0400, AJ <aj nospam.net> wrote:

 Apparently it is NOT off-topic (someone else said: "hey, all you guys who
 don't want semicolons: find another language or create your own!"). 
 While I
 wasn't proposing to change D, I wasn't NOT suggesting it, necessarily, 
 for
 consideration in some version down the line (or what D could maybe morph
 into).
Your suggestion that you were not proposing to change the D language is either supremely misleading,
Twas not intended to be. Perhaps just YOU feel it is?
 or flat out lying.
Believe me, I have better things to do than try to change someone else's programming language. I just want to know "the answer".
 The original post said "Why not eliminate the requirement for semicolon 
 statement terminators."  If you didn't mean D, then what the hell are you 
 talking about?
I could have almost equivalently said: "Why does D require semicolons as statement terminators on single-statement lines?". Obviously I'm thinking that the semicolon used as noted may very well be redundant. I just wanted "proof" one way or the other.
 And why on the D newsgroup?
D is promoted as "a better C++" and a "better" language along the lines of such "stylistics", and is (seemingly) under continuous development/rethinking (much more so than, say, C++). So what better group than the D ng?!
 This is a very very old argument.  It's been argued about 5 times on this 
 newsgroup alone.
I had no idea! How long ago? I'll go back and read the threads and with even more interest now. I assumed that the semicolon, used as noted, was just carry-over from C/C++ rather than a re-evaluated and adopted-by-D thing.
 And one more time isn't going to change anyone's mind.
Well I wasn't trying to change anything. I just want to know and decide for myself.
 Find another topic.
Maybe you shouldn't read threads you are not interested in? In that regard, find another thread. :P
Oct 21 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 21 Oct 2009 22:46:37 -0400, AJ <aj nospam.net> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.u16ild2leav7ka localhost.localdomain...
 On Wed, 21 Oct 2009 21:42:31 -0400, AJ <aj nospam.net> wrote:

 Apparently it is NOT off-topic (someone else said: "hey, all you guys  
 who
 don't want semicolons: find another language or create your own!").
 While I
 wasn't proposing to change D, I wasn't NOT suggesting it, necessarily,
 for
 consideration in some version down the line (or what D could maybe  
 morph
 into).
Your suggestion that you were not proposing to change the D language is either supremely misleading, or flat out lying. The original post said "Why not eliminate the requirement for semicolon statement terminators." If you didn't mean D, then what the hell are you talking about?
I could have almost equivalently said: "Why does D require semicolons as statement terminators on single-statement lines?". Obviously I'm thinking that the semicolon used as noted may very well be redundant. I just wanted "proof" one way or the other.
So misleading then. The "equivalent" statement implies much less action than your original statement. We have fallen victim to some English subtleties it appears.
 This is a very very old argument.  It's been argued about 5 times on  
 this
 newsgroup alone.
I had no idea! How long ago? I'll go back and read the threads and with even more interest now. I assumed that the semicolon, used as noted, was just carry-over from C/C++ rather than a re-evaluated and adopted-by-D thing.
search for semicolon, I'm sure you'll find stuff.
 Find another topic.
Maybe you shouldn't read threads you are not interested in? In that regard, find another thread. :P
I'm just trying to save you time and effort. If you want to argue tired old arguments, then why not start a thread on how emacs is tons better than vi? You'd get the same effect. In other words, my statement was a tip, not an attack ;) -Steve
Oct 21 2009
parent reply "AJ" <aj nospam.net> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.u16lelraeav7ka localhost.localdomain...
 On Wed, 21 Oct 2009 22:46:37 -0400, AJ <aj nospam.net> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.u16ild2leav7ka localhost.localdomain...
 On Wed, 21 Oct 2009 21:42:31 -0400, AJ <aj nospam.net> wrote:

 Apparently it is NOT off-topic (someone else said: "hey, all you guys 
 who
 don't want semicolons: find another language or create your own!").
 While I
 wasn't proposing to change D, I wasn't NOT suggesting it, necessarily,
 for
 consideration in some version down the line (or what D could maybe 
 morph
 into).
Your suggestion that you were not proposing to change the D language is either supremely misleading, or flat out lying. The original post said "Why not eliminate the requirement for semicolon statement terminators." If you didn't mean D, then what the hell are you talking about?
I could have almost equivalently said: "Why does D require semicolons as statement terminators on single-statement lines?". Obviously I'm thinking that the semicolon used as noted may very well be redundant. I just wanted "proof" one way or the other.
So misleading then.
No, not misleading: you misinterpreted and made eroneous assumption. Obviously I am thinking that it's just carryover artifact from C++. But I may be thinking that with too little information (I've never implemented a language with or without semicolon statement terminators), so I was asking "Why?".
 The "equivalent" statement implies much less action  than your original 
 statement.
Neither imply any action. If you want to misinterpret it that way, that's up to you. Both simply ask "Why?".
 We have fallen victim to some English  subtleties it appears.
You are the only victim here: You are a victim of your own assumptions.
 This is a very very old argument.  It's been argued about 5 times on 
 this
 newsgroup alone.
I had no idea! How long ago? I'll go back and read the threads and with even more interest now. I assumed that the semicolon, used as noted, was just carry-over from C/C++ rather than a re-evaluated and adopted-by-D thing.
search for semicolon, I'm sure you'll find stuff.
I will!
 Find another topic.
Maybe you shouldn't read threads you are not interested in? In that regard, find another thread. :P
I'm just trying to save you time and effort.
Uh huh.
 If you want to argue tired  old arguments,
Oh, you were arguing? About what? I just asked "Why?".
 then why not start a thread on how emacs is tons better  than vi?
Start your own thread if you just want to argue. I'm looking for answers.
 You'd get the same effect.  In other words, my statement was a  tip, not 
 an attack ;)
Bullshit. You meant it as "an order" and you know it. :P
Oct 21 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 21 Oct 2009 23:54:40 -0400, AJ <aj nospam.net> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.u16lelraeav7ka localhost.localdomain...
 On Wed, 21 Oct 2009 22:46:37 -0400, AJ <aj nospam.net> wrote:
 If you want to argue tired  old arguments,
Oh, you were arguing? About what? I just asked "Why?".
And I answered. And you seemed to continue "not arguing." I guess we have a fundamental disconnect on what you want, so I guess I'll stop posting on this thread in order to save time and effort of my own :P I'll just re-answer the question in the same manner I would to a child who continually asks "why": Because.
 In other words, my statement was a  tip, not
 an attack ;)
Bullshit. You meant it as "an order" and you know it. :P
Now who's misinterpreting? ;) -Steve
Oct 21 2009
parent "AJ" <aj nospam.net> writes:
"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:op.u16piilgeav7ka localhost.localdomain...
 On Wed, 21 Oct 2009 23:54:40 -0400, AJ <aj nospam.net> wrote:

 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message
 news:op.u16lelraeav7ka localhost.localdomain...
 On Wed, 21 Oct 2009 22:46:37 -0400, AJ <aj nospam.net> wrote:
 If you want to argue tired  old arguments,
Oh, you were arguing? About what? I just asked "Why?".
And I answered.
No you didn't. If you would have given an answer, then I would still have a question.
 And you seemed to continue "not arguing."  I guess we  have a fundamental 
 disconnect on what you want, so I guess I'll stop  posting on this thread 
 in order to save time and effort of my own :P
Thanks.
 I'll just re-answer the question in the same manner I would to a child who 
 continually asks "why": Because.
OK, I'll try and let you know I decide (if it's yay or nay) on the semicolon thing (it may be awhile if I have to figure it out by implementing a language rather than just research the documented knowledge/opinions of others though, so don't hold your breath).
 In other words, my statement was a  tip, not
 an attack ;)
Bullshit. You meant it as "an order" and you know it. :P
Now who's misinterpreting? ;)
You the opportunist thinking everyone is fooled by your antics.
Oct 21 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Adam D. Ruppe wrote:

Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly
doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
aparsinganchorperiodsinasentencearentstrictlynecessarywecould
putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
youareSemicolonsarethesamething

(Fixed that for you!)
Oct 22 2009
next sibling parent "AJ" <aj nospam.net> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hbp2lc$1m2a$2 digitalmars.com...
 Adam D. Ruppe wrote:

 Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething

 (Fixed that for you!)
Ah, going from well-defined specific context to other, irrelevant context. Who do you think you are fooling?
Oct 22 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 Adam D. Ruppe wrote:
 
 Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething
 
 (Fixed that for you!)
Having no spaces is not comparable to having no semicolons, because newlines are kept. Better to have a little more complex parser than putting the burden of adding the correct semicolons on the programmers. Bye, bearophile
Oct 22 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hbp5qa$1teh$1 digitalmars.com...
 Walter Bright:

 Adam D. Ruppe wrote:

 Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething

 (Fixed that for you!)
Having no spaces is not comparable to having no semicolons, because newlines are kept. Better to have a little more complex parser than putting the burden of adding the correct semicolons on the programmers.
I'm already kicking myself for trying to jump into the middle of yet another semicolon debate, but..."burden" of semicolons? Isn't that a bit overstated? I suppose it depends on the person, but I find it to be every bit as automatic as reaching for the Shift key when I write camelcase, or hitting enter for a new line, or going for control when I want to arrow around a word-at-a-time. And those are hardly burdens (and sure, technically a semicolon plus newline is more than *just* newline, but only negligibly so). Line-continuation operators, on the other hand, or complex rules for when a semicolon is or isn't required (along with the resulting inconsistency of some things having semicolons and other things not), do tend to noticeably get in my way.
Oct 22 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

 I'm already kicking myself for trying to jump into the middle of yet another 
 semicolon debate, but..."burden" of semicolons? Isn't that a bit overstated? 
 I suppose it depends on the person, but I find it to be every bit as 
 automatic as reaching for the Shift key when I write camelcase, or hitting 
 enter for a new line, or going for control when I want to arrow around a 
 word-at-a-time. And those are hardly burdens (and sure, technically a 
 semicolon plus newline is more than *just* newline, but only negligibly so).
Yes, you are right, adding the semicolon doesn't take a lot of time, but when you miss it, the program doesn't compile, and you have to find where you have missed it, sometimes this requires some time. And I've seen plenty of newbie programmers that think "the computer" is idiot and fussy for asking them to put such useless semicolons. I guess this is not a strong argument because newbie programmers will probably not want to start with D as first language :-) Bye, bearophile
Oct 22 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 22/10/2009 12:58, bearophile wrote:
 Nick Sabalausky:

 I'm already kicking myself for trying to jump into the middle of yet another
 semicolon debate, but..."burden" of semicolons? Isn't that a bit overstated?
 I suppose it depends on the person, but I find it to be every bit as
 automatic as reaching for the Shift key when I write camelcase, or hitting
 enter for a new line, or going for control when I want to arrow around a
 word-at-a-time. And those are hardly burdens (and sure, technically a
 semicolon plus newline is more than *just* newline, but only negligibly so).
Yes, you are right, adding the semicolon doesn't take a lot of time, but when you miss it, the program doesn't compile, and you have to find where you have missed it, sometimes this requires some time. And I've seen plenty of newbie programmers that think "the computer" is idiot and fussy for asking them to put such useless semicolons. I guess this is not a strong argument because newbie programmers will probably not want to start with D as first language :-) Bye, bearophile
Let's bring another language into the mix: Pascal uses periods as the statement separator but it's only required between two statements. something like begin statementA. statementB. statementC end notice how there's no period after statementC. This was considered at the time as confusing and people preferred c style semicolons because they are consistently everywhere so you don't need to think "do I need to put it here or not" The trade-off here is obvious: if you use line continuations like in python they would be very rare but would not be automatic and consistent when you do need to use them. I personally prefer to have semicolons.
Oct 23 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Yigal Chripun:

 The trade-off here is obvious: if you use line continuations like in 
 python they would be very rare but would not be automatic and consistent 
 when you do need to use them.
In my Python code (or in good code you may find around, like in some modules of the std library) you may have a hard time finding few line continuations. Generally you can avoid them putting code in parentheses. And if/when you want to use them it's simple. So I think you are wrong. Bye, bearophile
Oct 23 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 23/10/2009 19:41, bearophile wrote:
 Yigal Chripun:

 The trade-off here is obvious: if you use line continuations like
 in python they would be very rare but would not be automatic and
 consistent when you do need to use them.
In my Python code (or in good code you may find around, like in some modules of the std library) you may have a hard time finding few line continuations. Generally you can avoid them putting code in parentheses. And if/when you want to use them it's simple. So I think you are wrong. Bye, bearophile
Nothing you said contradicts what I said. The fact that they are rare in python means that you need to think if and when you need to use them whereas in c/c++/d/etc you use semicolons consistently throughout the code so adding them is an automatic action that requires no thought. here's an analogy: there's a speed limit set by law inside cities so any driver with little experience will automatically slow down when entering a city. that speed limit becomes an automatic habit you don't need to think about. however when you see a sign with a different speed limit you do need to process that info in the brain and conscientiously change your speed.
Oct 23 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Fri, Oct 23, 2009 at 4:54 PM, Yigal Chripun <yigal100 gmail.com> wrote:
 On 23/10/2009 19:41, bearophile wrote:
 Yigal Chripun:

 The trade-off here is obvious: if you use line continuations like
 in python they would be very rare but would not be automatic and
 consistent when you do need to use them.
In my Python code (or in good code you may find around, like in some modules of the std library) you may have a hard time finding few line continuations. Generally you can avoid them putting code in parentheses. And if/when you want to use them it's simple. So I think you are wrong. Bye, bearophile
Nothing you said contradicts what I said. The fact that they are rare in python means that you need to think if and when you need to use them whereas in c/c++/d/etc you use semicolons consistently throughout the code so adding them is an automatic action that requires no thought.
You don't really have to keep it much in mind. Either your editor will tell you you've done something wrong by indenting things in an unexpected way, or if not, the parser will tell you when it does its pass to byte-compile the source.
 here's an analogy:
 there's a speed limit set by law inside cities so any driver with little
 experience will automatically slow down when entering a city. that speed
 limit becomes an automatic habit you don't need to think about.
 however when you see a sign with a different speed limit you do need to
 process that info in the brain and conscientiously change your speed.
Think of the code editor / byte-compilation engine as the buddy in the passenger seat telling you to slow down. Its not a problem when you have such a buddy. --bb
Oct 23 2009
parent Yigal Chripun <yigal100 gmail.com> writes:
On 24/10/2009 02:29, Bill Baxter wrote:
 On Fri, Oct 23, 2009 at 4:54 PM, Yigal Chripun<yigal100 gmail.com>  wrote:
 On 23/10/2009 19:41, bearophile wrote:
 Yigal Chripun:

 The trade-off here is obvious: if you use line continuations like
 in python they would be very rare but would not be automatic and
 consistent when you do need to use them.
In my Python code (or in good code you may find around, like in some modules of the std library) you may have a hard time finding few line continuations. Generally you can avoid them putting code in parentheses. And if/when you want to use them it's simple. So I think you are wrong. Bye, bearophile
Nothing you said contradicts what I said. The fact that they are rare in python means that you need to think if and when you need to use them whereas in c/c++/d/etc you use semicolons consistently throughout the code so adding them is an automatic action that requires no thought.
You don't really have to keep it much in mind. Either your editor will tell you you've done something wrong by indenting things in an unexpected way, or if not, the parser will tell you when it does its pass to byte-compile the source.
 here's an analogy:
 there's a speed limit set by law inside cities so any driver with little
 experience will automatically slow down when entering a city. that speed
 limit becomes an automatic habit you don't need to think about.
 however when you see a sign with a different speed limit you do need to
 process that info in the brain and conscientiously change your speed.
Think of the code editor / byte-compilation engine as the buddy in the passenger seat telling you to slow down. Its not a problem when you have such a buddy. --bb
I didn't say it's a big problem. My only point was that one is performed unconsciously whereas the other is performed consciously. I don't care to continue the semicolon debate. I don't think one is inherently better than the other. I have my own preference here but that all it is - a *personal* preference, not a god given rule. ==== If we are at the topic of language syntax: Have you ever heard of MPS by Jetbrains? MPS (meta programming system) is a tool to design your own language complete with an IDE, and everything else you get for a modern language. The way MPS is implemented is interesting since they do away completely with working with text, parsing and lexing. the language is defined directly at the AST level - as nodes with rules and types. the editor is a structural editor that allows you to fill cells according to the defined nodes. it's analogous to an XML editor where you define an xsd (node structure and their types/semantics) and the editor allows you to manipulate the tree structure directly. the structure is always well defined by the tree structure and there's no need to have statement separators or line continuations.
Oct 24 2009
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thu, Oct 22, 2009 at 12:46:50AM -0700, Walter Bright wrote:
 (Fixed that for you!)
hehehe :) -- Adam D. Ruppe http://arsdnet.net
Oct 22 2009
prev sibling next sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Walter Bright wrote:
 Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething
And how it that any better: If;the;point;isnt;plain;obvious;from;the;above;fewer;symbols;most;certain= ly; does;NOT;mean;a;language;is;necessarily;easier;to;parse;Symbols;give;us; a;parsing;anchor;periods;in;a;sentence;arent;strictly;necessary;we;could;= put;one;per;line;or;just;figure;out;where;they;belong;by;parsing;the;cont= ext; But;thats;fairly;obviously;much;harder;than;using;periods;to;follow;where= ; you;are;Semicolons;are;the;same;thing; Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Oct 22 2009
next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Thu, 22 Oct 2009 22:43:13 +0400, J=C3=A9r=C3=B4me M. Berger <jeberger=
 free.fr>  =

wrote:

 Walter Bright wrote:
 Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething
And how it that any better: If;the;point;isnt;plain;obvious;from;the;above;fewer;symbols;most;cert=
ainly;
 does;NOT;mean;a;language;is;necessarily;easier;to;parse;Symbols;give;u=
s;
 a;parsing;anchor;periods;in;a;sentence;arent;strictly;necessary;we;cou=
ld;
 put;one;per;line;or;just;figure;out;where;they;belong;by;parsing;the;c=
ontext;
 But;thats;fairly;obviously;much;harder;than;using;periods;to;follow;wh=
ere;
 you;are;Semicolons;are;the;same;thing;

 		Jerome
FWIW, it's *much* easier to read (but I don't know how relevant it is to= = the discussion)
Oct 22 2009
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Denis Koroskin wrote:
 On Thu, 22 Oct 2009 22:43:13 +0400, J=C3=A9r=C3=B4me M. Berger <jeberge=
r free.fr>=20
 wrote:
=20
 Walter Bright wrote:
 Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething
And how it that any better: If;the;point;isnt;plain;obvious;from;the;above;fewer;symbols;most;cert=
ainly;=20
 does;NOT;mean;a;language;is;necessarily;easier;to;parse;Symbols;give;u=
s;
 a;parsing;anchor;periods;in;a;sentence;arent;strictly;necessary;we;cou=
ld;
 put;one;per;line;or;just;figure;out;where;they;belong;by;parsing;the;c=
ontext;=20
 But;thats;fairly;obviously;much;harder;than;using;periods;to;follow;wh=
ere;=20
 you;are;Semicolons;are;the;same;thing;

         Jerome
=20 FWIW, it's *much* easier to read
Easier than Walter's? Probably, but don't tell me that it's easier=20 than how it should be written (with spaces and no semicolons).
 (but I don't know how relevant it is to the discussion)
About as much as Walter's example. The question is: "Does putting=20 semicolons between statements when there is already a space there=20 improve or impede readability?". Walter's example shows that removing all separation is bad but=20 nobody was suggesting doing that. My example shows that putting=20 semicolons everywhere is bad too. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Oct 22 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jérôme M. Berger wrote:
 Walter Bright wrote:
 Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething
And how it that any better: If;the;point;isnt;plain;obvious;from;the;above;fewer;symbols;most;certainly; does;NOT;mean;a;language;is;necessarily;easier;to;parse;Symbols;give;us; a;parsing;anchor;periods;in;a;sentence;arent;strictly;necessary;we;could; put;one;per;line;or;just;figure;out;where;they;belong;by;parsing;the;context; But;thats;fairly;obviously;much;harder;than;using;periods;to;follow;where; you;are;Semicolons;are;the;same;thing;
I can read the ; version several times faster than the first.
Oct 22 2009
parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Walter Bright wrote:
 J=E9r=F4me M. Berger wrote:
 Walter Bright wrote:
 Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething
And how it that any better: If;the;point;isnt;plain;obvious;from;the;above;fewer;symbols;most;cert=
ainly;=20
 does;NOT;mean;a;language;is;necessarily;easier;to;parse;Symbols;give;u=
s;
 a;parsing;anchor;periods;in;a;sentence;arent;strictly;necessary;we;cou=
ld;
 put;one;per;line;or;just;figure;out;where;they;belong;by;parsing;the;c=
ontext;=20
 But;thats;fairly;obviously;much;harder;than;using;periods;to;follow;wh=
ere;=20
 you;are;Semicolons;are;the;same;thing;
=20 I can read the ; version several times faster than the first.
And what about the spaces version? After all, nobody suggested=20 removing *all* separation between statements like you did, just=20 *redundant* separation. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Oct 22 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jérôme M. Berger wrote:
     And what about the spaces version? After all, nobody suggested 
 removing *all* separation between statements like you did, just 
 *redundant* separation.
The spaces and punctuation were quite redundant in the message. I doubt it would be difficult to write a program that would take that and insert all the spaces and punctuation. I'm not much of a written language historian, but paragraphs, spaces, punctuation, and case were all invented to improve readability. Very old written languages have none of them, they're just a wall of letters. Punctuation and whitespace are in programming languages to improve readability and reduce errors (some of these choices make the languages harder to parse, but are worthwhile because they make it easier for humans to parse).
Oct 22 2009
parent "AJ" <aj nospam.net> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hbqkoo$28pt$1 digitalmars.com...
 Jérôme M. Berger wrote:
     And what about the spaces version? After all, nobody suggested 
 removing *all* separation between statements like you did, just 
 *redundant* separation.
The spaces and punctuation were quite redundant in the message. I doubt it would be difficult to write a program that would take that and insert all the spaces and punctuation. I'm not much of a written language historian, but paragraphs, spaces, punctuation, and case were all invented to improve readability. Very old written languages have none of them, they're just a wall of letters. Punctuation and whitespace are in programming languages to improve readability and reduce errors (some of these choices make the languages harder to parse, but are worthwhile because they make it easier for humans to parse).
Which, of course, has absolutely nothing to do with semicolons at the end of a line of program code.
Oct 22 2009
prev sibling parent reply bambo <ba m.bo> writes:
Walter Bright schrieb:
 Adam D. Ruppe wrote:
 
 Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething
 
 (Fixed that for you!)
Walter, what a remarkable proove the semicolon helps us all a lot! You are sooooo BRIGHT! You are so creative and intelligent! I LOVE YOU!
Oct 22 2009
parent reply Max Samukha <spambox d-coding.com> writes:
On Thu, 22 Oct 2009 23:21:25 +0200, bambo <ba m.bo> wrote:

Walter Bright schrieb:
 Adam D. Ruppe wrote:
 
 Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething
 
 (Fixed that for you!)
Walter, what a remarkable proove the semicolon helps us all a lot! You are sooooo BRIGHT! You are so creative and intelligent! I LOVE YOU!
This is one of Walter's proofs that don't prove anything. Spaces between words are *not redundant*. And we are talking about *redundant* semicolons in programs where sentences (statements) are mostly placed each on its own line, unlike human languages where sentences are separated by points. New lines between statements are separators that make semicolons redundant. Anyway, I agree that semicolons should stay. However, the reasons are different.
Oct 23 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Max Samukha wrote:
 On Thu, 22 Oct 2009 23:21:25 +0200, bambo <ba m.bo> wrote:
 
 Walter Bright schrieb:
 Adam D. Ruppe wrote:

 Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething

 (Fixed that for you!)
Walter, what a remarkable proove the semicolon helps us all a lot! You are sooooo BRIGHT! You are so creative and intelligent! I LOVE YOU!
This is one of Walter's proofs that don't prove anything. Spaces between words are *not redundant*.
In Chinese they are. Andrei
Oct 23 2009
parent Max Samukha <spambox d-coding.com> writes:
On Fri, 23 Oct 2009 07:09:01 -0500, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

Max Samukha wrote:
 On Thu, 22 Oct 2009 23:21:25 +0200, bambo <ba m.bo> wrote:
 
 Walter Bright schrieb:
 Adam D. Ruppe wrote:

 Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething

 (Fixed that for you!)
Walter, what a remarkable proove the semicolon helps us all a lot! You are sooooo BRIGHT! You are so creative and intelligent! I LOVE YOU!
This is one of Walter's proofs that don't prove anything. Spaces between words are *not redundant*.
In Chinese they are. Andrei
You are right.
Oct 23 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Max Samukha wrote:
 On Thu, 22 Oct 2009 23:21:25 +0200, bambo <ba m.bo> wrote:
 
 Walter Bright schrieb:
 Adam D. Ruppe wrote:

 mostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething

 (Fixed that for you!)
Walter, what a remarkable proove the semicolon helps us all a lot! You are sooooo BRIGHT! You are so creative and intelligent! I LOVE YOU!
This is one of Walter's proofs that don't prove anything. Spaces between words are *not redundant*.
Armed with a dictionary, there's really only one parse of the above text that works. Consider also that when text is encrypted using pre-computer methods, the first thing done is all spaces are removed and it is put in monocase (because that makes it harder for cryptanalysis). Human decryptors put them back in. Consider the fragment: Ifthepointisntplainobviousfromtheabovefewersymbols Where else could the spaces possibly go?
Oct 23 2009
next sibling parent =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
Walter Bright wrote:
 Max Samukha wrote:
 On Thu, 22 Oct 2009 23:21:25 +0200, bambo <ba m.bo> wrote:

 Walter Bright schrieb:
 Adam D. Ruppe wrote:

 mostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething

 (Fixed that for you!)
Walter, what a remarkable proove the semicolon helps us all a lot! You are sooooo BRIGHT! You are so creative and intelligent! I LOVE YOU!
This is one of Walter's proofs that don't prove anything. Spaces between words are *not redundant*.
Armed with a dictionary, there's really only one parse of the above text that works. Consider also that when text is encrypted using pre-computer methods, the first thing done is all spaces are removed and it is put in monocase (because that makes it harder for cryptanalysis). Human decryptors put them back in. Consider the fragment: Ift hepo inti sn tplainobviousfromthe abovefewersymbols
SYNTAX ERROR!
Oct 23 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hbt1sv$1650$1 digitalmars.com...
 Max Samukha wrote:
 On Thu, 22 Oct 2009 23:21:25 +0200, bambo <ba m.bo> wrote:

 Walter Bright schrieb:
 Adam D. Ruppe wrote:

 mostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething

 (Fixed that for you!)
Walter, what a remarkable proove the semicolon helps us all a lot! You are sooooo BRIGHT! You are so creative and intelligent! I LOVE YOU!
This is one of Walter's proofs that don't prove anything. Spaces between words are *not redundant*.
Armed with a dictionary, there's really only one parse of the above text that works. Consider also that when text is encrypted using pre-computer methods, the first thing done is all spaces are removed and it is put in monocase (because that makes it harder for cryptanalysis). Human decryptors put them back in. Consider the fragment: Ifthepointisntplainobviousfromtheabovefewersymbols Where else could the spaces possibly go?
There's only one possible way: Ift hep oint is NT, pla I nob VI O' U.S. Fromt he, a bovef. Ew! Ers y m bols! It's obviously a note from a crazy person.
Oct 23 2009
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Fri, Oct 23, 2009 at 04:07:42PM -0400, Nick Sabalausky wrote:
 There's only one possible way:
 
 Ift hep oint is NT, pla I nob VI O' U.S. Fromt he, a bovef. Ew! Ers y m 
 bols!
 
 It's obviously a note from a crazy person.
Or is it a UNIX command line????? :P -- Adam D. Ruppe http://arsdnet.net
Oct 23 2009
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 23 Oct 2009 22:07:42 +0200, Nick Sabalausky <a a.a> wrote:

 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 news:hbt1sv$1650$1 digitalmars.com...
 Consider the fragment:

     Ifthepointisntplainobviousfromtheabovefewersymbols

 Where else could the spaces possibly go?
There's only one possible way: Ift hep oint is NT, pla I nob VI O' U.S. Fromt he, a bovef. Ew! Ers y m bols! It's obviously a note from a crazy person.
Nonono. Those who have studied cryptanalysis know that the right way would be: IFTHE POINT ISNTP LAINO BVIOU SFROM THEAB OVEFE WERSY MBOLS -- Simen
Oct 23 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 Armed with a dictionary, there's really only one parse of the above text 
 that works.
http://en.wikipedia.org/wiki/Viterbi_algorithm Bye, bearophile
Oct 23 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Max Samukha wrote:
 On Thu, 22 Oct 2009 23:21:25 +0200, bambo <ba m.bo> wrote:

 Walter Bright schrieb:
 Adam D. Ruppe wrote:

 mostcertainly
 doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
 aparsinganchorperiodsinasentencearentstrictlynecessarywecould
 putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
 Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
 youareSemicolonsarethesamething

 (Fixed that for you!)
Walter, what a remarkable proove the semicolon helps us all a lot! You are sooooo BRIGHT! You are so creative and intelligent! I LOVE YOU!
This is one of Walter's proofs that don't prove anything. Spaces between words are *not redundant*.
Armed with a dictionary, there's really only one parse of the above text that works.
therapistswhopreachedonweeknights Andrei
Oct 23 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 therapistswhopreachedonweeknights
Not a problem. Use surrounding context.
Oct 23 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
AJ wrote:
 Walter, do you write at all? If so, why not take a breather and write an 
 article about this, given that you have direct experience in addition to 
 opinion on the topic? :)
I write an awful lot - blogs, documentation, articles, presentations, etc. The ; debate, though, is a very old and tired one, and makes me tired just thinking about it :-) So many much more interesting things to write about. Bottom line: yes, there is a case both ways. Nobody will be convinced to change sides. Both can be made to work. There's nothing new to say about it.
Oct 21 2009
parent reply "AJ" <aj nospam.net> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hbo88h$1qk$1 digitalmars.com...
 AJ wrote:
 Walter, do you write at all? If so, why not take a breather and write an 
 article about this, given that you have direct experience in addition to 
 opinion on the topic? :)
I write an awful lot - blogs, documentation, articles, presentations, etc. The ; debate, though, is a very old and tired one, and makes me tired just thinking about it :-) So many much more interesting things to write about. Bottom line: yes, there is a case both ways. Nobody will be convinced to change sides. Both can be made to work. There's nothing new to say about it.
How about just a list of pros and cons for each? Or even, just the esoteric things that you as an implementer may already know that the layman doesn't? Semicolons As Statement Terminators On Single-Statement Lines Pros: 1. Makes parsing of certain (they need to be listed) constructs easier (how much?) (?). 2. Cons: 1. Makes source code less comprehensible. 2. Is redundant with the newline designator. 3. Is more typing. 4.
Oct 21 2009
next sibling parent reply "AJ" <aj nospam.net> writes:
"AJ" <aj nospam.net> wrote in message news:hbodvl$c1d$1 digitalmars.com...
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hbo88h$1qk$1 digitalmars.com...
 AJ wrote:
 Walter, do you write at all? If so, why not take a breather and write an 
 article about this, given that you have direct experience in addition to 
 opinion on the topic? :)
I write an awful lot - blogs, documentation, articles, presentations, etc. The ; debate, though, is a very old and tired one, and makes me tired just thinking about it :-) So many much more interesting things to write about. Bottom line: yes, there is a case both ways. Nobody will be convinced to change sides. Both can be made to work. There's nothing new to say about it.
How about just a list of pros and cons for each? Or even, just the esoteric things that you as an implementer may already know that the layman doesn't?
Semicolons As Statement Terminators On Single-Statement Lines Pros: 1. Makes parsing of certain (they need to be listed) constructs easier (how much?) (?). 2. Adds redundancy which helps diagnose and isolate the following common programming errors: A. B. Cons: 1. Makes source code less comprehensible. 2. Is redundant with the newline designator. 3. Is more typing. 4.
Oct 21 2009
parent reply "AJ" <aj nospam.net> writes:
 Semicolons As Implicit Programming Language Statement Terminators (An 
Analysis in Process)

 Pros:

 1. Makes parsing of certain (they need to be listed) constructs easier (how
 much?) (?).
 2. Adds redundancy which helps diagnose and isolate  (facilitates reporting 
of ) the following common
 programming/syntax errors:
    A.
    B.
 3. One well-defined statement terminator.
 4. No need to think: just assume what C/C++ uses is best, without question.
 5. Does not require long statement line-continuation character (for 
instance, "if" statements with
lots of clauses, and function calls/definitions with lots of arguments).
 6. Prevents subtle bugs.
 7. Facilitates languages that don't have header files.
 8. Makes lexical analysis less syntactic.
 9. Acts as a forward jump point for parser restart on error.
10. Makes select source code more comprehensible.
11.

 Cons:

 1. Makes most source code less comprehensible.
 2. Is redundant with the newline designator.
 3. Is more typing.
 4. Introduces tedium in development of implementations from header files.
 5. Makes Andrei vomit.

 7. Imposes a requirement on the common case to handle the exceptional case.
 8. Is a crutch for parser developers/stifles parser technology.
 9. Imposes parser's role onto every developer.
10. Allows one to write hard-to-see "do nothings" like: for(;;);
11. Introduces subtle bugs.
12. Allows ignorant jettisoning of header file concept.
13.


Discussion/Analysis

On Pro5, "if" statements with lots of clauses: Parser should parse "if 
statement" as soon as it sees "if" rather than parse general "statement". 
Aren't things like "if" ubiquitous enough to accept them as lexical rather 
than syntactical/semantical?
On Pro5, Function calls/definitions with lots of arguments: same comment as 
on "if" statements with lots of clauses.

On Pro8: Isn't that just a rewording of Con8?


(5/8/08)
Oct 22 2009
next sibling parent Kagamin <spam here.lot> writes:
AJ Wrote:

  Cons:
 
  1. Makes most source code less comprehensible.
That depends on what parser you have. If you're a basic addict, why you bother about C family language?
  2. Is redundant with the newline designator.
Statements don't end at newline.
  3. Is more typing.
Code reuse saves typing.
  5. Makes Andrei vomit.
Yeah, that's a problem.

Programmers have parsers too.
  7. Imposes a requirement on the common case to handle the exceptional case.
Does the sole existence of C family languages drive you mad so you want to kill'em with fire?
  9. Imposes parser's role onto every developer.
You can't work in a different way.
 10. Allows one to write hard-to-see "do nothings" like: for(;;);
a=b b=a a=b b=a b=b a=a
 12. Allows ignorant jettisoning of header file concept.
what's with header files?
Oct 22 2009
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
AJ wrote:
  Cons:
 10. Allows one to write hard-to-see "do nothings" like: for(;;);
That's not allowed in D, for that exact reason. You have to write for (;;) { } for a do-nothing loop. -Lars
Oct 22 2009
prev sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
AJ wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hbo88h$1qk$1 digitalmars.com...
 AJ wrote:
 Walter, do you write at all? If so, why not take a breather and write an 
 article about this, given that you have direct experience in addition to 
 opinion on the topic? :)
I write an awful lot - blogs, documentation, articles, presentations, etc. The ; debate, though, is a very old and tired one, and makes me tired just thinking about it :-) So many much more interesting things to write about. Bottom line: yes, there is a case both ways. Nobody will be convinced to change sides. Both can be made to work. There's nothing new to say about it.
How about just a list of pros and cons for each? Or even, just the esoteric things that you as an implementer may already know that the layman doesn't?
If you're trying to catch C/C++ coders, you need semicolons. If they're optional in some circumstances, that will lead to recommendations that you always include them in case the code changes to require them. This only leaves the possibility of removing semicolons entirely. This would mandate newlines as separators instead. Then you'd need a different character to negate newlines. The C/C++ crowd would leave at this point, since that's just silly. (Though less typing.)
Oct 21 2009
next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Christopher Wright wrote:
 This only leaves the possibility of removing semicolons entirely. This
 would mandate newlines as separators instead. Then you'd need a
 different character to negate newlines. The C/C++ crowd would leave at
 this point, since that's just silly. (Though less typing.)
Trivial solution: use indentation. If a line is more deeply indented than the previous line, it's a continuation of the previous statement. (Of course the people who complain about significant newlines are only going to scream louder about significant indentation, but you can't please everybody.) -- Rainer Deyke - rainerd eldwood.com
Oct 21 2009
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 22 Oct 2009 05:39:10 +0200, Rainer Deyke <rainerd eldwood.com>  
wrote:

 Christopher Wright wrote:
 This only leaves the possibility of removing semicolons entirely. This
 would mandate newlines as separators instead. Then you'd need a
 different character to negate newlines. The C/C++ crowd would leave at
 this point, since that's just silly. (Though less typing.)
Trivial solution: use indentation. If a line is more deeply indented than the previous line, it's a continuation of the previous statement.
All spaces, I presume? :p
Oct 21 2009
parent Rainer Deyke <rainerd eldwood.com> writes:
Simen Kjaeraas wrote:
 On Thu, 22 Oct 2009 05:39:10 +0200, Rainer Deyke <rainerd eldwood.com>
 wrote:
 Trivial solution: use indentation.  If a line is more deeply indented
 than the previous line, it's a continuation of the previous statement.
All spaces, I presume? :p
Tabs wouldn't be a problem so long as they are used consistently (one tab per indentation level). Given two whitespace sequences A and B, there are four possibilities: - They are identical, so they represent the same indentation. - A is a prefix of B, so B represents the deeper indentation. - B is a prefix of A, so A represents the deeper indentation. - Neither is a prefix of the other, which would be a syntax error. -- Rainer Deyke - rainerd eldwood.com
Oct 21 2009
prev sibling parent "AJ" <aj nospam.net> writes:
"Christopher Wright" <dhasenan gmail.com> wrote in message 
news:hboivs$l8g$1 digitalmars.com...
 AJ wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:hbo88h$1qk$1 digitalmars.com...
 AJ wrote:
 Walter, do you write at all? If so, why not take a breather and write 
 an article about this, given that you have direct experience in 
 addition to opinion on the topic? :)
I write an awful lot - blogs, documentation, articles, presentations, etc. The ; debate, though, is a very old and tired one, and makes me tired just thinking about it :-) So many much more interesting things to write about. Bottom line: yes, there is a case both ways. Nobody will be convinced to change sides. Both can be made to work. There's nothing new to say about it.
How about just a list of pros and cons for each? Or even, just the esoteric things that you as an implementer may already know that the layman doesn't?
If you're trying to catch C/C++ coders, you need semicolons.
I'm a C++ user, and I asked the question!
 If they're optional in some circumstances,
Rather, required in some circumstances.
 that will lead to recommendations that you always include them in case the 
 code changes to require them.
I didn't know D sought to lure people away from other languages! Not that I think keeping something unnecessary (if it is so) in their language is the way to attract them. <snipped rest of wild contrivation>
Oct 21 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
AJ wrote:
 Why not eliminate the requirement for semicolon statement terminators 
 (unless there are multiple statements per line)? Less typing is "more"! 
Because semicolons add redundancy which helps diagnose and isolate common programming errors.
Oct 21 2009
parent "AJ" <aj nospam.net> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hbo546$2snd$3 digitalmars.com...
 AJ wrote:
 Why not eliminate the requirement for semicolon statement terminators 
 (unless there are multiple statements per line)? Less typing is "more"!
Because semicolons add redundancy which helps diagnose and isolate common programming errors.
I added that (incomplete) thought to the list I of pros and cons I just started in another post.
Oct 21 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
AJ wrote:
 Why not eliminate the requirement for semicolon statement terminators 
 (unless there are multiple statements per line)? Less typing is "more"! 
Please don't post crazy stuff like this. This proposal would break every line of D code ever written. YOU ARE WASTING YOUR TIME (and everyone elses).
Oct 22 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Don Wrote:
 Please don't post crazy stuff like this. This proposal would break every 
 line of D code ever written.
If semicolons become optional, the old code that uses them will keep working, because adding an extra semicolon isn't an error. Broken lines like: foo(x, y); a = [1, 2, 3]; c = [1:2, 3:4]; d = {0, 1}; too will keep working because the things inside parentheses [] () (and {} when it's a static struct initializer) don't need an explicit line continuation sign. Some lines will need editing because they will need the line continuation syntax. I think this may be acceptable. Bye, bearophile
Oct 22 2009
prev sibling parent "AJ" <aj nospam.net> writes:
"Don" <nospam nospam.com> wrote in message 
news:hbp00i$1d88$1 digitalmars.com...
 AJ wrote:
 Why not eliminate the requirement for semicolon statement terminators 
 (unless there are multiple statements per line)? Less typing is "more"!
Please don't post crazy stuff like this. This proposal
It's not a proposal, it's a question. It's becoming more well-formed as the thread evolves.
 would break every line of D code ever written.
I don't care about that. I just want to know the "right" way to do it. When I figure that out (and I will), I'll either give D designers one point or take one point away ("did he/they get it right or get it wrong?").
 YOU ARE WASTING YOUR TIME (and everyone elses).
Accumulating knowledge is never a waste of time. If you personally are not interested in the topic, why bother reading the thread? Isn't reading threads on topics you are not interested in and cannot add value to a waste of your time?
Oct 22 2009
prev sibling next sibling parent Kagamin <spam here.lot> writes:
bearophile Wrote:

 Even "worse", someone may even implement such alternative D syntax, and the
sky will fall on your head:
 http://delight.sourceforge.net/
import dlt io Printer class Main void main Printer stdout stdout write Hello World!\n lolol
Oct 22 2009
prev sibling next sibling parent reply Mike James <foo bar.com> writes:
I say we should get rid of vowels - it worked for the ancient egyptians :-)

 Next thing you know someone will propose eliminating braces and just
 using whitespace to denote blocks. It's utter madness.
Or get rid of all the visible chars and use Whitespace... http://compsoc.dur.ac.uk/whitespace/ -=mike=-
Oct 22 2009
parent reply "AJ" <aj nospam.net> writes:
"Mike James" <foo bar.com> wrote in message 
news:hbp7le$2200$1 digitalmars.com...
I say we should get rid of vowels - it worked for the ancient egyptians :-)

 Next thing you know someone will propose eliminating braces and just
 using whitespace to denote blocks. It's utter madness.
Or get rid of all the visible chars and use Whitespace... http://compsoc.dur.ac.uk/whitespace/
Until editors/IDEs become Whitespace-aware, I wouldn't recommend using Whitespace: one click on "Save" in an editor that converts tabs into spaces and your code is gone. (I was so mad when that happened enough times that I went back to C++).
Oct 22 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
AJ wrote:
 "Mike James" <foo bar.com> wrote in message 
 news:hbp7le$2200$1 digitalmars.com...
 I say we should get rid of vowels - it worked for the ancient egyptians :-)

 Next thing you know someone will propose eliminating braces and just
 using whitespace to denote blocks. It's utter madness.
Or get rid of all the visible chars and use Whitespace... http://compsoc.dur.ac.uk/whitespace/
Until editors/IDEs become Whitespace-aware, I wouldn't recommend using Whitespace: one click on "Save" in an editor that converts tabs into spaces and your code is gone. (I was so mad when that happened enough times that I went back to C++).
You should try WhitespaceIDE: http://sourceforge.net/projects/whitespaceide/
Oct 22 2009
parent reply "AJ" <aj nospam.net> writes:
"Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
news:hbpau3$297f$1 digitalmars.com...
 AJ wrote:
 "Mike James" <foo bar.com> wrote in message 
 news:hbp7le$2200$1 digitalmars.com...
 I say we should get rid of vowels - it worked for the ancient egyptians 
 :-)

 Next thing you know someone will propose eliminating braces and just
 using whitespace to denote blocks. It's utter madness.
Or get rid of all the visible chars and use Whitespace... http://compsoc.dur.ac.uk/whitespace/
Until editors/IDEs become Whitespace-aware, I wouldn't recommend using Whitespace: one click on "Save" in an editor that converts tabs into spaces and your code is gone. (I was so mad when that happened enough times that I went back to C++).
You should try WhitespaceIDE: http://sourceforge.net/projects/whitespaceide/
I'm not nearly about to recreate all that lost code that I've since redeveloped in C++!! (The very clean syntax is alluring though).
Oct 22 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
AJ wrote:
 "Ary Borenszweig" <ary esperanto.org.ar> wrote in message 
 news:hbpau3$297f$1 digitalmars.com...
 AJ wrote:
 "Mike James" <foo bar.com> wrote in message 
 news:hbp7le$2200$1 digitalmars.com...
 I say we should get rid of vowels - it worked for the ancient egyptians 
 :-)

 Next thing you know someone will propose eliminating braces and just
 using whitespace to denote blocks. It's utter madness.
Or get rid of all the visible chars and use Whitespace... http://compsoc.dur.ac.uk/whitespace/
Until editors/IDEs become Whitespace-aware, I wouldn't recommend using Whitespace: one click on "Save" in an editor that converts tabs into spaces and your code is gone. (I was so mad when that happened enough times that I went back to C++).
You should try WhitespaceIDE: http://sourceforge.net/projects/whitespaceide/
I'm not nearly about to recreate all that lost code that I've since redeveloped in C++!! (The very clean syntax is alluring though).
You might find of utility this piece of code to recover your lost work:
Oct 22 2009
prev sibling next sibling parent reply Ali Cehreli <acehreli yahoo.com> writes:
AJ Wrote:

 Why not eliminate the requirement for semicolon statement terminators 
 (unless there are multiple statements per line)? Less typing is "more"! 
A number of times in this thread, you claimed that you were not proposing anything but merely asking "Why?". You may have very well intended that, but your two statements above form a proposal. At least for the English speaking people in Silicon Valley, they do... When followed by that incomplete phrase, it forms a proposal. Considering almost infinite "why not" proposals one might bring, yours is as silly as any other. Also, I will not guess what you mean with "more" of less typing. I know that removing semicolons would have "more typing" of the backspace key for people coming from any language that currently requires semicolon. Ali
Oct 22 2009
next sibling parent "AJ" <aj nospam.net> writes:
"Ali Cehreli" <acehreli yahoo.com> wrote in message 
news:hbqcvd$1ku4$1 digitalmars.com...
 AJ Wrote:

 Why not eliminate the requirement for semicolon statement terminators
 (unless there are multiple statements per line)? Less typing is "more"!
A number of times in this thread, you claimed that you were not proposing anything but merely asking "Why?". You may have very well intended that, but your two statements above form a proposal. At least for the English speaking people in Silicon Valley, they do... When followed by that incomplete phrase, it forms a proposal. Considering almost infinite "why not" proposals one might bring, yours is as silly as any other. Also, I will not guess what you mean with "more" of less typing. I know that removing semicolons would have "more typing" of the backspace key for people coming from any language that currently requires semicolon. Ali
Read what I mean, not what I say.
Oct 22 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Ali Cehreli wrote:
 Considering almost infinite "why not" proposals
I also suggest that "why not" is the wrong way to set up a proposal. A proposal should come with "why" do it. Furthermore, any proposal that breaks existing code needs to have a very high level of advantages to justify it.
Oct 22 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
AJ wrote:
 Why not eliminate the requirement for semicolon statement terminators 
 (unless there are multiple statements per line)? Less typing is "more"!
You'll find every argument and point of view on this here: http://www.reddit.com/r/programming/comments/9wlb7/proggitors_do_you_like_the_idea_of_indented/
Oct 22 2009
next sibling parent reply "AJ" <aj nospam.net> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hbqj12$25a6$1 digitalmars.com...
 AJ wrote:
 Why not eliminate the requirement for semicolon statement terminators 
 (unless there are multiple statements per line)? Less typing is "more"!
You'll find every argument and point of view on this here: http://www.reddit.com/r/programming/comments/9wlb7/proggitors_do_you_like_the_idea_of_indented/
Great! Thanks! I'll look there for sure. I was on the D site last night trying to search the D archives, but the search capabilities are so meager. I found a good post on 5/8/08 I think it was (about semicolons), but didn't feel like wading thru mud to find earlier posts. So, I'm asking, is there a good way to search the archives, via subject line etc.? There's other stuff I'd like to investigate there also. I'd download 70000 msgs to my newsreader, but I'm only using OE so can only do 1000 at a time. That would be a great/efficient way to get up to speed on D history. Recommendations? (Yes, I can use another newsreader if need be).
Oct 22 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
AJ wrote:
 I was on the D site last night trying to search the D archives, but the 
 search capabilities are so meager. I found a good post on 5/8/08 I think it 
 was (about semicolons), but didn't feel like wading thru mud to find earlier 
 posts. So, I'm asking, is there a good way to search the archives, via 
 subject line etc.? There's other stuff I'd like to investigate there also. 
 I'd download 70000 msgs to my newsreader, but I'm only using OE so can only 
 do 1000 at a time. That would be a great/efficient way to get up to speed on 
 D history. Recommendations? (Yes, I can use another newsreader if need be). 
The searching is done by google, so anything that works for google should work in the search box.
Oct 22 2009
parent reply "AJ" <aj nospam.net> writes:
Walter Bright wrote:
 AJ wrote:
 I was on the D site last night trying to search the D archives, but
 the search capabilities are so meager. I found a good post on 5/8/08
 I think it was (about semicolons), but didn't feel like wading thru
 mud to find earlier posts. So, I'm asking, is there a good way to
 search the archives, via subject line etc.? There's other stuff I'd
 like to investigate there also. I'd download 70000 msgs to my
 newsreader, but I'm only using OE so can only do 1000 at a time.
 That would be a great/efficient way to get up to speed on D history.
 Recommendations? (Yes, I can use another newsreader if need be).
The searching is done by google, so anything that works for google should work in the search box.
It just does full text searches. Advanced searching (by subject, poster etc.) is not available as in Google Groups (as far as I can tell). I would like to search subject lines only.
Oct 22 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
AJ wrote:
 It just does full text searches. Advanced searching (by subject, poster 
 etc.) is not available as in Google Groups (as far as I can tell). I would 
 like to search subject lines only. 
It's not google groups. It's google.
Oct 22 2009
parent reply "AJ" <aj nospam.net> writes:
Walter Bright wrote:
 AJ wrote:
 It just does full text searches. Advanced searching (by subject,
 poster etc.) is not available as in Google Groups (as far as I can
 tell). I would like to search subject lines only.
It's not google groups. It's google.
It's not that lame ass shit, I was trying to research 70 thousand posts (70 thousand? whoa that's a lot))... hello!
Oct 23 2009
parent Justin Johansson <no spam.com> writes:
AJ Wrote:

 Walter Bright wrote:
 AJ wrote:
 It just does full text searches. Advanced searching (by subject,
 poster etc.) is not available as in Google Groups (as far as I can
 tell). I would like to search subject lines only.
It's not google groups. It's google.
It's not that lame ass shit, I was trying to research 70 thousand posts (70 thousand? whoa that's a lot))... hello!
Me thinks that the use of semicolons should be optional. Therefore you have 10 options: use a programming language that has semicolons in its syntax, or use a programming language that does not have semicolons in its syntax. And if you don't like that answer, consider that a semicolon is otherwise what's left after you have half of your intestines removed.
Oct 23 2009
prev sibling parent "AJ" <aj nospam.net> writes:
Walter Bright wrote:
 AJ wrote:
 Why not eliminate the requirement for semicolon statement terminators
 (unless there are multiple statements per line)? Less typing is
 "more"!
You'll find every argument and point of view on this here: http://www.reddit.com/r/programming/comments/9wlb7/proggitors_do_you_like_the_idea_of_indented/
Been there now. Not a good link for the issue at hand. I found no point to add to my working list from it. Here is the current "list" (yeah, a bit facetious, but purposefully obvious in that regard): Semicolons As Implicit Programming Language Statement Terminators (An Analysis in Process) Pros: 1. Makes parsing of certain (they need to be listed) constructs easier (how much?) (?). 2. Adds redundancy which helps diagnose and isolate (facilitates reporting of ) the following common programming/syntax errors: A. B. 3. One well-defined statement terminator. 4. No need to think: just assume what C/C++ uses is best, without question. 5. Does not require long statement line-continuation character (for instance, "if" statements with lots of clauses, and function calls/definitions with lots of arguments). 6. Prevents subtle bugs. 7. Facilitates languages that don't have header files. 8. Makes lexical analysis less syntactic. 9. Acts as a forward jump point for parser restart on error. 10. Makes select source code more comprehensible. 11. Cons: 1. Makes most source code less comprehensible. 2. Is redundant with the newline designator. 3. Is more typing. 4. Introduces tedium in development of implementations from header files. 5. Makes Andrei vomit. 7. Imposes a requirement on the common case to handle the exceptional case. 8. Is a crutch for parser developers/stifles parser technology. 9. Imposes parser's role onto every developer. 10. Allows one to write hard-to-see "do nothings" like: for(;;); 11. Introduces subtle bugs. 12. Allows ignorant jettisoning of header file concept. 13.
Oct 22 2009
prev sibling parent "Joel C. Salomon" <joelcsalomon gmail.com> writes:
Who here has entered more keystrokes in this thread then they have
semicolons in their codebase?

—Joel Salomon
Oct 22 2009