Hi all --
As you may have seen/heard on github, Vass is working on a bug fix for the
long-term problem of passing sync/single to generic arguments: Previously,
such cases were unwrapped and treated as reads of the actual argument, passing
in the underlying value with no full/empty state. Thus, in:
proc foo(x) {
...
}
var mySyncVar$: sync int;
foo(mySyncVar$);
foo() would be interpreted as taking an int and the foo(mySyncVar$) would be
interpreted as foo(mySyncVar$.readFE()). This has seemed inconsistent to most
of us for some time now, the original rationale for it didn't seem to hold up
as the language has matured, and it is something I attempted to fix a year ago
without success. Vass has been more successful this month (motivated by his
work to get is*Type()-style queries working correctly for all types).
One place where this has impact is in the implementation of write/writeln for
sync/single, which were previously treated as a blocking read of the value and
passing the value to the corresponding write/writeln for its base type. It has
always seemed unfortunate/surprising to me (and to users, I believe) to have
such cases consume the full/empty state, and has led to buggy programs, so what
I've proposed we do for this release is to reinterpret write/writeln as an
inspection of the sync/single variable's full state, writing:
"<empty>", if the variable is empty
its value, if the variable is full
The rationale for this is that when you're writing something, I believe you're
typically wanting to inspect its logical state, not treat it as a consumption
of the value. And that if someone wants the previous behavior, they would call
their own readFE/readFF at the callsite, passing the base value on to the
write/writeln call. I think that this is a nice change and improvement, but
it's clearly a significant change so I wanted other developers to be able to
protest if they thought it was clearly wrong -- particularly if they had a
better proposal. Or if it seems like too big/scary a change to make so close
to the release.
Similarly, and less significantly, min()/max() are defined generically and as a
result, used to perform a readFE/readFF of a sync/single argument at the
callsite and then just operate on the base value. In the new "pass the
sync/single by ref" interpretation, the generic implementations don't work
because they trip over the full/empty state. Our proposal here is to not
support min()/max() on synchronized types, requiring users to do the
readFE/readFF at the callsite if they want to perform min()/max() on the value
being wrapped by the sync/single. Thus, in Vass's patch, passing min()/max() a
sync or single (or atomic) results in a compiler error explaining that those
routines are not supported for said types.
I think this semantic fix is long overdue and that the ensuing changes are nice
steps forward as well. Moreover, I think that the fix makes it worth taking
the changes even at this late date in the 1.10 release cycle. But if there's a
strong feeling that we should hold off until after the 1.10 branch is cut, I'd
like to hear that.
Thanks,
-Brad
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce.
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
