While making the rounds of “compiler magic” functions, I bumped on iif, the ternary operator, which f.i. Prism, VB and other support. Which looks like:
function iif (boolean; expressionIfTrue; expressionIfFalse) : value;
One part of the magic goes to the type-checking, the other part which interests me here, is that in a regular function call, all parameters are evaluated once before the call is made.
For iif, either expressionIfTrue or expressionIfFalse is evaluated, but not both, this means you can have such code as:
v := iif( Assigned(myObject); myObject.VirtualGetMethod; zero );
While with a regular function (without compiler magic), if myObject isn’t assigned, you would get an exception, as myObject.VirtualGetMethod would be invoked regardless. There are obviously countless other uses when the expressions have side-effects.
It occurred to me that in DWS, that “magic” is not only already available to internal “magic functions”, but that it could also be easily offered in the language and made no longer magic at all. It could just be another call convention, in which you wouldn’t pass a value or a reference, but something akin to a “light” anonymous expression parameter.
Would it be worth it?
Such a parameter could be qualified with a uses for instance (to reuse the keyword) rather than a var or const.
function iif( bool : Boolean; uses ifTrue, ifFalse : Variant) : Variant;
begin
if bool then
Result := ifTrue
else Result := ifFalse;
end;
Would declare the iif “magic” function on variants.
Nothing would limit you to invoke a uses expression only once, so f.i.
procedure PrintNFloats(n : Integer; uses needFloat : Float);
begin
while n>0 do begin
Print(needFloat);
Dec(n);
end;
end;
PrintNFloats(10, Random); // will print 10 different random numbers
And you could use the caller’s capture for side-effects, f.i. by combining a var parameter and a uses expression parameter making use of that variable.
procedure SkipEmpty(var iter: Integer; maxIter: Integer; uses needStr: String);
begin
while (iterator<=maxIterator) and (needString='') do
Inc(iterator);
end;
...
SkipEmpty(iter, sl.Count-1, sl[iter]); // with a TStrings
SkipEmpty(iter, High(tbl), tbl[iter]); // with an array
Contrary to anonymous functions, the capture is thus explicitly declarative, and also hierarchical only (it’s only valid in functions directly called from your functions). That’s a drastic limitation, so such a syntax isn’t intended for out-of-context tasks (like closures), but for local sub-tasks, which you also guarantee will be local (something that anonymous methods can’t guarantee).
And as a final sample, in the exemple above if you want to equate the ‘hello’ and ‘world’ strings to an empty string for SkipEmpty, you could use:
SkipEmpty(iter, sl.Count-1,
iif(sl[iter] in ['hello', 'world'], '', sl[iter])
);
You could thus chain the expression parameters to introduce some non-traditional (for Delphi code) behaviors.
All in all, this could cover a variety of scenarios for default values, conditional alternatives, iterators, with a much restricted capability compared to full-blown anonymous methods, but with hopefully less scope for confusion than anonymous methods offer. But still, it would introduce the possibility of complex side-effects.
Any opinions? Should the possibility be surfaced or be kept only as an internal magic?
Post Scriptum:
As Craig Stuntz & APZ noted in the comments, this is similar to Digital Mars D’s lazy parameters, and both suggested using the “lazy” keyword in place of “uses” to match. However, lazy evokes more delayed evaluation, but evaluated once (as in “lazy binding”, etc.), something D doesn’t seem to support AFAICT with the lazy keyword (every use of a parameter leads to an evaluationif I’m not mistaken). While “uses” was to indicate you could “use” the parmeter’s underlying expression, as many times as you wanted to. More input welcome 🙂