Hi Chris --

> New things are not l-values --- I just tried this and the compiler agrees.
>
> AFAICT the only way you can currently give ref parameters default values is
> something along these lines:
>
> var err = new errorstate();
> proc foo(ref err = err) { ... }

My apologies for not trying my proposed solution before sending it out (I 
didn't actually know whether it would work or not).  Chapel's 'ref' 
intents are a relatively new addition to the language, and I wouldn't be 
surprised if this was the first time anyone had tried providing default 
values for them.  So I think we can afford to redefine what the 
language/compiler does today if it doesn't seem sufficiently 
useful/correct/consistent.

As motivation for changing the way the implementation currently works, 
consider the following program:

-------------------------------------------------------------------------

class C {        // this test also works if C is declared as a record
   var x: real;
}

proc foo(inout x: C = new C(x=1.0)) {
   writeln(x);
   x = new C(x=3.0);
}

var myC = new C(x=2.0);
foo();                     // prints {x = 1.0}
writeln(myC);              // prints {x = 2.0}
foo(myC);                  // prints {x = 2.0}
writeln(myC);              // prints {x = 3.0}

-------------------------------------------------------------------------

Essentially, the 'inout' intent means copy-in/copy-out.  If no actual is 
provided (as in the first call to foo()), then 'x' can be viewed as a 
temporary variable for the duration of the function, as though a variable 
with the value 'new C(x=1.0)' had been passed into the function; the 
copy-out will then be dropped on the floor on exit.  Note that normally 
the actual passed into an 'inout' intent must be a legal l-value (as with 
'ref' intents) but that we permit the 'new C(x=1.0)' expression to be used 
as its default value anyway as a convenience.

Another related case to consider is a simple 'out' argument intent:

-------------------------------------------------------------------------

class C {        // this test also works if C is declared as a record
   var x: real;
}

proc foo(out x: C = new C(x=1.0)) {
   writeln(x);
   x = new C(x=3.0);
}

var myC = new C(x=2.0);
foo();                     // prints {x = 1.0}
writeln(myC);              // prints {x = 2.0}
foo(myC);                  // prints {x = 1.0} (NB: differs from previous)
writeln(myC);              // prints {x = 3.0}

-------------------------------------------------------------------------

In this case, the argument's default value is used as its initializing 
expression (regardless of whether or not an actual is provided).  If the 
actual argument is provided, the argument is copied-out to it at the 
function's return; otherwise it's dropped on the floor.  So this is 
another case where the expectation is that any actual is a legal l-value, 
yet the default value need not be.


So I'm trying to understand whether there would be any reason not to treat 
'ref' intents similarly to the above and have the formal refer to an 
anonymous variable representing the initializing expression.  I'm not 
seeing any immediate reason to not do so, but could be missing something. 
It seems like it would give you what you want here:

> To use C parlance, this is taking a reference to a global variable, whereas
> we want to create a reference to an automatic variable in the call stack.
> Unless I'm missing something, you can't currently do this.

And it seems consistent with the previous two cases.


> The syntax I proposed "ref x? : errorstate" then translates as "if x is
> given, use that, if not then create a new variable of type errorstate in
> the call stack and let x be a reference to that". And "ref x? = new
> errorstate()" would translate as "if x is given, use that, if not then
> create a new variable with value new errorstate() and let x be a reference
> to that."
>
> Even more simply, the question mark means "create a new automatic variable
> if you have to".

I believe I understand what you're proposing, but am just trying to avoid 
adding new syntax to the language if existing syntax suffices (and feels, 
to me, simpler and more consistent with existing concepts).

-Brad

------------------------------------------------------------------------------
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers

Reply via email to