Re: [game-lang] Language Syntax

[Richard Walter <rwalter42@xxxxxxxxx>]

Simon,

I'm genuinely confused now.

Joel said:
  "Judicious use of whitespace and delimiters, when properly formatted help readability rather than hinder it."

You responded:
  "Interesting. I can imagine this is true, but ... I've never come across it."

I then responded with examples of code where the "judicious use of whitespace" helped readability.

You then translated my examples into Python, *including the judicious use of whitespace*, to say "See, Python can do this, too."

Even your version of the multi-line example:

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

breaks your rule about meaningful whitespace at the front of lines indicating indention level.  And, it also breaks up the alignment the two addresses and the clear use of the 'not' on the second line.

I want to clearly show the pattern that emerges, so this would be better:

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

So, I'm not really sure where you are coming from - Is judicious use of whitespace helpful or not?  If so, then why not allow it's free use whereever.  If not, then why do your (counter-)examples show it?

We have two potential rules:

Rule A: Whitespace is never meaningful.
Rule B: Whitespace at the begining of the lines is meaningful and used to indicate functional indention level, except when the previous line ended with an '\' to escape the newline, in which case whitespace at the beginning of the next line is not meaningful.  Whitespace not at the beginning of the line is not meaningful.

And I see rule A as being way clearer & concise than B.

> 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;
>
>      }
>    }

Serious question: Why can't I do this in python?

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


My point being that it's possible to create bad-looking code in pretty much any language.

Trying to madate "good code style" by fixing rules in the syntax seems like a bad thing.  You're taking the definition of what is "readable" & "good" out of individual control and moving it into the realm of the laguage itself - essentially forcing everyone to live with the "one-true way" whether they like it or not.

> > - tabs & spaces are indistinguishable.
> 
> There's no way round it: with indentation syntax, they
> can't be indistinguishable.

Yes, that's part of the reason that I advocate not using indention syntax.

If tabs & spaces are not indistinguishable, then you get the following bad results:
  a) Two files look the same in a text editor, but are functionally *different*.
     Debugging this can be extremely frustrating.  This is one of my major sources of irritation with make.
  b) Copy/paste code may or may not work, depending on whether the source, destination, and copy process maintain byte-exact code.
     Copying some code from a web page could corrupt the contents in unpredictable ways.  I don't know if copying out of .pdf's preserves tabs/spaces.  Text editors may try to be "helpful".
  c) Typing code from a printed source becomes perilous - knowing when to type tab and when to type space.
  d) Modifying other code becomes more tedious.  I need to specifically look at whether the code uses tabs/spaces and ensure that my editor inserts the same characters at the start of the lines.  Yes, python has blazed the trail and maybe newer text editors have sane rules to deal with python, but just like I don't want to mandate style, I don't want to mandate a particular editor(s) either.
  
The bottom line is that humans are visual.  If two things *look* the same, then they ought to *behave* the same.

> When it's printed or edited by a program with a
> different tab size, the layout will change in ways you
> didn't expect.

And if python in printed or edited by someone who doesn't appreciate indention syntax, then the *program* will change in ways you didn't expect.

When whitespace is not meaningful, then I can take "badly formatted" source code and can reconstruct a nice looking version with only understanding the syntax rules (and can write a program to do it for me, if I need to do it alot.)  If an indention syntax program is mangled, fixing it becomes a much, much harder problem to try to decide where statements fit into the logical flow.  


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

Fortran has (had?) specific column restrictions, including a 72-column limit.  And yes, I think that that is bad and should be not imposed today.

However, if you pair indention syntax that has an \ escape character to indicate that the next line is a continuation with an unlimited line length, then you have the problem that indication of whether the indention on line X is meaningful or not may be off the screen on the line above.

-Richard



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