From: james.grosbach@Microchip.COM (James Grosbach)
--IMA.Boundary.151096188
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
     
     Is there any particular reason why the compiler can't assume that 
     passing a reference to a variable may initialize that variable?
     
     If that were the case, then the example below would imply the 
     following:
     
     What is being passed to InitVars() is not really the variable 'msg', 
     but a reference to that variable. The reference is initialized (i.e., 
     it refers to 'msg'), and so the call InitVars(msg) would not produce a 
     warning message about possible usage before initialization.
     
     Since the InitVars() function may or may not be accessible at the time 
     Main() is compiled, it won't be possible to tell if InitVars() really 
     does initialize the object refered to by its parameter. The 
     conservitive assumption is that it does, and the object should be 
     flagged as initialized. Thus, any use of the object 'msg' after the 
     call to InitVars() should not result in the warning message.
     
     It would be possible to be more precise if whenever a procedure is 
     compiled which takes parameters with a 'var' associated, the compiler 
     remembers which of those references are used to store a value to the 
     referenced object and uses that information when processing a call the 
     the function.
     
        Jim Grosbach
______________________________ Reply Separator 
_________________________________
Subject: 'var' modification
Author:  Steve Watkins  at Internet_Exchange
Date:    12/9/97 9:25 AM
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 to 
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 DEFINED. 
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
     
     
--IMA.Boundary.151096188
Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers"
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Content-Disposition: inline; filename="RFC822 message headers"
Received: from titan.Microchip.COM (172.16.245.37) by chccm2.microchip.com 
with
SMTP
  (IMA Internet Exchange 2.1 Enterprise) id 0004DF44; Tue, 9 Dec 97 07:24:24
-0700
Received: from prometheus.Microchip.COM
(firewall-user@prometheus-gate.Microchip.COM [198.175.253.129]) by
titan.Microchip.COM (8.6.12/8.6.12) with SMTP id HAA16644 for
; Tue, 9 Dec 1997 07:18:40 -0700
Received: by prometheus.Microchip.COM; id AA28717; Tue, 9 Dec 97 07:42:27 MST
Resent-Date: Tue, 9 Dec 1997 09:25:04 -0500
Received: from www.semware.com(206.65.52.161) by prometheus.Microchip.COM via
smap (3.2)
	id xma028690; Tue, 9 Dec 97 07:42:11 -0700
Received: from steve.semware.com (unverified [206.65.52.170]) by semware.com
 (EMWAC SMTPRS 0.83) with SMTP id ;
 Tue, 09 Dec 1997 09:22:00 -0500
Received: by steve.semware.com with Microsoft Mail
	id ; Tue, 9 Dec 1997 09:25:05 -0500
Message-Id: 
From: Steve Watkins 
To: "'tsepro@semware.com'" 
Subject: 'var' modification
Date: Tue, 9 Dec 1997 09:25:04 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Sender: tsepro-request@semware.com
Resent-Message-Id: 
Resent-From: tsepro@semware.com
--IMA.Boundary.151096188--
---
---------------