headers
Jörgen Tegnér | 21 Jul 23:26

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

-- 
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.
Permalink | Reply |
headers
Peter Gummer | 22 Jul 02:06
Favicon

Re: Result not assigned

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 <at> telia.com>
Sent: Tuesday, July 22, 2008 7:30 AM
To: <smarteiffel <at> loria.fr>
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
(Continue reading)

Permalink | Reply |
headers
Jörgen Tegnér | 22 Jul 09:22

Re: Result not assigned

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
(Continue reading)

Permalink | Reply |
headers
Peter Gummer | 22 Jul 09:43
Favicon

Re: Result not assigned

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
Permalink | Reply |
headers
Jörgen Tegnér | 22 Jul 12:22

Re: Result not assigned

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.
Permalink | Reply |
headers
Philippe Ribet | 10 Aug 22:10

Re: Result not assigned

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.
>
>  
>
(Continue reading)

Permalink | Reply |
headers
Georg Bauhaus | 22 Jul 12:30

Re: Result not assigned


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".
(Continue reading)

Permalink | Reply |
headers
Richard A. O'Keefe | 23 Jul 02:06
Favicon

Re: Result not assigned

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

Gmane