> > an opcode call, IT IS A KOPCODE BY DEFAULT (emphases mine).
>
>Might the default rate be better selected by using the rate of the LHS of
>the
>expression? At least a situation like mine would be covered. Is there some
>reasoning behind this default?
>
There is a currently-standard mechanism for fixing the ambiguity, although,
truthfully, I'm a little reluctant to bring it up.
The current rate-determination mechanism is aesthetically very unpleasant.
That operation of a fairly benign opcode like ftlen should be affected by
such a complex rule is not a Good Thing.
Here's another way to force ftlen to operate at i-rate.
iopcode iftlen(table t) {
return (ftlen(t));
}
In this case, iftlen returns the i-rate lenght of the table because the
enclosing opcode provides a default rate.
The proposal that the LHS of an assignment provide an upper-bound (but not a
lower-bound) rate-restriction on the rate of opcodes on the RHS strikes me
as a sensible one. It's far more intuitive than the current rule. I suspect
that many (if not all) of the default-according-to-scope rules could be
eliminated if this proposal were adopted.
The one flaw I can see with the proposal is that leaves loopholes in several
cases. For example the statment
if (ftlen(t)) { // <---what is the rate?
}
>This would have limited use, mostly in conjunction with > the polymorphic
>table operators.
The same rule also applies to user-defined x-rate opcodes.
>Using the "time-cast" would allow for the following rewrite:
>
>---
> ksig mysig;
> (irate) mysig = 4;
Nice functionality; I'd have to think about how this one would work though.
One semantic complication I see is this case:
asig aArray[5];
ksig kIndex;
(irate)aArray[kIndex] = 1;
A simpler mechanism that would acheive the same result:
ksig mysig = 4; // RHS must be i-rate (or const).
// initialization is during i-pass.
aSig aArray[5] = { 1,2,3,4,5 }; // ditto.
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:11:07 EST