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

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> What about copy on write?

  What about simply not assigning anything to the parameter if you don't
want to modify it?

-- 
                                                          - Warp

Post a reply to this message

>  What about simply not assigning anything to the parameter if you don't
> want to modify it?

Nothing's wrong with how it is now, maybe the docs
could be changed to reflect that #local can be used
to pass values by parameter to avoid this kind of
confusion.

Post a reply to this message