* obsolete ascii? (for language lawyers) @ 1999-06-29 0:00 Peter Hermann 1999-06-29 0:00 ` John Herro ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Peter Hermann @ 1999-06-29 0:00 UTC (permalink / raw) LRM A.1(36) states an obsolete package ASCII. now look at my example: with text_io; procedure hello is bell : character := character'val(7); --bell2 : character := bel; -- is not allowed :-( begin text_io.put_line ("Hallo Welt..." & ascii.bel & bell); end hello; What is the reason for this degradation? Why then (zum Kuckuck!) is package ascii declared obsolete? ------------------ An additional remark: text_io.put_line(ascii.bel); is not allowed, because put_line (in contrast to put) does not allow single characters as parameters. This is hard to explain to a beginner and therefore a nasty design decision for text_io: having to obey to special cases. Moreover, one could never say: 'put_line' is a combined 'put' and a 'new_line', for the sake of simplicity. -- Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen http://www.csv.ica.uni-stuttgart.de/homes/ph/ Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: obsolete ascii? (for language lawyers) 1999-06-29 0:00 obsolete ascii? (for language lawyers) Peter Hermann @ 1999-06-29 0:00 ` John Herro 1999-07-02 0:00 ` Peter Hermann 1999-06-29 0:00 ` David C. Hoos, Sr. 1999-07-02 0:00 ` Peter Hermann 2 siblings, 1 reply; 15+ messages in thread From: John Herro @ 1999-06-29 0:00 UTC (permalink / raw) Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> writes: > with text_io; > procedure hello is > bell : character := character'val(7); > --bell2 : character := bel; -- is not allowed :-( > begin > text_io.put_line ("Hallo Welt..." & ascii.bel & bell); > end hello; Although ASCII is part of package Standard, and Standard is automatically WITHed and USEd in every compilation, ASCII isn't automatically USEd. You must make use of dot notation or explicitly USE ASCII. The above will compile, even with the declaration of bell2 uncommented, if you write "ASCII.bel" instead of "bel" or write "use ASCII;" immediately AFTER "procedure hello is". - John Herro You can download a shareware AdaTutor program at http://members.aol.com/AdaTutor ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: obsolete ascii? (for language lawyers) 1999-06-29 0:00 ` John Herro @ 1999-07-02 0:00 ` Peter Hermann 0 siblings, 0 replies; 15+ messages in thread From: Peter Hermann @ 1999-07-02 0:00 UTC (permalink / raw) John Herro <johnherro@aol.com> wrote: > Although ASCII is part of package Standard, and Standard is automatically > WITHed and USEd in every compilation, No. Package Standard is embracing every Ada program, i.e. your main procedure and all your subroutines are "part of" standard, they are inside the declaration scope of standard. > ASCII isn't automatically USEd. You must > make use of dot notation or explicitly USE ASCII. Package ascii is, following the above, on the same level as your programs. In this way a required dot notation or an explicite with and use is reasonable. -- Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen http://www.csv.ica.uni-stuttgart.de/homes/ph/ Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: obsolete ascii? (for language lawyers) 1999-06-29 0:00 obsolete ascii? (for language lawyers) Peter Hermann 1999-06-29 0:00 ` John Herro @ 1999-06-29 0:00 ` David C. Hoos, Sr. 1999-06-29 0:00 ` Ted Dennison 1999-07-02 0:00 ` Peter Hermann 2 siblings, 1 reply; 15+ messages in thread From: David C. Hoos, Sr. @ 1999-06-29 0:00 UTC (permalink / raw) Peter Hermann wrote in message <7las7v$5p0$1@infosun2.rus.uni-stuttgart.de>... >LRM A.1(36) states an obsolete package ASCII. > >now look at my example: > > with text_io; >procedure hello is > bell : character := character'val(7); > --bell2 : character := bel; -- is not allowed :-( >begin > text_io.put_line ("Hallo Welt..." & ascii.bel & bell); > end hello; >What is the reason for this degradation? You would need a use clause for package ASCII, or use dot notation. >Why then (zum Kuckuck!) is package ascii declared obsolete? Because a package like Ada.Characters.Latin_1 replaces it, and extends the range to include 256 characters instead of 128. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: obsolete ascii? (for language lawyers) 1999-06-29 0:00 ` David C. Hoos, Sr. @ 1999-06-29 0:00 ` Ted Dennison 0 siblings, 0 replies; 15+ messages in thread From: Ted Dennison @ 1999-06-29 0:00 UTC (permalink / raw) In article <7lb7ri$2g2@hobbes.crc.com>, "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote: > > Peter Hermann wrote in message > <7las7v$5p0$1@infosun2.rus.uni-stuttgart.de>... > >Why then (zum Kuckuck!) is package ascii declared obsolete? > > Because a package like Ada.Characters.Latin_1 replaces it, and > extends the range to include 256 characters instead of 128. Also, ASCII is an obsolete American standard, while Latin_1 is an international standard that fits into the "Unicode" universal character standard. -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: obsolete ascii? (for language lawyers) 1999-06-29 0:00 obsolete ascii? (for language lawyers) Peter Hermann 1999-06-29 0:00 ` John Herro 1999-06-29 0:00 ` David C. Hoos, Sr. @ 1999-07-02 0:00 ` Peter Hermann 1999-07-02 0:00 ` Robert Dewar ` (2 more replies) 2 siblings, 3 replies; 15+ messages in thread From: Peter Hermann @ 1999-07-02 0:00 UTC (permalink / raw) Thanks to John Herro, David C. Hoos, Sr., Ted Dennison. I am afraid I did not explain my question precisely enough. With Ada95 we have a quite better type character, but I can't see any reason why i should not have the possibility to directly write down e.g. the bel-character, the ff-character, the cr-character, the esc-character etc. etc. as a simple identifier, the comfort of which will be removed as soon as the 'obsolete' package ascii will be removed! We even cannot write something like character'(bel) or the like. Sort of latin1.bel could do it? Are there better ideas? Or did I miss a given feature? Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> wrote: > LRM A.1(36) states an obsolete package ASCII. > > now look at my example: > > with text_io; > procedure hello is > bell : character := character'val(7); > --bell2 : character := bel; -- is not allowed :-( > begin > text_io.put_line ("Hallo Welt..." & ascii.bel & bell); > end hello; > What is the reason for this degradation? > Why then (zum Kuckuck!) is package ascii declared obsolete? > ------------------ > An additional remark: > text_io.put_line(ascii.bel); is not allowed, > because put_line (in contrast to put) does not > allow single characters as parameters. > This is hard to explain to a beginner and > therefore a nasty design decision for text_io: > having to obey to special cases. > Moreover, one could never say: > 'put_line' is a combined 'put' and a 'new_line', > for the sake of simplicity. -- Peter Hermann Tel+49-711-685-3611 Fax3758 ica2ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen http://www.csv.ica.uni-stuttgart.de/homes/ph/ Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: obsolete ascii? (for language lawyers) 1999-07-02 0:00 ` Peter Hermann @ 1999-07-02 0:00 ` Robert Dewar 1999-07-02 0:00 ` Keith Thompson 1999-07-02 0:00 ` Robert A Duff 1999-07-02 0:00 ` Ted Dennison 2 siblings, 1 reply; 15+ messages in thread From: Robert Dewar @ 1999-07-02 0:00 UTC (permalink / raw) In article <7lhqs9$9c$1@infosun2.rus.uni-stuttgart.de>, Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> wrote: > Thanks to John Herro, David C. Hoos, Sr., Ted Dennison. > I am afraid I did not explain my question precisely enough. > With Ada95 we have a quite better type character, but > I can't see any reason why i should not have the possibility > to directly write down e.g. the bel-character, the > ff-character, > the cr-character, the esc-character etc. etc. as a simple > identifier, > the comfort of which will be removed as soon as the > 'obsolete' package ascii will be removed! Don't worry, there is no possibility whatsoever of anyone doing anything so idiotic as to create major incompatibilities by removing package Ascii. Even if the ISO committee did make a silly decision like this, vendors would put it back. The whole business of obsolescent features is in my view completely silly. The features in annex J are so small and marginal, that to remove them would not begin to be worth the headaches caused by legacy code. You should feel free to use any of these features without the slightest hesitation in my view. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: obsolete ascii? (for language lawyers) 1999-07-02 0:00 ` Robert Dewar @ 1999-07-02 0:00 ` Keith Thompson 1999-07-03 0:00 ` Robert Dewar 0 siblings, 1 reply; 15+ messages in thread From: Keith Thompson @ 1999-07-02 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > Don't worry, there is no possibility whatsoever of anyone > doing anything so idiotic as to create major incompatibilities > by removing package Ascii. Even if the ISO committee did make > a silly decision like this, vendors would put it back. Agreed. > The whole business of obsolescent features is in my view > completely silly. The features in annex J are so small and > marginal, that to remove them would not begin to be worth > the headaches caused by legacy code. > > You should feel free to use any of these features without > the slightest hesitation in my view. Here, I have to disagree. Part of the point of declaring a feature to be obsolescent is to warn that it might be removed in a future version of the standard. (I agree that this isn't likely to happen.) The more important reason, however, is to let people know that there's a newer, better way to do the same thing. These are features that are in the language *only* to support legacy code; if the language were being designed from scratch today, they wouldn't be there. I wouldn't use '%' as a string literal delimiter, or write a context clause for Text_IO (rather than Ada.Text_IO), or a handler for Numeric_Error, in new code -- not because I expect any of those features to vanish, but because it's bad style. (I wonder how many Ada programmers even know that this: with Text_IO; procedure Obsolesce is X : Integer := 16:FF:; begin Text_IO.Put_Line(%X = % & Integer'Image(X)); end Obsolesce; is valid.) On the other hand, if you have legacy code that uses these features, it's not worth going back and changing it unless you're doing a major rewrite anyway. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: obsolete ascii? (for language lawyers) 1999-07-02 0:00 ` Keith Thompson @ 1999-07-03 0:00 ` Robert Dewar 1999-07-03 0:00 ` Keith Thompson 0 siblings, 1 reply; 15+ messages in thread From: Robert Dewar @ 1999-07-03 0:00 UTC (permalink / raw) In article <yecemiq75ww.fsf@king.cts.com>, Keith Thompson <kst@cts.com> wrote: > more important reason, however, is to let people know that > there's a newer, better way to do the same thing. These are > features that are in the language *only* to support legacy > code; if the language were being designed from scratch today, > they wouldn't be there. No, you cannot conclude any of the above. All you can conclude is that certain people and in particular the design team, thought that some of the above were true. Those of us who disagreed in some cases did not argue strongly, because, at least speaking for myself, I did not care if features ended up in annex J or not. For example, I happen to think that the way that Ada 83 maps interrupts is much cleaner and higher level than the method in Ada 95 which is deliberately chosen to be lower level and closer to the way some hardware works (not all hardware incidentally, most computers in the world, powered by ia32 chips have hardware that maps very nicely the semantic model of Ada 83 interrupts (although I doubt any Ada implementation has taken advantage of this). > I wouldn't use '%' as a string literal delimiter Neither would I, but not because someone put this feature into Annex J, but rather because the reason for this feature (input devices lacking the clearer quote sign) have disappeared from sight, so it makes no sense to use it (this is true of those writing Ada 83 today as well!) > or write a context clause for Text_IO (rather than > Ada.Text_IO) Fine you are welcome to this opinion, but please form it for OTHER reasons than the fact that this is in Annex J. Personally I see no reason whatever to type the 4 or 8 (use) extra characters, since there is no possibility of generating any confusion on the part of the reader by using Text_IO rather than Ada.Text_IO, and I actually find Unchecked_Conversion nicer than Ada.Unchecked_Conversion, since this really should be a fundamental language feature, and I see no reason why the reader needs the reminder of the fiction that it is a library package, let alone to need to be reminded of exactly where to find this bogus library package (bogus because some implementation magic will always be required for UC!) > or a handler for Numeric_Error, in new code Again, no well written Ada 83 code has handlers for Numeric_Error either, since Ada 83 compilers are encouraged to treat CE and NE the same, Ada 95 style, and have been for many many years. Yes, some annoying compilers refused to follow this implementation advice :-) > not because I expect any of those > features to vanish, but because it's bad style. No, that's wrong, there is no absolute standard that says it is bad style. Not even the RM says this, it says: 1 This Annex contains descriptions of features of the language whosefunctionality is largely redundant with other features defined by thisInternational Standard. Use of these features is not recommended in newly written programs. Note here that the RM claims only "largely redundant", not the much stronger claim from Keith that there is always a newer and better way of doing things. And it does not say that the reason for the recommendation is that it is bad style. Indeed the understanding when the design team presented Annex J was always that the reason for this recommendation was that these features might disappear in the future. So what we are left with is really that *Keith* thinks it is bad style. Fine, everyone has different stylistic views. The next time you are deciding whether to write Text_IO or Ada.Text_IO, it is perfectly appropriate to choose what *you* think is the right style, if you like you can let yourself be influenced by the stylistic preferences of Keith or Robert or anyone else, but you should not accept Keith's claim that there is some definite higher authority that declares that using Annex J features is bad style :-) I actually did worry a bit that people would adopt Keith's attitude, and you can easily see inflexible management turning this into a prohibition without sufficient thought. This is why I worked hard to get pragma Elaborate moved out of Annex J, since that for *sure* was functionality that is needed (if you think Elaborate_All replaces it, you have not tried to port some large legacy programs :-) At this stage, there is not much left in Annex J (we did work to pull stuff out!) The remaining items are package renamings -- use them freely why not? character replacements -- unnecessary for the most part. A possible exception is if you are using certain funny European keyboards (actually some people in WG9 claimed that the bar replacement was essential). Reduced accuracy subtypes -- useful for controlling I/O behavior in some situations (there was an attempt to remove these completely from the language -- this useful application was pointed out, and a compromise put them back in, but only in Annex J. Constrained attribute on private types. Probably only useful in legacy code. ASCII. Very useful, it is an annoying amount of typing to have to say with Ada.Characters.Latin_1 and then Ada.Characters.Latin_1.Bel instead of simply Ascii.Bel in a unit that needs this single reference. Furthermore the Latin_1 package puts piles of junk symbols that are almost certainly of no use into your name space. I find the insistence on using Ada.Characters.Latin_1 to be excessive Ada pedantry, and you should not for a moment be intimidated into writing all this nonsense unless *YOU* prefer to write it, and think it makes things clearer. Numeric_Error, this is only relevant if you are writing code that is intended to be portable between Ada 95 and Ada 83 (some people are still in this situation), in which case you should write when Constraint_Error | Numeric_Error => (and I hope you do not have too many such handlers, code with lots of explicit Constraint_Error handlers is suspect!) At clauses. Obsolete indeed, the new address clause is cleaner and more consistent, but no particular reason to go changing legacy code. No reason to use this in new code. Interrupt entries. As mentioned above, a nice feature. One has to hope that one's compiler implements this nice feature :-) Mod clauses. Same comments apply as for at clauses. Storage_Size. I don't really see why this is obsolete. The alternate pragma form is fine, but in some ways the Ada 83 style is more consistent with other Ada 95 syntax. > (I wonder how many Ada programmers even know that this: > > with Text_IO; > procedure Obsolesce is > X : Integer := 16:FF:; > begin > Text_IO.Put_Line(%X = % & Integer'Image(X)); > end Obsolesce; > > is valid.) Well the fact is that any competent Ada programmer should have at least read through the features of the language, and these features include Annex J. It is certainly possible that you may meet the % in existing code, and a programmer who knows the features of Ada including this one, is better off than one who does not! > On the other hand, if you have legacy code that uses these > features, it's not worth going back and changing it Indeed! > unless you're doing a major rewrite anyway. And maybe not even then, don't fix things that are not broken. In some cases, the fixes may not be completely trivial (certainly true for the interrupt case for example, and for reduced accuracy subtypes -- it may be QUITE difficult to determine if reduced accuracy subtypes have some significant function -- for example one of our customers was using reduced accuracy subtypes to define larger epsilon values to be used in comparison of floating-point values). Robert Dewar Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: obsolete ascii? (for language lawyers) 1999-07-03 0:00 ` Robert Dewar @ 1999-07-03 0:00 ` Keith Thompson 1999-07-08 0:00 ` John Duncan 1999-07-08 0:00 ` Tucker Taft 0 siblings, 2 replies; 15+ messages in thread From: Keith Thompson @ 1999-07-03 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > In article <yecemiq75ww.fsf@king.cts.com>, > Keith Thompson <kst@cts.com> wrote: > > > more important reason, however, is to let people know that > > there's a newer, better way to do the same thing. These are > > features that are in the language *only* to support legacy > > code; if the language were being designed from scratch today, > > they wouldn't be there. > > No, you cannot conclude any of the above. All you can conclude > is that certain people and in particular the design team, > thought that some of the above were true. > > Those of us who disagreed in some cases did not argue strongly, > because, at least speaking for myself, I did not care if > features ended up in annex J or not. Ok, I was making some (possibly invalid) assumptions. I wasn't closely involved in the design process, so everything I say here is merely my opinion. In fact, feel free to assume that anything I say anywhere is merely my opinion. Note that I tend to be prejudiced in favor of clean, coherent design over backwards compatibility. I recognize the need for backwards compatibility, but I tend to grit my teeth a bit when I see features that seem to exist only for that reason. I don't expect everyone to share this prejudice. With that in mind, let's go through Annex J. J.1 Renamings of Ada 83 Library Units. I really like the idea of making all the language-defined library units children of a small number of parent units (Ada, System, and Interfaces). It avoids polluting the user's namespace, and (hopefully) encourages vendors and other users to do the same kind of thing -- like the GNAT.* hierarchy. By adopting a uniform style of referring to Ada.Text_IO rather than Text_IO, one can avoid having to worry about the fact that Text_IO has a top-level renaming, but Wide_Text_IO doesn't. If this feature were in the language for any reason other than backward compatibility, it wouldn't be limited to the units that were defined in Ada 83. (Robert mentions that Unchecked_Conversion is really more a fundamental feature of the langauge than a library package. Perhaps it should have been made an attribute. I don't think this is terribly relevant to the subject at hand, though.) J.2 Allowed Replacements of Characters Ada 83 allowed users to use ! for |, : for # (in based literals), and % for ". There were (barely) good reasons for this at the time; it would have been better (IMHO) to implement preprocessors for those rare systems that couldn't use |, #, and ". Ada 95 still allows these replacements. When someone starts an Obfuscated Ada contest, we'll be ready. J.3 Reduced Accuracy Subtypes I don't think I've ever used these. An accuracy constraint isn't really a "constraint" in the sense that a range constraint is; it only affects certain predefined attributes and, indirectly, the behavior of the predefined I/O packages. A note in the AARM suggests the idea of replacing this with an attribute definition clause, which I think would have been cleaner if not for the need for backwards compatibility. J.4 The Constrained Attribute As the AARM says, the Ada 83 definition of this attribute (for subtypes) was confusing, and the introduction of private subtypes just makes it worse. I don't have anything to add here. J.5 ASCII Yes, Ada.Characters.Latin_1 is more verbose than ASCII, but it also covers the entire character set that Ada 95 is required to support. If the language were being designed from scratch, it wouldn't make sense to have both. If you want to refer to names like BEL directly, you only have to type with Ada.Characters.Latin_1; use Ada.Characters.Latin_1; once per compilation unit. J.6 Numeric_Error I think we can all agree this is obsolete, and is still there only for backward compatibility reasons. There's no reason to use it in new code, unless you need strict Ada 83 compatibility (which hardly seems necessary these days). (For the record, I suggested raising Constraint_Error rather than Numeric_Error in TeleSoft's compiler, but I was overruled.) J.7 At Clauses I think this is a clear example of a feature for which there's a better alternative in Ada 95 ("for foo use at expr" replaced by "for foo'address use expr"). J.7.1 Interrupt Entries I haven't used these much. I'll take your word for it that the old form is still useful. J.8 Mod Clauses See At Clauses. J.9 The Storage_Size Attribute The Storage_Size pragma, which allows a different Storage_Size to be specified for each task object, makes the 'Storage_Size of a task type questionably meaningful. > > I wouldn't use '%' as a string literal delimiter > > Neither would I, but not because someone put this feature into > Annex J, but rather because the reason for this feature (input > devices lacking the clearer quote sign) have disappeared from > sight, so it makes no sense to use it (this is true of those > writing Ada 83 today as well!) Right, and that's why it's in Annex J, yes? > > or write a context clause for Text_IO (rather than > > Ada.Text_IO) > > Fine you are welcome to this opinion, but please form it for > OTHER reasons than the fact that this is in Annex J. I have. > > not because I expect any of those > > features to vanish, but because it's bad style. > > No, that's wrong, there is no absolute standard that says it > is bad style. There is an absolute standard that defines "bad style" as "what Keith Thompson doesn't like". 8-)} Isn't style always a matter of opinion? Hopefully informed opinion, of course. Naturally, everyone should agree with mine. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> One of the great tragedies of ancient history is that Helen of Troy lived before the invention of the champagne bottle. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: obsolete ascii? (for language lawyers) 1999-07-03 0:00 ` Keith Thompson @ 1999-07-08 0:00 ` John Duncan 1999-07-08 0:00 ` Tucker Taft 1 sibling, 0 replies; 15+ messages in thread From: John Duncan @ 1999-07-08 0:00 UTC (permalink / raw) > Ada 83 allowed users to use ! for |, : for # (in based literals), and > % for ". There were (barely) good reasons for this at the time; it > would have been better (IMHO) to implement preprocessors for those > rare systems that couldn't use |, #, and ". Ada 95 still allows these > replacements. When someone starts an Obfuscated Ada contest, we'll be > ready. I have to agree that it's important to have these things remain in the language, just like it's important to include trigraphs in C++. The point is that a new version has utility in being an upwardly-compatible superset of the previous standard. ISO/IEC 646 is more than just a wacky 7-bit set. It is a character set that the entire world agreed upon as a standard that could be respected as an acceptable factor of the national languages in use at the time. It's enough to represent without ambiguity almost all romantic words, even though it is lacking on punctuation. (You can't do much with 108 characters, considering 52 of them are the basic romantic letters.) But, provided that strict adherence to the standard is enabled, legacy code written with trigraphs, which are pretty weird, can be compiled. In the same way, the however many MSLOC written in standard Ada 83 can be compiled by a validated Ada 95 compiler. Perhaps you enjoy porting code, but most people don't. Porting can cause maintenance problems and people get associated to porting projects that could have been more useful and happy doing development. I wonder if you think that COBOL should forgo its column-oriented structure for a more terminal-friendly one and drop the references to a Hollerith card completely from the standard. Then, expect people to use the new compilers. It's absurd. As a new compiler vendor, you'd implement the extensions to support card format anyway. It's just not worth alienating the old. -John ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: obsolete ascii? (for language lawyers) 1999-07-03 0:00 ` Keith Thompson 1999-07-08 0:00 ` John Duncan @ 1999-07-08 0:00 ` Tucker Taft 1 sibling, 0 replies; 15+ messages in thread From: Tucker Taft @ 1999-07-08 0:00 UTC (permalink / raw) Keith Thompson wrote: > > Robert Dewar <robert_dewar@my-deja.com> writes: > > In article <yecemiq75ww.fsf@king.cts.com>, > > Keith Thompson <kst@cts.com> wrote: > > > > > more important reason, however, is to let people know that > > > there's a newer, better way to do the same thing. These are > > > features that are in the language *only* to support legacy > > > code; if the language were being designed from scratch today, > > > they wouldn't be there. > > > > No, you cannot conclude any of the above. All you can conclude > > is that certain people and in particular the design team, > > thought that some of the above were true. > > > > Those of us who disagreed in some cases did not argue strongly, > > because, at least speaking for myself, I did not care if > > features ended up in annex J or not. > > Ok, I was making some (possibly invalid) assumptions. I wasn't > closely involved in the design process, so everything I say here is > merely my opinion. In fact, feel free to assume that anything I say > anywhere is merely my opinion. > > Note that I tend to be prejudiced in favor of clean, coherent design > over backwards compatibility. I recognize the need for backwards > compatibility, but I tend to grit my teeth a bit when I see features > that seem to exist only for that reason. I don't expect everyone to > share this prejudice. For what it is worth, I tend to agree with Keith's view more than Robert's here. The point of Annex J was to remove from the main part of the manual the constructs of Ada 83 which were *perceived by the design team* as being marginal or redundant in the context of Ada 95. The goal was to present a (slightly ;-) simpler language, by moving these marginal/redundant features out of the main stream of the discussion. Of course, the manual is still daunting, and Robert will be happy to point out that the Ada 83 manual was significantly more readable (warts and all ;-). But if you want to know the design team's intent, it was along the lines of what Keith has said -- avoid talking about things that are only there for supporting legacy code, so that a new user of Ada encountering the Ada 95 manual has a few less things to worry about. Clearly, not all the Ada 9X reviewers had the same perception of Annex J. > -- > Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> > San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> > One of the great tragedies of ancient history is that Helen of Troy > lived before the invention of the champagne bottle. -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: obsolete ascii? (for language lawyers) 1999-07-02 0:00 ` Peter Hermann 1999-07-02 0:00 ` Robert Dewar @ 1999-07-02 0:00 ` Robert A Duff 1999-07-02 0:00 ` Ted Dennison 2 siblings, 0 replies; 15+ messages in thread From: Robert A Duff @ 1999-07-02 0:00 UTC (permalink / raw) Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> writes: > Thanks to John Herro, David C. Hoos, Sr., Ted Dennison. > I am afraid I did not explain my question precisely enough. > With Ada95 we have a quite better type character, but > I can't see any reason why i should not have the possibility > to directly write down e.g. the bel-character, the ff-character, > the cr-character, the esc-character etc. etc. as a simple identifier, You could not write just "BEL" in Ada 83, and you still can't in Ada 95. You have to say "Ascii.BEL;", or you can "use Ascii;" and then you can say just "BEL". Same for both Ada 83 and Ada 95. This is good -- I don't want my namespace cluttered with all those arcane symbols, most of which I never use. Furthermore, the meaning of these control characters on I/O is rather non-portable, so they shouldn't be directly visible everywhere. You cannot say "with Ascii;" -- the name Ascii is always directly visible (unless you hide it with something else called Ascii). > the comfort of which will be removed as soon as the > 'obsolete' package ascii will be removed! All compilers are required to support package Ascii and all the other Obsolescent Features. I doubt if any of the Obsolescent Features will ever be removed from the language. > We even cannot write something like character'(bel) or the like. > Sort of latin1.bel could do it? In Ada 95, you can also "with Ada.Characters.Latin_1;", and then say "Latin_1.BEL", and you can also use a use clause, of course. > Are there better ideas? Or did I miss a given feature? You seem to be saying that Ada 95 took something away, which is not True. Package Ascii is still there, and still works exactly the same way. - Bob -- Change robert to bob to get my real email address. Sorry. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: obsolete ascii? (for language lawyers) 1999-07-02 0:00 ` Peter Hermann 1999-07-02 0:00 ` Robert Dewar 1999-07-02 0:00 ` Robert A Duff @ 1999-07-02 0:00 ` Ted Dennison 1999-07-02 0:00 ` Ted Dennison 2 siblings, 1 reply; 15+ messages in thread From: Ted Dennison @ 1999-07-02 0:00 UTC (permalink / raw) In article <7lhqs9$9c$1@infosun2.rus.uni-stuttgart.de>, Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> wrote: > Thanks to John Herro, David C. Hoos, Sr., Ted Dennison. > I am afraid I did not explain my question precisely enough. > With Ada95 we have a quite better type character, but > I can't see any reason why i should not have the possibility > to directly write down e.g. the bel-character, the ff-character, > the cr-character, the esc-character etc. etc. as a simple identifier, > the comfort of which will be removed as soon as the > 'obsolete' package ascii will be removed! I'm not entirely sure I understand your problem. Latin_1 has all those characters. Is it just that "Characters.Latin_1.BEL" takes up more columns in your source file than "ASCII.BEL"? There are a number of easy ways to fix that. If you want, you could even do the following: package ASCII renames Characters.Latin_1; ..and you'd be able to write your code very much like you used to. -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: obsolete ascii? (for language lawyers) 1999-07-02 0:00 ` Ted Dennison @ 1999-07-02 0:00 ` Ted Dennison 0 siblings, 0 replies; 15+ messages in thread From: Ted Dennison @ 1999-07-02 0:00 UTC (permalink / raw) In article <7lih9i$ckb$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > characters. Is it just that "Characters.Latin_1.BEL" takes up more > package ASCII renames Characters.Latin_1; Yikes! Make both those "Ada.Characters.Latin_1". -- T.E.D. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~1999-07-08 0:00 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-06-29 0:00 obsolete ascii? (for language lawyers) Peter Hermann 1999-06-29 0:00 ` John Herro 1999-07-02 0:00 ` Peter Hermann 1999-06-29 0:00 ` David C. Hoos, Sr. 1999-06-29 0:00 ` Ted Dennison 1999-07-02 0:00 ` Peter Hermann 1999-07-02 0:00 ` Robert Dewar 1999-07-02 0:00 ` Keith Thompson 1999-07-03 0:00 ` Robert Dewar 1999-07-03 0:00 ` Keith Thompson 1999-07-08 0:00 ` John Duncan 1999-07-08 0:00 ` Tucker Taft 1999-07-02 0:00 ` Robert A Duff 1999-07-02 0:00 ` Ted Dennison 1999-07-02 0:00 ` Ted Dennison
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox