Re: More on flavor conversions (was:Re: Revised FlavorsText)
All
Michel has given good reason to think that the issue of how to provide inter-flavor conversion is more subtle than I first thought (see my interspersed comments below).
At this late stage I think "When in doubt, leave it out" is good advice. So I propose to omit my suggested subclause 7.5.4 and instead insert in §7.1, say after
"...It is recommended that at the language level, the flavor should be constant over a procedure/function or a compilation unit."
just a recommendation on these lines:
"An implementation with more than one flavor should provide means for
conversion between suitably chosen pairs of interval types of different
flavors. How this is provided -- e.g., whether it is an import operation
to, or an export operation from, the current flavor -- is implementation-
defined."
Comments please.
John Pryce
============================================
On 2014 Mar 18, at 13:39, Michel Hack wrote:
> John Pryce replied to:
>> On 2014 Mar 18, at 09:57, Hossam A. H. Fahmy wrote:
>>> I agree with George. The text seems to be well written
>>> and covers the intended purpose.
>>> George wrote:
>>>> Sounds OK to me.
>
> Sorry to spoil the party, but I disagree (not with the "well written"
> part, but with the underlying intended purpose).
>
>> Grand. What about the "which flavor is in force" aspect, i.e. is conversion
>> an import or an export function? I still feel import is more natural.
>
> Yes, Import and Export is the right way to think about this. But we are
> strirring up a hornet's nest if we want actual conversion operations,
> which require full knowledge and understanding of BOTH flavors. That
> seems an unreasonable burden to me.
Well, my earlier proposed wording stopped short of "actual conversion operations". I agree with Michel that trying to specify these would stir up a hornet's nest.
> Earlier, John wrote:
>> - If there's no way of converting, it's just several disjoint
>> implementations so what's the point?
>
> That's precisely the point: one standard that provides for the
> possibility of several disjoint implementations that do however
> agree on a large and important common subset.
This is a different view from mine on how closely related two flavors in one implementation should be, but I must agree it is a valid view.
>> - The implementation must document what conversion *means* mathematically,
>> hence for what intervals it succeeds at Level 1: which includes common
>> intervals.
>
> The implementation must also provide this documentation for its interchange
> types, and THAT's how I would expect two flavors to cooperate: The F1 and
> F2 programs exchange data through import and export of interchange types.
> For common intervals this completely solves the problem. For others the
> Import function may give a failure indication (some non-common intervals
> may still be convertible, e.g. if both flavors support unbounded intervals).
Fair point.
> This DOES assume that there will be no gratuitous differences between the
> interchange formats of the two flavors, e.g. different representations for
> decorations that substantially denote the same quality. Perhaps it was a
> mistake to place interchange formats entirely in the flavor-specific chapter
> -- but given the lack of a sufficiently worked out alternative flavor, it is
> not easy to tease out the common notions.
Yes