question about byRef behavior

I have a question about "byRef" behavior in the following code fragment:
 

 function x(s)          'by default, s is passed "byRef" 
     s="altered by x()" 
 end function
  
 sVar="zero"
  
 x(sVar)
 msgBox sVar
  
 call x(sVar)
 msgBox sVar
 

 
The first time function x() is invoked, using the "x(sVar)" form,
sVar is not modified after x() returns.
 
But the second time function x() is invoked, using the "call x(sVar)"
form, sVar is modified, as expected, after x() returns.
 
Can someone explain why the first invocation of x() failed to let
x() modify sVar? This seems like very nuanced behavior. Is it
always necessary to use the "call " keyword if you want explicit
"byRef" behavior?
 
-Thanks, Terry Horwath

Hi thorwath,

a short answer:

  (1) sRet = x( sVar )      
 
calls function x() AS a Function and passes sVarby reference (as it was intented by
the author); the () are for used to delimit the (short) parameter list - and to indicate
(redundantly) that this is a function call
                       
  (2) x sVar               
 
calls function x() AS a Sub (of course, on wonders why); sVar will be modified by x();
no () hints at the fact, that this a Sub call

  (3) x( sVar ) - better written as
        x (sVar)
 
calls the function AS a Sub, but passing sVar by Value - indicated by the
() around the variable name; the () may be looking like parameter list
parantheses, but they aren't

  (4) Call x( sVar )
 
calls x() As a Sub; because Call *needs* the parantheses (to indicate
that a function is called AS a Sub), the () aren't interpreted as
'please pass per Value' parantheses

  (5) Call x( (sVar) )
 
will be behave as (3).

a longer discussion:

   http://www.visualbasicscript.com/m_40908/tm.htm
  
I agree with ebgreen's conclusion:

   There is really just two things to remember if you avoid Call: 

     1) If the procedure returns a value, put () around the parameters.
     2) If the procedure does not return a value, don't put () around parameters.
    
This will guide you right for 99% of your VBScript programming without
following my meanderings or learning by heart the rules TNO cited, especially
if you don't call Functions As Subs, but use each of these different types
of NamedCodeBlocks/procedures as theirs authors intended them to be used (or
wrap bad designed ones in better Functions OR Subs of your own).
 

Thanks so much for providing this type of detailed information. As a newby to this
lang, I find some of the basic contructs just difficult to get a handle on, due to
making erroneous assumptions based on other past-life langs. And the feedback I
get here is just great.

I have carefully read your reply and that very detailed thread you referenced above,
with TNO's (and others) detailed rules. Based on that review, I would also like to
confirm the following new assumption:

If I am willing to allways use the call prefix, I think I can always using () to wrap my passed
parms, even if the sub or func does not take parms, when I not using a return value.
In the case where I am using the return value from a func, I won't use the  call prefix,
but will always use the ().

It that assumption correct? I guess I am trying to find a technique where I can allways
enclose the passed parms in (), whether it is a sub or a func.

Also, I have one final question based on the mention of a lang construct:

(from one of the replies in the referenced thread)

"Yes, it works; but those () aren't parameter list () , but "please pass per
value" parantheses, that - by nature and  definition - can be put around
just one element.

Add to this that the VBScript Docs WRONGLY put parameter list () all over the
place - probably the docs and/or the documenters were infected with a heavy
dose of Javascript - it's no wonder, Subs, Functions, and () aren't easy to
get right in VBScript".

I have gone back to the Microsoft online help file [Microsoft vbScript Help.CHM],
which I have assumed is the bible on this lang, and I can't find any entries
for either "()", "parameter" or "parameter list". This search also failed in my
vbScript in a Nutshell book as well. So what the heck is the "parameter list"
construct anyway? Or, is this just a slang way of refering to the any set
of params passed to a sub or func?

-Thanks, Terry

A parameter list is simply a list of values passed to a Function or Sub Procedure inside the () symbols. In JavaScript and alot of other Object Oriented Programming languages a Parameter List  is treated like an associative array and can be treated as such. This term was probably just inherited into vbscript by its makers by a force of habit (C++) and doesn't mean anything more in this language besides being a simply list.

To iterate is human, to recurse divine. -- L. Peter Deutsch

I called about half of the () in my postings related to this topic "parameter
list parentheses", because

  (a) they are used in VBScript to this aim for functions

  (a) they must be carefully differentiated from "please pass this argument
      by value" () that may be used for parameters of Subs or Functions

Perhaps I should have bolded ebgreen's

  2) If the procedure does not return a value, don't put () around parameters
 
or paraphrased it like:

  3) The parameter list of a Sub call isn't delimited by (); if you see a () after
       the name of a Sub it's either the second type or a syntax error
    
In some languages you can't call anything without (); if you have no parameters to
pass or don't want to tell just now you have to put () around the empty list; sometimes
you must put a void or an ellipsis between the () to help the compiler along. Still
other languages don't use parameter list () at all (Tcl, shells); as to the Perl you
mentioned: D. Conway's best practice for parantheses is to avoid them for builtins and
'honorary' builtins.

That's why I wouldn't strive to "find a technique where I can allways enclose the passed
parms in (), whether it is a sub or a func". I would accept the hard (?) fact of life
that Subs aren't Functions and that in VBScript the second need "parameter list parentheses"
and the first don't. Then you can forget about Call (as a further means of muddle the difference)
and keep your mind alert for those  cases where special (fancy?) parameter passing forces you
to think about "protect this param" ().

After reading this again, I think I must add: All the above concerns the calling of NamedCodeBlocks.
If you want my simple rule for the defining of any NamedCodeBlocks whatsoever - Subs, Functions,
with no arguments, with 42 parameters, ....

         Put parameter list () after the name in any case

I never had problems with this, but YMMV.