Charles Fox wrote:
> I've been following D for a few years now, and I'd like to suggest ditching
> the (now completely redundant) curley brackets from the C-like syntax and
> borrowing Python's use of tabs to replace them.   I see no reason to keep the
> curley brackets now we have nice editors that know about (and can display) tab
> characters.  The ideal programming language should have no redundancy, you
> shouldn't have to say anything twice, and at present we are still repearting
> ourselves with both curley brackets and indentation!  What do you think?

EWWWWWWWWW! redundant? Hardly. There is a place for insanity such as this, its called Python.

Daniel Keep wrote:
> Another interesting thing is Lua code: it doesn't require you to use an
> explicit statement separator; it's smart enough to "know" where
> statements start and end.  And yet the majority of Lua code I've seen
> uses those redundant semicolons and parenthesis.  Why?  Not really sure;
> could be they're either so C-style brain-damaged they can't code without
> compulsively hitting those keys (must... insert... delimiters...), or
> they just like the additional explicitness.

Well, FWIW, when I first switched from a significant period of time of C-like languages to another language (VB, for a school assignment. Don't ask) I was automatically hitting ';' at the end of every statement.

Sort of the same thing happened when I coded in Pascal (well, Delphi mostly) for a while, I hit ';' at the end of every statement (it's only required as a statement _separator_ in Pascal, so it's unnecessary after the last statement). Since it compiled I never stopped.
Of course, there you can justify it by the fact that it makes it easier to add statements to a block :)

I guess it's just one of those things that, once learned, you keep doing until you notice that the compiler you're using keeps complaining about them :).

Charles Fox wrote:
> I've been following D for a few years now, and I'd like to suggest ditching
> the (now completely redundant) curley brackets from the C-like syntax and
> borrowing Python's use of tabs to replace them.   I see no reason to keep the
> curley brackets now we have nice editors that know about (and can display) tab
> characters.  The ideal programming language should have no redundancy, you
> shouldn't have to say anything twice, and at present we are still repearting
> ourselves with both curley brackets and indentation!  What do you think?

http://media.urbandictionary.com/image/large/SRSLY-40514.jpg

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Frits van Bommel wrote:

