Result not assigned

[Jörgen Tegnér]

Hi list,

the code below compiles fine with SmartEiffel. Obviously it's a bug in
that I forgot to assign anything to Result. Shouldn't the compiler warn
or abort when compiling this code?


class A
creation {ANY}
        make
feature {ANY}
        make is
                local
                        b: BOOLEAN
                do
                        b := hmmm
                end
        hmmm: BOOLEAN is
                do
                end
end -- class A


Jörgen
--
I'm kinda looking forward to the alzheimer's... I'll get to meet new
people every day. I'll never have take the blame for anything. I'll get
to meet new people every day.

[Peter Gummer]

Why? Result is assigned to its default value, i.e. False. Why would the
compiler complain about this? It's perfectly valid.

- Peter

--------------------------------------------------
From: "Jörgen Tegnér" <jorgen.tegner@...>
Sent: Tuesday, July 22, 2008 7:30 AM
To: <smarteiffel@...>
Subject: Result not assigned

> Hi list,
>
> the code below compiles fine with SmartEiffel. Obviously it's a bug in
> that I forgot to assign anything to Result. Shouldn't the compiler warn
> or abort when compiling this code?
>
>
> class A
> creation {ANY}
> make
> feature {ANY}
> make is
> local
> b: BOOLEAN
> do
> b := hmmm
> end
> hmmm: BOOLEAN is
> do
> end
> end -- class A
>
>
> Jörgen

 

[Jörgen Tegnér]

On Tue, 2008-07-22 at 10:06 +1000, Peter Gummer wrote:
> Why? Result is assigned to its default value, i.e. False. Why would the
> compiler complain about this? It's perfectly valid.
>

OK, it's valid code.

Suppose most functions are made to return a result from a calculation,
not just the default value. A warning would then be useful in catching
errors in user code.

I spent an hour looking for a logic bug yesterday when in fact the code
was just a missing Result assignment. Oh well, one more lesson learned.

Jörgen

> - Peter
>
> > make is
> > local
> > b: BOOLEAN
> > do
> > b := hmmm
> > end
> > hmmm: BOOLEAN is
> > do
> > end
> > end -- class A
> >
> >
> > Jörgen
>  

--
I'm kinda looking forward to the alzheimer's... I'll get to meet new
people every day. I'll never have take the blame for anything. I'll get
to meet new people every day.

[Peter Gummer]

Jörgen Tegnér wrote:

> Suppose most functions are made to return a result from a calculation,
> not just the default value. A warning would then be useful in catching
> errors in user code.

A warning would be truly annoying, given that it is extremely common to
leave Result at its default value. Each project would generate thousands of
pointless warnings.

This aspect of Eiffel is one thing that attracted me to the language, having
worked with languages like Delphi and C# that initialise class member
variables to default values but, inconsistently, do not do so for local
variables, instead generating error or warning messages. It used to drive me
nuts: the compiler was smart enough to figure out that the local variable
was uninitialised, but too stupid to initialise it to the default value
appropriate for its type. Eiffel's approach is much simpler.

- Peter
 

[Jörgen Tegnér]

On Tue, 2008-07-22 at 17:43 +1000, Peter Gummer wrote:

> Jörgen Tegnér wrote:
>
> > Suppose most functions are made to return a result from a calculation,
> > not just the default value. A warning would then be useful in catching
> > errors in user code.
>
> A warning would be truly annoying, given that it is extremely common to
> leave Result at its default value. Each project would generate thousands of
> pointless warnings.
>

I mean't the case when not even one assignment was done. Is that common?

There is now a warning for unused local variables. I was thinking of a
similar one for the case of an never assigned Result. A nice small
project for a rainy summerday to get into the compiler details. But only
if it's useful of course.

Jörgen

> - Peter
>  
--
I'm kinda looking forward to the alzheimer's... I'll get to meet new
people every day. I'll never have take the blame for anything. I'll get
to meet new people every day.

[Georg Bauhaus]

On 22.07.2008, at 09:43, Peter Gummer wrote:

> Jörgen Tegnér wrote:
>
>> Suppose most functions are made to return a result from a  
>> calculation,
>> not just the default value. A warning would then be useful in  
>> catching
>> errors in user code.
>
> A warning would be truly annoying, given that it is extremely common  
> to leave Result at its default value.

Provided a function/object has a logically useful default value that
happens to match Eiffel's idea of a default value. The latter is  
possibly
just practical for Eiffel's simplicity model.

> Each project would generate thousands of pointless warnings.


The Java approach is worth considering, too, IMHO: The compiler is  
smart enough
to figure out that the local variable was uninitialised and cries  
``error''
when no value was assigned before the variable is used.
The possible advantage of Java's approach is to prevent logic errors  
caused by the
"academic habit" to leave out what is deemed "obvious".

Can't say I like this silent approach in a programming environment.
Programmer performed inference (of the initial value) may use up more  
time spent
on "debugging the obvious" than a simple forced initialisation with  
the logically
adequate default value.


>
>  It used to drive me nuts: the compiler was smart enough to figure  
> out that the local variable was uninitialised, but too stupid to  
> initialise it to the default value appropriate for its type.  
> Eiffel's approach is much simpler.
>
> - Peter
>
>

--
Georg Bauhaus [phone]
Y A Time Drain  http://www.9toX.de

[Richard A. O'Keefe]

I cut my teeth on Burroughs Extended Algol for the B6700,
where all variables were automatically initialised.

It eventually dawned on me that automatic initialisation
just traded "NOT initialised" for "WRONGLY initialised".

Just two days ago, a gcc warning about an uninitialised
variable alerted me to a real bug in some C code, a
bioinformatics package produced by a famous organisation
and actively maintained.

--
If stupidity were a crime, who'd 'scape hanging?

[Philippe Ribet]

Jörgen Tegnér wrote:

>On Tue, 2008-07-22 at 17:43 +1000, Peter Gummer wrote:
>  
>
>>Jörgen Tegnér wrote:
>>
>>    
>>
>>>Suppose most functions are made to return a result from a calculation,
>>>not just the default value. A warning would then be useful in catching
>>>errors in user code.
>>>      
>>>
>>A warning would be truly annoying, given that it is extremely common to
>>leave Result at its default value. Each project would generate thousands of
>>pointless warnings.
>>
>>    
>>
>
>I mean't the case when not even one assignment was done. Is that common?
>
>There is now a warning for unused local variables. I was thinking of a
>similar one for the case of an never assigned Result. A nice small
>project for a rainy summerday to get into the compiler details. But only
>if it's useful of course.
>
>  
>

Yes, it is really common in Eiffel not to assign a value to Result
because it is initialised with a default value as everything else. It
has a sense to let the default value unchanged. May be some specific
child will redefine this function and always set the Result to True. It
is common in OO programming!

The unsused local variable is very different case: as it is local, if it
is unused it is useless (it can't be used elsewhere).

One good practice in Eiffel could limit such errors: first write pre-
and post-conditions. If you write your post-condition, probably you will
specify some property of the result. It's just one more reason to write
assertions. The more you use Eiffel, the more you understand how
valuable the assertions are.

Sorry for the late answer, it was hollidays time ;-)

--

             Philippe Ribet


SmartEiffel:
one methodoology, one language,
highest quality kept secret.
Visit http://smarteiffel.loria.fr