| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
P 1788, In the interest of simplicity, since it appears our standard has only one flavor, inter-flavor conversion is moot (or at best speculative). If there ever is a second flavor standardized, inter-flavor conversion SHALL be addressed. And other issues. On Mar 24, 2014, at 6:22 AM, John Pryce <j.d.pryce@xxxxxxxxxx> wrote: > 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. YES ! ! ! George Corliss > 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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail