Am 13.07.2021 um 12:05 schrieb Mr:

> Coming from Python I know that my apriori not (yet) feeling the same about this
> is probably thus biased, but could you please also develop more about why as a
> user you would prefer an abundant punctuation over a meaningful indentation
> system ?

Indentation is trouble.

If you ever encounter a source file that mixes tab-indented and 
space-indented code, you may realize what I mean. In languages that 
don't assign semantics to indentation, such a mix results in eyesores at 
worst. In languages where whitespace matters, it can get far worse.

The core problem there of course is that there are different standards 
how many spaces a tab should be worth: Two? Four? Eight? Three? Six? 
Five? Been there, seen all of those.

And it's not like you can tell at a single glance what's going wrong 
there, with tabs and spaces both being entirely invisible and therefore 
looking identical.


And if you've ever edited makefiles (or proto-makefiles as used in 
Autoconf-based build systems), you really learn to hate languages that 
assign semantics to whitespace. If you set your editor to replace tabs 
with spaces, you _will_ break your makefiles.

(Granted, most indentation-aware languages don't assign different 
semantics to tab indentation vs. space indentation.)


So there's the tab issue, for starters.


The next issue of indentation-structured languages - or at least those 
that use a hard "end of line is end of statement" rule - is that they 
put a practical limit on how complex you can make a single statement. If 
you have a very complex mathematical formula, you need to break it up 
into smaller chunks, assign those to variables, and then assemble those 
into your final result. Or even more interim results first.

Now it can be argued that this forces you to give more structure to your 
code, thus making it easier to understand.

However, breaking up an expression into named sub-expressions is not the 
only way to structure complex formula. Specifically, even short formulae 
might benefit from being spread out over multiple lines. And maybe 
liberally peppered with indentation without having to worry about 
breaking semantics.

And what if you're just using a formula from someplace else, and have no 
idea whatsoever what the individual portions of the formula really mean? 
Or if you've optimized a mathematical expression for performance in such 
a way that its original "natural structure" is no longer visible anyway?

What you'll then do is use meaningless single-letter variable names to 
the sub-expression, and the resulting code will look far more complex 
and far more difficult to grasp than it would have, could you have 
written it as a single expression spread over multiple lines and 
indented freely.

And speaking of variable names, restricting the practical length of a 
statement may actually lead to poorer rather than better code, in that 
people may develop a habit of keeping variable names short and thus 
potentially more cryptic.

(Some "end-of-line-aware" programming languages allow spreading 
statements across multiple line by "invalidating" a line ending, but the 
corresponding syntax tends to be somewhat clunky. If you've ever done 
much C/C++ preprocessor programming, you'll know what I mean. What's 
more, such syntax often breaks in the presence of stray blanks at the 
end of a line, which are a pain to find.)


Also, sometimes it may actually improve readability to put multiple 
short statements on a single line (especially when there's a group of 
statements that repeats in structure). Some end-of-line-aware languages 
allow this (e.g. shell scripts), but again generally at the cost of 
added symbols and therefore clunkiness.

Of course it can be argued that whitespace-agnostic languages need the 
same extra symbols between statements, not only in a single line but 
also between lines. But in my mind separator characters become less 
clunky if they're used consistently throughout, as opposed to just on 
special occasions.


And then there's the matter of copy-and-pasting:

When you copy-and-paste code from arbitrary sources (a web page here, a 
PDF there, a terminal window over there, and what else you might happen 
to come across), you may end up with broken indentation.

If the code is reasonably complex, have fun faithfully restoring the 
original semantics.

If the semantics is all in the non-whitespace, smart editors may 
actually be able to restore the original indentation, at least to the 
point that its structure is agion easy enough to grasp for a human. If 
semantics is in the indentation itself, how could an editor ever restore 
that indentation?


Also, look at written human language: There's a reason we're using 
special characters to indicate the boundaries between sentences and 
subclauses, rather than using a "one line = one sentence" default rule 
and using special syntax to spread sentences across multiple lines.


Now I can't rule out that Python may for some reason manage to get 
around each and every one of the above issues - I've had virtually no 
exposure to that language yet. But based on my experience with other 
end-of-line- and indentation-aware languages, my guess is that at least 
some of those issues do apply.

But even if Python should be entirely immune, that doesn't mean it would 
be easy to design a new POV-Ray SDL that is also indentation-aware and 
has the same level of immunity as Python.

And yet, feel free to throw together a corresponding proposal, and 
present it here. Even if it should turn out to be seriously flawed, 
there may still be interesting and inspiring morsels in there.


Heck, I've never claimed that my own proposal was really any good. I 
just threw it out there to have _some_ starting point. For discussion at 
worst, or for further development at best.

As a matter of fact, I don't even _particularly_ like it. It's not very 
elegant, because it is not custom-tailored to our needs. It is derived 
from an existing base. It does have interesting properties though, one 
of which arises _specifically_ out of being derived from an existing 
base. And for now I think it has the potential to be useful, and maybe 
even reasonably good.

No worse than the current SDL, and better structured - that's all I'm 
asking of a new SDL. Ideally with consistent syntax between scene 
descriptions and functions, and maybe with a rigorous enough structure 
to allow for a compiling rather than interpreting parser.

Post a reply to this message