Tor Olav Kristensen <tor### [at] toberemovedgmailcom> wrote:
> > #macro TEST(A)
> >    #local A = A + 1;
> > #end
> > 
> > #declare B = 1;
> > 
> > TEST(B)
> ...

> Your code above may work, but was it meant to work that way ?
> I.e. Is the behaviour above a bug - or is it a feature ?
> :)

> To me it is illogical that a #local statement should be
> able to change _anything_ outside its scope.

  OTOH, how should it behave?

  Macro parameters are passed "by reference". This means that you can
do this:

#macro TEST(A)
  #declare A = A+1;
#end

and it will modify the original identifier given as parameter.

  You want #local to not to modify the original identifier. So basically
you want #local to make a local copy of the identifier and modify only that.
But then all kinds of problematic situations may arise, for instance:

#macro TEST(A)
  #local A = A+1;
  #declare A = A+1;
#end

  Should the #declare modify the local copy or the original identifier?

  More importantly: There are two A's now, the original and the local copy.
Which 'A' should be used in the right-hand-side of the '=' of the #declare,
the local copy or the original variable? If the #local only modifies a copy,
then this "local A" will have a different value than the original identifier.

-- 
                                                          - Warp

Post a reply to this message

>> Unfortunately in 3.6 passing values by parameter is buggy,
>> it's fixed in the 3.7 beta, but in general you probably shouldn't
>> rely on values being returned correctly via parameter.
>>
> Just for curiosity sake, do you mean in general programming, or only in 
> SDL (and why)?

I meant just for POV SDL, passing values by parameter is the
norm in some languages, and passing values around in global
variables is considered bad form in most languages.

> At the end, I read that a parameter (in programming) is just a variable 
> stored in the stack (and recovered later).

Yeah, an identifier associates the variable name with a location
in memory which contains a value.  In POV a macro can be
passed an identifier, so that associates the parameter name
with the identifier name and location in memory.

Most programming languages don't have different versions
of variable assignment, the scope of a variable is usually
determined by the location it was created.

Post a reply to this message

Nooow works with 3.7 beta :). It happens that i always wait until the 
official release is finished.

Thanks again to all, and pleased to meet you

Post a reply to this message

Warp napsal(a):
> Tor Olav Kristensen <tor### [at] toberemovedgmailcom> wrote:
>>> #macro TEST(A)
>>>    #local A = A + 1;
>>> #end
>>>
>>> #declare B = 1;
>>>
>>> TEST(B)
>> ...
> 
>> Your code above may work, but was it meant to work that way ?
>> I.e. Is the behaviour above a bug - or is it a feature ?
>> :)
> 
>> To me it is illogical that a #local statement should be
>> able to change _anything_ outside its scope.
> 
>   OTOH, how should it behave?
> 
>   Macro parameters are passed "by reference". This means that you can
> do this:
> 
> #macro TEST(A)
>   #declare A = A+1;
> #end
> 
> and it will modify the original identifier given as parameter.
> 
>   You want #local to not to modify the original identifier. So basically
> you want #local to make a local copy of the identifier and modify only that.
> But then all kinds of problematic situations may arise, for instance:
> 
> #macro TEST(A)
>   #local A = A+1;
>   #declare A = A+1;
> #end
> 
>   Should the #declare modify the local copy or the original identifier?
> 
>   More importantly: There are two A's now, the original and the local copy.
> Which 'A' should be used in the right-hand-side of the '=' of the #declare,
> the local copy or the original variable? If the #local only modifies a copy,
> then this "local A" will have a different value than the original identifier.
> 
The specs says #local always creates the most local variable possible 
while #declare writes to the most local existing one. The most local 
existing one will be parsed.

-- 
the ultimate time-killer:
+a0.0 +am2 +r9

Johnny D

Post a reply to this message

> Yeah, an identifier associates the variable name with a location
> in memory which contains a value.  In POV a macro can be
> passed an identifier, so that associates the parameter name
> with the identifier name and location in memory.
> 
> Most programming languages don't have different versions
> of variable assignment, the scope of a variable is usually
> determined by the location it was created. 
> 
> 

