Re: Motion P1788/M0008.01_Exception_Handling
Nate, P1788 members
On 20 Sep 2009, at 22:40, Nate Hayes wrote:
I don't think your FLAG idea should be discarded.
I only mean to suggest what you mention is a particular implementation
choice, which I believe is already accomodated nicely by the Motion 8
abstractions.
For example, FLAG can be seen as just a pre-computed alias for the
combination of all yy(1), yy(2) ... yy(n) decorations that would
otherwise
be returned by isValid( yy ), which you originally noticed would
require a
potentially expensive component-wise examination of all the yy
decorations.
So your example implementation trades the cost of the isValid( yy )
operation for requiring the user and/or implementor to manage the
extra FLAG
memory and state.
In some implementations or computing environments, this may indeed
be a
highly desireable and effective implementation strategy. In others
it may
not be. I think the strength of the Motion 8 abstraction is it
*allows* the
implementation example you provide,...
Thanks for your positive response. I would love to believe what you
say is true, but at present can't see how to make this a reality.
In the "fully decorated" case, there would be an array
yy.dec of size n by P
(using my earlier ".dec" notation) of decorations yy.dec(i,p) on the
output array yy, which would contain the FLAG information -- in field
(s) that I'll call
yy.dec.FLAG.
Now at implementation level we could arrange the memory stride in the
i direction to be zero (this would require storing the yy.dec array
separate from the interval array yy.inv, but we've decided compilers
can do that). Then, physically, yy.dec would be a 1-dimensional
array. And, if the actual action of updating an element
yy.dec.FLAG(i,p)
is a logical OR, then at the end of the calculation, this 1D array
would hold the data I want.
Indeed, if the memory stride were made zero in both directions, I
would get the effect of a single scalar flag, that could be made of
"regional" scope.
So far so good. INSIDE the function ff, this hasn't changed the
semantics; indeed the code can stay identical. But OUTSIDE, back in
the calling program, the semantics are very different. Somehow, what
is conceptually one array as a formal-argument within ff:
struct(interval inv, decoration dec) yy[n,P]
(I hope that is roughly correct C) has to be mapped to two actual-
argument arrays in the calling program
interval yyinv[n,P] 2D array holding the result intervals,
decoration yydec[P] 1D array holding the result decorations.
I can see how I could (conceptually) hand-code a one-off parameter
passing process that would make this happen. But I can't at present
see a language mechanism to inform a compiler that this is to be done.
Looking at it more abstractly, I don't think a change that forces one
to write the calling program differently can be just "a particular
implementation choice" as you put it.
Any suggestions? Either within the existing definition of C++ or
Fortran, or via a language extension.
Best wishes
John Pryce