> Well, FWIW, when I first switched from a significant period of time of C-like languages to another language (VB, for a school assignment. Don't ask) I was automatically hitting ';' at the end of every statement.
> 
I find my self punctuating English with them; It's really funny when things like that creep into "real" life;

I have also been known to use a single line comment to annotate notes in class;

// in other non-CS classes to <g>

Charles Fox wrote:
> I've been following D for a few years now, and I'd like to suggest ditching
> the (now completely redundant) curley brackets from the C-like syntax and
> borrowing Python's use of tabs to replace them.   I see no reason to keep the
> curley brackets now we have nice editors that know about (and can display) tab
> characters.  The ideal programming language should have no redundancy, you
> shouldn't have to say anything twice, and at present we are still repearting
> ourselves with both curley brackets and indentation!  What do you think?

I like Python, but I find the use of tabs for scope to have both plusses  and minuses.  Even with a good tab-aware editor it's difficult to do major reworks of chunks of code.  Like cutting a big nested chunk of stuff from one place and dropping it into a another function somehwere else.  You have to be very careful when doing that kind of thing with Python code.   With a curly brace language the braces make sure you don't mess anything up.  Just paste it in however you want and hit your editor's 'reformat selection' button.

Also I was just looking through the Python mailing list archives the other day and saw lots of code snippets from which the leading whitespace had been stripped by news software or something along the way.  Including the braces is just more robust in the long term.

That said, it is nice to be able to omit all the ';' and '{' characters.  But like another person said it's 6 of one 1/2 dozen the other.  They both have pros and cons, and since D aims to be an easy transition language for C/C++ users, it makes sense to stick with the braces.

--bb

BCS wrote:
> I have also been known to use a single line comment to annotate notes in class;
> 
> // in other non-CS classes to <g>

heheh .. I do that too!!

Daniel Keep wrote:
> Charles Fox wrote:
> [...]
> Why?  Not really sure; could be they're either so C-style
> brain-damaged they can't code without compulsively hitting those keys
> (must... insert... delimiters...),
> [...]

LOL! :D

--
Tom;

Chris Nicholson-Sauls schrieb:
> Charles Fox wrote:
> Doing this, we would sacrifice expressiveness,
How's that?

> source portability,
Why?

> useful niche  features such as anonymous scopes,
Not if you have a keyword for that.

> and enter the world of ambiguous nesting levels.
In what way are they ambiguous?

> Python and D are two different galaxies.
I'd say: "different tools, same shed".

> Python is not a systems language (technically, its interprative, and doesn't provide any low-level functionality that I recall).
Python is as interpretated as Java is (bytecode VM).
It is often refered to as a glue language because it will hold together
very different pieces of software. Even those written in C or even D.

> Scope-by-indentation is a good choice in that case, where the speed and blindness of parsing are paramount.  It would be a massacre for D.
That is just not true. Scope indentation usually just results in an openly visible code structure and shorter source code because of the lack of unnecessary delimiter syntax.

I've written a preprocessor for C-style languages which allows me to write in a Python like manner and still have C(++) or D sources for compilation.

I wrote the first version in january 2005 and have been using it eversince. It all works very well and allows me to write very readable sources that are usually about 25-30% shorter than the output files.

The only shortcoming I've noticed was that with indentation based syntax you are unable to write bottom controlled loops, at least not in a way that it'll be recognized as such.


Regards,
Nils

Daniel Keep wrote:
> Another interesting thing is Lua code: it doesn't require you to use an
> explicit statement separator; it's smart enough to "know" where
> statements start and end.  And yet the majority of Lua code I've seen
> uses those redundant semicolons and parenthesis.  Why?  Not really sure;
> could be they're either so C-style brain-damaged they can't code without
> compulsively hitting those keys (must... insert... delimiters...), or
> they just like the additional explicitness.

Adding the ';' makes it a lot easier for the compiler to give reasonable targetted error messages when the syntax is wrong. Not only does it give the parser an obvious "resynchronize" marker, it helps the user "resynchronize" when faced with complex text.

Nils Hensel wrote:
> Chris Nicholson-Sauls schrieb:
> 
>>Charles Fox wrote:
>>Doing this, we would sacrifice expressiveness,
> 
> How's that?

You gave an example yourself at the bottom of your post, when you mentioned bottom-controlled loops.  Although Ruby's until() loop is a good example of how to overcome such things, at least a little.  Then again, Ruby isn't a good example for this discussion... I find that Ruby is almost mind-bogglingly expressive, which is nice, but makes it difficult to compare with.

We would sacrifice it by giving whitespace meaning, thereby changing the priorities of operators and other symbols in parsing... or in short, changing this one piece of syntax changes the case-usability of the rest of the syntax.

Or maybe I'm just being anal in this instance.

> 
>>source portability,
> 
> Why?

I might like quad-spaces, you might like hard tabs, "Bob" might like 2-space, Walter likes 8-space, etc.  Sure, editors can apply whatever tabbing rules one likes, but then only if one sticks to hard tabs.  And heaven forbid if other whitespace starts getting meanings, then it can become "truly" non-portable if different OS's have different representations (an example is the newline, which is \n on some systems and \r\n on others).

> 
>>useful niche  features such as anonymous scopes,
> 
> Not if you have a keyword for that.

One might argue, then they aren't really anonymous.  ;)  That's tongue-in-cheek, but the point is sound.  Given these two examples:

# void main () {
#   doStuff;
#   { auto Foo f = new Foo;
#     doOtherStuff;
#   }
#   doFinalStuff;
# }

# void main ()
#   doStuff
#     auto Foo f = new Foo
#     doOtherStuff
#   doFinalStuff

Yes I do admit that the second example is two lines shorter.  However, a line with just a '}' on it is hardly worth counting, and also I find the braces immensely meaningful.  They make it very clear that I'm introducing a new scope, whereas in the other case my "scope" might be mistaken as a body block to the 'doStuff' symbol.  Not too likely to be  problem with D as it stands, sure -- but it could be surprising to someone who actually /comes/ to D from a background of Python, ABC, et al.  It also leaves me hanging as to whether or not main() is actually closed at this point.  How do you suppose we should do D's design-by-contract functions?  The only thing I can think of would be:

// current
# void foo (int x)
# in {
#   blah
# }
# out {
#   blah
# }
# body {
#   blah
# }
# unittest {
#   blah
# }

// new
# void foo (int x)
#   in:
#     blah
#   out:
#     blah
#   body:
#     blah
# unittest:
#   blah

Its cute, but one false move and I've got a dangling statement if I miss one little space character.  I know, I'm being anal again.  But its something I just don't feel I should have to worry about.  In this kind of syntax, I find I actually end up spending more time worrying about alignment, etc, when I'm just trying to get a rought draft implemented, rather than doing it later during cleanup/tweaking.

> 
>>and enter the world of ambiguous nesting levels.
> 
> In what way are they ambiguous?

See my previous example, and see the plethora of other discussions about it.

> 
>>Python and D are two different galaxies.
> 
> I'd say: "different tools, same shed".

Fair enough, except that they still have niches they fulfill that the other doesn't.  As I've said before, I have (and very occasionally still do) worked in Python, because at the time it seemed the most straight-forward way to solve a specific problem.

> 
>>Python is not a systems language (technically, its interprative, and doesn't provide
>>any low-level functionality that I recall).
> 
> Python is as interpretated as Java is (bytecode VM).
> It is often refered to as a glue language because it will hold together
> very different pieces of software. Even those written in C or even D.

Yes, indeed, and exactly.

> 
>>Scope-by-indentation is a good choice in that case, where the speed and blindness of parsing are paramount.  It would be a massacre for D.
> 
> That is just not true. Scope indentation usually just results in an
> openly visible code structure and shorter source code because of the
> lack of unnecessary delimiter syntax.

What is more "openly visible" than open-close symbols, such as {}'s?

> I've written a preprocessor for C-style languages which allows me to
> write in a Python like manner and still have C(++) or D sources for
> compilation.
> 
> I wrote the first version in january 2005 and have been using it
> eversince. It all works very well and allows me to write very readable
> sources that are usually about 25-30% shorter than the output files.
> 

Then you have what you want.  ;)  I'm not concerned with how short the output files are, but rather with how well I can 1) express what I want with absolute clarity, and 2) format the code to suit my own aesthetics so that I can understand it later with ease.

-- Chris Nicholson-Sauls