8b330001
From: Chris Lee 
I think it is correct to warn that the variable may be used before
initialization for the VAR modifier; the warning can catch
initialization errors of local variables.  It generally a safe
programming practice to initialize all variables.  Here's a revision of
your example:
    proc InitVars( VAR string s )
        s = "Hello"
    end
    proc Main()
        string msg[10] = ""			// proper initialization, no warning
        InitVars(msg)
    end
What is needed is a CONSTVAR modifier (I'm assuming here that variables
are passed on the stack).  For example:
    proc PrintString( string s )
		WriteLine( s )        
    end
    proc Main()
        string msg[255] = "some big long string..."	
	PrintString( s )
    end
A copy of msg would be made and passed to procedure PrintString.  With a
CONSTVAR modifier:
  proc PrintString( CONSTVAR string s )
		WriteLine( s )        
    end
    proc Main()
        string msg[255] = "some big long string..."	
	PrintString( s )
    end
Then a reference to msg would be passed, avoiding copying the string and
guaranteeing the caller (Main()) that msg wasn't modified by
PrintString.
The important point here is the guarantee that PrintString cannot modify
the variable; that aside, the VAR modifier behaves this way already.
The VAROUT modifier provides an unnecessary workaround for a legitimate
compiler warning;  the proper solution would be to initialize the
variable before use.
CSL.																																																																				
			
>-----Original Message-----
>From:	Steve Watkins [SMTP:steve.watkins@semware.com]
>Sent:	December 9, 1997 6:25 AM
>To:	'tsepro@semware.com'
>Subject:	'var' modification
>
>Here's an issue for those of you who have a little spare time to think this
>thru.  If you don't have the time, don't worry with it.
>
>In the current TSE macro language we have a 'var' modifier.  This is used to
>specify that a variable passed as a parameter to a procedure can be modified
>by that procedure.
>
>But one of the problems is this: (Consider the following macro)
>
>    proc InitVars( VAR string s )
>        s = "Hello"
>    end
>
>    proc Main()
>        string msg[10]
>        InitVars(msg)
>    end
>
>When 'msg' is passed to InitVars() an error message is given that 'msg' is
>possibly used before initialization.  But the intent of InitVars() here is 
o
>initialize the variable.
>
>One of the little additions in the next SC is the addition of a 'varout'
>modifier.  This is used when a procedure will DEFINE the variable before
>returning but does not need the variable to be initialized when it's passed
>to the procedure.
>
>Allowing
>
>    proc InitVars( VAROUT string s )
>        s = "Hello"
>    end
>
>does not require that 'msg' is initialized when passed to InitVars().
>Moreover, 'msg' is then considered DEFINED after the call to InitVars()
>(possibly avoiding additional warnings and errors).
>
>But here's the issue:
>
>    'VAROUT' does not require the variable passed to already be defined, and
>it considered DEFINED once passed to the procedure.
>
>    But 'VAR' _does_ require the variable to be initialized before it is
>passed and the returned value is not considered DEFINED by the function.
>
>So: What I'm considering is making 'VAR' mark the passed variable as 
EFINED.
> Thus the 'VAR' parameter would still require the variable to be initialized
>before it is passed but henceforth is considered DEFINED.
>
>Aside: The difference in my terms INITIALIZED and DEFINED is that any global
>variable is INITIALIZED by SC to a known value.  But it is not considered
>DEFINED until that variable is assigned a value by the user. This is one way
>of fleshing out unused variables.
>
>Here's the change in tabular form:
>
>
>                    Variable must be            Variable is DEFINED
>                    Initialized before          upon exiting procedure.
>                    passing
>
>Currently:
>
> (not supported)    No                          No
> (not supported)    No                          Yes
>VAR                 Yes                         No
> (not supported)    Yes                         Yes
>
>Proposed:
>
> (not supported)    No                          No
>VAROUT              No                          Yes
> (not supported)    Yes                         No
>VAR                 Yes                         Yes
>
>So, the main question is:
>
>Are there any real-world problems changing the 'VAR' modifier to mark the
>passed variable as DEFINED?  (I can come with some but they are more
>contrived than real)
>
>Steve
>
---
---------------