Chris Nicholson-Sauls schrieb:
> 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.

"until" is exactly what I use to overcome this but I don't know if that's anything like Ruby's for I don't know Ruby.

You still have to know that it's bottom-controlled, though. :(

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

This problem doesn't arise when you only give meaning to leading whitespace and leave everything else as it is, except for the "one line = one statement" rule (which is true for most cases).


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

You're right: tabs are evil. ;-)

But programmers shouldn't use them anyway IMO because they make code unreadable regardless of language.

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

you could use a keyword like "scope". For example:

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

That's the way indentation should work anyway, starting a block with a keyword, like you would usually do in D anyway. So

# if (condition)
# {
#   do_work();
# }

becomes

# if condition
#   do_work()


> It also leaves me hanging as to whether or not main() is actually
> closed at this point.

Experience tells me you may trust it to be closed. I've never had any difficulties with that. I believe you would soon feel the same, it's a proven technique.

> 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

You may omit the ':'. It's not needed.

> Its cute, but one false move and I've got a dangling statement if I miss one little space character.

But the same is true if you accidentally erase a closing brace. You can easily screw up C-style syntax as well, trust me on that one ;-)

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

I believe one crosses from worrying about alignment to just using alignment fairly quickly. Having to end up with readable code is a bonus IMO not a disadvantage.

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

I must confess I still don't see any ambiguity. To me it's pretty clear what opened the nesting level I'm currently in. I just have to look back to the last line with less indentation to see that.

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

I agree that Python and D are best at different uses, but that is not due to different parsing. It's because D is very much less dynamic than Python at runtime at the increase of speed.

Both approaches are valuable in different occasions, but both could be handled using the same syntax constructs.

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

A hint may be that there is no such thing as an "obfuscated Python"-contest as there is for C. You can write a whole C-program in one line if you are either an aesthetic pervert or just full of hate for your co-workers. ;-)

Just think about the different conventions where to but the opening curly brace. There is no such choice in Python. You only agree on the depth of indentation you use.

And years of working on OPC (other people's code ;-) have taught me the importance of writing easily understandable code. I would go as far as to say the best language would be one that forces you to comment your code as well as making it work.

>> I've written a preprocessor for C-style languages
> 
> Then you have what you want.  ;)

Yes, I do.
Don't get me wrong. I'm not advocating switching from C-style to
Python-style syntax for D. I also believe that to be a mistake at this time.

It was just that there seemed to be a lot of unjustified Python-bashing going on (not from you though, I replied to your post because you were the only one actually giving arguments :)

All I wanted to point out was that Python-style syntax does not prevent you from ending up with a powerful programming language such as D.

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

Same here, though I enjoy having shorter source files - less bugs and easier to grasp.

I just want to do away with the unnecessary stuff like most parentheses, braces, semi-colons and the like.

Actually some things are even longer to write in my preprocessor for the sake of expressiveness, e.g. logical operators ('and' instead of '&&').


> and 2) format the code to suit my own aesthetics
> so that I can understand it later with ease.

Which is great if you're the only one working on your code. Otherwise you have to hope for your co-workers to share the same aesthetics. :)


Regards,
Nils

Nils Hensel wrote:
> Chris Nicholson-Sauls schrieb:
> 
>>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.
> 
> 
> "until" is exactly what I use to overcome this but I don't know if
> that's anything like Ruby's for I don't know Ruby.
> 
> You still have to know that it's bottom-controlled, though. :(
> 

In Ruby the statement "until (x == y)" is the same as "while (x != y)", which when coupled with some cut logic inversion, can pull off the trick.  I don't think I ever used the Python equivelant, but I'm sure its likely the same.

>>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.
> 
> 
> This problem doesn't arise when you only give meaning to leading
> whitespace and leave everything else as it is, except for the "one line
> = one statement" rule (which is true for most cases).

That is true, the comment on only giving meaning to the indentation, and not to internal spaces.  And it would clarify most cases.  However, unfortunately I have pleanty of "one line != one statement" code, due to using API's (such as Windows *shudder*) that expect arduous function arguments, and/or due to complex logic/bool expressions that are easier for me to read when spread across lines.  I suppose a new indentation level in the middle of a statement would be enough to represent continuation, but then we introduce the new requirement of a statement terminator in the general case; re-introducing the "redundancies" that we had tossed.

