Re: [game-lang] Language Syntax

[Simon McGregor <londonien@xxxxxxxxx>]

Hi Richard :-),

On Mon, Aug 2, 2010 at 9:28 PM, Richard Walter <rwalter42@xxxxxxxxx> wrote:
> Simon,
>
> I'm genuinely confused now.

I think I see why you are confused. There's been a misunderstanding somewhere.

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

Right, this was in response to Joel's entire paragraph:

> The way that Python forces you to layout your code it not always the
> best for readability; judicious use of whitespace and delimiters, when
> properly formatted help readability rather than hinder it.

I interpreted this to mean that there were cases where Python forced
you to lay out your code in a way which prevented the judicious use of
whitespace and delimiters to help readability.

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

Right, because I was interested in hearing about examples where Python
(and in particular the indentation syntax, which was the only part of
the language which I was actually cheerleading for) forces you to lay
out your code in a way which hinders readability. I'm perfectly
willing to believe that there are such examples, but I can't really
imagine them and I'm interested to see them.

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

The indentation syntax isn't my rule, it's Python's syntax - which the
example doesn't break.

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

Judicious use of whitespace is very helpful. However, I have never yet
seen an example where judicious use of non-standard indentation for
nested logical blocks (i.e. not within individual statements) is
useful, and I've seen many examples where injudicious use of
non-standard indentation is harmful, so that's a good reason in my
opinion not to allow arbitrary use of whitespace for variable
indentation.

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

I agree it's clearer and concise to express in formal language;
however, if you try coding with it for a little while, it's
intuitively natural. Honestly, it's not hard to learn, mainly because
it was designed specifically around human visual parsing of text.

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

You're right of course! There's no perfect solution. But indentation
syntax makes it harder to create unnecessarily bad-looking code, which
to my mind is a good thing.

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

All I'd say is, give it a try and see whether it's really difficult to
live with the one true way. I know I'm repeating myself, but I
honestly can't think of an example (well, maybe a tiny few corner
cases, where there are workarounds anyway) where anyone I know would
like to indent differently from the way which is mandated in Python.
OK, strictly speaking, "would like other people to indent
differently", since there's always the "I can't be bothered to indent
my code" reason ;-).

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

> 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.
Judicious design of indentation syntax can make most examples of this
syntax errors.

>  b) Copy/paste code may or may not work, depending on whether the source, destination, and copy process maintain byte-exact code.
Again, mostly this will just throw a syntax error and take 2 seconds
to fix with search and replace.

>     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.
In a reasonable indentation syntax (like Python's), it doesn't matter.

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

I don't find this hard. Python does mandate an editor which can show
you tabs, but who codes in WordPad? (Maybe some people do - do you
really want to?)

> The bottom line is that humans are visual.  If two things *look* the same, then they ought to *behave* the same.

Tabs don't actually look like anything. That's the problem. Sometimes
they look like one thing, sometimes another.

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

Indentation syntax is part of the language. If C is edited by someone
who doesn't appreciate shortcut "||" (i.e. that "or" is not
commutative), the program will change.

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

True. I have no idea how often this happens in practice. There may be
good examples of it happening to Python code (although in most cases,
if tabs are replaced with a fixed number of spaces, the code will
function identically).

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

I think if you can't read all of the line above your current line of
code, you have bigger problems than merely deciding whether the
indentation is meaningful (which will usually be obvious anyway since
newline continuations are generally used within single statements).

This is not to say that everyone has to like indentation syntax. Each
to his/her own. But I'd advocate people giving it a go before making
their minds up on whether it's a good thing or not!

Sorry, this has all been a bit of a diversion anyway. We don't want
indentation syntax, since several people are strongly against it. We
ought to get back to reviewing GALA, fluent calculus and suchlike.

Best regards,


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