"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"! 

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.

"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

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

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

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

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)

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.

=?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

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.

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.

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.

"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 (?).

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.

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

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!

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

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"?

"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 (?)). 

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

"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! 

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

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.

=?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

"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

"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?).

"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

"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?

"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

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

"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

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

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

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

 

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

"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

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

"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

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

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

"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

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

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.

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.

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?

=?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?

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)

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

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.

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

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

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

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

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

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.

=?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

"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

=?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

"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

"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

"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

"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 

"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

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

Walter Bright <newshound1 digitalmars.com> writes:

Adam D. Ruppe wrote:

Ifthepointisntplainobviousfromtheabovefewersymbolsmostcertainly
doesNOTmeanalanguageisnecessarilyeasiertoparseSymbolsgiveus
aparsinganchorperiodsinasentencearentstrictlynecessarywecould
putoneperlineorjustfigureoutwheretheybelongbyparsingthecontext
Butthatsfairlyobviouslymuchharderthanusingperiodstofollowwhere
youareSemicolonsarethesamething

(Fixed that for you!)

"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?

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

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

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

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.

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

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.

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

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.

"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

=?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

"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)

=?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

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.

=?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

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

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

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!

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.

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

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.

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?

=?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!

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

"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

"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

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

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

Walter Bright <newshound1 digitalmars.com> writes:

Andrei Alexandrescu wrote:
 therapistswhopreachedonweeknights

Not a problem. Use surrounding context.

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.

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

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

"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)

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?

"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

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

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

"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

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

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

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.

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

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

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

"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? 

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

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

"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++). 

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/

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

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:

   	  	 	   	 	 	
   	 	 	 	 	  	  	  	
  	 	 	
  	 	 	  	  	  	

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

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

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.

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/

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

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.

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

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.

"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! 

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.

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

"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