Its either that \
or prefixing lines with \
those bloody back-slashes \
like some platforms I \
won't mention by name.  ;)

> 
> 
>>>>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).
> 
> 
> You're right: tabs are evil. ;-)
> 
> But programmers shouldn't use them anyway IMO because they make code
> unreadable regardless of language.

Well, we're agreed on that.  Which is saying something, as I used to be a hard-tabs nut.

> 
>>>>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.
> 
> 
> you could use a keyword like "scope". For example:
> 
> # void main ()
> #   doStuff
> #   scope
> #     auto Foo f = new Foo
> #     doOtherStuff
> #   doFinalStuff

But scope already has a meaning... ;)

> That's the way indentation should work anyway, starting a block with a
> keyword, like you would usually do in D anyway. So
> 
> # if (condition)
> # {
> #   do_work();
> # }
> 
> becomes
> 
> # if condition
> #   do_work()
> 

My style would have that opening brace on the line with the if() statement, so dropping the {}'s really only shaved a single line off -- and never would remove any more than that.  The one advantage this area does give to indentation-syntax is that it becomes easier to add debugging/etc code to pre-written one-line blocks that you hadn't considered for extra code.  Personally, I just make a point of never leaving the {}'s out, and this never effects me.

> 
>>It also leaves me hanging as to whether or not main() is actually
>>closed at this point.
> 
> 
> Experience tells me you may trust it to be closed. I've never had any
> difficulties with that. I believe you would soon feel the same, it's a
> proven technique.

My eyes see nothing but more code after main(), therefore it takes me a while to register that main() is no longer going on, but that this code is something else.  The fact that the whitespace is different simply doesn't register for me.  I guess I just spend far too much time in things where I mostly (or even completely) ignore spaces.

> 
>>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
> 
> 
> You may omit the ':'. It's not needed.

I know it isn't technically, but I liked the extra decoration.  Oh well, just me thinking in terms of symbols again I suppose.

> 
>>Its cute, but one false move and I've got a dangling statement if I miss
>>one little space character.
> 
> 
> But the same is true if you accidentally erase a closing brace. You can
> easily screw up C-style syntax as well, trust me on that one ;-)

I can't imagine why I would erase braces unless I was erasing the entire statement associated with them (they're always the first thing I type as well, right after the statement name and its parenthesis).  The difference is vital, however.  If I am working on some code, and I accidentally put 7 spaces where there should be 8, I may or may not realize something is amiss.  I sit and drum on Undo/Redo trying to spot something, and it just isn't there.

On the other hand, if I somehow manage to erase or overwrite a brace character, as I tap on Undo/Redo I immediately notice a brace is appearing/disappearing, so I stick it back in where it belongs.  Or, I can simply scan my cursor over the chunk of code I was editing, and the pair-highlighting feature makes it clear to me that this delimiter (parenthesis, bracket, or brace) has no partner; better give it one.

> 
>>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.
> 
> 
> I believe one crosses from worrying about alignment to just using
> alignment fairly quickly. Having to end up with readable code is a bonus
> IMO not a disadvantage.

In the general case, you are right.  But, what if I complete that draft of code, only to find that I've made a major mistake, and must scrap the entire thing and quickly re-write?  If I was having to pretty-format the whole way, then I've wasted time.

> 
>>>>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.
> 
> 
> I must confess I still don't see any ambiguity. To me it's pretty clear
> what opened the nesting level I'm currently in. I just have to look back
> to the last line with less indentation to see that.
> 
> 
>>>>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.
> 
> 
> I agree that Python and D are best at different uses, but that is not
> due to different parsing. It's because D is very much less dynamic than
> Python at runtime at the increase of speed.
> 
> Both approaches are valuable in different occasions, but both could be
> handled using the same syntax constructs.
> 
> 
>>>>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?
> 
> 
> A hint may be that there is no such thing as an "obfuscated
> Python"-contest as there is for C. You can write a whole C-program in
> one line if you are either an aesthetic pervert or just full of hate for
> your co-workers. ;-)
> 
> Just think about the different conventions where to but the opening
> curly brace. There is no such choice in Python. You only agree on the
> depth of indentation you use.
> 
> And years of working on OPC (other people's code ;-) have taught me the
> importance of writing easily understandable code. I would go as far as
> to say the best language would be one that forces you to comment your
> code as well as making it work.
> 

The caveat is, 1) there are really only two choices on where to put the brace -- same line or next line -- and 2) one can quite easily run "obfuscated" C code through a dummy parser and casually read the properly-formatted output copy.

