[M3devel] language question -- locals uninitialized or zero?

[Tony Hosking]

Indeed, the explicit NIL will indicate to the reader that the intent is that the variable have the value NIL.
It will be no less efficient (since otherwise the compiler must initialize it implicitly).
Moreover, it documents intent.

On the other hand, where the programmer really does *not* care about the initial value (perhaps because of subsequent assignment before read) I would claim that initializing to NIL only clutters the code and obscures intent.

Of course, there is the other alternative, such as for Java which statically prohibits uninitialized variables (either there is an initializing expression or the variable has a subsequent initializing assignment).  The result is much the same.

In any case, the point is that Modula-3 is *safe* in that no variable can ever have undefined mis-typed state, unlike C, where variables can have arbitrary undefined state.

On Feb 26, 2013, at 4:08 AM, "Rodney Bates" <rodney_bates at lcwb.coop> wrote:

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484





> 
> 
> -Rodney Bates
> 
> --- lemming at henning-thielemann.de wrote:
> 
> From: Henning Thielemann <lemming at henning-thielemann.de>
> To: Antony Hosking <antony.hosking at gmail.com>
> Cc: m3devel <m3devel at elegosoft.com>
> Subject: Re: [M3devel] language question -- locals uninitialized or zero?
> Date: Sun, 24 Feb 2013 10:22:08 +0100 (CET)
> 
> 
> On Sun, 24 Feb 2013, Antony Hosking wrote:
> 
>> I suppose it could, but that would be a space leak.The current implementation sets it to NIL.
> 
> I believe that the question was, whether he can rely on the pointer being 
> NIL, and I think he cannot.
> 
> Yes, he cannot, strictly by the language rules.  Somewhat pragmatically, it seems
> a real stretch to imagine why an implementer would choose anything other than NIL,
> for any reference type.  Even more pragmatically, I am quite sure we have no variant
> of the compiler that uses anything other than NIL.  But to have code that is guaranteed
> to survive any future new implementation, give it an explicit :=NIL.
> 
>