In Java you can declare a variable in a block (the most usual usage is 
for(int i=0;i<x.length;i++){..}) or a function, which is then the one to 
be used. To access the class variable you use this.var. To access the 
superclass variable/method instead you call super.var. A variable is 
local to the class/method/block it was declared in.
-- 
the ultimate time-killer:
+a0.0 +am2 +r9

Johnny D

Post a reply to this message

Warp wrote:
> Tor Olav Kristensen <tor### [at] toberemovedgmailcom> wrote:
>>> #macro TEST(A)
>>>    #local A = A + 1;
>>> #end
>>>
>>> #declare B = 1;
>>>
>>> TEST(B)
>> ...
> 
>> Your code above may work, but was it meant to work that way ?
>> I.e. Is the behaviour above a bug - or is it a feature ?
>> :)
> 
>> To me it is illogical that a #local statement should be
>> able to change _anything_ outside its scope.
> 
>   OTOH, how should it behave?
> 
>   Macro parameters are passed "by reference". This means that you can
> do this:
> 
> #macro TEST(A)
>   #declare A = A+1;
> #end
> 
> and it will modify the original identifier given as parameter.
> 
>   You want #local to not to modify the original identifier. So basically
> you want #local to make a local copy of the identifier and modify only that.
> But then all kinds of problematic situations may arise, for instance:
> 
> #macro TEST(A)
>   #local A = A+1;
>   #declare A = A+1;
> #end
> 
>   Should the #declare modify the local copy or the original identifier?
> 
>   More importantly: There are two A's now, the original and the local copy.
> Which 'A' should be used in the right-hand-side of the '=' of the #declare,
> the local copy or the original variable? If the #local only modifies a copy,
> then this "local A" will have a different value than the original identifier.

I see the problem.

(So if this is meant as a feature, it would be nice if the
documentation describes more in detail what effect #local has
on macro parameters.)

Maybe a solution could be to have only one assignment
directive (e.g. #set or #let or none) and let call-by-value
be the default for parameters to macros. call-by-reference
could be indicated by e.g. "var" in the macro declaration.

   #macro TEST(A, var B)
     #set A = A + 1;
     #set B = B + A;
   #end

   #set C = 1;
   #set D = 3;

   TEST(C, D)
   // C is still 1. D has been changed to 5.

Another possibility could be to use "in", "out" and "in out"
in front of the parameters, like in Ada.

http://www.csc.liv.ac.uk/~grant/Teaching/COMP205/paramPassing.html

-- 
Tor Olav
http://subcube.com

Post a reply to this message

Tor Olav Kristensen <tor### [at] toberemovedgmailcom> wrote:
> Maybe a solution could be to have only one assignment
> directive (e.g. #set or #let or none) and let call-by-value
> be the default for parameters to macros.

  That would make the already-slow macros even slower, especially for
larger identifier types...

-- 
                                                          - Warp

Post a reply to this message

>> Maybe a solution could be to have only one assignment
>> directive (e.g. #set or #let or none) and let call-by-value
>> be the default for parameters to macros.
>
>  That would make the already-slow macros even slower, especially for
> larger identifier types...

We could add a specific return command for passing values
by parameter...

#macro foobar(A, B)
   #return A = foo;
   #return B = bar;
#end

Not sure if that's a whole lot better though.

Post a reply to this message

Warp escribió:
> Tor Olav Kristensen <tor### [at] toberemovedgmailcom> wrote:
>> Maybe a solution could be to have only one assignment
>> directive (e.g. #set or #let or none) and let call-by-value
>> be the default for parameters to macros.
> 
>   That would make the already-slow macros even slower, especially for
> larger identifier types...

What about copy on write?

Post a reply to this message

Tim Attwood <tim### [at] comcastnet> wrote:
> We could add a specific return command for passing values
> by parameter...

> #macro foobar(A, B)
>    #return A = foo;
>    #return B = bar;
> #end

  I have a much simpler suggestion: If you don't want to modify an identifier
given as parameter, don't assign anything to it. It's that simple.

  If you need a copy of the identifier, then copy it:

#macro foobar(A)
{
  #local LocalCopyOfA = A;
  ...
}

  No need to make the SDL parser any more complicated than it already is.

-- 
                                                          - Warp

Post a reply to this message