Also, I seriously doubt anybody uses things such as may be found in "obfuscation" contests in legitimate real-world code.  If they do, then they deserve to be one very, very lonely programmer.  ;)

>>>I've written a preprocessor for C-style languages
>>
>>Then you have what you want.  ;)
> 
> 
> Yes, I do.
> Don't get me wrong. I'm not advocating switching from C-style to
> Python-style syntax for D. I also believe that to be a mistake at this time.
> 
> It was just that there seemed to be a lot of unjustified Python-bashing
> going on (not from you though, I replied to your post because you were
> the only one actually giving arguments :)
> 
> All I wanted to point out was that Python-style syntax does not prevent
> you from ending up with a powerful programming language such as D.
> 
> 
>>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,
> 
> 
> Same here, though I enjoy having shorter source files - less bugs and
> easier to grasp.
> 
> I just want to do away with the unnecessary stuff like most parentheses,
> braces, semi-colons and the like.

In the BovisMOO language, which I have full control over, there are certain cases where one can do away with some things (for example the expression ' :name ' is the same as ' $This:name() ').  But I actually find that trying to become completely independant of symbols/operators in a language design is quite simply beyond me.  Maybe just not enough of the right kind of experience.

> Actually some things are even longer to write in my preprocessor for the
> sake of expressiveness, e.g. logical operators ('and' instead of '&&').
> 
> 
> 
>>and 2) format the code to suit my own aesthetics
>>so that I can understand it later with ease.
> 
> 
> Which is great if you're the only one working on your code. Otherwise
> you have to hope for your co-workers to share the same aesthetics. :)

They'd better.  ;)  Generally though, at least being consistant in one's formatting is enough.  For example, I am completely baffled by Kris' coding style used in Mango, and yet I can read Mango code with no difficulty, because his style is consistant enough my eyes just "learn" it as they go.

-- Chris Nicholson-Sauls

Pragma wrote:
> To invoke the old idiom "if it ain't broken, don't fix it."  C-style syntax and character has been borrowed and used in countless other languages.  Other language have lived, and died, after C was created and long before the present.  Surely there's something to be said for how well it's syntax works?

That's so true. We all know and harp on C's faults, but overlook the overwhelming stuff that C got *right*. C was the first really usable high level language.

I've heard from some people who should know that one thing that has consistently held Python back from adoption is the whitespace thing.

As long as I have any influence on the matter, D is not going to adopt that feature of Python.

Dnia Fri, 27 Oct 2006 12:15:48 +0000 (UTC)
Charles Fox <charles@SPAMMENOT.robots.ox.ac.uk> napisał/a:

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

Hi all.

Try this:
http://smp.if.uj.edu.pl/~baryluk/d/dmt-1.0.tar.gz

Note: not tested well (it is very simple and naive, but can be used for tests. but to be usefull some issues should be resolved in future).


--
Witold Baryluk
MAIL: baryluk@smp.if.uj.edu.pl, baryluk@mpi.int.pl
JID: movax@jabber.autocom.pl

Witold Baryluk escribió:
> Dnia Fri, 27 Oct 2006 12:15:48 +0000 (UTC)
> Charles Fox <charles@SPAMMENOT.robots.ox.ac.uk> napisał/a:
> 
>> 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?
> 
> Hi all.
> 
> Try this:
> http://smp.if.uj.edu.pl/~baryluk/d/dmt-1.0.tar.gz

This is soooo nice, I know is too late to ask for pyton-like syntax, but this keeps the hope high ;)

-- 
Leandro Lucarella
Integratech S.A.
4571-5252

