Issue 754: Minor bug in 2.1 spec (orb_revision) Source: (, ) Nature: Revision Severity: Minor Summary: Summary: The grammar mentions fixed point literals for constsnts on page 3-12. The corresponding section of the grammar on page 3-19 does not include <fixed_pt_literal> as a valid constant initializer Resolution: incorporate changes in 2.3 and close this issue and 1066. Revised Text: 1. Change Production 80 to remove <fixed_pt_type> as a valid parameter type: Actions taken: October 21, 1997: received issue February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Tue, 21 Oct 1997 15:56:08 +1000 (EST) From: Michi Henning To: issues@omg.org Subject: Fixed point IDL constants Hi, a minor bug in the 2.1 spec: The grammar mentions fixed point literals for constants on page 3-12. However, the corresponding section of the grammar on page 3-19 does not include as a valid constant initializer. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 23 Jun 1998 11:40:49 +1000 (EST) From: Michi Henning To: orb_revision@omg.org Subject: Proposal for issue 754 Issue 754 says: Hi, a minor bug in the 2.1 spec: The grammar mentions fixed point literals for constants on page 3-12. However, the corresponding section of the grammar on page 3-19 does not include as a valid constant initializer. Here is a proposal. It fixes inconsistencies for wide characters and strings as well. The first part of this proposal makes no semantic changes. It simply brings the grammar in section 3.7 in line with the grammar shown in section 3.4 (whoever added the type extensions to IDL couldn't be bothered to edit the spec consistently). Change the production for on page 3-18 to read: ::= | | | | | | | | Change the production for on page 3-19 to read: ::= | | | | | | | At the bottom of page 3-19, add a production: ::= "fixed" This at least makes the grammar consistent throughout the document. However, there is a much more serious problem. At the beginning of section 3.7.2, we find: The in the production must be a previously defined name an , , , , , , or constant. The terminal here is nonsense. According to the above, the following would be legal: const mytype myconstant = 10D; However, according to these words, mytype *must* have been previously defined as: typedef fixed mytype; This doesn't make sense, because that is not a legal typedef according to the grammar (productions 27, 28, 29, 30, 32, and 81). We could change the first para of section 3.7.2 to read; The in the production must be a previously defined name an , , , , , , or constant. Note that this replaces with . However, now we get another problem: typedef fixed<5,2> mytype; // OK const mytype myconstant = 10D; // Illegal!!! The problem here is that constant definitions *cannot* specify digits and scale, because productions 13 and 82 do not allow this, so according to these productions, the only legal way to define a fixed-point constant is to write: const fixed myconstant = 10D; However, the grammar for typedefs *requires* digits and scale: typedef fixed<5,2> mytype; Now, as a result, the current grammar does not allow a named fixed-point type to be used in a constant definition: const mytype myconstant = 10D; // Semantic error The only solution I can think of is to remove named fixed-point types from constant declarations: The in the production must be a previously defined name an , , , , , or constant. Note that this now makes it illegal to use a named fixed-point type for constant definitions because I have removed the fixed-point token. This means that typedef fixed<5,2> mytype; is legal and that the only way to define a fixed-point constant is to write: const fixed myconstant = 10D; In other words, I can only use "fixed" to declare a fixed-point constant, but we can't use not a scoped name. So, I think this will do the trick. Never mind that there are no computational rules for fixed-point types and therefore no semantics. Also never mind that the type of a fixed-point quotient is unknowable at compile time. Also never mind that the C++ mapping for fixed-point types is pure fantasy... :-( Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: jon@floorboard.com Date: Mon, 22 Jun 1998 23:28:54 -0700 From: Jonathan Biggar To: Michi Henning CC: orb_revision@omg.org Subject: Re: Proposal for issue 754 References: Michi Henning wrote: > Note that this now makes it illegal to use a named fixed-point type > for constant definitions because I have removed the fixed-point > token. > > This means that > > typedef fixed<5,2> mytype; > > is legal and that the only way to define a fixed-point constant is > to write: > > const fixed myconstant = 10D; > > In other words, I can only use "fixed" to declare a fixed-point > constant, > but we can't use not a scoped name. I think the fix depends on the whether you believe that production 82: ::= "fixed" intended to introduce a sort of universal fixed point type for constants, or whether you belive that it is a broken definition, and should just be replaced with everywhere instead. I think the latter is a better solution. This then allows: typedef fixed<5,2> mytype; const mytype myconstant = 100.00D; and const fixed<7,3> myconstant2 = 9999.999D; Further evidence that this is the intended grammar comes from the (admittedly broken) C++ mapping, which does not address the issue of a "universal" fixed- point type for fixed-point constants; in fact it has no text describing how to map fixed-point constants at all. [I will post an issue on that separately.] -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Tue, 23 Jun 1998 16:49:09 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org, ab@omg.org Subject: Re: Proposal for issue 754 I've CC'd the ab list on this email because of my suggestion to remove IDL fixed-point types from the spec for the time being (see towards the end of this posting for the reasons). Michi. On Mon, 22 Jun 1998, Jonathan Biggar wrote: > I think the fix depends on the whether you believe that production 82: > > ::= "fixed" > > intended to introduce a sort of universal fixed point type for > constants, or whether you belive that it is a broken definition, and > should just be replaced with everywhere instead. Good point, and I thought of this too. > I think the latter is a better solution. This then allows: > > typedef fixed<5,2> mytype; > > const mytype myconstant = 100.00D; > > and > > const fixed<7,3> myconstant2 = 9999.999D; Yes. However, this then also requires some semantic rules as to what happens if the literal doesn't fit into the fixed point type, for example: const fixed<3,2> c1 = 3333D; // ??? const fixed<5,3> c2 = 1.4444; // ??? > Further evidence that this is the intended grammar comes from the ^^^^^^^^^^^^^^^^ Actually, I don't think that what you suggest is the intended grammar, because the spec wastes quite a few words on how to determine the *implicit* type of a fixed-point literal, on page 3-20: A fixed-point literal has the apparent number of total and fractional digits, except that leading and trailing zeros are factored out... Etc, etc... Funny though -- this of course means that it is impossible to define a fixed-point constant with value zero of type fixed<3,2>. :-( Yet another one for the list, sigh... Jon, I completely agree with you that things like const fixed<3,2> c1 = 1.1D; should be allowed, and are in fact a lot more sensible than the implicit typing that is in the spec now. However, as far as I can see, what you suggest was *not* the intent, otherwise the section on implicit typing would not be there. > Further evidence that this is the intended grammar comes from the > (admittedly broken) C++ mapping, which does not address the issue of > a > "universal" fixed- point type for fixed-point constants; The C++ mapping for fixed is broken so badly that I would be very reluctant to try and read any evidence from it whatsoever :-( > in fact it has > no text describing how to map fixed-point constants at all. [I will > post an issue on that separately.] This entire mess needs to be re-done from the ground up. The fixed point types don't even vaguely resemble something that hangs together. I *strongly* suggest that fixed point types be removed without further trace from CORBA 2.3 until we have a specification that actually defines them properly. I'm not being facetious here... We have fixed point types that - have a broken IDL grammar - have no computational semantics - don't have a mapping to all the supported target languages - for C++, have a mapping that is so badly broken that it cannot be implemented in a form that would resemble the spec - cannot be portably exchanged between ORBs from different vendors (due to the lack of computational semantics such as truncation rules, overflow, etc.) How much worse can it get?! *Please* let's at least have the honesty to admit that the fixed point types don't currently work and let's remove them from the spec until we get a change to clean this up properly (which won't be by the time 2.3 is released). I think it is far better to remove fixed point types now rather than leaving them kicking around in the spec for anyone with a shred of insight to laugh at... :-( Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: jon@floorboard.com Date: Tue, 23 Jun 1998 14:19:04 -0700 From: Jonathan Biggar To: Michi Henning CC: orb_revision@omg.org, ab@omg.org Subject: Re: Proposal for issue 754 References: Michi Henning wrote: > This entire mess needs to be re-done from the ground up. The fixed > point > types don't even vaguely resemble something that hangs together. > > I *strongly* suggest that fixed point types be removed without > further > trace from CORBA 2.3 until we have a specification that actually > defines them properly. Michi, I think you are overreacting here. Yes there are problems with fixed, but they can be addressed on a case by case issue. > I'm not being facetious here... We have fixed point types that > > - have a broken IDL grammar Your proposal (or mine after we resolve the differences) should fix this problem. We do also need to deal with the issue of rounding or truncating larger fixed point literals to fit into a particular constant value. > - have no computational semantics I disagree with you on two fronts. First CORBA is primarly interested in interface definition and interoperability, so the important parts, which is the declaration of what a fixed point type contains (a digits and scale, base 10) and a wire format (BCD) are already done. This is sufficient to guarantee that both client and server have the same idea of what a fixed-point value is, and interoperability at the wire level. Second, the computational semantics are reasonably, if informally defined in section 3.7.2. I agree that there are critical problems with the C++ language mapping, and we also need to define a specific algorithm for conversion of fixed-point types with different digits and/or scales. > - don't have a mapping to all the supported target languages Let the language mapping RTFs deal with this. > - for C++, have a mapping that is so badly broken that it cannot be > implemented in a form that would resemble the spec Agreed, but I do not agree that the core specification of fixed is too loose to allow us to fix the problem in the C++ mapping. > - cannot be portably exchanged between ORBs from different > vendors (due to the lack of computational semantics such > as truncation rules, overflow, etc.) This is completely wrong. The wire format is exactly specified, and truncation and overflow have nothing to do with the actual transmission of a fixed-point value from client to server or vice versa. To address the issue of computational semantics, I believe that we are constrained by the existing fixed point support in language mappings with reasonable fixed-point facilities to use what they already provide. This covers Ada, Cobol, Smalltalk and Java. Yes, it is likely that the fixed-point models of these languages are not all exactly the same, but I belive that for practical purposes, they are close enough for interoperability. We just need to fix the C and C++ mappings. > How much worse can it get?! I think it would be worse to give up and throw it all away. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 24 Jun 1998 11:09:56 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org, ab@omg.org Subject: Re: Proposal for issue 754 On Tue, 23 Jun 1998, Jonathan Biggar wrote: > Michi Henning wrote: > > This entire mess needs to be re-done from the ground up. The fixed > point > > types don't even vaguely resemble something that hangs together. > > > > I *strongly* suggest that fixed point types be removed without > further > > trace from CORBA 2.3 until we have a specification that actually > > defines them properly. > > Michi, I think you are overreacting here. Yes there are problems > with > fixed, but they can be addressed on a case by case issue. > > > I'm not being facetious here... We have fixed point types that > > > > - have a broken IDL grammar > > Your proposal (or mine after we resolve the differences) should fix > this > problem. We do also need to deal with the issue of rounding or > truncating larger fixed point literals to fit into a particular > constant > value. > > > - have no computational semantics > > I disagree with you on two fronts. First CORBA is primarly > interested > in interface definition and interoperability, so the important > parts, > which is the declaration of what a fixed point type contains (a > digits > and scale, base 10) and a wire format (BCD) are already done. This > is > sufficient to guarantee that both client and server have the same > idea > of what a fixed-point value is, and interoperability at the wire > level. Jon, I agree that we can fix the grammar. But there are other issues that need resolving as well. For example, the grammar for fixed has yet again opened the door for anonymous types: void op(in fixed<5,3> val); is legal. We should not only address the current constant definition problem, but probably also require a fixed-point to type to always be named by a typedef, otherwise we will get yet another raft of anonymous type problems in all the language mappings. The lack of computational semantics is a real killer, in my opinion. Sure, I can get a fixed-point value from one place to another, but that doesn't help, in my opinion. After all, if I bother to send fixed-point values from place to place, then presumably I'm doing this so computations can be performed on them. The problem is that the outcome of the computation is undefined, and with the current specification, it will likely be different for every ORB vendor. > Second, the computational semantics are reasonably, if informally > defined in section 3.7.2. I'm not sure I agree with that. In particular, behavior on overflow, underflow, loss of precision, and rounding vs truncation, are all ill defined, but essential for getting interoperable semantics. > I agree that there are critical problems with > the C++ language mapping, and we also need to define a specific > algorithm for conversion of fixed-point types with different digits > and/or scales. Yes. And I honestly don't believe that all of this can be done for 2.3. If we leave the fixed-point types in their half-baked state in the spec, we are buying into more serious problems down the track. Now that we have fixed-point types, a number of vendors will go ahead and implement them regardless of the problems. This of course means that vendors have to make essentially arbitrary decisions to deal with the defects, and will likely make incompatible decisions. Once we get round to properly fixing the fixed-point types, all these vendors will scream if something does not agree with their previous arbitrary decision ("We can't just go and break all that customer code!"). All of this will make it ever so much harder to get anything like usable semantics for fixed-point types. I honestly believe that it would be better to re-open an RFP for this, or at least charter an RTF. Once the core semantics for fixed-point are sorted out, and once we have a proper computational model, then we can think about language bindings and the like. Remember, we thought about addressing the fixed-point problems for the C++ mapping, and the consensus was that this is pointless to even try and do until after the core issues are sorted out. > > - don't have a mapping to all the supported target languages > > Let the language mapping RTFs deal with this. No, it's not that simple. The current fixed-point IDL already screws up language mappings no end. Constants are implicitly typed, fixed-point types can be anonymous, and the type of a fixed-point quotient is not determinable at compile-time. These are defects that create severe problems for language mappings and need to be sorted out in the core first, otherwise, each language mapping needs to invent a work-around for the defects in the core. That's like trying to build on a foundation of sand. > > - for C++, have a mapping that is so badly broken that it cannot be > > implemented in a form that would resemble the spec > > Agreed, but I do not agree that the core specification of fixed is too > loose to allow us to fix the problem in the C++ mapping. I disagree there. The above points are serious, in my opinion. > > - cannot be portably exchanged between ORBs from different > > vendors (due to the lack of computational semantics such > > as truncation rules, overflow, etc.) > > This is completely wrong. The wire format is exactly specified, and > truncation and overflow have nothing to do with the actual > transmission > of a fixed-point value from client to server or vice versa. See above -- sure, I can send the values from place to place, but that doesn't do me a lot of good unless they have the same meaning everywhere. > To address the issue of computational semantics, I believe that we are > constrained by the existing fixed point support in language mappings > with reasonable fixed-point facilities to use what they already > provide. This covers Ada, Cobol, Smalltalk and Java. Yes, it is likely > that the fixed-point models of these languages are not all exactly the > same, but I belive that for practical purposes, they are close enough > for interoperability. We just need to fix the C and C++ mappings. So, we need a core decision as to what the fixed point semantics are. Once we have that, we can map them onto languages. If we ignore the core problems and do the mapping now, developers will use fixed-point types and unwittingly believe that whatever semantics are provided by their ORB can be relied on and apply universally. This does *not* bode well for future interoperability. > > How much worse can it get?! > > I think it would be worse to give up and throw it all away. I'm not saying that we should throw it all away, but that we should have the guts to admit that currently, the fixed-point type spec isn't worth the paper it is written on. That's why I'm suggesting to remove it for now. Once it is fixed and hangs together, we can put it back in. I'm pretty sure that if we continue to allow a half-baked spec to hang around in CORBA, all we get is future interoperability problems. And CORBA loses face big time if it contains published specifications that don't even vaguely hang together. How badly does the OMG want to embarrass itself? Cheers, Michi. Copyright 1998 Michi Henning. All rights reserved. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Tue, 23 Jun 1998 22:31:50 -0400 To: Michi Henning From: Steve Vinoski Subject: Re: Proposal for issue 754 Cc: Jonathan Biggar , orb_revision@omg.org, ab@omg.org References: <35901BC8.70375891@floorboard.com> I can only agree wholeheartedly with Michi. He is not overreacting. An IONA engineer who attempted to implement the fixed point type was faced with more than several arbitrary decisions regarding rounding, truncation, etc., about which the spec defines nothing. The chances of using fixed-point arithmetic portably across multiple ORBs are pretty poor. For the last ORB revision go-around, I set out to try to borrow semantics for fixed types from COBOL, with "Add One to Dave" Gamble's help. Due to my own time constraints, I unfortunately made little headway. However, judging from what I saw, it believe it would take a couple of dedicate people only about one week to define everything necessary to fix this. In general, I am disheartened by the fact that serious screw-ups of one part of the CORBA spec or another seem to happening more and more frequently. Clearly, there are people out there who are rushing into making changes that they don't really understand, and the checks and balances we have in place are obviously not always working. This fixed-point type is a good example. The OBV grammar fiasco is another. I found another showstopper in the OBV specification earlier today. Some of the noises currently coming the Real-Time Group about proposed changes to CORBA personally frighten the hell out of me. Hopefully, Andrew's proposed modifications to the adoption process, intended to help prevent horrible errors from occuring in the future, will work. Until then, I agree with Michi -- there are cases like this fixed-point mess in which we should just admit we screwed up, and pull the broken parts out of the spec until they can be repaired. --steve At 11:09 AM 6/24/98 +1000, Michi Henning wrote: >On Tue, 23 Jun 1998, Jonathan Biggar wrote: > >> Michi Henning wrote: >> > This entire mess needs to be re-done from the ground up. The fixed point >> > types don't even vaguely resemble something that hangs together. >> > >> > I *strongly* suggest that fixed point types be removed without further >> > trace from CORBA 2.3 until we have a specification that actually >> > defines them properly. >> >> Michi, I think you are overreacting here. Yes there are problems with >> fixed, but they can be addressed on a case by case issue. >> >> > I'm not being facetious here... We have fixed point types that >> > >> > - have a broken IDL grammar >> >> Your proposal (or mine after we resolve the differences) should fix this >> problem. We do also need to deal with the issue of rounding or >> truncating larger fixed point literals to fit into a particular constant >> value. >> >> > - have no computational semantics >> >> I disagree with you on two fronts. First CORBA is primarly interested >> in interface definition and interoperability, so the important parts, >> which is the declaration of what a fixed point type contains (a digits >> and scale, base 10) and a wire format (BCD) are already done. This is >> sufficient to guarantee that both client and server have the same idea >> of what a fixed-point value is, and interoperability at the wire level. > >Jon, I agree that we can fix the grammar. But there are other issues >that need resolving as well. For example, the grammar for fixed has >yet again opened the door for anonymous types: > > void op(in fixed<5,3> val); > >is legal. We should not only address the current constant definition >problem, but probably also require a fixed-point to type to always be >named by a typedef, otherwise we will get yet another raft of anonymous >type problems in all the language mappings. > >The lack of computational semantics is a real killer, in my opinion. >Sure, I can get a fixed-point value from one place to another, but >that doesn't help, in my opinion. After all, if I bother to send >fixed-point values from place to place, then presumably I'm doing this >so computations can be performed on them. The problem is that >the outcome of the computation is undefined, and with the current >specification, it will likely be different for every ORB vendor. > >> Second, the computational semantics are reasonably, if informally >> defined in section 3.7.2. > >I'm not sure I agree with that. In particular, behavior on overflow, >underflow, loss of precision, and rounding vs truncation, are all >ill defined, but essential for getting interoperable semantics. > >> I agree that there are critical problems with >> the C++ language mapping, and we also need to define a specific >> algorithm for conversion of fixed-point types with different digits >> and/or scales. > >Yes. And I honestly don't believe that all of this can be done for 2.3. > >If we leave the fixed-point types in their half-baked state in the spec, >we are buying into more serious problems down the track. Now that we >have fixed-point types, a number of vendors will go ahead and implement >them regardless of the problems. This of course means that vendors have >to make essentially arbitrary decisions to deal with the defects, and >will likely make incompatible decisions. Once we get round to properly >fixing the fixed-point types, all these vendors will scream if something >does not agree with their previous arbitrary decision ("We can't just >go and break all that customer code!"). > >All of this will make it ever so much harder to get anything like usable >semantics for fixed-point types. > >I honestly believe that it would be better to re-open an RFP for this, >or at least charter an RTF. Once the core semantics for fixed-point >are sorted out, and once we have a proper computational model, then we >can think about language bindings and the like. Remember, we thought >about addressing the fixed-point problems for the C++ mapping, and the >consensus was that this is pointless to even try and do until after >the core issues are sorted out. > >> > - don't have a mapping to all the supported target languages >> >> Let the language mapping RTFs deal with this. > >No, it's not that simple. The current fixed-point IDL already screws up >language mappings no end. Constants are implicitly typed, fixed-point >types can be anonymous, and the type of a fixed-point quotient is not >determinable at compile-time. These are defects that create severe >problems for language mappings and need to be sorted out in the core >first, otherwise, each language mapping needs to invent a work-around >for the defects in the core. That's like trying to build on a foundation >of sand. > >> > - for C++, have a mapping that is so badly broken that it cannot be >> > implemented in a form that would resemble the spec >> >> Agreed, but I do not agree that the core specification of fixed is too >> loose to allow us to fix the problem in the C++ mapping. > >I disagree there. The above points are serious, in my opinion. > >> > - cannot be portably exchanged between ORBs from different >> > vendors (due to the lack of computational semantics such >> > as truncation rules, overflow, etc.) >> >> This is completely wrong. The wire format is exactly specified, and >> truncation and overflow have nothing to do with the actual transmission >> of a fixed-point value from client to server or vice versa. > >See above -- sure, I can send the values from place to place, but that >doesn't do me a lot of good unless they have the same meaning everywhere. > >> To address the issue of computational semantics, I believe that we are >> constrained by the existing fixed point support in language mappings >> with reasonable fixed-point facilities to use what they already >> provide. This covers Ada, Cobol, Smalltalk and Java. Yes, it is likely >> that the fixed-point models of these languages are not all exactly the >> same, but I belive that for practical purposes, they are close enough >> for interoperability. We just need to fix the C and C++ mappings. > >So, we need a core decision as to what the fixed point semantics are. >Once we have that, we can map them onto languages. If we ignore the core >problems and do the mapping now, developers will use fixed-point types >and unwittingly believe that whatever semantics are provided by their >ORB can be relied on and apply universally. This does *not* bode well >for future interoperability. > >> > How much worse can it get?! >> >> I think it would be worse to give up and throw it all away. > >I'm not saying that we should throw it all away, but that we should have >the guts to admit that currently, the fixed-point type spec isn't worth >the paper it is written on. That's why I'm suggesting to remove it for >now. Once it is fixed and hangs together, we can put it back in. > >I'm pretty sure that if we continue to allow a half-baked spec to hang >around in CORBA, all we get is future interoperability problems. And >CORBA loses face big time if it contains published specifications that don't >even vaguely hang together. > >How badly does the OMG want to embarrass itself? > > Cheers, > > Michi. >Copyright 1998 Michi Henning. All rights reserved. >-- >Michi Henning +61 7 33654310 >DSTC Pty Ltd +61 7 33654311 (fax) >University of Qld 4072 michi@dstc.edu.au >AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html > Return-Path: Sender: jon@floorboard.com Date: Tue, 23 Jun 1998 22:00:50 -0700 From: Jonathan Biggar To: Steve Vinoski CC: Michi Henning , orb_revision@omg.org, ab@omg.org Subject: Re: Proposal for issue 754 References: <35901BC8.70375891@floorboard.com> <199806240233.WAA27961@boston.iona.ie> Steve Vinoski wrote: > > I can only agree wholeheartedly with Michi. He is not > overreacting. An IONA > engineer who attempted to implement the fixed point type was faced > with > more than several arbitrary decisions regarding rounding, > truncation, etc., > about which the spec defines nothing. The chances of using > fixed-point > arithmetic portably across multiple ORBs are pretty poor. I don't want to give the impression that fixing this problem is trivial, but I also don't want to agree that it is hopelessly broken either. > For the last ORB revision go-around, I set out to try to borrow semantics > for fixed types from COBOL, with "Add One to Dave" Gamble's help. Due to my > own time constraints, I unfortunately made little headway. However, judging > from what I saw, it believe it would take a couple of dedicate people only > about one week to define everything necessary to fix this. I agree that we could fix it in a reasonable amount of time. Another place to look for good semantics for decimal fixed-point numbers would be the Ada 95 reference manual, sections 3.5.9, 3.5.10 and Appendices F & G. > In general, I am disheartened by the fact that serious screw-ups of one > part of the CORBA spec or another seem to happening more and more > frequently. Clearly, there are people out there who are rushing into making > changes that they don't really understand, and the checks and balances we > have in place are obviously not always working. This fixed-point type is a > good example. The OBV grammar fiasco is another. I found another > showstopper in the OBV specification earlier today. Some of the noises > currently coming the Real-Time Group about proposed changes to CORBA > personally frighten the hell out of me. Hopefully, Andrew's proposed > modifications to the adoption process, intended to help prevent horrible > errors from occuring in the future, will work. Until then, I agree with > Michi -- there are cases like this fixed-point mess in which we should just > admit we screwed up, and pull the broken parts out of the spec until they > can be repaired. If you truely believe that it would take only a couple of people a week to fix this, then why don't we do it now? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 24 Jun 1998 15:11:46 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Steve Vinoski , orb_revision@omg.org, ab@omg.org Subject: Re: Proposal for issue 754 On Tue, 23 Jun 1998, Jonathan Biggar wrote: > If you truely believe that it would take only a couple of people a week > to fix this, then why don't we do it now? There are only so many cycles I can donate... Jon, if you feel motivated enough to make a start and post a proposal, I'll review it and put my five cents worth in ;-) But I can't spare the time to go through and fix this myself. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: From: Cory Casanave To: Michi Henning , Steve Vinoski Cc: Jonathan Biggar , orb_revision@omg.org, ab@omg.org Subject: RE: Proposal for issue 754 Date: Wed, 24 Jun 1998 09:22:44 -0400 Also consider that with OBV a built-in for built-in fixed point types is much less compelling. IBM has already submitted DDECIMAL in the currency proposal instead of using the broken and not implemented fixed point type (so they use the not implemented OBV type!). Regards, Cory ---------- From: Steve Vinoski[SMTP:vinoski@iona.com] Sent: Tuesday, June 23, 1998 10:32 PM To: Michi Henning Cc: Jonathan Biggar; orb_revision@omg.org; ab@omg.org Subject: Re: Proposal for issue 754 I can only agree wholeheartedly with Michi. He is not overreacting. An IONA engineer who attempted to implement the fixed point type was faced with more than several arbitrary decisions regarding rounding, truncation, etc., about which the spec defines nothing. The chances of using fixed-point arithmetic portably across multiple ORBs are pretty poor. For the last ORB revision go-around, I set out to try to borrow semantics for fixed types from COBOL, with "Add One to Dave" Gamble's help. Due to my own time constraints, I unfortunately made little headway. However, judging from what I saw, it believe it would take a couple of dedicate people only about one week to define everything necessary to fix this. In general, I am disheartened by the fact that serious screw-ups of one part of the CORBA spec or another seem to happening more and more frequently. Clearly, there are people out there who are rushing into making changes that they don't really understand, and the checks and balances we have in place are obviously not always working. This fixed-point type is a good example. The OBV grammar fiasco is another. I found another showstopper in the OBV specification earlier today. Some of the noises currently coming the Real-Time Group about proposed changes to CORBA personally frighten the hell out of me. Hopefully, Andrew's proposed modifications to the adoption process, intended to help prevent horrible errors from occuring in the future, will work. Until then, I agree with Michi -- there are cases like this fixed-point mess in which we should just admit we screwed up, and pull the broken parts out of the spec until they can be repaired. --steve At 11:09 AM 6/24/98 +1000, Michi Henning wrote: >On Tue, 23 Jun 1998, Jonathan Biggar wrote: > >> Michi Henning wrote: >> > This entire mess needs to be re-done from the ground up. The fixed point >> > types don't even vaguely resemble something that hangs together. >> > >> > I *strongly* suggest that fixed point types be removed without further >> > trace from CORBA 2.3 until we have a specification that actually >> > defines them properly. >> >> Michi, I think you are overreacting here. Yes there are problems with >> fixed, but they can be addressed on a case by case issue. >> >> > I'm not being facetious here... We have fixed point types that >> > >> > - have a broken IDL grammar >> >> Your proposal (or mine after we resolve the differences) should fix this >> problem. We do also need to deal with the issue of rounding or >> truncating larger fixed point literals to fit into a particular constant >> value. >> >> > - have no computational semantics >> >> I disagree with you on two fronts. First CORBA is primarly interested >> in interface definition and interoperability, so the important parts, >> which is the declaration of what a fixed point type contains (a digits >> and scale, base 10) and a wire format (BCD) are already done. This is >> sufficient to guarantee that both client and server have the same idea >> of what a fixed-point value is, and interoperability at the wire level. > >Jon, I agree that we can fix the grammar. But there are other issues >that need resolving as well. For example, the grammar for fixed has >yet again opened the door for anonymous types: > > void op(in fixed<5,3> val); > >is legal. We should not only address the current constant definition >problem, but probably also require a fixed-point to type to always be >named by a typedef, otherwise we will get yet another raft of anonymous >type problems in all the language mappings. > >The lack of computational semantics is a real killer, in my opinion. >Sure, I can get a fixed-point value from one place to another, but >that doesn't help, in my opinion. After all, if I bother to send >fixed-point values from place to place, then presumably I'm doing this >so computations can be performed on them. The problem is that >the outcome of the computation is undefined, and with the current >specification, it will likely be different for every ORB vendor. > >> Second, the computational semantics are reasonably, if informally >> defined in section 3.7.2. > >I'm not sure I agree with that. In particular, behavior on overflow, >underflow, loss of precision, and rounding vs truncation, are all >ill defined, but essential for getting interoperable semantics. > >> I agree that there are critical problems with >> the C++ language mapping, and we also need to define a specific >> algorithm for conversion of fixed-point types with different digits >> and/or scales. > >Yes. And I honestly don't believe that all of this can be done for 2.3. > >If we leave the fixed-point types in their half-baked state in the spec, >we are buying into more serious problems down the track. Now that we >have fixed-point types, a number of vendors will go ahead and implement >them regardless of the problems. This of course means that vendors have >to make essentially arbitrary decisions to deal with the defects, and >will likely make incompatible decisions. Once we get round to properly >fixing the fixed-point types, all these vendors will scream if something >does not agree with their previous arbitrary decision ("We can't just >go and break all that customer code!"). > >All of this will make it ever so much harder to get anything like usable >semantics for fixed-point types. > >I honestly believe that it would be better to re-open an RFP for this, >or at least charter an RTF. Once the core semantics for fixed-point >are sorted out, and once we have a proper computational model, then we >can think about language bindings and the like. Remember, we thought >about addressing the fixed-point problems for the C++ mapping, and the >consensus was that this is pointless to even try and do until after >the core issues are sorted out. > >> > - don't have a mapping to all the supported target languages >> >> Let the language mapping RTFs deal with this. > >No, it's not that simple. The current fixed-point IDL already screws up >language mappings no end. Constants are implicitly typed, fixed-point >types can be anonymous, and the type of a fixed-point quotient is not >determinable at compile-time. These are defects that create severe >problems for language mappings and need to be sorted out in the core >first, otherwise, each language mapping needs to invent a work-around >for the defects in the core. That's like trying to build on a foundation >of sand. > >> > - for C++, have a mapping that is so badly broken that it cannot be >> > implemented in a form that would resemble the spec >> >> Agreed, but I do not agree that the core specification of fixed is too >> loose to allow us to fix the problem in the C++ mapping. > >I disagree there. The above points are serious, in my opinion. > >> > - cannot be portably exchanged between ORBs from different >> > vendors (due to the lack of computational semantics such >> > as truncation rules, overflow, etc.) >> >> This is completely wrong. The wire format is exactly specified, and >> truncation and overflow have nothing to do with the actual transmission >> of a fixed-point value from client to server or vice versa. > >See above -- sure, I can send the values from place to place, but that >doesn't do me a lot of good unless they have the same meaning everywhere. > >> To address the issue of computational semantics, I believe that we are >> constrained by the existing fixed point support in language mappings >> with reasonable fixed-point facilities to use what they already >> provide. This covers Ada, Cobol, Smalltalk and Java. Yes, it is likely >> that the fixed-point models of these languages are not all exactly the >> same, but I belive that for practical purposes, they are close enough >> for interoperability. We just need to fix the C and C++ mappings. > >So, we need a core decision as to what the fixed point semantics are. >Once we have that, we can map them onto languages. If we ignore the core >problems and do the mapping now, developers will use fixed-point types >and unwittingly believe that whatever semantics are provided by their >ORB can be relied on and apply universally. This does *not* bode well >for future interoperability. > >> > How much worse can it get?! >> >> I think it would be worse to give up and throw it all away. > >I'm not saying that we should throw it all away, but that we should have >the guts to admit that currently, the fixed-point type spec isn't worth >the paper it is written on. That's why I'm suggesting to remove it for >now. Once it is fixed and hangs together, we can put it back in. > >I'm pretty sure that if we continue to allow a half-baked spec to hang >around in CORBA, all we get is future interoperability problems. And >CORBA loses face big time if it contains published specifications that don't >even vaguely hang together. > >How badly does the OMG want to embarrass itself? > > Cheers, > > Michi. >Copyright 1998 Michi Henning. All rights reserved. >-- >Michi Henning +61 7 33654310 >DSTC Pty Ltd +61 7 33654311 (fax) >University of Qld 4072 michi@dstc.edu.au >AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html > Return-Path: Sender: jis@fpk.hp.com Date: Wed, 24 Jun 1998 14:13:16 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Labs To: orb_revision@omg.org Cc: Ed Barkmeyer , michi@dstc.edu.au Subject: Re: Proposal for issue 754 References: <9806241651.AA01149@radio.cme.nist.gov> Ed Barkmeyer wrote: > After a previous discussion on the broken "fixed" type, I heartily > support Michi's recommendation: > > I *strongly* suggest that fixed point types be removed without > further > > trace from CORBA 2.3 until we have a specification that actually > > defines them properly. Very hard to do that in an RTF. I'd rather avoid getting bogged down in this removal exercise right now. > Fixed-point types were a badly designed and hasty addition to IDL, > and the language mappings are consequently hopeless. > > And Michi cites two reasons that are at the heart of the problem: > > - have no computational semantics > > ... > > - cannot be portably exchanged between ORBs from different > > vendors (due to the lack of computational semantics such > > as truncation rules, overflow, etc.) > > Part of the language mapping difficulty is that we must determine > exactly what "computational semantics" must be carried in and > between > ORBs, and exactly what "computational semantics" must be provided > by the programming language mapping, and exactly what computational > semantics must be left to the client/server programmers. And we > got that wrong. > > Now I agree with Jon Biggar that revising one type is not that big > a deal, even when the changes are significant, and I agree with > Steve > that if you put a handful of knowledgeable persons in a room for a > few days, you can get a clean fix to the specifications. But > Michi's > and Steve's point is that we won't get that done and reviewed in > time for 2.3! So let's not do a hasty rewrite of a mess that was > created by a hasty original! What we might accomplish that way is > another round of implementations that still don't quite work and > don't quite work together whilst running up a tab that the CORBA > development managers are not going to want to repeat anytime soon. > > I recommend the ISO practice of leaving it the way it is in the > 2.3 RTF report, and adding the caveat that the use of "fixed" is > "deprecated" ("don't do it if you don't have to, we know the > standard is broken"), pending a later revision. I would rather that we just left it well alone and started the appropriate process (separate from this RTF) for deprecating it if that is what people want to do. I believe there are several possibilities to achieve this (an RTF with more time, RFR, RFP etc.), but the present ORB RTF, given its tight schedule appears to be not the way. I urge you all to please stop spending precious time discussing this issue and address some of the other more pressing issues. My specific suggestion is that we defer issues 1066, 1068, 1071 and 1072. I would appreciate it very much if Michi and Jon could resolve their differences on the proposal for fixing 754 and present it to us. I am hoping that Steve V, in his copious free time, will propose a fix for 1139 (issue about broken constant declarations), which I inadvertently and erroneously listed together with the the fixed point issues. Now how about moving on to other things that can actually be fixed in this short time. How about someone coming up with a concrete proposal to allow octet type and enum values in const declaration (Issue 571, 725). How about discussing whether we should restrict identifiers to only ASCII characters? (Issue 724) - I personally favor this one big time. We are looking for volunteers to propose resolution to all the #pragma related issues too (Issue 910, 916, 999). Any takers? Thanks, Jishnu Ps. Please, if at all possible, do not send RTF issue resolution discussions off to the AB list. It serves no real purpose, and clutters up yet another list. Those that are interested in participating in revision activities are on the ORB Revision list (or should be). Once we have made a determination about a set of issues and decide that it requires intervention from elsewhere, then we can take it there. Thanks much -- Jishnu Mukerji Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Return-Path: X-Sender: soley@emerald.omg.org Date: Wed, 24 Jun 1998 14:43:40 -0400 To: Jishnu Mukerji From: Richard Mark Soley Subject: Re: Proposal for issue 754 Cc: orb_revision@omg.org, Ed Barkmeyer , michi@dstc.edu.au References: <9806241651.AA01149@radio.cme.nist.gov> >I would rather that we just left it well alone and started the >appropriate process (separate from this RTF) for deprecating it if that >is what people want to do. I believe there are several possibilities to >achieve this (an RTF with more time, RFR, RFP etc.), but the present ORB >RTF, given its tight schedule appears to be not the way. I urge you all >to please stop spending precious time discussing this issue and address >some of the other more pressing issues. Right on. And while you're at it, starting a deprecation process (which would take as long as the process to fix the spec) doesn't make a lot of sense either!! Let's plan on getting this fixed in the next revision, and finish up this one. -- Richard Return-Path: Sender: jon@floorboard.com Date: Wed, 24 Jun 1998 12:02:05 -0700 From: Jonathan Biggar To: Jishnu Mukerji CC: orb_revision@omg.org, Ed Barkmeyer , michi@dstc.edu.au Subject: Re: Proposal for issue 754 References: <9806241651.AA01149@radio.cme.nist.gov> <359141BC.5DC588DD@fpk.hp.com> Jishnu Mukerji wrote: > I would rather that we just left it well alone and started the > appropriate process (separate from this RTF) for deprecating it if > that > is what people want to do. I believe there are several possibilities > to > achieve this (an RTF with more time, RFR, RFP etc.), but the present > ORB > RTF, given its tight schedule appears to be not the way. I urge you > all > to please stop spending precious time discussing this issue and > address > some of the other more pressing issues. > > My specific suggestion is that we defer issues 1066, 1068, 1071 and > 1072. I would appreciate it very much if Michi and Jon could resolve > their differences on the proposal for fixing 754 and present it to > us. I > am hoping that Steve V, in his copious free time, will propose a fix > for > 1139 (issue about broken constant declarations), which I > inadvertently > and erroneously listed together with the the fixed point issues. Ok, I'll step up to the task of seeing if I can pull together a reasoned proposal for fixed. I'll try to do the legwork and gruntwork, if I can get some promises to review what I do promptly and some help in clearly identifying everything that needs to be fixed (pun intended). > Now how about moving on to other things that can actually be fixed in > this short time. > > How about someone coming up with a concrete proposal to allow octet type > and enum values in const declaration (Issue 571, 725). > > How about discussing whether we should restrict identifiers to only > ASCII characters? (Issue 724) - I personally favor this one big time. > > We are looking for volunteers to propose resolution to all the #pragma > related issues too (Issue 910, 916, 999). Any takers? I'm going to let someone else volunteer on these. I think I now have enough on my plate... -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Sender: beckwb@gamma Date: Wed, 24 Jun 1998 23:33:04 -0400 To: Steve Vinoski From: Bill Beckwith Subject: Re: Proposal for issue 754 Cc: Michi Henning , Jonathan Biggar , orb_revision@omg.org, ab@omg.org References: <35901BC8.70375891@floorboard.com> At 10:31 PM 6/23/98 , Steve Vinoski wrote: > >In general, I am disheartened by the fact that serious screw-ups of one >part of the CORBA spec or another seem to happening more and more >frequently. Clearly, there are people out there who are rushing into making >changes that they don't really understand, and the checks and balances we >have in place are obviously not always working. I'd like to amplify Steve's point here. It seems like many submitters aren't even running the IDL in their submissions through an IDL compiler before submitting. This makes it obvious that they are not even prototyping the technologies before submitting. I don't fundamentally trust any design, no matter how smart the designers are, that hasn't been prototyped. I don't think there is an easy solution to the ensuring that OMG standards not only _can_ be implemented but can result in productive technologies. The OMG process has forced us collectively into some bizarre form of a waterfall design process. I hope Andrew's modifications to the adoption process help. -- Bill Return-Path: X-Sender: beckwb@gamma Date: Wed, 24 Jun 1998 23:35:15 -0400 To: Steve Vinoski From: Bill Beckwith Subject: Re: Proposal for issue 754 Cc: Michi Henning , Jonathan Biggar , orb_revision@omg.org, ab@omg.org References: <35901BC8.70375891@floorboard.com> At 10:31 PM 6/23/98 , Steve Vinoski wrote: > >This fixed-point type is a >good example. The OBV grammar fiasco is another. I found another >showstopper in the OBV specification earlier today. Some of the noises >currently coming the Real-Time Group about proposed changes to CORBA >personally frighten the hell out of me. There have been efforts by some RT folks to legislate the internal architecture of the ORB. I think that some of us are successfully swaying the others that this legislation is not technically necessary to achieve the bounding of execution time and control over internal resources. Thus, I hope the resulting specification doesn't scare you from an interface or architecture perspective. Meeting the execution semantics is difficult and should scare all of us. -- Bill Return-Path: X-Sender: beckwb@gamma Date: Wed, 24 Jun 1998 23:14:46 -0400 To: Jonathan Biggar From: Bill Beckwith Subject: Re: Proposal for issue 754 Cc: Steve Vinoski , Michi Henning , orb_revision@omg.org, ab@omg.org References: <35901BC8.70375891@floorboard.com> <199806240233.WAA27961@boston.iona.ie> At 01:00 AM 6/24/98 , Jonathan Biggar wrote: > >I agree that we could fix it in a reasonable amount of time. Another >place to look for good semantics for decimal fixed-point numbers would >be the Ada 95 reference manual, sections 3.5.9, 3.5.10 and Appendices F >& G. Your suggestion here may get passed over because many people don't have easy access to the Ada 95 LRM so I'll attach text from the appropriate sections. The Ada 83 specification for fixed point types was almost useful. Unfortunately it was broken in a couple of places. As a result, extra effort was made to ensure that a solid fixed point type specification went into Ada 95. I have included 3.5.9, 3.5.10, the entire appendix F, and the relevant part of appendix G, G.2.3 Model of Fixed Point Arithmetic. I have also edited out most discussions of Ada 83 v.s. Ada 95. FYI, the text below was paid for by the U.S. govt and thus is freely available for (re-)use. -- Bill ------------------------------------------------------------------------------ 3.5.9 Fixed Point Types 1 {fixed point type} {ordinary fixed point type} {decimal fixed point type} A fixed point type is either an ordinary fixed point type, or a decimal fixed point type. {delta (of a fixed point type)} The error bound of a fixed point type is specified as an absolute value, called the delta of the fixed point type. Syntax 2 fixed_point_definition ::= ordinary_fixed_point_definition | decimal_fixed_\ point_definition 3 ordinary_fixed_point_definition ::= delta static_expression real_range_specification 4 decimal_fixed_point_definition ::= delta static_expression digits static_expression [real_range_specificati\ on] 5 digits_constraint ::= digits static_expression [range_constraint] Name Resolution Rules 6 {expected type [fixed point type delta]} For a type defined by a fixed_ point_definition, the delta of the type is specified by the value of the expression given after the reserved word delta; this expression is expected to be of any real type. {expected type [decimal fixed point type digits]} {digits (of a decimal fixed point subtype)} {decimal fixed point type} For a type defined by a decimal_fixed_point_definition (a decimal fixed point type), the number of significant decimal digits for its first subtype (the digits of the first subtype) is specified by the expression given after the reserved word digits; this expression is expected to be of any integer type. Legality Rules 7 In a fixed_point_definition or digits_constraint, the expressions given after the reserved words delta and digits shall be static; their values shall be positive. 8 {small (of a fixed point type)} The set of values of a fixed point type comprise the integral multiples of a number called the small of the type. {ordinary fixed point type} For a type defined by an ordinary_fixed_point_ definition (an ordinary fixed point type), the small may be specified by an attribute_definition_clause (see 13.3); if so specified, it shall be no greater than the delta of the type. If not specified, the small of an ordinary fixed point type is an implementation-defined power of two less than or equal to the delta. 8.a Implementation defined: The small of an ordinary fixed point type. 9 For a decimal fixed point type, the small equals the delta; the delta shall be a power of 10. If a real_range_specification is given, both bounds of the range shall be in the range -(10**digits-1)*delta .. +(10**digits-1)*delta. 10 A fixed_point_definition is illegal if the implementation does not support a fixed point type with the given small and specified range or digits. 10.a Implementation defined: What combinations of small, range, and digits are supported for fixed point types. 11 For a subtype_indication with a digits_constraint, the subtype_mark shall denote a decimal fixed point subtype. 11.a To be honest: Or, as an obsolescent feature, a floating point subtype is permitted -- see J.3. Static Semantics 12 {base range [of a fixed point type]} The base range (see 3.5) of a fixed point type is symmetric around zero, except possibly for an extra negative value in some implementations. 13 {base range [of an ordinary fixed point type]} An ordinary_fixed_point_ definition defines an ordinary fixed point type whose base range includes at least all multiples of small that are between the bounds specified in the real_range_specification. The base range of the type does not necessarily include the specified bounds themselves. {constrained (subtype)} {unconstrained (subtype)} An ordinary_fixed_point_definition also defines a constrained first subtype of the type, with each bound of its range given by the closer to zero of: 14 the value of the conversion to the fixed point type of the corresponding expression of the real_range_specification; {implicit subtype conversion [bounds of a fixed point type]} 15 the corresponding bound of the base range. 16 {base range [of a decimal fixed point type]} A decimal_fixed_point_ definition defines a decimal fixed point type whose base range includes at least the range -(10**digits-1)*delta .. +(10**digits-1)*delta. {constrained (subtype)} {unconstrained (subtype)} A decimal_fixed_point_definition also defines a constrained first subtype of the type. If a real_range_ specification is given, the bounds of the first subtype are given by a conversion of the values of the expressions of the real_range_specification. {implicit subtype conversion [bounds of a decimal fixed point type]} Otherwise, the range of the first subtype is -(10**digits-1)*delta .. +(10**digits-1)*delta. Dynamic Semantics 17 {elaboration [fixed_point_definition]} The elaboration of a fixed_point_ definition creates the fixed point type and its first subtype. 18 For a digits_constraint on a decimal fixed point subtype with a given delta, if it does not have a range_constraint, then it specifies an implicit range -(10**D-1)*delta .. +(10**D-1)*delta, where D is the value of the expression. {compatibility (digits_constraint with a decimal fixed point subtype)} A digits_constraint is compatible with a decimal fixed point subtype if the value of the expression is no greater than the digits of the subtype, and if it specifies (explicitly or implicitly) a range that is compatible with the subtype. 18.a Discussion: Except for the requirement that the digits specified be no greater than the digits of the subtype being constrained, a digits_constraint is essentially equivalent to a range_constraint. 18.b Consider the following example: 18.c type D is delta 0.01 digits 7 range -0.00 .. 9999.99; 18.d The compatibility rule implies that the digits_constraint "digits 6" specifies an implicit range of "- 99.9999 .. 99.9999". Thus, "digits 6" is not compatible with the constraint of D, but "digits 6 range 0.00 .. 9999.99" is compatible. {94-4502.a} 18.e A value of a scalar type belongs to a constrained subtype of the type if it belongs to the range of the subtype. Attributes like Digits and Delta have no affect on this fundamental rule. So the obsolescent forms of digits_constraints and delta_constraints that are called ``accuracy constraints'' in RM83 don't really represent constraints on the values of the subtype, but rather primarily affect compatibility of the ``constraint'' with the subtype being ``constrained.'' In this sense, they might better be called ``subtype assertions'' rather than ``constraints.'' 18.f Note that the digits_constraint on a decimal fixed point subtype is a combination of an assertion about the digits of the subtype being further constrained, and a constraint on the range of the subtype being defined, either explicit or implicit. 19 {elaboration [digits_constraint]} The elaboration of a digits_constraint consists of the elaboration of the range_constraint, if any. {Range_Check [partial]} {check, language-defined (Range_Check)} If a range_constraint is given, a check is made that the bounds of the range are both in the range -(10**D-1)*delta .. +(10**D-1)*delta, where D is the value of the (static) expression given after the reserved word digits. {Constraint_Error (raised by failure of run-time check)} If this check fails, Constraint_Error is raised. Implementation Requirements 20 The implementation shall support at least 24 bits of precision (including the sign bit) for fixed point types. 20.a Reason: This is sufficient to represent Standard.Duration with a small no more than 50 milliseconds. Implementation Permissions 21 Implementations are permitted to support only smalls that are a power of two. In particular, all decimal fixed point type declarations can be disallowed. Note however that conformance with the Information Systems Annex requires support for decimal smalls, and decimal fixed point type declarations with digits up to at least 18. 21.a Implementation Note: The accuracy requirements for multiplication, division, and conversion (see G.2.1, ``Model of Floating Point Arithmetic'') are such that support for arbitrary smalls should be practical without undue implementation effort. Therefore, implementations should support fixed point types with arbitrary values for small (within reason). One reasonable limitation would be to limit support to fixed point types that can be converted to the most precise floating point type without loss of precision (so that Fixed_IO is implementable in terms of Float_IO). NOTES 22 (36) The base range of an ordinary fixed point type need not include the specified bounds themselves so that the range specification can be given in a natural way, such as: 23 type Fraction is delta 2.0**(-15) range -1.0 .. 1.0; 24 With 2's complement hardware, such a type could have a signed 16-bit representation, using 1 bit for the sign and 15 bits for fraction, resulting in a base range of -1.0 .. 1.0-2.0**(-15). Examples 25 Examples of fixed point types and subtypes: 26 type Volt is delta 0.125 range 0.0 .. 255.0; 27 -- A pure fraction which requires all the available -- space in a word can be declared as the type Fraction: type Fraction is delta System.Fine_Delta range -1.0 .. 1.0; -- Fraction'Last = 1.0 - System.Fine_Delta 28 type Money is delta 0.01 digits 15; -- decimal fixed point subtype Salary is Money digits 10; -- Money'Last = 10.0**13 - 0.01, Salary'Last = 10.0**8 - 0.01 ---------------------------------------------------------------------------- ---- 3.5.10 Operations of Fixed Point Types Static Semantics 1 The following attributes are defined for every fixed point subtype S: 2 S'Small S'Small denotes the small of the type of S. The value of this attribute is of the type universal_real. {specifiable [of Small for fixed point types]} {Small clause} Small may be specified for nonderived fixed point types via an attribute_ definition_clause (see 13.3); the expression of such a clause shall be static. 3 S'Delta S'Delta denotes the delta of the fixed point subtype S. The value of this attribute is of the type universal_real. 3.a Reason: The delta is associated with the subtype as opposed to the type, because of the possibility of an (obsolescent) delta_ constraint. 4 S'Fore S'Fore yields the minimum number of characters needed before the decimal point for the decimal representation of any value of the subtype S, assuming that the representation does not include an exponent, but includes a one-character prefix that is either a minus sign or a space. (This minimum number does not include superfluous zeros or underlines, and is at least 2.) The value of this attribute is of the type universal_ integer. 5 S'Aft S'Aft yields the number of decimal digits needed after the decimal point to accommodate the delta of the subtype S, unless the delta of the subtype S is greater than 0.1, in which case the attribute yields the value one. [(S'Aft is the smallest positive integer N for which (10**N)*S'Delta is greater than or equal to one.)] The value of this attribute is of the type universal_integer. 6 The following additional attributes are defined for every decimal fixed point subtype S: 7 S'Digits S'Digits denotes the digits of the decimal fixed point subtype S, which corresponds to the number of decimal digits that are representable in objects of the subtype. The value of this attribute is of the type universal_integer. Its value is determined as follows: {94-4768.k} {digits (of a decimal fixed point subtype)} 8 For a first subtype or a subtype defined by a subtype_indication with a digits_constraint, the digits is the value of the expression given after the reserved word digits; 9 For a subtype defined by a subtype_indication without a digits_constraint, the digits of the subtype is the same as that of the subtype denoted by the subtype_mark in the subtype_ indication. 9.a Implementation Note: Although a decimal subtype can be both range-constrained and digits-constrained, the digits constraint is intended to control the Size attribute of the subtype. For decimal types, Size can be important because input/output of decimal types is so common. 10 The digits of a base subtype is the largest integer D such that the range -(10**D-1)*delta .. +(10**D-1)*delta is included in the base range of the type. 10.a Change: Made 3.5.10(10);5.7 into a bullet under S'Digits, rather than separately listing it under S'Base'Digits, as per WG9 resolution. 11 S'Scale S'Scale denotes the scale of the subtype S, defined as the value N such that S'Delta = 10.0**(-N). {scale (of a decimal fixed point subtype)} [The scale indicates the position of the point relative to the rightmost significant digits of values of subtype S.] The value of this attribute is of the type universal_integer. 11.a Ramification: S'Scale is negative if S'Delta is greater than one. By contrast, S'Aft is always positive. 12 S'Round S'Round denotes a function with the following specification: 13 function S'Round(X : universal_real) return S'Base 14 The function returns the value obtained by rounding X (away from 0, if X is midway between two values of the type of S). NOTES 15 (37) All subtypes of a fixed point type will have the same value for the Delta attribute, in the absence of delta_constraints (see J.3). 16 (38) S'Scale is not always the same as S'Aft for a decimal subtype; for example, if S'Delta = 1.0 then S'Aft is 1 while S'Scale is 0. 17 (39) {predefined operations [of a fixed point type]} The predefined operations of a fixed point type include the assignment operation, qualification, the membership tests, and explicit conversion to and from other numeric types. They also include the relational operators and the following predefined arithmetic operators: the binary and unary adding operators - and +, multiplying operators, and the unary operator abs. 18 (40) As for all types, objects of a fixed point type have Size and Address attributes (see 13.3). Other attributes of fixed point types are defined in A.5.4. ------------------------------------------------------------------------------ Annex F (normative) Information Systems 1 {information systems} This Annex provides a set of facilities relevant to Information Systems programming. These fall into several categories: 2 an attribute definition clause specifying Machine_Radix for a decimal subtype; 3 the package Decimal, which declares a set of constants defining the implementation's capacity for decimal types, and a generic procedure for decimal division; and 4 the child packages Text_IO.Editing and Wide_Text_IO.Editing, which support formatted and localized output of decimal data, based on ``picture String'' values. 5 See also: 3.5.9, ``Fixed Point Types''; 3.5.10, ``Operations of Fixed Point Types''; 4.6, ``Type Conversions''; 13.3, ``Representation At- tributes''; A.10.9, ``Input-Output for Real Types''; B.4, ``Interfacing with COBOL''; B.3, ``Interfacing with C''; Annex G, ``Numerics''. 6 The character and string handling packages in Annex A, ``Predefined Language Environment'' are also relevant for Information Systems. Implementation Advice 7 If COBOL (respectively, C) is widely supported in the target environment, implementations supporting the Information Systems Annex should provide the child package Interfaces.COBOL (respectively, Interfaces.C) specified in Annex B and should support a convention_identifier of COBOL (respectively, C) in the interfacing pragmas (see Annex B), thus allowing Ada programs to interface with programs written in that language. Extensions to Ada 83 7.a {extensions to Ada 83} This Annex is new to Ada 9X. F.1 Machine_Radix Attribute Definition Clause Static Semantics 1 {specifiable [of Machine_Radix for decimal first subtypes]} {Machine_ Radix clause} Machine_Radix may be specified for a decimal first subtype (see 3.5.9) via an attribute_definition_clause; the expression of such a clause shall be static, and its value shall be 2 or 10. {94-4827.b} {94-4827.a} A value of 2 implies a binary base range; a value of 10 implies a decimal base range. 1.a Ramification: In the absence of a Machine_Radix clause, the choice of 2 versus 10 for S'Machine_Radix is not specified. Implementation Advice 2 Packed decimal should be used as the internal representation for objects of subtype S when S'Machine_Radix = 10. 2.a Discussion: The intent of a decimal Machine_Radix attribute definition clause is to allow the programmer to declare an Ada decimal data object whose representation matches a particular COBOL implementation's representation of packed decimal items. The Ada object may then be passed to an interfaced COBOL program that takes a packed decimal data item as a parameter, assuming that convention COBOL has been specified for the Ada object's type in a pragma Convention. 2.b Additionally, the Ada compiler may choose to generate arithmetic instructions that exploit the packed decimal represen- tation. Examples 3 Example of Machine_Radix attribute definition clause: 4 type Money is delta 0.01 digits 15; for Money'Machine_Radix use 10; F.2 The Package Decimal Static Semantics 1 The library package Decimal has the following declaration: 2 package Ada.Decimal is pragma Pure(Decimal); 3 Max_Scale : constant := implementation-defined; Min_Scale : constant := implementation-defined; 4 Min_Delta : constant := 10.0**(-Max_Scale); Max_Delta : constant := 10.0**(-Min_Scale); 5 Max_Decimal_Digits : constant := implementation-defined; 6 generic type Dividend_Type is delta <> digits <>; type Divisor_Type is delta <> digits <>; type Quotient_Type is delta <> digits <>; type Remainder_Type is delta <> digits <>; procedure Divide (Dividend : in Dividend_Type; Divisor : in Divisor_Type; Quotient : out Quotient_Type; Remainder : out Remainder_Type); pragma Convention(Intrinsic, Divide); 7 end Ada.Decimal; 7.a Implementation defined: The values of named numbers in the package Decimal. 8 Max_Scale is the largest N such that 10.0**(-N) is allowed as a decimal type's delta. Its type is universal_integer. 9 Min_Scale is the smallest N such that 10.0**(-N) is allowed as a decimal type's delta. Its type is universal_integer. 10 Min_Delta is the smallest value allowed for delta in a decimal_fixed_ point_definition. Its type is universal_real. 11 Max_Delta is the largest value allowed for delta in a decimal_fixed_ point_definition. Its type is universal_real. 12 Max_Decimal_Digits is the largest value allowed for digits in a decimal_ fixed_point_definition. Its type is universal_integer. 12.a Reason: The name is Max_Decimal_Digits versus Max_Digits, in order to avoid confusion with the named number System.Max_Digits relevant to floating point. Static Semantics 13 The effect of Divide is as follows. The value of Quotient is Quotient_ Type(Dividend/Divisor). The value of Remainder is Remainder_ Type(Intermediate), where Intermediate is the difference between Dividend and the product of Divisor and Quotient; this result is computed exactly. Implementation Requirements 14 Decimal.Max_Decimal_Digits shall be at least 18. 15 Decimal.Max_Scale shall be at least 18. 16 Decimal.Min_Scale shall be at most 0. NOTES 17 (1) The effect of division yielding a quotient with control over rounding versus truncation is obtained by applying either the function attribute Quotient_Type'Round or the conversion Quotient_Type to the expression Dividend/Divisor. F.3 Edited Output for Decimal Types 1 The child packages Text_IO.Editing and Wide_Text_IO.Editing provide localizable formatted text output, known as edited output {edited output} , for decimal types. An edited output string is a function of a numeric value, program-specifiable locale elements, and a format control value. The numeric value is of some decimal type. The locale elements are: 2 the currency string; 3 the digits group separator character; 4 the radix mark character; and 5 the fill character that replaces leading zeros of the numeric value. 6 For Text_IO.Editing the edited output and currency strings are of type String, and the locale characters are of type Character. For Wide_ Text_IO.Editing their types are Wide_String and Wide_Character, respectively. 7 Each of the locale elements has a default value that can be replaced or explicitly overridden. 8 A format-control value is of the private type Picture; it determines the composition of the edited output string and controls the form and placement of the sign, the position of the locale elements and the decimal digits, the presence or absence of a radix mark, suppression of leading zeros, and insertion of particular character values. 9 A Picture object is composed from a String value, known as a picture String, that serves as a template for the edited output string, and a Boolean value that controls whether a string of all space characters is produced when the number's value is zero. A picture String comprises a sequence of one- or two-Character symbols, each serving as a placeholder for a character or string at a corresponding position in the edited output string. The picture String symbols fall into several categories based on their effect on the edited output string: 10 Decimal Digit: '9' Radix Control: '.' 'V' Sign Control: '+' '-' '<' '>' "CR" "D\ B" Currency Control: '$' '#' Zero Suppression: 'Z' '*' Simple Insertion: '_' 'B' '0' '/' 11 The entries are not case-sensitive. Mixed- or lower-case forms for "CR" and "DB", and lower-case forms for 'V', 'Z', and 'B', have the same effect as the upper-case symbols shown. 12 An occurrence of a '9' Character in the picture String represents a decimal digit position in the edited output string. 13 A radix control Character in the picture String indicates the position of the radix mark in the edited output string: an actual character position for '.', or an assumed position for 'V'. 14 A sign control Character in the picture String affects the form of the sign in the edited output string. The '<' and '>' Character values indicate parentheses for negative values. A Character '+', '-', or '<' appears either singly, signifying a fixed-position sign in the edited output, or repeated, signifying a floating-position sign that is preceded by zero or more space characters and that replaces a leading 0. 15 A currency control Character in the picture String indicates an occurrence of the currency string in the edited output string. The '$' Character represents the complete currency string; the '#' Character represents one character of the currency string. A '$' Character appears either singly, indicating a fixed-position currency string in the edited output, or repeated, indicating a floating-position currency string that occurs in place of a leading 0. A sequence of '#' Character values indicates either a fixed- or floating-position currency string, depending on context. 16 A zero suppression Character in the picture String allows a leading zero to be replaced by either the space character (for 'Z') or the fill character (for '*'). 17 A simple insertion Character in the picture String represents, in general, either itself (if '/' or '0'), the space character (if 'B'), or the digits group separator character (if '_'). In some contexts it is treated as part of a floating sign, floating currency, or zero suppression string. 18 An example of a picture String is "<###Z_ZZ9.99>". If the currency string is "FF", the separator character is ',', and the radix mark is '.' then the edited output string values for the decimal values 32.10 and -5432.10 are "bbFFbbb32.10b" and "(bFF5,432.10)", respectively, where 'b' indicates the space character. 19 The generic packages Text_IO.Decimal_IO and Wide_Text_IO.Decimal_IO (see A.10.9, ``Input-Output for Real Types'') provide text input and non-edited text output for decimal types. NOTES 20 (2) A picture String is of type Standard.String, both for Text_IO.Editing and Wide_Text_IO.Editing. F.3.1 Picture String Formation 1 {picture String (for edited output)} {well-formed picture String (for edited output)} A well-formed picture String, or simply picture String, is a String value that conforms to the syntactic rules, composition constraints, and character replication conventions specified in this clause. Dynamic Semantics 2 3 picture_string ::= fixed_$_picture_string | fixed_#_picture_string | floating_currency_picture_string | non_currency_picture_string 4 fixed_$_picture_string ::= [fixed_LHS_sign] fixed_$_char {direct_insertion} [zero_suppression] number [RHS_sign] | [fixed_LHS_sign {direct_insertion}] [zero_suppression] number fixed_$_char {direct_insertion} [RHS_sign] | floating_LHS_sign number fixed_$_char {direct_insertion} [RHS_sign] | [fixed_LHS_sign] fixed_$_char {direct_insertion} all_zero_suppression_number {direct_insertion} [RHS_sign] | [fixed_LHS_sign {direct_insertion}] all_zero_suppression_number {direct_\ insertion} fixed_$_char {direct_insertion} [RHS_sign] | all_sign_number {direct_insertion} fixed_$_char {direct_insertion} [RHS_\ sign] 5 fixed_#_picture_string ::= [fixed_LHS_sign] single_#_currency {direct_insertion} [zero_suppression] number [RHS_sign] | [fixed_LHS_sign] multiple_#_currency {direct_insertion} zero_suppression number [RHS_sign] | [fixed_LHS_sign {direct_insertion}] [zero_suppression] number fixed_#_currency {direct_insertion} [RHS_sign] | floating_LHS_sign number fixed_#_currency {direct_insertion} [RHS_sign] | [fixed_LHS_sign] single_#_currency {direct_insertion} all_zero_suppression_number {direct_insertion} [RHS_sign] | [fixed_LHS_sign] multiple_#_currency {direct_insertion} all_zero_suppression_number {direct_insertion} [RHS_sign] | [fixed_LHS_sign {direct_insertion}] all_zero_suppression_number {direct_\ insertion} fixed_#_currency {direct_insertion} [RHS_sign] | all_sign_number {direct_insertion} fixed_#_currency {direct_insertion} [\ RHS_sign] 6 floating_currency_picture_string ::= [fixed_LHS_sign] {direct_insertion} floating_$_currency number [RHS_sign] | [fixed_LHS_sign] {direct_insertion} floating_#_currency number [RHS_sign] | [fixed_LHS_sign] {direct_insertion} all_currency_number {direct_insertio\ n} [RHS_sign] 7 non_currency_picture_string ::= [fixed_LHS_sign {direct_insertion}] zero_suppression number [RHS_sign] | [floating_LHS_sign] number [RHS_sign] | [fixed_LHS_sign {direct_insertion}] all_zero_suppression_number {direct_\ insertion} [RHS_sign] | all_sign_number {direct_insertion} | fixed_LHS_sign direct_insertion {direct_insertion} number [RHS_sign] 8 fixed_LHS_sign ::= LHS_Sign 9 LHS_Sign ::= + | - | < 10 fixed_$_char ::= $ 11 direct_insertion ::= simple_insertion 12 simple_insertion ::= _ | B | 0 | / 13 zero_suppression ::= Z {Z | context_sensitive_insertion} | fill_string 14 context_sensitive_insertion ::= simple_insertion 15 fill_string ::= * {* | context_sensitive_insertion} 16 number ::= fore_digits [radix [aft_digits] {direct_insertion}] | radix aft_digits {direct_insertion} 17 fore_digits ::= 9 {9 | direct_insertion} 18 aft_digits ::= {9 | direct_insertion} 9 19 radix ::= . | V 20 RHS_sign ::= + | - | > | CR | DB 21 floating_LHS_sign ::= LHS_Sign {context_sensitive_insertion} LHS_Sign {LHS_Sign | context_sens\ itive_insertion} 22 single_#_currency ::= # 23 multiple_#_currency ::= ## {#} 24 fixed_#_currency ::= single_#_currency | multiple_#_currency 25 floating_$_currency ::= $ {context_sensitive_insertion} $ {$ | context_sensitive_insertion} 26 floating_#_currency ::= # {context_sensitive_insertion} # {# | context_sensitive_insertion} 27 all_sign_number ::= all_sign_fore [radix [all_sign_aft]] [>] 28 all_sign_fore ::= sign_char {context_sensitive_insertion} sign_char {sign_char | context_s\ ensitive_insertion} 29 all_sign_aft ::= {all_sign_aft_char} sign_char all_sign_aft_char ::= sign_char | context_sensitive_insertion 30 sign_char ::= + | - | < 31 all_currency_number ::= all_currency_fore [radix [all_currency_aft]] 32 all_currency_fore ::= currency_char {context_sensitive_insertion} currency_char {currency_char | context_sensitive_insertion} 33 all_currency_aft ::= {all_currency_aft_char} currency_char all_currency_aft_char ::= currency_char | context_sensitive_insertion 34 currency_char ::= $ | # 35 all_zero_suppression_number ::= all_zero_suppression_fore [ radix [all_zer\ o_suppression_aft]] 36 all_zero_suppression_fore ::= zero_suppression_char {zero_suppression_char | context_sensitive_inserti\ on} 37 all_zero_suppression_aft ::= {all_zero_suppression_aft_char} zero_suppressi\ on_char all_zero_suppression_aft_char ::= zero_suppression_char | context_sensitiv\ e_insertion 38 zero_suppression_char ::= Z | * {94-4985.e} 39 The following composition constraints apply to a picture String: 40 A floating_LHS_sign does not have occurrences of different LHS_ Sign Character values. 41 If a picture String has '<' as fixed_LHS_sign, then it has '>' as RHS_sign. 42 If a picture String has '<' in a floating_LHS_sign or in an all_ sign_number, then it has an occurrence of '>'. {94-4985.a} 43 If a picture String has '+' or '-' as fixed_LHS_sign, in a floating_LHS_sign, or in an all_sign_number, then it has no RHS_ sign. {94-4974.a} 44 An instance of all_sign_number does not have occurrences of different sign_char Character values. 45 An instance of all_currency_number does not have occurrences of different currency_char Character values. 46 An instance of all_zero_suppression_number does not have occurrences of different zero_suppression_char Character values, except for possible case differences between 'Z' and 'z'. 47 A replicable Character is a Character that, by the above rules, can occur in two consecutive positions in a picture String. 48 A Character replication is a String 49 char & '(' & spaces & count_string & ')' 50 where char is a replicable Character, spaces is a String (possibly empty) comprising only space Character values, and count_string is a String of one or more decimal digit Character values. A Character replication in a picture String has the same effect as (and is said to be equivalent to) a String comprising n consecutive occurrences of char, where n=Integer'Value(count_string). 51 An expanded picture String is a picture String containing no Character replications. 51.a Discussion: Since 'B' is not allowed after a RHS sign, there is no need for a special rule to disallow "9.99DB(2)" as an abbreviation for "9.99DBB" NOTES 52 (3) Although a sign to the left of the number can float, a sign to the right of the number is in a fixed position. F.3.2 Edited Output Generation Dynamic Semantics 1 The contents of an edited output string are based on: 2 A value, Item, of some decimal type Num, 3 An expanded picture String Pic_String, 4 A Boolean value, Blank_When_Zero, {94-4985.f} 5 A Currency string, 6 A Fill character, 7 A Separator character, and 8 A Radix_Mark character. 9 The combination of a True value for Blank_When_Zero and a '*' character in Pic_String is inconsistent; no edited output string is defined. 10 A layout error is identified in the rules below if leading non-zero digits of Item, character values of the Currency string, or a negative sign would be truncated; in such cases no edited output string is defined. {94-4985.b} 11 The edited output string has lower bound 1 and upper bound N where N = Pic_String'Length + Currency_Length_Adjustment - Radix_Adjustment, and 12 Currency_Length_Adjustment = Currency'Length - 1 if there is some occurrence of '$' in Pic_String, and 0 otherwise. 13 Radix_Adjustment = 1 if there is an occurrence of 'V' or 'v' in Pic_Str, and 0 otherwise. 14 {displayed magnitude (of a decimal value)} Let the magnitude of Item be expressed as a base-10 number I ***I .F ***F , called the displayed magnitude p 1 1 q of Item, where: 15 q = Min(Max(Num'Scale, 0), n) where n is 0 if Pic_String has no radix and is otherwise the number of digit positions following radix in Pic_String, where a digit position corresponds to an occurrence of '9', a zero_suppression_char (for an all_zero_ suppression_number), a currency_char (for an all_currency_ number), or a sign_char (for an all_sign_number). 16 I /= 0 if p>0. p {94-4985.d} 17 If n < Num'Scale, then the above number is the result of rounding (away from 0 if exactly midway between values). 18 If Blank_When_Zero = True and the displayed magnitude of Item is zero, then the edited output string comprises all space character values. Otherwise, the picture String is treated as a sequence of instances of syntactic categories based on the rules in F.3.1, and the edited output string is the concatenation of string values derived from these categories according to the following mapping rules. 19 Table F-1 shows the mapping from a sign control symbol to a corresponding character or string in the edited output. In the columns showing the edited output, a lower-case 'b' represents the space character. If there is no sign control symbol but the value of Item is negative, a layout error occurs and no edited output string is produced. {94-4985.b} ----------------------------------------------------------------- | | | Table F-1: Edited Output for Sign Control Symbols | | | |-------------------------------------------------------------- | | | | | | | Edited Output for | Edited Output for | | Sign Control Symbol | Non-Negative Number | Negative Number | | | | | |---------------------------------------------------------------| | | | | | '+' | '+' | '-' | | | | | | '-' | 'b' | '-' | | | | | | '<' | 'b' | '(' | | | | | | '>' | 'b' | ')' | | | | | | "CR" | "bb" | "CR" | | | | | | "DB" | "bb" | "DB" | | | | | ----------------------------------------------------------------- 20 An instance of fixed_LHS_sign maps to a character as shown in Table F-1. 21 An instance of fixed_$_char maps to Currency. 22 An instance of direct_insertion maps to Separator if direct_insertion = '_', and to the direct_insertion Character otherwise. 23 An instance of number maps to a string integer_part & radix_part & fraction_part where: 24 The string for integer_part is obtained as follows: 25 Occurrences of '9' in fore_digits of number are replaced from right to left with the decimal digit character values for I , ..., I , respectively. 1 p 26 Each occurrence of '9' in fore_digits to the left of the leftmost '9' replaced according to rule 1 is replaced with '0'. 27 If p exceeds the number of occurrences of '9' in fore_ digits of number, then the excess leftmost digits are eligible for use in the mapping of an instance of zero_ suppression, floating_LHS_sign, floating_$_currency, or floating_#_currency to the left of number; if there is no such instance, then a layout error occurs and no edited output string is produced. 28 The radix_part is: 29 "" if number does not include a radix, if radix = 'V', or if radix = 'v' 30 Radix_Mark if number includes '.' as radix 31 The string for fraction_part is obtained as follows: 32 Occurrences of '9' in aft_digits of number are replaced from left to right with the decimal digit character values for F , ... F . 1 q 33 Each occurrence of '9' in aft_digits to the right of the rightmost '9' replaced according to rule 1 is replaced by '0'. 34 An instance of zero_suppression maps to the string obtained as follows: 35 The rightmost 'Z', 'z', or '*' Character values are replaced with the excess digits (if any) from the integer_part of the mapping of the number to the right of the zero_suppression instance, 36 A context_sensitive_insertion Character is replaced as though it were a direct_insertion Character, if it occurs to the right of some 'Z', 'z', or '*' in zero_suppression that has been mapped to an excess digit, 37 Each Character to the left of the leftmost Character replaced according to rule 1 above is replaced by: 38 the space character if the zero suppression Character is 'Z' or 'z', or 39 the Fill character if the zero suppression Character is '*'. 40 A layout error occurs if some excess digits remain after all 'Z', 'z', and '*' Character values in zero_suppression have been replaced via rule 1; no edited output string is produced. 41 An instance of RHS_sign maps to a character or string as shown in Table F-1. 42 An instance of floating_LHS_sign maps to the string obtained as follows. 43 Up to all but one of the rightmost LHS_Sign Character values are replaced by the excess digits (if any) from the integer_part of the mapping of the number to the right of the floating_LHS_sign instance. 44 The next Character to the left is replaced with the character given by the entry in Table F-1 corresponding to the LHS_Sign Character. 45 A context_sensitive_insertion Character is replaced as though it were a direct_insertion Character, if it occurs to the right of the leftmost LHS_Sign character replaced according to rule 1. 46 Any other Character is replaced by the space character.. 47 A layout error occurs if some excess digits remain after replacement via rule 1; no edited output string is produced. 48 An instance of fixed_#_currency maps to the Currency string with n space character values concatenated on the left (if the instance does not follow a radix) or on the right (if the instance does follow a radix), where n is the difference between the length of the fixed_#_currency instance and Currency'Length. A layout error occurs if Currency'Length exceeds the length of the fixed_#_currency instance; no edited output string is produced. 49 An instance of floating_$_currency maps to the string obtained as follows: 50 Up to all but one of the rightmost '$' Character values are replaced with the excess digits (if any) from the integer_part of the mapping of the number to the right of the floating_$_currency instance. 51 The next Character to the left is replaced by the Currency string. 52 A context_sensitive_insertion Character is replaced as though it were a direct_insertion Character, if it occurs to the right of the leftmost '$' Character replaced via rule 1. 53 Each other Character is replaced by the space character. 54 A layout error occurs if some excess digits remain after replacement by rule 1; no edited output string is produced. 55 An instance of floating_#_currency maps to the string obtained as follows: 56 Up to all but one of the rightmost '#' Character values are replaced with the excess digits (if any) from the integer_part of the mapping of the number to the right of the floating_#_currency instance. {94-4979.b} 57 The substring whose last Character occurs at the position immediately preceding the leftmost Character replaced via rule 1, and whose length is Currency'Length, is replaced by the Currency string. {94-4979.a} 58 A context_sensitive_insertion Character is replaced as though it were a direct_insertion Character, if it occurs to the right of the leftmost '#' replaced via rule 1. 59 Any other Character is replaced by the space character. 60 A layout error occurs if some excess digits remain after replacement rule 1, or if there is no substring with the required length for replacement rule 2; no edited output string is produced. 61 An instance of all_zero_suppression_number maps to: 62 a string of all spaces if the displayed magnitude of Item is zero, the zero_suppression_char is 'Z' or 'z', and the instance of all_zero_suppression_number does not have a radix at its last character position; 63 a string containing the Fill character in each position except for the character (if any) corresponding to radix, if zero_ suppression_char = '*' and the displayed magnitude of Item is zero; 64 otherwise, the same result as if each zero_suppression_char in all_zero_suppression_aft were '9', interpreting the instance of all_zero_suppression_number as either zero_suppression number (if a radix and all_zero_suppression_aft are present), or as zero_ suppression otherwise. {94-4985.e} 65 An instance of all_sign_number maps to: 66 a string of all spaces if the displayed magnitude of Item is zero and the instance of all_sign_number does not have a radix at its last character position; 67 otherwise, the same result as if each sign_char in all_sign_ number_aft were '9', interpreting the instance of all_sign_number as either floating_LHS_sign number (if a radix and all_sign_ number_aft are present), or as floating_LHS_sign otherwise. {94-4985.e} 68 An instance of all_currency_number maps to: 69 a string of all spaces if the displayed magnitude of Item is zero and the instance of all_currency_number does not have a radix at its last character position; 70 otherwise, the same result as if each currency_char in all_ currency_number_aft were '9', interpreting the instance of all_ currency_number as floating_$_currency number or floating_#_currency number (if a radix and all_currency_number_ aft are present), or as floating_$_currency or floating_#_currency otherwise. {94-4985.e} Examples 71 In the result string values shown below, 'b' represents the space character. 72 Item: Picture and Result Strings: 73 123456.78 Picture: "-###**_***_**9.99" "bbb$***123,456.78" "bbFF***123.456,78" (currency = "FF", separator = '.', radix mark = ',') 74 123456.78 Picture: "-$$$**_***_**9.99" Result: "bbb$***123,456.78" "bbbFF***123.456,78" (currency = "FF", separator = '.', radix mark = ',') 75 0.0 Picture: "-$$$$$$.$$" Result: "bbbbbbbbbb" 76 0.20 Picture: "-$$$$$$.$$" Result: "bbbbbb$.20" 77 -1234.565 Picture: "<<<<_<<<.<<###>" Result: "bb(1,234.57DMb)" (currency = "DM") 78 12345.67 Picture: "###_###_##9.99" Result: "bbCHF12,345.67" (currency = "CHF") F.3.3 The Package Text_IO.Editing 1 The package Text_IO.Editing provides a private type Picture with associated operations, and a generic package Decimal_Output. An object of type Picture is composed from a well-formed picture String (see F.3.1) and a Boolean item indicating whether a zero numeric value will result in an edited output string of all space characters. The package Decimal_Output contains edited output subprograms implementing the effects defined in F.3.2. Static Semantics 2 The library package Text_IO.Editing has the following declaration: 3 package Ada.Text_IO.Editing is 4 type Picture is private; 5 function Valid (Pic_String : in String; Blank_When_Zero : in Boolean := False) return Boolean; 6 function To_Picture (Pic_String : in String; Blank_When_Zero : in Boolean := False) return Picture; 7 function Pic_String (Pic : in Picture) return String; function Blank_When_Zero (Pic : in Picture) return Boolean; 8 Max_Picture_Length : constant := implementation_defined; 9 Picture_Error : exception; 10 Default_Currency : constant String := "$"; Default_Fill : constant Character := '*'; Default_Separator : constant Character := ','; Default_Radix_Mark : constant Character := '.'; 11 generic type Num is delta <> digits <>; Default_Currency : in String := Text_IO.Editing.Default_Currenc\ y; Default_Fill : in Character := Text_IO.Editing.Default_Fill; Default_Separator : in Character := Text_IO.Editing.Default_Separat\ or; Default_Radix_Mark : in Character := Text_IO.Editing.Default_Radix_M\ ark; package Decimal_Output is function Length (Pic : in Picture; Currency : in String := Default_Currency) return Natural; 12 function Valid (Item : in Num; Pic : in Picture; Currency : in String := Default_Currency) return Boolean; 13 function Image (Item : in Num; Pic : in Picture; Currency : in String := Default_Currency; Fill : in Character := Default_Fill; Separator : in Character := Default_Separator; Radix_Mark : in Character := Default_Radix_Mark) return String; 14 procedure Put (File : in File_Type; Item : in Num; Pic : in Picture; Currency : in String := Default_Currency; Fill : in Character := Default_Fill; Separator : in Character := Default_Separator; Radix_Mark : in Character := Default_Radix_Mark); 15 procedure Put (Item : in Num; Pic : in Picture; Currency : in String := Default_Currency; Fill : in Character := Default_Fill; Separator : in Character := Default_Separator; Radix_Mark : in Character := Default_Radix_Mark); 16 procedure Put (To : out String; Item : in Num; Pic : in Picture; Currency : in String := Default_Currency; Fill : in Character := Default_Fill; Separator : in Character := Default_Separator; Radix_Mark : in Character := Default_Radix_Mark); end Decimal_Output; private ... -- not specified by the language end Ada.Text_IO.Editing; {94-4480.f} 16.a Implementation defined: The value of Max_Picture_Length in the package Text_IO.Editing 17 The exception Constraint_Error is raised if the Image function or any of the Put procedures is invoked with a null string for Currency. {94-4985.c} 18 function Valid (Pic_String : in String; Blank_When_Zero : in Boolean := False) return Boolean; 19 Valid returns True if Pic_String is a well-formed picture String (see F.3.1) the length of whose expansion does not exceed Max_ Picture_Length, and if either Blank_When_Zero is False or Pic_String contains no '*'. 20 function To_Picture (Pic_String : in String; Blank_When_Zero : in Boolean := False) return Picture; 21 To_Picture returns a result Picture such that the application of the function Pic_String to this result yields an expanded picture String equivalent to Pic_String, and such that Blank_When_Zero applied to the result Picture is the same value as the parameter Blank_When_Zero. Picture_Error is raised if not Valid(Pic_String, Blank_When_Zero). 22 function Pic_String (Pic : in Picture) return String; function Blank_When_Zero (Pic : in Picture) return Boolean; 23 If Pic is To_Picture(String_Item, Boolean_Item) for some String_ Item and Boolean_Item, then: 24 Pic_String(Pic) returns an expanded picture String equivalent to String_Item and with any lower-case letter replaced with its corresponding upper-case form, and 25 Blank_When_Zero(Pic) returns Boolean_Item. 26 If Pic_1 and Pic_2 are objects of type Picture, then "="(Pic_1, Pic_2) is True when 27 Pic_String(Pic_1) = Pic_String(Pic_2), and 28 Blank_When_Zero(Pic_1) = Blank_When_Zero(Pic_2). 29 function Length (Pic : in Picture; Currency : in String := Default_Currency) return Natural; 30 Length returns Pic_String(Pic)'Length + Currency_Length_ Adjustment - Radix_Adjustment where 31 Currency_Length_Adjustment = 32 Currency'Length - 1 if there is some occurrence of '$' in Pic_String(Pic), and 33 0 otherwise. 34 Radix_Adjustment = 35 1 if there is an occurrence of 'V' or 'v' in Pic_ Str(Pic), and 36 0 otherwise. 37 function Valid (Item : in Num; Pic : in Picture; Currency : in String := Default_Currency) return Boolean; 38 Valid returns True if Image(Item, Pic, Currency) does not raise Layout_Error, and returns False otherwise. 39 function Image (Item : in Num; Pic : in Picture; Currency : in String := Default_Currency; Fill : in Character := Default_Fill; Separator : in Character := Default_Separator; Radix_Mark : in Character := Default_Radix_Mark) return String; 40 Image returns the edited output String as defined in F.3.2 for Item, Pic_String(Pic), Blank_When_Zero(Pic), Currency, Fill, Separator, and Radix_Mark. If these rules identify a layout error, then Image raises the exception Layout_Error. 41 procedure Put (File : in File_Type; Item : in Num; Pic : in Picture; Currency : in String := Default_Currency; Fill : in Character := Default_Fill; Separator : in Character := Default_Separator; Radix_Mark : in Character := Default_Radix_Mark); procedure Put (Item : in Num; Pic : in Picture; Currency : in String := Default_Currency; Fill : in Character := Default_Fill; Separator : in Character := Default_Separator; Radix_Mark : in Character := Default_Radix_Mark); 42 Each of these Put procedures outputs Image(Item, Pic, Currency, Fill, Separator, Radix_Mark) consistent with the conventions for Put for other real types in case of bounded line length (see A.10.6, ``Get and Put Procedures''). 43 procedure Put (To : out String; Item : in Num; Pic : in Picture; Currency : in String := Default_Currency; Fill : in Character := Default_Fill; Separator : in Character := Default_Separator; Radix_Mark : in Character := Default_Radix_Mark); 44 Put copies Image(Item, Pic, Currency, Fill, Separator, Radix_ Mark) to the given string, right justified. Otherwise unassigned Character values in To are assigned the space character. If To'Length is less than the length of the string resulting from Image, then Layout_Error is raised. Implementation Requirements 45 Max_Picture_Length shall be at least 30. The implementation shall support currency strings of length up to at least 10, both for Default_ Currency in an instantiation of Decimal_Output, and for Currency in an invocation of Image or any of the Put procedures. {94-4480.f} 45.a Discussion: This implies that a picture string with character replications need not be supported (i.e., To_Picture will raise Picture_Error) if its expanded form exceeds 30 characters. NOTES 46 (4) The rules for edited output are based on COBOL (ANSI X3.23:1985, endorsed by ISO as ISO 1989-1985), with the following differences: 47 The COBOL provisions for picture string localization and for 'P' format are absent from Ada. 48 The following Ada facilities are not in COBOL: 49 currency symbol placement after the number, 50 localization of edited output string for multi- character currency string values, including support for both length-preserving and length-expanding currency symbols in picture strings 51 localization of the radix mark, digits separator, and fill character, and 52 parenthesization of negative values. The value of 30 for Max_Picture_Length is the same limit as in COBOL. 52.a Reason: There are several reasons we have not adopted the COBOL-style permission to provide a single-character replacement in the picture string for the `$' as currency symbol, or to interchange the roles of `.' and `,' in picture strings 52.b It would have introduced considerable complexity into Ada, as well as confusion between run-time and compile-time character interpretation, since picture Strings are dynamically computable in Ada, in contrast with COBOL 52.c Ada's rules for real literals provide a natural interpretation of `_' as digits separator and `.' for radix mark; it is not essential to allow these to be localized in picture strings, since Ada does not allow them to be localized in real literals. 52.d The COBOL restriction for the currency symbol in a picture string to be replaced by a single character currency symbol is a compromise solution. For general international usage a mechanism is needed to localize the edited output to be a multi-character currency string. Allowing a single-Character localization for the picture Character, and a multiple-character localization for the currency string, would be an unnecessary complication. F.3.4 The Package Wide_Text_IO.Editing Static Semantics 1 {Ada.Wide_Text_IO.Editing} The child package Wide_Text_IO.Editing has the same contents as Text_IO.Editing, except that: 2 each occurrence of Character is replaced by Wide_Character, 3 each occurrence of Text_IO is replaced by Wide_Text_IO, 4 the subtype of Default_Currency is Wide_String rather than String, and 5 each occurrence of String in the generic package Decimal_Output is replaced by Wide_String. 5.a Implementation defined: The value of Max_Picture_Length in the package Wide_Text_IO.Editing NOTES 6 (5) Each of the functions Wide_Text_IO.Editing.Valid, To_Picture, and Pic_String has String (versus Wide_String) as its parameter or result subtype, since a picture String is not localizable. ------------------------------------------------------------------------------ G.2.3 Model of Fixed Point Arithmetic 1 In the strict mode, the predefined arithmetic operations of a fixed point type shall satisfy the accuracy requirements specified here and shall avoid or signal overflow in the situations described. Implementation Requirements 2 The accuracy requirements for the predefined fixed point arithmetic operations and conversions, and the results of relations on fixed point operands, are given below. 2.a Discussion: This subclause does not cover the accuracy of an operation of a static expression; such operations have to be evaluated exactly (see 4.9). 3 The operands of the fixed point adding operators, absolute value, and comparisons have the same type. These operations are required to yield exact results, unless they overflow. 4 Multiplications and divisions are allowed between operands of any two fixed point types; the result has to be (implicitly or explicitly) converted to some other numeric type. For purposes of defining the accuracy rules, the multiplication or division and the conversion are treated as a single operation whose accuracy depends on three types (those of the operands and the result). For decimal fixed point types, the attribute T'Round may be used to imply explicit conversion with rounding (see 3.5.10). 5 When the result type is a floating point type, the accuracy is as given in G.2.1. {perfect result set} For some combinations of the operand and result types in the remaining cases, the result is required to belong to a small set of values called the perfect result set; {close result set} for other combinations, it is required merely to belong to a generally larger and implementation-defined set of values called the close result set. When the result type is a decimal fixed point type, the perfect result set contains a single value; thus, operations on decimal types are always fully specified. 5.a Implementation defined: The definition of close result set, which determines the accuracy of certain fixed point multiplications and divisions. 6 When one operand of a fixed-fixed multiplication or division is of type universal_real, that operand is not implicitly converted in the usual sense, since the context does not determine a unique target type, but the accuracy of the result of the multiplication or division (i.e., whether the result has to belong to the perfect result set or merely the close result set) depends on the value of the operand of type universal_real and on the types of the other operand and of the result. 6.a Discussion: We need not consider here the multiplication or division of two such operands, since in that case either the operation is evaluated exactly (i.e., it is an operation of a static expression all of whose operators are of a root numeric type) or it is considered to be an operation of a floating point type. 7 For a fixed point multiplication or division whose (exact) mathematical result is v, and for the conversion of a value v to a fixed point type, the perfect result set and close result set are defined as follows: 8 If the result type is an ordinary fixed point type with a small of s, 9 if v is an integer multiple of s, then the perfect result set contains only the value v; 10 otherwise, it contains the integer multiple of s just below v and the integer multiple of s just above v. 11 The close result set is an implementation-defined set of consecutive integer multiples of s containing the perfect result set as a subset. 12 If the result type is a decimal type with a small of s, 13 if v is an integer multiple of s, then the perfect result set contains only the value v; 14 otherwise, if truncation applies then it contains only the integer multiple of s in the direction toward zero, whereas if rounding applies then it contains only the nearest integer multiple of s (with ties broken by rounding away from zero). 15 The close result set is an implementation-defined set of consecutive integer multiples of s containing the perfect result set as a subset. 15.a Ramification: As a consequence of subsequent rules, this case does not arise when the operand types are also decimal types. 16 If the result type is an integer type, 17 if v is an integer, then the perfect result set contains only the value v; 18 otherwise, it contains the integer nearest to the value v (if v lies equally distant from two consecutive integers, the perfect result set contains the one that is further from zero). {94-4920.a} 19 The close result set is an implementation-defined set of consecutive integers containing the perfect result set as a subset. 20 The result of a fixed point multiplication or division shall belong either to the perfect result set or to the close result set, as described below, if overflow does not occur. In the following cases, if the result type is a fixed point type, let s be its small; otherwise, i.e. when the result type is an integer type, let s be 1.0. 21 For a multiplication or division neither of whose operands is of type universal_real, let l and r be the smalls of the left and right operands. For a multiplication, if (l*r)/s is an integer or the reciprocal of an integer (the smalls are said to be ``compatible'' in this case), the result shall belong to the perfect result set; otherwise, it belongs to the close result set. For a division, if l/(r*s) is an integer or the reciprocal of an integer (i.e., the smalls are compatible), the result shall belong to the perfect result set; otherwise, it belongs to the close result set. 21.a Ramification: When the operand and result types are all decimal types, their smalls are necessarily compatible; the same is true when they are all ordinary fixed point types with binary smalls. 22 For a multiplication or division having one universal_real operand with a value of v, note that it is always possible to factor v as an integer multiple of a ``compatible'' small, but the integer multiple may be ``too big.'' If there exists a factorization in which that multiple is less than some implementation-defined limit, the result shall belong to the perfect result set; otherwise, it belongs to the close result set. {94-4952.a} 22.a Implementation defined: Conditions on a universal_real operand of a fixed point multiplication or division for which the result shall be in the perfect result set. 23 A multiplication P * Q of an operand of a fixed point type F by an operand of an integer type I, or vice-versa, and a division P / Q of an operand of a fixed point type F by an operand of an integer type I, are also allowed. {94-4768.r} {94-4889.l} In these cases, the result has a type of F; explicit conversion of the result is never required. The accuracy required in these cases is the same as that required for a multiplication F(P * Q) or a division F(P / Q) obtained by interpreting the operand of the integer type to have a fixed point type with a small of 1.0. 24 The accuracy of the result of a conversion from an integer or fixed point type to a fixed point type, or from a fixed point type to an integer type, is the same as that of a fixed point multiplication of the source value by a fixed point operand having a small of 1.0 and a value of 1.0, as given by the foregoing rules. The result of a conversion from a floating point type to a fixed point type shall belong to the close result set. The result of a conversion of a universal_real operand to a fixed point type shall belong to the perfect result set. 25 The possibility of overflow in the result of a predefined arithmetic operation or conversion yielding a result of a fixed point type T is analogous to that for floating point types, except for being related to the base range instead of the safe range. {Overflow_Check [partial]} {check, language-defined (Overflow_Check)} If all of the permitted results belong to the base range of T, then the implementation shall deliver one of the permitted results; otherwise, 26 {Constraint_Error (raised by failure of run-time check)} if T'Machine_Overflows is True, the implementation shall either deliver one of the permitted results or raise Constraint_Error; 27 if T'Machine_Overflows is False, the result is implementation defined. 27.a Implementation defined: The result of a fixed point arithmetic operation in overflow situations, when the Machine_Overflows attribute of the result type is False. {94-4774.e} {94-4889.k} ------------------------------------------------------------------------------ Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 25 Jun 1998 13:43:41 +1000 (EST) From: Michi Henning To: Bill Beckwith cc: orb_revision@omg.org Subject: Re: Proposal for issue 754 On Wed, 24 Jun 1998, Bill Beckwith wrote: > I have included 3.5.9, 3.5.10, the entire appendix F, and the relevant > part of appendix G, G.2.3 Model of Fixed Point Arithmetic. I have > also edited out most discussions of Ada 83 v.s. Ada 95. Thanks Bill, that will help! Michi. PS: That spec is exactly as much fun to read as I expected ;-) Return-Path: Date: Wed, 24 Jun 1998 20:46:08 -0700 From: Jonathan Biggar Organization: Floorboard Software To: Bill Beckwith CC: Steve Vinoski , Michi Henning , orb_revision@omg.org, ab@omg.org Subject: Re: Proposal for issue 754 References: <35901BC8.70375891@floorboard.com> <199806240233.WAA27961@boston.iona.ie> <199806250338.XAA20707@gamma.ois.com> Thanks for the input. I've got my own copy on CDROM (nice thing, Walnut Creek CDs), but it's useful for the other folk to be able to see this. --- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: From: Jeffrey Mischkinsky Subject: Re: Proposal for issue 754 To: bill.beckwith@ois.com (Bill Beckwith) Date: Wed, 24 Jun 1998 21:24:59 -0700 (PDT) Cc: vinoski@iona.com, michi@dstc.edu.au, jon@floorboard.com, orb_revision@omg.org, ab@omg.org 'Bill Beckwith' writes: > > At 10:31 PM 6/23/98 , Steve Vinoski wrote: > > > >In general, I am disheartened by the fact that serious screw-ups of > one > >part of the CORBA spec or another seem to happening more and more > >frequently. Clearly, there are people out there who are rushing > into making > >changes that they don't really understand, and the checks and > balances we > >have in place are obviously not always working. > > I'd like to amplify Steve's point here. It seems like many > submitters > aren't even running the IDL in their submissions through an IDL > compiler > before submitting. This makes it obvious that they are not even > prototyping > the technologies before submitting. I don't fundamentally trust any > design, > no matter how smart the designers are, that hasn't been prototyped. > > I don't think there is an easy solution to the ensuring that OMG > standards > not only _can_ be implemented but can result in productive > technologies. > The OMG process has forced us collectively into some bizarre form of > a waterfall design process. I hope Andrew's modifications to > the adoption process help. > > -- Bill i agree > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 +1 650-312-5158 jeffm@visigenic.com +1 650-312-5158 Return-Path: From: "Daniel R. Frantz" To: Subject: port-rtf. Proposals for vote: 754, 1514 Date: Tue, 7 Jul 1998 16:13:37 -0400 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Here is an editorial issue I missed before (1514) and one that a conference call should be closed with no action(754). I've put them in canonical form for voting. Members, please vote on these. Others comment if you wish to influence the voting. All votes need to be in by Friday, July 10. Dan P.S. With no surprise, I vote "yes". ======================================================== Issue 745: DynAny : invoke operation next() Nature: Change Summary: It may be convenient for programmers that operation next() be invoked in order to access the first component of a DynAny Resolution: Closed, no action. This would be an incompatible change. --------------------------------------------------------- Issue 1514: Typos in DynamicImplementation example Nature: Editorial Summary: On page 9-58 of CORBA 2.2 the example DatabaseEntryImpl class has two problems: 1. It derives from POA_PortableServer::DynamicImplementation instead of PortableServer::DynamicImplementation. 2. DatabaseEntryImpl has a member function named _defaultPOA instead of _default_POA. Resolution: Accepted for CORBA 2.3. Revision: Section "Single Servant, many objects and types, using DSI", page 9-58. Change the C++ example to: // C++ class DatabaseEntryImpl : | public PortableServer::DynamicImplementation { public: DatabaseEntryImpl (DatabaseAccessPoint db); virtual void invoke (ServerRequest_ptr request); ~DatabaseEntryImpl (); | virtual POA_ptr _default_POA() { return poa; } }; Return-Path: Date: Sun, 12 Jul 1998 14:45:04 -0700 From: jon@floorboard.com (Jon Biggar) To: orb_revision@omg.org Subject: Fixed point type overhall proposal Since I only got comments from Michi (and a lot of comments at that), I've gone ahead and written up a proposal for consideration. [This proposal covers issues #754, #1066, #1068, #1071.] Proposal for overhauling the IDL Fixed Point Type Definition: Part 1: Fix the grammar to prohibit anonymous fixed point parameter declarations [Resolves 754] Change Production 80 to remove as a valid parameter type: ::= | | | | Also add the missing production on page 3-19: ::= "fixed" Rational: Leaving this in causes problems with the C++ binding in the same way that the grammar from CORBA 1.1 and earlier had problems with sequences and arrays as parameters. This is also likely to cause problems with the Ada binding, since each fixed point declaration is mapped to a distinct Ada type. Part 2: Fix the grammar for fixed point constants [Resolves #1066] Change the first paragraph of section 3.7.2 to read: The in the production must be a previously defined name of an , , , , , , or constant. Also, change the "3000.00" in the example of fixed point digits and scale to "3000.00D". Rational: Fixed point constants are defined using the syntax "fixed", not "fixed", while fixed point types are defined using the later syntax. So there is no way for a to refer to a . Part 3: Modify the paragraph at the top of 3-21 to read: A quotient may have an arbitrary number of decimal places, denoted by a scale of s inf . The computation proceeds pairwise, with the usual rules for left-to-right association, operator precedence, and parentheses. All intermediate computations should be performed using double precision (i.e. 62 digit) arithmetic. If an individual computation between a pair of fixed-point literals actually generates more than 31 significant digits, then a 31-digit result is retained as follows: Rational: This change is to make sure that all IDL compilers calculate the results of fixed-point constants the same way, so as not to break interoperability. Part 4: Reword the description of Fixed Type in section 3.8.3 to be: The fixed data type represents a fixed-point decimal number of up to 31 significant digits. The scale factor is a non-negative integer less than or equal to the total number of digits (note that constants with effectively negative scale, such as 10000, are always permitted). The fixed data type will be mapped to the native fixed point capability of a programming language, if available. If there is not a native fixed point type, then the IDL mapping for that language will a fixed point data type. Applications that use the IDL fixed point type across multiple programming languages must take in to account differences between the languages in handling rounding, overflow, and arithmetic precision. Rational: If these values of scale are not universally supported by language bindings, then they are not portable, and so should not be supported by IDL. The Smalltalk, Ada, Cobol and Java languages already contain a native fixed point facility. To define a separate IDL fixed point capability for these languages would be redundant and interfere with integrating legacy code. Part 5: Close Issue 1068 and 1071 without change Rational: The text is quite clear about the mechanism for assigning digits and scale to fixed point constants. This part of the text only addresses how the IDL compiler evaluates arithmetic expressions involving fixed point literals at compile time and is not intended to define how fixed point arithmetic works in various programming languages at run time. Return-Path: Sender: jon@floorboard.com Date: Thu, 16 Jul 1998 21:53:54 -0700 From: Jonathan Biggar To: orb_revision@omg.org Subject: More edits needed for Issue 754 proposal While perusing the CORBA 2.2 spec this evening, I discovered text that needs changing as part of the fixed point cleanup proposal for issue 754: In section 8.7.2, delete the second paragraph that talks about TypeCode constants for fixed point types, since there are no longer any anonymous fixed point types. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Fri, 17 Jul 1998 09:20:05 -0400 To: Jonathan Biggar From: Steve Vinoski Subject: Re: More edits needed for Issue 754 proposal Cc: orb_revision@omg.org At 09:53 PM 7/16/98 -0700, Jonathan Biggar wrote: >While perusing the CORBA 2.2 spec this evening, I discovered text that >needs changing as part of the fixed point cleanup proposal for issue >754: > >In section 8.7.2, delete the second paragraph that talks about TypeCode >constants for fixed point types, since there are no longer any anonymous >fixed point types. Actually, the OBV RTF transferred an issue concerning 8.7.2 to the ORB RTF, and I have already submitted new text to Jishnu that does exactly what you've asked for. --steve Return-Path: Sender: jis@fpk.hp.com Date: Fri, 17 Jul 1998 10:43:51 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Steve Vinoski Cc: Jonathan Biggar , orb_revision@omg.org Subject: Re: More edits needed for Issue 754 proposal References: <199807171321.JAA11362@boston.iona.ie> Steve Vinoski wrote: > At 09:53 PM 7/16/98 -0700, Jonathan Biggar wrote: > >While perusing the CORBA 2.2 spec this evening, I discovered text > that > >needs changing as part of the fixed point cleanup proposal for > issue > >754: > > > >In section 8.7.2, delete the second paragraph that talks about > TypeCode > >constants for fixed point types, since there are no longer any > anonymous > >fixed point types. > > Actually, the OBV RTF transferred an issue concerning 8.7.2 to the > ORB RTF, > and I have already submitted new text to Jishnu that does exactly > what > you've asked for. > > --steve Yup, this is taken care of in the resolution for 1258 that will be on vote 4. Attached is a sneak preview: Jishnu. Issue 1258: Type code constants are not defined/mentioned in OBV spec (obv-rtf) Click here for this issue's archive. Source: International Business Machines (Mr. Leo Uzcategui, leou@us.ibm.com) Nature: Revision Severity: Summary: I don't understand why TypeCode constants, e.g. TC_CORBA_InterfaceDescription and TC_CORBA_FullInterfaceDescription, are not mentioned or defined in the OBV spec. The CORBA spec defines a set of predefined TypeCode constants for InterfaceDescription, OperationDescription, AttributeDescription, etc., named TC_CORBA_InterfaceDescription, ... (see section 8.7 TypeCodes in CORBA 2.2) It seems that new ones should be defined to be consistent, but then it may be my misunderstanding. Resolution: Modify section 8.7.2 as shown below Revised Text: 8.7.2 TypeCode Constants If FOO is an IDL type declaration, the IDL compiler will produce a declaration of a TypeCode constant. Names of TypeCode constants are specific to each language mapping. These constants can be used with the Dynamic Invocation Interface and any other routines that require TypeCodes. The predefined TypeCode constants, named according to the C language mapping, are: TC_null TC_void TC_short TC_long TC_longlong TC_ushort TC_ulong TC_ulonglong TC_float TC_double TC_longdouble TC_boolean TC_char TC_wchar TC_octet TC_any TC_TypeCode TC_Object = tk_objref { Object } TC_string= tk_string { 0 } // unbounded TC_wstring = tk_wstring{0} mmmmm/// unbounded Actions to be taken: incorporate change in 2.3 and close April 28, 1998: received issue