Re: M0036.03 Flavors and standard invalidation
Jürgen, P1788
On 6 Sep 2012, at 20:10, Wolff von Gudenberg wrote:
> Now with flavors but also possible without, another kind of decorations indicating a state like "isKaucherInterval" enter the scene. I think they have to be recorded in addition to the operation based decoration. An interval is now a bare Interval and a set of decorations.
Surely such a thing doesn't exist? The third sentence of the draft §5.1 "Flavors overview" says:
(*)
> Flavor is a property of program execution context, not of an individual interval, therefore just one flavor shall be in force at any point of execution.
So it is not as complex as Jürgen envisages.
> Flavor-specific, implementation or user defined decorations increase the complexity again.
Who said 1788 should support implementation- or user-defined decorations? 1788 can't stop an implementation (or language) playing with fire in that way, but that's beyond its scope. So it does not increase 1788's complexity.
Flavor-specific decorations cannot be avoided, I think. But
- The overall standard just needs to require *one* decoration, say
"COM", that says
"computation of the current expression used common evaluations".
- The set-based group need to decide what other decorations, in
addition to COM, the set-based flavor needs.
- The modal group do the same for their flavor.
Because of (*), the two groups can make their decisions independently. And a running program is only aware of one decoration scheme at any point of execution.
I think also that all flavors need an enquiry function "is this interval common?", which is not the same thing as carrying the COM decoration. E.g. sqrt([-3,4]) in the set-based flavor returns [0,2] which is common but cannot carry the COM decoration.
Maybe there are other complexities I am missing, but they are not as bad as Jürgen seems to suggest.
John Pryce