ANN: Dao Language v.0.9.6-beta is release!

[Antoon Pardon]

Op 2005-12-08, Steven D'Aprano schreef <steve at REMOVETHIScyber.com.au>:
> On Thu, 08 Dec 2005 08:23:52 +0000, Antoon Pardon wrote:
>
>> Op 2005-12-07, Steven D'Aprano schreef <steve at REMOVETHIScyber.com.au>:
>>> On Wed, 07 Dec 2005 15:26:59 +0000, Zeljko Vrba wrote:
>>>
>>>> Braces are very convenient to match block start and end. Open a C program
>>>> in the VI editor, and press % in command mode on some brace.. It will take
>>>> you to its matching brace. How do you do something like that with python code
>>>> (or any code that is based purely on indentation..)
>>>
>>> (1) You don't need to, because you can *see* where the indentation
>>> changes, so you don't need to rely on your editor counting for you.
>> 
>> But you can't alway easily discern by how much.
>
> Admittedly, the blind and visually impaired might not. They will need a
> screen reader that understands indentation.
>
> Admittedly, a badly formatted arbitrary piece of text with arbitrary
> indentation from line to line is difficult to judge.
>
> But fortunately we're discussing code, not arbitrary text. Code will not
> jump from one random level of indentation to another: there will often be
> blocks of lines with the same indentation; when the indent level increases
> it should always increase by one only; and when it decreases it will
> usually decrease by one, sometimes two, more rarely three.

Four is not that unusual. The last method in a class and you already
have at least two. If that method ended with an if in a while, not
that uncommon, and you have four.

> If your functions have more than, say, twelve levels of indentation, you
> should be refactoring them.

Well I'm not going to put a hard number on it, but I agree with the gist
of your statement.

> If you are stuck reading other people's code, where they have hard-coded
> indents as (say) two spaces, you may have trouble. But if they are using a
> more standard four or eight spaces, it is easier to judge, and better
> still if they use tabs, you can tell your editor to set the tabs to
> whatever size works for you.

IME it doesn't make that much of a difference whether two spaces are
used, or four. One is too little and more than four is too much, but
between those two it doesn't make much difference for me.

> [snip]
>
>> But sometimes you mess up and your code is no longer indented as it
>> should. If you marked the end of the indentations, you can easily 
>> correct this.
>
> And sometimes you mess up and delete braces you shouldn't have.

Sure and if you have correctly indented your code, that will be
easily corrected too.

> If you
> had Or worse, you delete code you shouldn't have. Whoops!

Lets hope you have a backup.

> Start/end markers (whether braces or keywords) plus indentation carry
> redundant information. Redundancy means you can *sometimes* correct *some*
> errors. But there are costs to redundancy: you have to carry the redundant
> information around (in source code, in your head, in the complexity of the
> parser) for the 99.99% of time that there is no error.

99.99% of the time, I don't need a backup either. Besides what I had in
mind wouldn't force anyone to use end markers. It wouldn't break any
program(with the exception of programs using variable like endif). It
would just allow people to put in the redundancy where they think it would
be usefull.

> And what happens when the indentation and the markers disagree? Languages
> like C decide arbitrarily that the markers are meaningful and indentation
> is not, and it is a potent source of bugs and obfuscation.

Make it an error. That IMO is what redundant information is for, so that
when it doesn't agree, you are alerted to the problem.

> Making a mistake in indentation level is precisely analogous to leaving
> out markers in other languages. If your editor is smart enough, and the
> code is not ambiguous, a smart editor will pick that up straight away. And
> if not, the Python compiler will soon tell you, and you can then fix the
> bug in your code.

A smart editor may just happily continue, putting all further statements
on the wrong indentation level. Besides I hate smart editors. They
always seem to get in my way. This will probably say more about my lack
of knowledge about emacs, but the fact that it always jumps to the
corresponding left parent, bracket or brace when I type the right
character in, just drives me nuts.

Besides no editor has saved me once from the fact that I forget a colon
as last charater of an if, else, try or whatever compound statement,
so why should I rely on the editor for other problems?

-- 
Antoon Pardon