On Thu, 30 Nov 2006 03:56:39 +0100, Witold Baryluk wrote:

> Dnia Fri, 27 Oct 2006 12:15:48 +0000 (UTC)
> Charles Fox <charles@SPAMMENOT.robots.ox.ac.uk> napisał/a:
> 
>> 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?
> 
> Hi all.
> 
> Try this:
> http://smp.if.uj.edu.pl/~baryluk/d/dmt-1.0.tar.gz
> 
> Note: not tested well (it is very simple and naive, but can be used for tests. but to be usefull some issues should be resolved in future).


I must be old :)  I have to say that I like the C style brackets.  I'll catch you guys later at the old programmers home :)

Mark

Mark Wrenn wrote:
> 
> I must be old :)  I have to say that I like the C style brackets.  I'll
> catch you guys later at the old programmers home :)
> 
> Mark

I'm not old and I like the brackets too

Tomas Lindquist Olsen wrote:
> Mark Wrenn wrote:
>>
>> I must be old :)  I have to say that I like the C style brackets.  I'll
>> catch you guys later at the old programmers home :)
>>
>> Mark
> 
> I'm not old and I like the brackets too

Likewise

Mark Wrenn wrote:
> On Thu, 30 Nov 2006 03:56:39 +0100, Witold Baryluk wrote:
> 
>> Dnia Fri, 27 Oct 2006 12:15:48 +0000 (UTC)
>> Charles Fox <charles@SPAMMENOT.robots.ox.ac.uk> napisał/a:
>>
>>> 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?
>> Hi all.
>>
>> Try this:
>> http://smp.if.uj.edu.pl/~baryluk/d/dmt-1.0.tar.gz
>>
>> Note: not tested well (it is very simple and naive, but can be used for
>> tests. but to be usefull some issues should be resolved in future).
> 
> 
> I must be old :)  I have to say that I like the C style brackets.  I'll
> catch you guys later at the old programmers home :)
> 
> Mark

Put me in the "old" camp too I guess.

I've posted before about this, but I still think it bears repeating why this isn't a good idea for D.

I've been doing some Trac hacking lately so I've come to despise Python's whitespace scheme.  Oh sure, it makes for some nice looking code, but in the end, my code fails compilation after compilation just because I mashed the [tab] key (instead of four spaces) by mistake.

Recently, I showed an example to my wife (who's not a programmer BTW) of two lines of python code:

    print('hello world')
    print('hello world')

I then told her that "one of those lines is 100% valid code, and the other isn't."  I added that "the bad line will stop my program dead in it's tracks, even though I double checked my work, just as we did.  The difference is one has four spaces and the other a [tab] character."  Her response?

"Wow, that's pretty lame."

If the design failure here is easily grasped by someone, who's entire "coding" experience can be summed up in using LiveJournal and MySpace daily, then something is very, very wrong.

-- 
- EricAnderton at yahoo

Get an editor that understands Python ;-) Most will either use whatever that code block uses, or highlight the problem indentation in bright red.

Personally I much prefer the Python way of doing indentation, after all you indent your code anyway making the curly braces somewhat redundant (and I program about equally in C/C++ and Python).

:-) Dan

Pragma wrote:
> 
> Put me in the "old" camp too I guess.
> 
> I've posted before about this, but I still think it bears repeating why this isn't a good idea for D.
> 
> I've been doing some Trac hacking lately so I've come to despise Python's whitespace scheme.  Oh sure, it makes for some nice looking code, but in the end, my code fails compilation after compilation just because I mashed the [tab] key (instead of four spaces) by mistake.
> 
> Recently, I showed an example to my wife (who's not a programmer BTW) of two lines of python code:
> 
>     print('hello world')
>     print('hello world')
> 
> I then told her that "one of those lines is 100% valid code, and the other isn't."  I added that "the bad line will stop my program dead in it's tracks, even though I double checked my work, just as we did.  The difference is one has four spaces and the other a [tab] character."  Her response?
> 
> "Wow, that's pretty lame."
> 
> If the design failure here is easily grasped by someone, who's entire "coding" experience can be summed up in using LiveJournal and MySpace daily, then something is very, very wrong.
>