Ada.Bounded_Strings
in [ADA]
|
From: Adam Beneschan on 4 Apr 2008 17:09 On Apr 4, 9:10 am, Pascal Obry <pas...(a)obry.net> wrote: > > Sorting out string handling out would be nice, too. > > Probably something to do in this area I agree. OK, this is *really* beating a dead horse, but... When I read this and was thinking randomly about Ada's string handling, I got to wondering why Bounded_Strings was defined as a generic, rather than declaring a discriminated type with the maximum length as the discriminant. I don't know why I hadn't thought of this before, in the last 13 years, but I figured someone else had probably asked that, so sure enough after a bit of searching I ended up finding the answer in the Ada 95 Rationale. The problem is, the answer doesn't make a whit of sense to me. The idea was to declare a non-generic package and a Bounded_String type that looked like: type Bounded_String (Max_Length : Positive) is record Length : Natural; Data : String(1..Max_Length); end record; The disadvantage of this approach was given as this: "[P]redefined assignment and equality for discriminated Bounded_String do not have the desired behavior. Assignment makes sense when the maximum lengths of source and target are different, as long as the source's current length is no greater than the target's maximum length, yet predefined ":=" would raise Constraint_Error on the discriminant mismatch". The reason this doesn't make sense to me is, how does the generic definition solve the problem? If you have two different maximum lengths, then you have to instantiate Bounded_Strings twice to get types with different maximum lengths; and then the Bounded_String types are separate types and you can't do an assignment anyway. So I don't see why this was considered a disadvantage of the discriminant approach. (Plus, with a discriminant definition you could at least write an assignment *procedure* with one OUT parameter, but you can't do that with generics, except by defining a second generic package that takes two instances of Bounded_Strings as formal parameters, which would then have to be instantiated for every combination of two lengths for which you'd want to do assignment.) I realize I'm at least a decade too late in asking this, but in case someone has a good memory, I was wondering if someone could explain this to me? And would it be useful to add a package like this now? (I'm thinking of this because Graham alluded to Ada's not being adopted in business settings, and I'm wondering whether this kind of type would seem more comfortable and familiar to COBOL-type programmers than an Unbounded_String type. But I'm just guessing---I really wouldn't know.) -- thanks, Adam
From: Robert A Duff on 4 Apr 2008 19:35 Adam Beneschan <adam(a)irvine.com> writes: > The disadvantage of this approach was given as this: "[P]redefined > assignment and equality for discriminated Bounded_String do not have > the desired behavior. Assignment makes sense when the maximum lengths > of source and target are different, as long as the source's current > length is no greater than the target's maximum length, yet predefined > ":=" would raise Constraint_Error on the discriminant mismatch". > > The reason this doesn't make sense to me is, how does the generic > definition solve the problem? It doesn't, but it does cause the problem to be prevented statically, rather than via an exception at run time. As far as I know, there is no way to actually solve the problem in Ada -- that is, allow all the assignments that make sense, and no others. I must admit, that generic seems awfully heavy. Part of the rationale (rationalization?) was that you can just pick some reasonable max length, and instantiate the thing once, and use it all over your program. - Bob
From: Adam Beneschan on 4 Apr 2008 21:46 On Apr 4, 4:35 pm, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > Adam Beneschan <a...(a)irvine.com> writes: > > The disadvantage of this approach was given as this: "[P]redefined > > assignment and equality for discriminated Bounded_String do not have > > the desired behavior. Assignment makes sense when the maximum lengths > > of source and target are different, as long as the source's current > > length is no greater than the target's maximum length, yet predefined > > ":=" would raise Constraint_Error on the discriminant mismatch". > > > The reason this doesn't make sense to me is, how does the generic > > definition solve the problem? > > It doesn't, but it does cause the problem to be prevented statically, > rather than via an exception at run time. Right. But even in the discriminant case, the compiler would usually know statically that the assignment would necessarily raise an exception. (I'm assuming the discriminant would be constant in the vast majority of cases.) The compilers I'm familiar with would display that fact at compile time. Our compiler also has an option to reject programs that will necessarily fail a predefined check such as this. > As far as I know, there is no way to actually solve the problem in Ada > -- that is, allow all the assignments that make sense, and no others. Not in a way that allows you to put the two characters := in the statement. But in the discriminant case, you can still define your own assignment *procedure*, which is almost as good. I know, it doesn't help with initializers. > I must admit, that generic seems awfully heavy. Part of the rationale > (rationalization?) was that you can just pick some reasonable max > length, and instantiate the thing once, and use it all over your > program. Again, this doesn't sound reasonable in the context of the sort of "business applications" that I used to work on in COBOL. For other types of applications, it's probably OK, or Ada.Strings.Unbounded may be best. The reason I'm even thinking about all this is that I had been hoping for a number of years now that Ada would be able to make inroads into "business" applications and maybe be seen as an alternative to COBOL, and I'm a bit disappointed that, AFAIK, nothing or very little has happened in that arena. Not that I think Ada.Strings.Bounded is a major reason for this, or that providing a better string-handling facility would help at all. (shrug) -- Adam
From: Randy Brukardt on 5 Apr 2008 00:55 "Adam Beneschan" <adam(a)irvine.com> wrote in message news:444c0bf9-a2ad-4280-8d69-58d59938f69e(a)d2g2000pra.googlegroups.com... .... > Again, this doesn't sound reasonable in the context of the sort of > "business applications" that I used to work on in COBOL. For other > types of applications, it's probably OK, or Ada.Strings.Unbounded may > be best. The reason I'm even thinking about all this is that I had > been hoping for a number of years now that Ada would be able to make > inroads into "business" applications and maybe be seen as an > alternative to COBOL, and I'm a bit disappointed that, AFAIK, nothing > or very little has happened in that arena. Not that I think > Ada.Strings.Bounded is a major reason for this, or that providing a > better string-handling facility would help at all. (shrug) I think that the inability to write a package that "naturally" uses literals (and possibly indexing and slicing) for a private type are also large impediments. (Worse, the current string packages cannot be retrofitted to use such a capability even if it was added to Ada, lessening the possibility of doing that.) Net-net, I think the string packages are a disaster: just good enough to prevent them from being properly replaced, but not good enough to use in a natural way. (And Ada doesn't do anything useful to support UTF-8, which doesn't help matters any.) Randy.
From: Dmitry A. Kazakov on 5 Apr 2008 03:30
On Fri, 4 Apr 2008 23:55:56 -0500, Randy Brukardt wrote: > "Adam Beneschan" <adam(a)irvine.com> wrote in message > news:444c0bf9-a2ad-4280-8d69-58d59938f69e(a)d2g2000pra.googlegroups.com... > ... >> Again, this doesn't sound reasonable in the context of the sort of >> "business applications" that I used to work on in COBOL. For other >> types of applications, it's probably OK, or Ada.Strings.Unbounded may >> be best. The reason I'm even thinking about all this is that I had >> been hoping for a number of years now that Ada would be able to make >> inroads into "business" applications and maybe be seen as an >> alternative to COBOL, and I'm a bit disappointed that, AFAIK, nothing >> or very little has happened in that arena. Not that I think >> Ada.Strings.Bounded is a major reason for this, or that providing a >> better string-handling facility would help at all. (shrug) > > I think that the inability to write a package that "naturally" uses literals > (and possibly indexing and slicing) for a private type are also large > impediments. + classes of all types. All string types shall become members of one class. > (Worse, the current string packages cannot be retrofitted to > use such a capability even if it was added to Ada, lessening the possibility > of doing that.) Why is this a problem? Old packages could be re-implemented using new features with the specifications left as-is for backward compatibility. > Net-net, I think the string packages are a disaster: just good enough to > prevent them from being properly replaced, but not good enough to use in a > natural way. (And Ada doesn't do anything useful to support UTF-8, which > doesn't help matters any.) I see encodings as a different and more difficult problem. All strings are implementations of an abstract array interface. With different encoding not only the arrays, but also their elements will have a class: ASCII, Latin-1, UCS-2, full Unicode. I have no idea how to handle that keeping all strings in one class. Further, there is the presentation layer (when, say, UTF-8 is seen as a sequence of octets). I am not sure if that need to be exposed. Probably it has to be in order to interface other languages. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |