>Just a guess, but I'm assuming this idea in its more general form
>(i.e. as a last resort, a polymorphic opcode takes on the rate of
>the statement that its in) has the problem that for some statements,
>the rate of the statement is tied to the rate of the expression in
>it. So, you could get an undecidable case, where the statement rate depends
>on the expression rate, but the expression rate depends on the statement
>rate. The "null assignment" statement is an obvious
>example, a few other statements may have this problem
>too.
>
Sorry about this.. I'm going to ramble on the issue for a bit.
It seems to me that, if this is accepted as a rule, that it would be
desireable to make this a first resort rather than a last resort. Well.. a
second resort after determination of the opcode rate from argument rates.
From an author's point of view, the LHS rule can be applied easily when
you're writing SAOL code from strictly local context: no painful examination
of every enclosing conditional and opcode is required.
Interestingly, it can be shown that the LHS rule tends to overpromote
undecided opcodes slightly: there are cases where the LHS rule makes
a-opcodes out of otherwise undecided opcodes that would have been k-opcodes;
however, in these cases, if the promotion promotes the undecided opcode
above an enclosing guard rate (e.g. an enclosing k-rate while loop), then
the assignment is illegal anyway. i.e. The LHS rule makes some opcodes run
at a higher rate, but it never makes currently legal code illegal.
As you point out, the LHS rule fails in the cass of null assignments, as
well as in the case of guard expressions in conditional statements, which is
unfortunate. In this case we end up making an already-unfortunate language
rule even more unfortunate.
Worth considering: if the LHS rule were extended to include matching of
formal arguments as well, it would adress most (but still not all) cases of
null assignments. After all:
ftlen(t);
just isn't that interesting as a statement, regardless of what rate it
executes at. That being said, a user-defined x-opcode used in a null
assignment *is* a problem.
Since xsig variables take on the rate of the enclosing x-opcode (as
determined by the rate of arguments at (presumably) point of invocation --
not what I've implemented, but I'm switching over to this, as I think this
is a correct interpretation), I'm not sure that I can think of any circular
cases. I'm assuming that whatever the rule is, you resolve the x-opcode rate
from arguments and context at the point of invocation, and work your way
inward on the call chain. I'm also assuming that xsig arguments to x-opcodes
all get promoted to one rate: the rate of the opcode invocation.
A serious proposal that would do away with the issue altogether is this:
(1) make x-opcodes with no rate-determining arguments illegal.
(2) Either give ftlen() and whatever other opcodes fall into this pit a
dummy argument to determine rate; or provide explicit iftlen(t) and
kftlen(t) opcodes. (okok. aftlen too).
If it were up to me, I'd be in favor of the last proposal, regardless of how
unpleasant the consequences to the handful of not-yet-production saol
compilers.
I'm not sure how I fall on this one, honestly. It doesn't entirely put the
problem to bed, although it does, from an author's perspective, probably
simplify writing of SAOL significantly. I can't think of much worse than:
if(1) { iVal = ftlen(t); }
The following:
iopcode iftlen(t) { return (ftlen(t)); }
kopcode kftlen(t) { return (ftlen(t)); }
aopcode aftlen(t) { return (ftlen(t)); }
is a little better, I suppose, assuming we agree that this works.
Too bad we don't have provisions for standard include files.
#include <stdsaol>
might work, although what else might go in there probably raise far more
questions than its worth thinking about. (The Sfxx compiler does have a
standard include directory).
regards,
robin davies.
_________________________________________________________________________
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