View mode: basic / threaded / horizontal-split · Log in · Help
April 26, 2012
OT: Indent-sensitive languages again (was: Docs: Section on local variables)
On 25/04/2012 12:30, Stewart Gordon wrote:
> On 21/04/2012 17:26, Andrej Mitrovic wrote:
> <snip>
>> Next thing you know the compiler will start warning me when I indent
>> my code with uneven number of spaces!
>
> Or more usefully, warn if you have a mishmash of tab and space indentation.
>
> How do indent-sensitive languages (Haskell, Python, whatever else) deal with mixed
> tab/space indentation, for that matter?

Just found out
http://urchin.earth.li/~ian/style/haskell.html
http://www.secnetix.de/olli/Python/block_indentation.hawk
that both Haskell and Python uses a tab size of 8 characters.  Personally, I think they 
should error if the meaning of a section of code depends on the tab size.

OTOH, YAML avoids the issue in the strictest way possible: forbidding tab characters.  I 
wonder if there are other languages that require you to indent with tabs.

But one possible design for languages like these is to allow indentation to be either 
entirely spaces or entirely tabs, but not a mixture.  This would also be a good way for 
linters for a variety of languages to behave.

Another way would be to allow tabs, spaces or a mixture, with the only restriction being 
that a given block must be consistently indented with the same sequence of tabs/spaces.

Stewart.
April 26, 2012
Re: Docs: Section on local variables
On 04/25/2012 06:10 PM, Andrej Mitrovic wrote:
> On 4/25/12, Stewart Gordon<smjg_1998@yahoo.com>  wrote:
>> Even if it's left over from debugging, it
>> looks silly, and
>> might lead other people reading the code to believe something's wrong.
>
> There's about a million ways to make code unreadable, and nobody
> writes pitch-perfect code that has absolutely no leftover code or
> comments.
>
> And what if you're refactoring and you do multiple builds every couple
> of seconds? You add a variable, remove it, etc etc. Enabling this
> warning will just make for a noisy compiler. Keeping variables clean
> is the responsibility of the programmer and not the compiler.
>
> If it doesn't affect the semantics of code the compiler should shut
> up. Please don't turn the compiler into a reincarnation of Clippy.

+1.

Another thing: It might not be unused in every static code path.

Even more important:

template isInputRange(R)
{
    enum bool isInputRange = is(typeof(
    {
        R r;              // can define a range object
        if (r.empty) {}   // can test for empty
        r.popFront();     // can invoke popFront()
        auto h = r.front; // can declare an unused variable
    }()));
}

Having these kinds of errors in the compiler would be a major PITA that
butchers the language without any benefit for correct code. This should
not be the responsibility of the compiler. It is not a good match for D.
April 26, 2012
Re: Docs: Section on local variables
On 26/04/2012 08:26, Timon Gehr wrote:
<snip>
> Another thing: It might not be unused in every static code path.

One way to deal with this would be to do the checking before conditional compilation. 
That said, I've a feeling that mixin expansion might get in the way of this.

