Re: Motion P1788/M0008.01_Exception_Handling
Marco Nehmeier wrote:
> Nate Hayes wrote:
>>
>> Note that if yy is a 100 element vector, it is normal in vector
>> operations that evaluating
>>
>> yy <= 0
>>
>> requires 100 component-wise evaluations of yy. In this regard, the
>> fact that isValid( yy )
>>
>> requires 100 component-wise examinations of yy elements does not
>> seem to me poor design; it is just status-quo for vector operations.
>> Along
>> these lines, I think your example breaks the syntactic model one
>> would generally expect from a vector library. So if clean and
>> natural code syntax is your concern, I think the FLAG implementation may
>> be the wrong approach.
>>
>> However, an object-oriented design might be able to salvage the
>> model by introducing the notion of a "decorated interval vector",
>> e.g., class DecoratedIntervalVector< N > {
>> public:
>> Interval inv[N];
>> Decoration dec;
>> };
>>
>> DecoratedIntervalVector< n > yy[P];
>>
>> Now the compiler has something to possibly work with to make the
>> FLAG model more natural in its vector-like syntax.
>>
>> Nate Hayes
>
>
> Nate, P1788,
>
> we have read the motion 8 carefully, but we still have some questions:
> In particular the way the operation is not specified clearly for us.
>
> Are there separated operations for bare and decorated intervals
yes.
If [1,2] is a bare interval, there is an operator so that
[1,2] + [1,2] = [2,4]
results in a bare interval. If possiblyDefined is a bare decoration, there
is also an operator so that
[1,2] + possiblyDefined = possiblyDefined,
i.e., bare interval plus bare decoration equals bare decoration. Any
operator that returns either a bare interval or a bare decoration is a
forgetful operator.
> or have the former be cast to the latter?
bare intervals may be promoted to decorated intervals so they can
participate with other decorated intervals. If ([3,7],possiblyDefined) is a
decorated interval, then there is an operator such that
[1,2] + ([3,7],possiblyDefined) = ([4,9],possiblyDefined),
i.e., bare interval plus decorated interval equals decorated interval (the
addition operator is not forgetful in this case).
>
> An operation of the decorated interval vector example above would read
> in our opinion:
>
> DecoratedIntervalVector< n > operation (DecoratedIntervalVector< n >
> v1, DecoratedIntervalVector< n > v2) {
> DecoratedIntervalVector v;
>
> for (i...n) {
> DecoratedInterval temp = op(v1[i], v2[i]);
> v.dec |= temp.dec;
> v.inv[i] = temp.interval;
> }
>
> return v;
> }
There may also be forgetful operations on non-decorated interval vectors,
such as
IntervalVector< n > operation (
IntervalVector< n > v1, IntervalVector< n > v2) {
IntervalVector< n > v;
for (i..n) {
v[i] = op(v1[i],v2[i]);
}
return v;
}
Note that elements of IntervalVector< n > could possibly be some mixed
collection of bare intervals and bare decorations. So in this case,
exceptions can still propagate even though no decorated intervals are being
used.
>
>
> We would like to discuss our new concept of flagspaces.
>
> Flagspaces are scopes like namespaces or blocks.
> Flagspaces manage information about exceptions, either a set of flags
> or decoration trits.
>
>
> Flagspaces are an alternative to the decorated intervals of motion 8,
> all intervals are bare the decoration is kept by the flagspaces. They
> provide a user defined scope of decorations, hence each granularity
> between global flag and decorated interval can be acheived. We have
> regional flags, the larger the region, the better the code.
>
> Flagspaces may be nested consistent with the usual scope nesting.
> There are 3 possible transfer mechanisms between nested flagspaces.
>
> 1. copy existing flags on entrance but don't deliver the new flags on
> exit. 2. don't copy existing flags on entrance and don't deliver the new
> flags on exit
> 3. don't copy existing flags on entrance but deliver the new flags
> on exit. The fourth case copy on entrance and exit would be the same
> as not opening a new flagspace.
>
> Function evaluation is defined as if the body with replaced arguments
> is executed inline.
>
> As a language extension flagspaces can effectively be implemented. But
> implementation in standard C++ may cost some efficiency.
>
> The source code for the example above could look like this:
>
>
> Interval {
> ....
>
> Interval op(Interval i1, Interval i2) {
> ....
> if (...)
> flagspace.setErrorFlag();
>
> ....
> }
> }
>
>
> IntervalVector {
>
> Interval data[];
>
> ....
>
>
> IntervalVector operator(IntervalVector v1, IntervalVector v2) {
> IntervalVector tmp;
>
> for (i...)
> tmp[i] = op(v1[i], v2[i]);
>
> return tmp;
> }
>
> }
>
>
> ....
>
> main {
>
> flagspace {
>
> IntervalVector v1;
> IntervalVector v2;
>
> IntervalVector v = operator(v1, v2);
>
> if isErrorFlag {
> ....
> }
> }
> }
>
>
> comments welcome
>
>
> Juergen, Stefan & Marco
It is very elegant syntax for decorated intervals.
Under the hood, it seems the flagspace would in principle use some variant
of the DecoratedIntervalVector class; the main difference being the
v.dec member variable of the DecoratedIntervalVector would be aliased to
some decoration representing the local scope of the flagspace.
It may still be nice to distinguish between bare intervals/decorations and
decorated intervals. Only operations returning decorated intervals would
modify the state of the flagspace; this may allow efficiencies in sections
of code where forgetful operations on bare intervals and bare decorations
are all that is needed.
Nate Hayes