Re: [game-lang] Language Syntax

[Simon McGregor <londonien@xxxxxxxxx>]

>> > [Joel said]
>> > The way that Python forces you to layout your code is
>> > not always the best for readability; judicious use of
>> > whitespace and delimiters, when properly formatted help
>> > readability rather than hinder
>> > it.
>>
>> Interesting. I can imagine this is true, but in the sorts
>> of code I write, I've never come across it.
>
> [Richard said]
> I can't speak to your poor coding skills... :) :) :)
>
>> Did you have any examples in mind?
>
> Sure:
>
> a) if (a==0 && b==1)
> b) if (a == 0 && b == 1)
> c) if ((a == 0) && (b == 1))
>
> I would rank in increasing order of better readability.

I find this Python code clearer still :

if (a==0) and (b==1):
    consequence

...but any of

if a==0 and b==1:
    consequence-block

if ( a == 0 ) and ( b == 1 ):
   consequence-block

if (a==0 and b==1): consequence-statement;

if ((a == 0) and (b == 1)):
   consequence-block

...are equivalent.

The only meaningful whitespace in Python is indentation level, which
defines block nesting, and newlines, are an alternative to ';' for
ending statements, and can be escaped so the statement continues on
multiple lines (they also end single-line comments, which are
regrettably the only comments Python supports).

You are free to use as many brackets as you like, and extra spaces
anywhere which doesn't precede the first complete statement on a line.
Brackets are optional in most tests and loops, but this has nothing to
do with meaningful whitespace (unless you count the whitespace in the
C code "char *p" as meaningful).

> And, when tests get really long, then this is better than c:
>
>  if ( ((a_addr[31:0] == 32'h1234_5678) &&  write_enable && light_on) ||
>       ((b_addr[ 7:0] ==  8'h       1c) && !write_eanble && light_on) ||
>        (catastrophic_failure && doom && gloom && end_of_world) )

It took me 5-15 seconds of bracket-matching to work out which brackets
matched which in this expression, until I realised you meant what
would I would write in Python like this:

if   (a_addr['31:0']=="32'h1234_5678" and write_enable and light_on)   \
  or (b_addr['7:0']=="8'h       1c" and not write_enable and light_on) \
  or (catastrophic_failure and doom and gloom and end_of_world):
      consequence-block

...which, yes, I think is a whole lot more readable (even admitting
that the newline escapes are unsightly).

> Similar blocks of code with variables of different lengths also can be better aligned with whitespace:
>
>  num_players = 3;
>  game_phase  = BIDDING;
>  happy       = 0;
>  sad         = 0;
>  light_on    = 0;

Look, I don't know where you get your ideas about indentation syntax
from, but all of this is perfectly legal and normal in Python code. It
would be weird to make mid-line whitespace meaningful, which is indeed
why it isn't meaningful in Python.

I'm viewing this in a proportional font, so I can't see the spaces
line up, but the Python equivalent of your above code is:

num_players = 3
game_phase  = BIDDING
happy       = 0
sad         = 0
light_on    = 0

...which again, I have to say I find slightly more readable (no
semicolon clutter).


> The bottom line, for me, is that I can appreciate the logic and clarity that indention syntax can theoretically provide.  But the real world intrudes and, in practice, it can be more of a hinderance than a help, especially in the places where you are trying to add clarity by placing things in specific locations.

In every single one of your examples, Python code has the same freedom
with spaces and delimiters as the code you posted. This makes me think
that maybe you misunderstand how indentation syntax works in Python
(and there are indeed some myths around).

In Python, you can place things more or less where you like, providing
you indent whole blocks in consistent and sensible way. For instance,
you can't do the equivalent of this C layout:

if (condition) {
      for (i=0; i<j; i++) { if (other_condition) {
bar();
      foo(); } a[1] = 2;

      }
   }

...which, incidentally is not a million miles away from certain pieces
of code which I have had to debug in the real commercial world.

> And, not to add fuel to the fire, but I'd hope that from a language standpoint:
>   - tabs & spaces are indistinguishable.

There's no way round it: with indentation syntax, they can't be
indistinguishable.
This is slightly annoying, but has a minor benefit in that if you do
in fact mix tabs and spaces, you only think you are controlling your
code's layout. When it's printed or edited by a program with a
different tab size, the layout will change in ways you didn't expect.

>   - no column width limitation.
Which languages have column width limitation? I've never come across
this in Python.

> There may be good style reasons for an individual to code in a certain way, but the language should not mandate their use.
I have real problems envisaging situations where indentation syntax
prevents you from laying out your code in a sensible way. The only
case I can imagine is where a series of nested blocks is somehow
conceptually a single sequence, so you want the same indentation for
the blocks.

For instance,

if (a) {
if (b) {
if (c) {
   consequence
} } }

which would have to be written in Python as

if(a):
   if(b):
      if(c):
         consequence

...but as I say, I've never come across anything like this. Or if I
have, I've made an effort to rewrite it as something more like

if all(
   a,
   b,
   c
):
   consequence


Simon
_______________________________________________
game-lang mailing list
game-lang@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/game-lang