> Even more important:
>
> template isInputRange(R)
> {
> enum bool isInputRange = is(typeof(
> {
> R r; // can define a range object
> if (r.empty) {} // can test for empty
> r.popFront(); // can invoke popFront()
> auto h = r.front; // can declare an unused variable
<snip>

cast(void) r.front;

Stewart.
April 26, 2012
Re: OT: Indent-sensitive languages again (was: Docs: Section on local variables)
Stewart Gordon:

> But one possible design for languages like these is to allow 
> indentation to be either entirely spaces or entirely tabs, but 
> not a mixture.  This would also be a good way for linters for a 
> variety of languages to behave.

Among the arguments of the Python2.6 interpreter there is also:

-t     : issue warnings about inconsistent tab usage (-tt: issue 
errors)

"inconsistent tab usage" means mixing tabs and spaces.

Bye,
bearophile
April 26, 2012
Re: Docs: Section on local variables
Timon Gehr:

> Andrej Mitrovic:
>> Keeping variables clean
>> is the responsibility of the programmer and not the compiler.
>>
>> If it doesn't affect the semantics of code the compiler should 
>> shut up. Please don't turn the compiler into a reincarnation 
>> of Clippy.
>
> +1.

I think currently the D compiler doesn't shut up in some cases.

Comparing the unused variable warning with Clippy is not good. 
Clippy gives suggestions, while here the compiler is giving 
something more like an error message.


> Another thing: It might not be unused in every static code path.
>
> Even more important:
>
> template isInputRange(R)
> {
>     enum bool isInputRange = is(typeof(
>     {
>         R r;              // can define a range object
>         if (r.empty) {}   // can test for empty
>         r.popFront();     // can invoke popFront()
>         auto h = r.front; // can declare an unused variable
>     }()));
> }

If the unused variable is a warning, and I use "-wi" that code 
compiles.

The warning for unused variables helps me clean up my C code and 
has avoided me more than one bug. So I'd like this optional 
warning in the D front-end. I'd even like a warning for variables 
assigned and then later never read again.

Bye,
bearophile
April 26, 2012
Re: Docs: Section on local variables
On 26/04/2012 08:26, Timon Gehr wrote:
<snip>
> template isInputRange(R)
> {
> enum bool isInputRange = is(typeof(
> {
> R r; // can define a range object
> if (r.empty) {} // can test for empty
> r.popFront(); // can invoke popFront()
> auto h = r.front; // can declare an unused variable
> }()));
> }
<snip>

This is indeed a blocker for fixing it to work according to the current spec.  I've just filed
http://d.puremagic.com/issues/show_bug.cgi?id=7989
to address it.

Stewart.
April 26, 2012
Re: Docs: Section on local variables
On 26/04/2012 15:05, Stewart Gordon wrote:
<snip>
> http://d.puremagic.com/issues/show_bug.cgi?id=7989

From JMD:
"The fact that isInputRange and isForwardRange rely on
declaring variables which aren't used being legal. It would be really annoying
for unused local variables to be illegal when dealing with template constraint
stuff like isInputRange and isForwardRange. Code would have to be needlessly
contorted to deal with that fact, and you wouldn't ever get a good error about
why the result of the template was false, because it would be part of a
template constraint.

IHMO, the very issue that this bug report brings up highlights a good reason
why unused local variables should continue to be ignored by the compiler."

(on 3960)
"I think that issue# 7989 is a great argument for why there shouldn't be any
warnings or errors for unused variables. Such would needlessly make writing
template constraints harder."

Since this is relevant to both issues, I'll continue the discussion here.

I can begin to see why it makes errors for unused variables a bad idea.  But why no 
warnings?  Obviously the user wouldn't like to see warnings thrown at them when they try 
using templates with such constraints.  But:

- The average programmer is, the vast majority of the time, not writing template 
constraints, but trying to write bug-free application code.
- A quality compiler would swallow warnings generated by the content of IsExpressions, 
just as it already swallows errors generated by them - the only difference being that 
warnings don't cause the IsExpression to return false.

Stewart.
April 26, 2012
Re: Docs: Section on local variables
On Thu, 26 Apr 2012 14:46:38 -0400, Stewart Gordon <smjg_1998@yahoo.com>  
wrote:

> I can begin to see why it makes errors for unused variables a bad idea.   
> But why no warnings?  Obviously the user wouldn't like to see warnings  
> thrown at them when they try using templates with such constraints.  But:
>
> - The average programmer is, the vast majority of the time, not writing  
> template constraints, but trying to write bug-free application code.
> - A quality compiler would swallow warnings generated by the content of  
> IsExpressions, just as it already swallows errors generated by them -  
> the only difference being that warnings don't cause the IsExpression to  
> return false.

I think the mechanism is highly desired, but gets in the way in a select  
few situations.  The best answer IMO is to disable that mechanism when  
it's not desired.  It's then an opt-out mechanism that doesn't require  
instrumenting most code.

Some ideas:

pragma(used) int x;
@used int x;

-Steve
April 26, 2012
Re: Docs: Section on local variables
On Thursday, April 26, 2012 19:46:38 Stewart Gordon wrote:
> I can begin to see why it makes errors for unused variables a bad idea. But
> why no warnings? Obviously the user wouldn't like to see warnings thrown
> at them when they try using templates with such constraints. But:

The existence of -w makes it so that warnings are just as bad as errors for 
something like this, since it makes warnings errors. The result is that there 
is a minimal difference between warnings and errors with dmd.

And honestly, while I agree that code shouldn't normally have unused 
variables, I so rarely see code with any that I think that it's a complete 
non-issue in general. I don't even know the last time that I saw an unused
variable left in code (except for on purpose in something like isInputRange).
I'd much prefer that warning about that sort of thing be left up to a
lint-like tool.

- Jonathan M Davis
April 26, 2012
Re: Docs: Section on local variables
Jonathan M Davis:

> I don't even know the last time that I saw an unused
> variable left in code (except for on purpose in something like 
> isInputRange).

So if the compiler warns you of unused variables, this will not 
cause your code almost no warnings. No troubles for you. For 
uncommon situations like isInputRange a specific annotation 
solves the problem cleanly.


> I'd much prefer that warning about that sort of thing be left 
> up to a lint-like tool.

How many C/C++ programmers do you know that use lints? I think 
not enough. The Microsoft C++ compiler and Clang are adding more 
and more compile-time tests, replacing lints, this a trend D 
designers can't ignore. So saying "leave it to lints" it's almost 
like saying "ignore the problem".

Bye,
bearophile
1 2 3 4
Top | Discussion index | About this forum | D home