Python-like tabs instead of curley brackets?

Chris Nicholson-Sauls ibisbasenji at
Sun Oct 29 21:27:19 PST 2006

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

More information about the Digitalmars-d mailing list