Ada.Strings.Bounded
in [ADA]
|
From: Adam Beneschan on 23 Apr 2008 11:03 On Apr 23, 7:40 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Wed, 23 Apr 2008 13:14:24 +0000 (UTC), Peter Hermann wrote: > > BTW (changing topic): > > I am still hoping that the next Ada 2015 will contain > > > subtype Number_Base is Integer range 2 .. 36; -- old:16; > > You should have asked for more, much MORE! Right! Base 36 allows us to use letters from A to Z, instead of just A to F. But with Unicode, we now have many, many, many more letters, so why limit it to 36? I think it would be great to have a numeric base that would allow us to encode a numeric literal that includes C with a hacek, a Tamil letter, some 5th-century Ogham runes, and a couple Chinese ideographs all in the same literal. It's obvious that this would be a very useful feature. -- Adam
From: Adam Beneschan on 23 Apr 2008 11:12 On Apr 23, 3:42 am, Georg Bauhaus <rm.dash-bauh...(a)futureapps.de> wrote: > Without of course knowing why the choices were made the > way they were made for the LRM, my conclusion is that > many programmers still prefer high school ideas about > numbers over the theory of computer numbers. Nahhh, we just want to write programs that work, and have a language that helps prevent us from making stupid errors, but without forcing us to waste time writing needless junk in order to have things fit more consistently into some "theory". Remember, "theory" is our servant, not our master. -- Adam
From: (see below) on 23 Apr 2008 11:36 On 23/04/2008 16:12, in article 62dde2ab-d6ad-454b-aa87-8dbc23855903(a)v23g2000pro.googlegroups.com, "Adam Beneschan" <adam(a)irvine.com> wrote: > On Apr 23, 3:42 am, Georg Bauhaus <rm.dash-bauh...(a)futureapps.de> > wrote: > >> Without of course knowing why the choices were made the >> way they were made for the LRM, my conclusion is that >> many programmers still prefer high school ideas about >> numbers over the theory of computer numbers. > > Nahhh, we just want to write programs that work, and have a language > that helps prevent us from making stupid errors, but without forcing > us to waste time writing needless junk in order to have things fit > more consistently into some "theory". Remember, "theory" is our > servant, not our master. Bravo! -- Bill Findlay <surname><forename> chez blueyonder.co.uk
From: Ray Blaak on 23 Apr 2008 13:09 Adam Beneschan <adam(a)irvine.com> writes: > Nahhh, we just want to write programs that work, and have a language > that helps prevent us from making stupid errors, but without forcing > us to waste time writing needless junk in order to have things fit > more consistently into some "theory". Remember, "theory" is our > servant, not our master. Careful. That way lies the path to the dark side: dynamic typing, garbage collection, interpreted scripts. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK(a)STRIPCAPStelus.net The Rhythm has my soul.
From: Randy Brukardt on 23 Apr 2008 20:29
"Georg Bauhaus" <rm.dash-bauhaus(a)futureapps.de> wrote in message news:480f1298$0$6782$9b4e6d93(a)newsspool2.arcor-online.net... .... > Without of course knowing why the choices were made the > way they were made for the LRM, my conclusion is that > many programmers still prefer high school ideas about > numbers over the theory of computer numbers. The reason is that the "theory" doesn't match the capabilities of actual computer hardware. If you required intermediate results to be checked, integer expressions would generate 5 times as much code and run only half as fast as they do. (I'm basing that on the code generated by Janus/Ada, and only considering operators beyond the first in an expression. It might be possible to do a bit better, but I've looked at the code generated by other compilers and I don't think it is wildly different) That wouldn't be competive with other computer languages. You could complain that X := E'pred(E'succ(C)); isn't different. And indeed I'd agree: it *is* twice as big and substantially slower than the equivalent X := (C + 1) - 1; would be. It just doesn't matter much because it is rare to use more than one attribute in an expression, while using multiple integer operators in an expression is very common. > Is it really inacceptable to write > > Larger_Type'(Blah + 1) mod 99; > > The expression doesn't hide a secret about its > value range. There may be no such type, and optimizers transform expressions all of the time based on the "the correct answer is always OK" rule. It may not be necessary to evaluate the expression with a larger type. You're essentially saying that you *don't* want the correct answer in that case, which seems way too pedantic. I don't think that much code improvement could be done at all with a strict rule (it's hard to do any as it as, given that overflow checking prevents a lot of reordering that would be OK in C). The net effect is that if you want efficient code, you have to relax the strict rules somewhere. And Ada does that without sacrificing any safety. (Another similar place is the "invalid" object rules, which allow compilers to eliminate range checks so long as the value is checked before doing anything dangerous [like array indexing].) Randy. |