Python-like tabs instead of curley brackets?

[Nils Hensel]

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