>Actually, it can be even simpler. Regardless of where the
Designator/Selector
>is, let return either a bag with one element or just that element when it
>only resolves one value. If this is in a function, that function will
decide
>what to do if it gets a bag with multiple values (ie, it might be able to
>handle it, it might be indeterminate, it might be able to skip it and try
>other resoltions).
*-one-and-only implicit application achieves the same effect, but avoids
"runtime"
type determination
>If you require a designator/selector to act in a special way when it's
inside
>a function, you muddy the logic of the AD/AS, and if you tell it to always
>act as a *-one-and-only you break functions that can deal with (or expect
to
>get) bags, since there is no way to know that a certain parameter to a
certain
>function does/doesn't want a bag.
You ALWAYS know what parameter the funtion wants - it is in its definition.
We agreed not to allow overloading of bag/singleton values
> "A bag containing one value is treated as semantically equivalent to a
> single value of the specified bag type."
Disagree. Bag with one value is NOT the same as a single value. (is
String[1] equivalent to String ?)
It needs to be transformed and *-one-and_only is the only way to transorm it
that we defined.
Implicit application of it would only be a simplification for policy
writers..
