* Re: Ragged Array Proposal [not found] <37e7c08e@eeyore.callnetuk.com> @ 1999-09-22 0:00 ` Ted Dennison 1999-09-22 0:00 ` Ray Blaak 1999-09-23 0:00 ` Robert I. Eachus 1 sibling, 1 reply; 31+ messages in thread From: Ted Dennison @ 1999-09-22 0:00 UTC (permalink / raw) In article <37e7c08e@eeyore.callnetuk.com>, "Nick Roberts" <nickroberts@callnetuk.com> wrote: > I have set up a WWW site, and posted an article on it detailing a first > draft of my proposal for a 'ragged array type' extension to the language. > The URL is: > > http://www.callnetuk.com/home/nickroberts > > Do please take a look. > > I seem to get the impression that the cognoscenti consider this > particular idea worthless. I am perfectly serious about it, however; I would have used the word "excessive" rather than "worthless". But then again, I probably wouldn't count as a cognoscentum. One thing confuses me about your proposal. You say that when the array is declared all the elements will be constrained. But then you say that you can dynamicly change elements. Are you saying that if I try to assign a 5 character string into an array element that is a 4 character string, the compiler would accept it? If so, how about if a function returns a 5 character string? Or how about if the 4 character string element in the ragged array is passed into a subprogram as an "out" or "in out" parameter? Also for your example you say "the various ways of doing the equivalent thing in Ada 95 are all unappealing." I but I can do the equivalent thing in Ada 95 in only 2 more lines of code: type Command_String_Ptr is access all String; for Command_String_Ptr'Storage_Size use 1024; type Command is (Cut, Copy, Paste, ...); Labels: constant array (Command) of Command_String_Ptr := (Cut => new String'("Cu&t"), Copy => new String'("&Copy"), Paste => new String'("&Paste"), ...); Admittedly I have to keep watch that I leave enough space in the pool for all the command strings. But if this is in an outer block on a virtual memory OS (by far the typcial case), I don't even need the "for" clause. Anyway, perhaps you should explain in the proposal why this approach is unappealing vs. complicating the language. On the plus side, I find the proposal's visual layout, as well as that of the rest of your website, quite visually appealing. I hope it won't be too much of a challange to maintain that standard as your website grows. -- 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] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-22 0:00 ` Ragged Array Proposal Ted Dennison @ 1999-09-22 0:00 ` Ray Blaak 1999-09-23 0:00 ` Tucker Taft ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Ray Blaak @ 1999-09-22 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> writes: > Also for your example you say "the various ways of doing the equivalent > thing in Ada 95 are all unappealing." I but I can do the equivalent > thing in Ada 95 in only 2 more lines of code: > > type Command_String_Ptr is access all String; > for Command_String_Ptr'Storage_Size use 1024; > > type Command is (Cut, Copy, Paste, ...); > > Labels: constant array (Command) of Command_String_Ptr := > (Cut => new String'("Cu&t"), > Copy => new String'("&Copy"), > > Paste => new String'("&Paste"), > ...); The problem with this approach is that the data is duplicated. It is both in the static data area of the program (i.e. the string constants), and in the heap. In Ada95, to avoid duplicating the data, the approach is tedious (i.e. having an aliased constant for each string, and assigning their 'Access values into the array). -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-22 0:00 ` Ray Blaak @ 1999-09-23 0:00 ` Tucker Taft 1999-09-23 0:00 ` Nick Roberts 1999-09-24 0:00 ` Robert Dewar 1999-09-23 0:00 ` Ted Dennison 1999-09-24 0:00 ` Robert Dewar 2 siblings, 2 replies; 31+ messages in thread From: Tucker Taft @ 1999-09-23 0:00 UTC (permalink / raw) Ray Blaak wrote: > > Ted Dennison <dennison@telepath.com> writes: > > Also for your example you say "the various ways of doing the equivalent > > thing in Ada 95 are all unappealing." I but I can do the equivalent > > thing in Ada 95 in only 2 more lines of code: > > > > type Command_String_Ptr is access all String; > > for Command_String_Ptr'Storage_Size use 1024; > > > > type Command is (Cut, Copy, Paste, ...); > > > > Labels: constant array (Command) of Command_String_Ptr := > > (Cut => new String'("Cu&t"), > > Copy => new String'("&Copy"), > > > > Paste => new String'("&Paste"), > > ...); > > The problem with this approach is that the data is duplicated. It is both in > the static data area of the program (i.e. the string constants), and in the > heap. If you change Command_String_Ptr to be "access constant String;" then the recommended implementation does *not* duplicate the static data. It is link-time allocated and initialized. This might vary by compiler, but anything having to do with link-time initialization is an "optimization," so that is true even for static constants. I know at least that the Aonix and Green Hills Ada 95 compilers statically allocate and initialize allocators for access-to-constant types. I haven't checked GNAT. > In Ada95, to avoid duplicating the data, the approach is tedious (i.e. having > an aliased constant for each string, and assigning their 'Access values into > the array). As mentioned above, that is not necessary if the type is access-to-constant (which it must be if you are using 'Access on aliased constants). Take a look at the generated code for new String'("xxx") when the type is access-to-constant. It should not involve any run-time code (presuming the implementation advice was followed by the compiler implementor). > > -- > Cheers, The Rhythm is around me, > The Rhythm has control. > Ray Blaak The Rhythm is inside me, > blaak@infomatch.com The Rhythm has my soul. -- -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] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-23 0:00 ` Tucker Taft @ 1999-09-23 0:00 ` Nick Roberts 1999-09-23 0:00 ` Hyman Rosen ` (2 more replies) 1999-09-24 0:00 ` Robert Dewar 1 sibling, 3 replies; 31+ messages in thread From: Nick Roberts @ 1999-09-23 0:00 UTC (permalink / raw) Tucker Taft <stt@averstar.com> wrote in message news:37EA4E91.1D4D1FC@averstar.com... [...] | If you change Command_String_Ptr to be "access constant String;" then | the recommended implementation does *not* duplicate the static data. | It is link-time allocated and initialized. This might vary by compiler, | but anything having to do with link-time initialization is an "optimization," | so that is true even for static constants. I know at least that the | Aonix and Green Hills Ada 95 compilers statically allocate and initialize | allocators for access-to-constant types. I haven't checked GNAT. [...] My contention is that using an access type and allocators is unappealing simply because the programmer is forced to use an access type and allocators for doing something _really simple_: declaring an array of strings! With the greatest respect, it is perhaps easy for those of you who are steeped in knowledge of the language to overlook this (and there can be no arguing that STT is steeped in knowledge of the language!). Try telling a C++ programmer that, in Ada, they have to declare an access type, and then repeat the "new String'("xyz")" incantation for every string, just to declare an array of strings, and they might be likely to say "Ada? No thanks, I'll stick to C++, if you don't mind." Frankly, the pre-allocation trick (which is fine and dandy in all other respects) only makes things worse from this point of view (simplicity for the programmer), since it makes it looks like something is happening (dynamic allocation) which is actually not. I agree with the idea that Ada language constructs should not be too divorced from their likely underlying implementations, and this seems like a rare example of Ada committing this sin. I would agree that ragged arrays commit the same sin, but I would say less so. To those who argue that adding ragged arrays would add unnecessary complexity to the language, my reply is not to confuse complexity of the language with complexity of _using_ the language. It would unarguably simplify the language tremendously to remove arrays, records, generics, tagged types, subprograms, etc., but it wouldn't simplify using the language. My argument is that ragged arrays would add relatively little to the complexity of the language, but would, in practice, very often simplify using the language a great deal. I think the example of the ragged array in a record demonstrates the most serious reason for introducing ragged arrays. Think about the likely underlying implementation for this (an array of pointers or offsets and a block of data, all totally internal to the record), and then think about how the same thing could be done in existing Ada 95. In general, the closest you can get in Ada 95 is to use an access type (either to the array as a whole, or to the components of the array), and dynamic allocation. The ragged array will generally be more efficient: if your program is going to have multiple objects constrained to the same subtype of the record (a very likely scenario), the 'dope' information only needs to be stored once, saving memory; the necessity to call upon the allocator to allocate either the array or its components is avoided, saving processor time; the necessity to declare access types and mess around with the associated paraphernalia can be avoided (saving hair, in extreme cases :-). Ted Dennison wrote: | One thing confuses me about your proposal. You say that when the array | is declared all the elements will be constrained. But then you say that | you can dynamicly change elements. Are you saying that if I try to | assign a 5 character string into an array element that is a 4 character | string, the compiler would accept it? If so, how about if a function | returns a 5 character string? Or how about if the 4 character string | element in the ragged array is passed into a subprogram as an "out" or | "in out" parameter? I'm not quite sure where I say this, Ted, but I hope I can clarify things using your examples. The subtypes of the components of a ragged array, called the 'profile' of the array, form part of the constraint of the array. Supposing we declared an 'array of strings' ragged array type: type String_Array is array (Positive range <>) of String; we could then declare an object of this type, constrained to, say, three components, with a profile of, say, a 3-character string, a 4-character string, and a 5-character string: People: String_Array(1..3)(String(1..3),String(1..4),String(1..5)); Note the 'profiled constraint': an ordinary index constraint, followed by an 'array profile'. Alternatively, the object could have been constrained by an initial value: People: String_Array := ("Tom","Dick","Harry"); (Note the nice, simple syntax.) Either way, People is now permanently constrained, both in terms of its indexes and its profile. The assignment: People(2) := "Jane"; would be perfectly all right, since People(2) is a 4-character string. However, either of: People(3) := "Jane"; People(2) := "Emily"; would raise Constraint_Error. Nothing can change either the index subtype or the profile of People, and its components follow the same rules they would as stand-alone objects. Since the actual parameter matching an 'out' or 'in out' mode formal parameter must be an object, and all objects of an array type - including my proposed ragged array type - must be constrained, the constraint, including the profile of a ragged array, would be passed in upon a call to the procedure, just as with all other mutable types, and the procedure could not change the constraint. As for a function result, since function return types (as well as any subprogram parameter types) are allowed to be unconstrained, a function could be declared which had simply String_Array as its return type, and then the function could return results with any compatible subtype (i.e. any index range and any profile). For example, a function could be defined to reverse the order of the components of a string array: function Reverse_Order (A: in String_Array) return String_Array; and then the expression Reverse_Order(("Tom","Dick","Harry")) would return the array ("Harry","Dick","Tom"). It is significant to note that the implementation of this function would have to be highly inefficient (involving repeated slicing and concatenating). This illustrates that there would often be situations where an array of access values would be far preferable to a ragged array. My argument is that, conversely, there would often be situations where a ragged array would be preferable to an array of access values. I'm grateful to Ted for his compliment on the appearance of my site (I'll try to maintain the standard!), and I'm very grateful to people taking the time to look at my proposal and post comments. Best wishes, ------------------------------------- Nick Roberts http://www.callnetuk.com/home/nickroberts http://www.adapower.com/lab/adaos ------------------------------------- PS: I'm not at all emotionally attached to the nomenclature that I've invented (even the name "ragged array"), and not entirely happy with it, so suggestions for improvements gratefully accepted. The same goes for the syntax. PPS: Hold on to your hats, folks! Next up is going to be a 'single derived object' proposal. I haven't finished with you yet :-) ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-23 0:00 ` Nick Roberts @ 1999-09-23 0:00 ` Hyman Rosen 1999-09-24 0:00 ` Nick Roberts 1999-09-24 0:00 ` Robert Dewar 1999-09-24 0:00 ` Ted Dennison 2 siblings, 1 reply; 31+ messages in thread From: Hyman Rosen @ 1999-09-23 0:00 UTC (permalink / raw) "Nick Roberts" <nickroberts@callnetuk.com> writes: > Try telling a C++ programmer that, in Ada, they have to declare an access > type, and then repeat the "new String'("xyz")" incantation for every string, > just to declare an array of strings, and they might be likely to say "Ada? > No thanks, I'll stick to C++, if you don't mind." A C programmer, maybe. In C++, if you want to initialize one of the STL containers with constant data, you pretty much have to make copies of things. In C, we often do char *fruits[] = { "apple", "orange", "pear" }; The compiler does a bunch of accounting for us to make this possible. What we have really written above is the following: static char unique_apple[6] { 'a', 'p', 'p', 'l', 'e', 0 }; static char unique_orange[7] = { 'o', 'r', 'a', 'n', 'g', 'e', 0 }; static char unique_pear[5] = { 'p', 'e', 'a', 'r', 0 }; char *fruits[3] = { &unique_apple[0], &unique_orange[0], &unique_pear[0] }; Is it possible to do something similar in Ada? Something like (forgive my fractured pseudo-Ada syntax) - apple: aliased String(5) := "apple"; orange: aliased String(6) := "orange"; pear: aliased String(4) := "pear"; type StringPtr is access String(<>); fruits: StringPtr[1..3] := (apple'access, orange'access, pear'access); ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-23 0:00 ` Hyman Rosen @ 1999-09-24 0:00 ` Nick Roberts 1999-09-24 0:00 ` Hyman Rosen 0 siblings, 1 reply; 31+ messages in thread From: Nick Roberts @ 1999-09-24 0:00 UTC (permalink / raw) Hyman Rosen <hymie@prolifics.com> wrote in message news:t7k8ph19um.fsf@calumny.jyacc.com... [...] | Is it possible to do something similar in Ada? | Something like (forgive my fractured pseudo-Ada syntax) - | | apple: aliased String(5) := "apple"; | orange: aliased String(6) := "orange"; | pear: aliased String(4) := "pear"; | | type StringPtr is access String(<>); | | fruits: StringPtr[1..3] := (apple'access, orange'access, pear'access); This is one of the unappealing alternatives I was talking about. In Ada 95, one would have to write something like: Fruit_001: constant aliased String := "Apple"; Fruit_002: constant aliased String := "Orange"; Fruit_003: constant aliased String := "Pear"; ... type String_Sight is access constant String; Fruits: constant array (Positive range <>) of String_Sight := (Fruit_001'Access, Fruit_002'Access, Fruit_003'Access, ...); Whereas with ragged arrays, one need only write: Fruits: constant array (Positive range <>) of String := ("Apple", "Orange", "Pear", ...); Much simpler and clearer, don't you think? ------------------------------------- Nick Roberts http://www.callnetuk.com/home/nickroberts http://www.adapower.com/lab/adaos ------------------------------------- ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-24 0:00 ` Nick Roberts @ 1999-09-24 0:00 ` Hyman Rosen 1999-09-25 0:00 ` Robert Dewar 0 siblings, 1 reply; 31+ messages in thread From: Hyman Rosen @ 1999-09-24 0:00 UTC (permalink / raw) "Nick Roberts" <nickroberts@callnetuk.com> writes: > Whereas with ragged arrays, one need only write: > Fruits: constant array (Positive range <>) of String := > ("Apple", "Orange", "Pear", ...); > Much simpler and clearer, don't you think? I don't know, because I don't have the correct intuitions about Ada. The more complicated version certainly seems to me like the sort of code generally advocated here, where everything is very explicitly stated in the code. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-24 0:00 ` Hyman Rosen @ 1999-09-25 0:00 ` Robert Dewar 1999-09-27 0:00 ` Hyman Rosen 0 siblings, 1 reply; 31+ messages in thread From: Robert Dewar @ 1999-09-25 0:00 UTC (permalink / raw) In article <t74sgkys8h.fsf@calumny.jyacc.com>, Hyman Rosen <hymie@prolifics.com> wrote: > I don't know, because I don't have the correct intuitions about Ada. > The more complicated version ^^^^^^^^^^^^^^^^ "more complicated" /= longer Actually the C version is quite a bit more complex, because of the rather peculiar rules about whether string pointers are or are not constants, and about the issue of whether "abc" == "abc" (in general of course the answer in C is no) It looks simpler, but that can hide a lot of sins :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-25 0:00 ` Robert Dewar @ 1999-09-27 0:00 ` Hyman Rosen 1999-09-27 0:00 ` Brian Rogoff 1999-09-28 0:00 ` Robert Dewar 0 siblings, 2 replies; 31+ messages in thread From: Hyman Rosen @ 1999-09-27 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > "more complicated" /= longer > > Actually the C version is quite a bit more complex, because of > the rather peculiar rules about whether string pointers are > or are not constants, and about the issue of whether > "abc" == "abc" (in general of course the answer in C is no) > > It looks simpler, but that can hide a lot of sins :-) Like I said, I don't have proper Ada intuition. Frankly, for all its supposed readability, looking at Ada code makes my eyes and my brain swim. I think it's because Ada uses too many words and not enough symbols. I've felt that way ever since I first saw Ada code lo those many years ago, and I still feel so today. I would certainly say that C's type system is simpler than Ada's. The C ragged array example is completely simple. Granted, you have to know C, but that's true of any language. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-27 0:00 ` Hyman Rosen @ 1999-09-27 0:00 ` Brian Rogoff 1999-09-28 0:00 ` Robert Dewar 1 sibling, 0 replies; 31+ messages in thread From: Brian Rogoff @ 1999-09-27 0:00 UTC (permalink / raw) On 27 Sep 1999, Hyman Rosen wrote: > Robert Dewar <robert_dewar@my-deja.com> writes: > > "more complicated" /= longer > > > > Actually the C version is quite a bit more complex, because of > > the rather peculiar rules about whether string pointers are > > or are not constants, and about the issue of whether > > "abc" == "abc" (in general of course the answer in C is no) > > > > It looks simpler, but that can hide a lot of sins :-) > > Like I said, I don't have proper Ada intuition. Frankly, for all its > supposed readability, looking at Ada code makes my eyes and my brain > swim. I think it's because Ada uses too many words and not enough > symbols. I've felt that way ever since I first saw Ada code lo those > many years ago, and I still feel so today. That's funny. I actually agree that Ada is a bit wordy for my tastes, and would prefer a few more symbols, but I find that reading C++ "makes my eyes and brain swim" because of its overuse of symbols, weird overloadings of words like "static", and generally bad syntax. I find well written Ada far easier to read than C or C++, even though I write much more C family language code! To be fair, C++ is the way it is largely to remain compatible with C; reading the examples in the "C++ resyntaxed" paper (where C++ gets a slightly more Pascalish syntax) was much easier to me. I guess you can only please some of the people some of the time... -- Brian ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-27 0:00 ` Hyman Rosen 1999-09-27 0:00 ` Brian Rogoff @ 1999-09-28 0:00 ` Robert Dewar 1 sibling, 0 replies; 31+ messages in thread From: Robert Dewar @ 1999-09-28 0:00 UTC (permalink / raw) In article <t7zoy8vt8x.fsf@calumny.jyacc.com>, Hyman Rosen <hymie@prolifics.com> wrote: > Robert Dewar <robert_dewar@my-deja.com> writes: > > "more complicated" /= longer > > > > Actually the C version is quite a bit more complex, because of > > the rather peculiar rules about whether string pointers are > > or are not constants, and about the issue of whether > > "abc" == "abc" (in general of course the answer in C is no) > > > > It looks simpler, but that can hide a lot of sins :-) > > Like I said, I don't have proper Ada intuition. Frankly, for all its > supposed readability, looking at Ada code makes my eyes and my brain > swim. I think it's because Ada uses too many words and not enough > symbols. I've felt that way ever since I first saw Ada code lo those > many years ago, and I still feel so today. > > I would certainly say that C's type system is simpler than Ada's. > The C ragged array example is completely simple. Granted, you have > to know C, but that's true of any language. No, I still disagree, the apparent simple syntax of C in this case hides too many details. In particular, the fact that the string literals are not what they appear, but instead are implicit pointers is quite confusing. In particular there are two confusing issues 1. Are the referenced strings constants or variables? As you know the answer is not simple, and in some cases is even implementation dependent in practice, or has compiler switches to control the answer. 2. The equality check between two strings if (a == "the") { ... has difficult semantics. Generally it does not do at all what is expected, and in some cases again, the result can be implementation or compiler switch dependent. Sure you can respond "well you have to know C", but, note that a common type of publication in the C community are books that go through pitfalls like this, and explain how to avoid falling into them. Ada prefers an approach that avoids the pitfalls in the first place. There is even a C++ primer that has a section called "pitfalls" in every chapter, outlining things that compile fine, but do not do what you might expect at run time. This kind of phenomenon is simply far less common in Ada, since Ada was designed to avoid pitfalls of this kind, note that I say far less common, not non-existant, but the difference is striking. Sure, if you know a language well enough, you can completly insulate yourself from such problems. This is also true of PDP-8 machine language, but this is NOT a legitimate argument for writing in PDP-8 machine language! > Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-23 0:00 ` Nick Roberts 1999-09-23 0:00 ` Hyman Rosen @ 1999-09-24 0:00 ` Robert Dewar 1999-09-24 0:00 ` Wes Groleau 1999-09-24 0:00 ` Ted Dennison 2 siblings, 1 reply; 31+ messages in thread From: Robert Dewar @ 1999-09-24 0:00 UTC (permalink / raw) In article <37eaa24b@eeyore.callnetuk.com>, "Nick Roberts" <nickroberts@callnetuk.com> wrote: > With the greatest respect, it is perhaps easy for those of you > who are steeped in knowledge of the language to overlook this > (and there can be no arguing that STT is steeped in knowledge > of the language!). Of *course* we understand that it is easier to construct ragged arrays if you have a specific feature for doing this. That is precisely why this was discussed extensively during the language design. If it was NOT the case that your suggestion would make at least some cases easier to program, then you would not bother to make the suggestion, but the mere existence of such cases does not justify the addition. In this particular case, there is a significant implementation burden (wait till you are really working on your Ada compiler to appreciate that :-). In particular, getting the debugger to understand this completely new type would be significant work. What we decided during the design process was that the added functionality was simply not worth the added implementation burden. I see nothing that has changed this decision, or that makes it worth while to reopen the discussion at this stage, and the decision seems reasonable to me (then and now). > Try telling a C++ programmer that, in Ada, they have to declare an access > type, and then repeat the "new String'("xyz")" incantation for every string, > just to declare an array of strings, and they might be likely to say "Ada? > No thanks, I'll stick to C++, if you don't mind." Again, if someone really chooses a language based on the perceived simplicity of one element of the language, there is nothing much you can do, because when you compare two languages there will always be cases where one is easier than the other. Incidentally, remember that C++ does not have strings, only string pointers. If it is the syntax that is bothering you, define a unary plus appropriately, so you can write: x : array (1 .. 3) of S := (+"how", +"about", +"that"); > > Frankly, the pre-allocation trick (which is fine and dandy in all other > respects) only makes things worse from this point of view (simplicity for > the programmer), since it makes it looks like something is happening > (dynamic allocation) which is actually not. The recommended way of doing things does not involve any allocators .... just the use of 'Access which is like & in C. > I would agree that ragged arrays commit the same sin, but I > would say less so. No, more so, the recommended approach with 'Access is 100% WYSIWYG. > To those who argue that adding ragged arrays would add unnecessary > complexity to the language, my reply is not to confuse complexity of the > language with complexity of _using_ the language. Simplicity/Complexity has many aspects, in this case the complexity of both definition and implementation is considerable. I think the usage is not easy either, have you given any thought to how you would apply rep clauses to this type? what component_size would mean? whether this is a new formal type for generics (that's just 3 of dozens of semantic issues of complexity for the user that leap to mind). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-24 0:00 ` Robert Dewar @ 1999-09-24 0:00 ` Wes Groleau 1999-09-25 0:00 ` Robert Dewar 1999-09-25 0:00 ` Robert Dewar 0 siblings, 2 replies; 31+ messages in thread From: Wes Groleau @ 1999-09-24 0:00 UTC (permalink / raw) > In this particular case, there is a significant implementation > burden (wait till you are really working on your Ada compiler > to appreciate that :-). In particular, getting the debugger to > understand this completely new type would be significant work. In the cases of gdb and Apex Duo, where the same debugger understands both C and Ada, then the debugger should be able to understand char *fruits[] = { "apple", "orange", "pear" }; So how much work would it be to handle an Ada syntax that has the same underlying implementation? Of course, if the answer is "not much" there's still the question of whether the value is worth the addition to the language. I'm somewhat in favor of the capability (I have yet to look at the proposed syntax). The loudest complaints I hear from C-sick folks (who've seen Ada 83 but never heard of Ada.Strings.* or Interfaces.C) concerns Ada's alleged lack of string capabilities. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-24 0:00 ` Wes Groleau @ 1999-09-25 0:00 ` Robert Dewar 1999-09-25 0:00 ` Robert Dewar 1 sibling, 0 replies; 31+ messages in thread From: Robert Dewar @ 1999-09-25 0:00 UTC (permalink / raw) In article <37EBD2F3.E1E32672@ftw.rsc.raytheon.com>, Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote: > In the cases of gdb and Apex Duo, where the same debugger understands > both C and Ada, then the debugger should be able to understand > > char *fruits[] = { "apple", "orange", "pear" }; > > So how much work would it be to handle an Ada syntax that has the > same underlying implementation? Quite a bit, the storage structure you are proposing for your ragged arrays is quite different from the structure implied by the above C structure. Just because it looks a bit similar to the human eye at the source level is quite irrelevant. You would need a way of marking the Ada structure (tricky using standard debugging formats, because there is no analogous C format at the storage level), and circuitry in the debugger for interpreting this structure. I guess you should add a world class debugger to the list of things you planning to knock off in your spare time one day :-) > The loudest complaints I hear from C-sick folks (who've seen Ada 83 > but never heard of Ada.Strings.* or Interfaces.C) concerns Ada's > alleged lack of string capabilities. Anyone can complain about anything, especially when the complaint is based on willful ignorance (willful here because any C programmer who wants to find out about the string capabilities in Ada, which are far more powerful than those in C of course, can easily do so!) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-24 0:00 ` Wes Groleau 1999-09-25 0:00 ` Robert Dewar @ 1999-09-25 0:00 ` Robert Dewar 1 sibling, 0 replies; 31+ messages in thread From: Robert Dewar @ 1999-09-25 0:00 UTC (permalink / raw) In article <37EBD2F3.E1E32672@ftw.rsc.raytheon.com>, Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote: > > In this particular case, there is a significant implementation > > burden (wait till you are really working on your Ada compiler > > to appreciate that :-). In particular, getting the debugger to > > understand this completely new type would be significant work. > > In the cases of gdb and Apex Duo, where the same debugger understands > both C and Ada, then the debugger should be able to understand > > char *fruits[] = { "apple", "orange", "pear" }; > > So how much work would it be to handle an Ada syntax that has the > same underlying implementation? Oops, I got mixed up, and thought that Nick had written this, so please ignore my suggestion of implementing a debugger (that was intended for Nick :-) Wes, if you are seriously proposing that the ragged arrays be implemented with a storage structure identical to that used for fruits above, then you have suddenly enormously increased the implementation burden. That's because the C structure depends on the notion of simple machine addresses that point to a null terminated string. This means you have to introduce a whole new concept at both the Ada semantic level (strings that are not allowed to contain the null character), and at the implementation level (string pointers with implicit bounds that are incompatible with normal pointer-to-unconstrained). It's doable, I suppose, but you have enormously increased the complexity of the proposal, probably unintentially (that's the trouble in language design, things that seem so simple and straightforward turn out to be much more messy than you think). Robert Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-23 0:00 ` Nick Roberts 1999-09-23 0:00 ` Hyman Rosen 1999-09-24 0:00 ` Robert Dewar @ 1999-09-24 0:00 ` Ted Dennison 1999-09-24 0:00 ` Nick Roberts 2 siblings, 1 reply; 31+ messages in thread From: Ted Dennison @ 1999-09-24 0:00 UTC (permalink / raw) In article <37eaa24b@eeyore.callnetuk.com>, "Nick Roberts" <nickroberts@callnetuk.com> wrote: > People: String_Array(1..3)(String(1..3),String(1..4),String(1..5)); > I'm not sure I like this example. Right now in Ada you would have to use explicit subtypes in any such declaration. But above you are using anonymous subtypes (eg: "String(1..3)"). I know creating a bunch of onetime subtypes might seem to be a pain, but it would restore consistency with the rest of the language. > (Note the nice, simple syntax.) Either way, People is now permanently > constrained, both in terms of its indexes and its profile. The assignment: > > People(3) := "Jane"; > People(2) := "Emily"; > > would raise Constraint_Error. Nothing can change either the index OK. That's not so bad then. It would seem quite possible to create stack space for such variables. The only bad issue I still see is that its probably going to need a dope vector from hell to keep track of all the contraints of all its elements. But this isn't any different than the current situation with my array of string pointers. I'm starting to like this proposal. I think the syntax does need still some work. For instance, can variant records be components too? What would one of those declarations look like? How about classwide tagged types? Also, if we do this, wouldn't the constrained subtype restriction on record fields start to look a bit restrictive? -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-24 0:00 ` Ted Dennison @ 1999-09-24 0:00 ` Nick Roberts 0 siblings, 0 replies; 31+ messages in thread From: Nick Roberts @ 1999-09-24 0:00 UTC (permalink / raw) Ted Dennison <dennison@telepath.com> wrote in message news:7sg24e$4oo$1@nnrp1.deja.com... [...] | > People: String_Array(1..3)(String(1..3),String(1..4),String(1..5)); | | I'm not sure I like this example. Right now in Ada you would have to use | explicit subtypes in any such declaration. But above you are using | anonymous subtypes (eg: "String(1..3)"). I know creating a bunch | of onetime subtypes might seem to be a pain, but it would restore | consistency with the rest of the language. I'm not quite sure what Ted is about here, but Ada has always allowed stand-alone object definitions to have a subtype indication ('String(1..5)') rather than just a subtype mark ('String_5'), and I cannot see any obvious reason why the proposed 'array profile' shouldn't allow subtype indications. | The only bad issue I still see is that its | probably going to need a dope vector from hell to keep track of all the | contraints of all its elements. But this isn't any different than the | current situation with my array of string pointers. An Ada implementation's internal representation of the profile would simply be an array of whatever the implementation uses for stand-alone object's subtypes (possibly requiring one extra level of indirection). This may be considered to be a 'dope vector from Hell', but it would be hidden from the programmer, and, since in practice most subtypes are static anyway, it would often be optimised away anyway. | I'm starting to like this proposal. Thank you! | I think the syntax does need still some work. For instance, can variant | records be components too? What would one of those declarations look | like? How about classwide tagged types? I agree wholeheartedly. I am unsatisfied by both the syntax and the nomenclature as I have it at present in my proposal. Even the name 'ragged array' is not really appropriate. I would be very grateful for suggestions of improvements. | Also, if we do this, wouldn't the constrained subtype restriction on | record fields start to look a bit restrictive? Firstly, the specific rule is that record components must be definite, rather than unconstrained (they can be unconstrained elementary types, each type of which is assumed to occupy the same amount of memory regardless of constraint). Secondly, it is the purpose of record discriminants to parametise the subtypes of record components. My proposal for ragged arrays is essentially to provide a way (the 'array profile') to parametise the subtypes of the components of an array. It is necessary that the subtypes of every component of any definite array or record subtype is definite, since otherwise, in general, it would be impossible to know how much memory to allocate for the component (and grossly wasteful to allocate enough for any possible value). Now, if a component in a record were allowed to have an indefinite subtype, how could that subtype get constrained (to make it definite)? There would be no point in inventing some mechanism to do so when such a mechanism already effectively exists: discriminants. ------------------------------------- Nick Roberts http://www.callnetuk.com/home/nickroberts http://www.adapower.com/lab/adaos ------------------------------------- ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-23 0:00 ` Tucker Taft 1999-09-23 0:00 ` Nick Roberts @ 1999-09-24 0:00 ` Robert Dewar 1 sibling, 0 replies; 31+ messages in thread From: Robert Dewar @ 1999-09-24 0:00 UTC (permalink / raw) In article <37EA4E91.1D4D1FC@averstar.com>, Tucker Taft <stt@averstar.com> wrote: I know at least that the > Aonix and Green Hills Ada 95 compilers statically allocate and initialize > allocators for access-to-constant types. I haven't checked GNAT. Yes, GNAT does the same optimization, it is after all trivial. It is interesting to note that the original form with allocators could also be optimized. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-22 0:00 ` Ray Blaak 1999-09-23 0:00 ` Tucker Taft @ 1999-09-23 0:00 ` Ted Dennison 1999-09-24 0:00 ` Robert Dewar 2 siblings, 0 replies; 31+ messages in thread From: Ted Dennison @ 1999-09-23 0:00 UTC (permalink / raw) In article <m3vh922o3u.fsf@vault80.infomatch.bc.ca>, Ray Blaak <blaak@infomatch.com> wrote: > Ted Dennison <dennison@telepath.com> writes: > > Labels: constant array (Command) of Command_String_Ptr := > > (Cut => new String'("Cu&t"), > > Copy => new String'("&Copy"), > > > > Paste => new String'("&Paste"), > > ...); > > The problem with this approach is that the data is duplicated. It is > both in the static data area of the program (i.e. the string > constants), and in the heap. Perhaps. But unless I'm operating in an extremely low memory environment, why should I care? An if memory is that limited, I probably will be using a language subset that doesn't allow dynamic allocation anyway. -- 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] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-22 0:00 ` Ray Blaak 1999-09-23 0:00 ` Tucker Taft 1999-09-23 0:00 ` Ted Dennison @ 1999-09-24 0:00 ` Robert Dewar 2 siblings, 0 replies; 31+ messages in thread From: Robert Dewar @ 1999-09-24 0:00 UTC (permalink / raw) In article <m3vh922o3u.fsf@vault80.infomatch.bc.ca>, > The problem with this approach is that the data is duplicated. It is both in > the static data area of the program (i.e. the string constants), and in the > heap. The right way to write this is using 'Access on constant strings, and then the data will not be duplicated. Of course a compiler might optimize the above case anyway. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal [not found] <37e7c08e@eeyore.callnetuk.com> 1999-09-22 0:00 ` Ragged Array Proposal Ted Dennison @ 1999-09-23 0:00 ` Robert I. Eachus 1999-09-24 0:00 ` Nick Roberts 1 sibling, 1 reply; 31+ messages in thread From: Robert I. Eachus @ 1999-09-23 0:00 UTC (permalink / raw) Nick Roberts wrote: > I seem to get the impression that the cognoscenti consider this particular > idea worthless. I am perfectly serious about it, however; I am completely > convinced that it would be both workable and valuable (extremely so, in > fact). I beseech anyone who might be interested to take a serious look; I > would be delighted to have feedback (_any_ kind of feedback), either to me > by e-mail or to this newsgroup. Not worthless, just excessive. There are already two ways to do what you seem to want: arrays of Ada.Strings.Unbounded.Unbounded_String, or a generic package that does what you want using Controlled types. If you want to supply a package like that it would probably be considered, if not for the next standard, at least to be provided by all implementors. (And if you do it before the ARG meeting Monday, it might even get considered there...) Note: I have implemented a slightly more general version of that package, where my major concern was to provide extensible records. Hmmm. What you want seems to be a generic package with a specification like: with Ada.Finalization; generic type Index is (<>); package Ragged is type Element is private with null; type Element_Reference is access all Element'Class; type Ragged_Array is array (Index range <>) of Element_Reference; procedure Assign_To(R: in out Ragged_Array; I: in Index, E: Element); function Dereference(R: Ragged_Array; I: Index) return Element'Class; private -- implemenation defined... end Ragged; Any comments? -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-23 0:00 ` Robert I. Eachus @ 1999-09-24 0:00 ` Nick Roberts 1999-09-25 0:00 ` Robert Dewar ` (3 more replies) 0 siblings, 4 replies; 31+ messages in thread From: Nick Roberts @ 1999-09-24 0:00 UTC (permalink / raw) Robert I. Eachus <eachus@mitre.org> wrote in message news:37EA9A72.594ED8F5@mitre.org... [...] | Not worthless, just excessive. There are already two ways to do what | you seem to want: arrays of Ada.Strings.Unbounded.Unbounded_String, or a | generic | package that does what you want using Controlled types. Using Ada.Strings.Unbounded is one of the unappealing alternatives I was talking about. To use the fructuous example of another post in this thread, in Ada 95 one would have to declare: Fruits: constant array (Positive range <>) of Unbounded_String := (To_Unbounded_String("Apple"), To_Unbounded_String("Orange"), To_Unbounded_String("Pear"), ...); This technique suffers from the same heavy syntax of the allocator technique, and while it saves having to explicitly declare an access type, it's almost certain to have an implementation that involves dynamic allocation (together with the further baggage of a controlled type). A very clever optimiser might be able to perform pre-allocation (as mentioned in other posts in this thread), but I suspect that most Ada compilers, in reality, would not. An overloading of "+" could be declared to slim down the declaration of each component, but this does not resolve the inefficiency. Similar comments apply to the use of Ada.Strings.Bounded. In this case, there is the same syntactic clumsiness (with the addition of a generic instantiation), and also inefficiency (albeit wasted memory rather than dynamic allocation). | Note: I have implemented a slightly more general version of that | package, where my major concern was to provide extensible records. | Hmmm. What you want seems to be a generic package with a specification | like: | | with Ada.Finalization; | generic | type Index is (<>); | package Ragged is | | type Element is private with null; | type Element_Reference is access all Element'Class; | type Ragged_Array is array (Index range <>) of Element_Reference; | | procedure Assign_To(R: in out Ragged_Array; I: in Index, E: | Element); | function Dereference(R: Ragged_Array; I: Index) return | Element'Class; | | private | -- implemenation defined... | end Ragged; | | Any comments? This kind of package really only 'wraps up' the techniques using access values or fixed-size buffers; it doesn't resolve the underlying problems. Use of this kind of package will still suffer from the heavy syntax (in the above case, a generic instantiation, a tagged type derivation, a declaration of an object, and then several calls to a procedure!), and the inefficiency of using dynamic allocation or fixed-size buffers. | If you want to | supply a package like that it would probably be considered, if not for | the next standard, at least to be provided by all implementors. (And if | you do it before the ARG meeting Monday, it might even get considered | there...) I would be delighted for the ARG to consider my ragged array proposal, if it comes within the group's remit. I will endeavour to get some or all of the 'Changes to the RM' section written before Monday. I want to illustrate what I think is the key advantage of ragged arrays. In the examples in my proposal, I declare an abstract type Figure, and a ragged array type Figure_Array, and then various concrete types derived from Figure. I then declare a record type Compound_Figure with a component of this ragged array type, and finally I declare a subtype of this record type, Double_Triangle. I don't specify the components for the concrete figure types, but suppose the type Circle has components for a radius and a centre (on flat plane), and that there is a Label figure which has components for a Wide_Character and a centre. Furthermore, suppose we declare another subtype: subtype Telephone_Button is Compound_Figure(2)(Circle,Label); A value could be assigned to an object, Star say, of the Telephone_Button subtype as follows: Star := (2, (15,(23,47), ('*',(23,47))); Now, consider how such a record subtype could be implemented in Ada 95. One possibility is: type Figure_Access is access all Figure'Class; type Figure_Array is array (Positive range <>) of Figure_Access; type Compound_Figure (Length: Natural) is new Figure with record Constituents: Figure_Array(1..Length); ... end record; Now consider declaring the subtype Telephone_Button. This can done with: subtype Telephone_Button is Compound_Figure(2); But note how the subtypes of the components of the array cannot be constrained. Being able to impose such a constraint would be a valuable technique in many situations. Now consider assigning a value to an object of this subtype. We can either use an allocator: Star := (2, new Circle(15,(23,47)), new Label('*',(23,47))); Or we can used aliased objects: TBC: constant aliased Circle := (15,(23,47)); SBL: constant aliased Label := ('*',(23,47)); Star := (2, TBC'Access, SBL'Access); I think both of these methods are less preferable to the ragged array. It's obvious that the syntax is less concise. What may not be so obvious, however, but which, I am convinced, is of great significance, is that the above Ada 95 version (or, indeed, any Ada 95 alternative) will generally be less efficient, in terms of memory used and often execution speed too, and there's _no way around it_ except kludges. It's unfortunate that it is difficult to come up with a realistic example that isn't either too complicated for an example, or simply dismissed with a wave of the hand as being unrealistic. But I am convinced that this is a problem that could be critical for certain applications. Suppose an application had extremely limited memory, for example (e.g. an embedded controller), or needed to store a huge number of items of subtypes similar to Telephone_Button; the memory saving from the use of ragged arrays could be significant, or even critical. ------------------------------------- Nick Roberts http://www.callnetuk.com/home/nickroberts http://www.adapower.com/lab/adaos ------------------------------------- ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-24 0:00 ` Nick Roberts @ 1999-09-25 0:00 ` Robert Dewar 1999-09-25 0:00 ` Robert Dewar ` (2 subsequent siblings) 3 siblings, 0 replies; 31+ messages in thread From: Robert Dewar @ 1999-09-25 0:00 UTC (permalink / raw) In article <37ebb120@eeyore.callnetuk.com>, "Nick Roberts" <nickroberts@callnetuk.com> wrote: > Using Ada.Strings.Unbounded is one of the unappealing alternatives I was > talking about. The trouble with this thread is that it is just replaying an old discussion with little new being added on both sides. I guess that is somewhat inevitable as new people begin to think about things, often without digging through the past :-) Nick, you might want to dig up some of the old discussions and proposals on ragged arrays ... Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-24 0:00 ` Nick Roberts 1999-09-25 0:00 ` Robert Dewar @ 1999-09-25 0:00 ` Robert Dewar 1999-09-25 0:00 ` Robert Dewar 1999-09-27 0:00 ` Ted Dennison 3 siblings, 0 replies; 31+ messages in thread From: Robert Dewar @ 1999-09-25 0:00 UTC (permalink / raw) In article <37ebb120@eeyore.callnetuk.com>, "Nick Roberts" <nickroberts@callnetuk.com> wrote: > Using Ada.Strings.Unbounded is one of the unappealing alternatives I was > talking about. The trouble with this thread is that it is just replaying an old discussion with little new being added on both sides. I guess that is somewhat inevitable as new people begin to think about things, often without digging through the past :-) Nick, you might want to dig up some of the old discussions and proposals on ragged arrays ... Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-24 0:00 ` Nick Roberts 1999-09-25 0:00 ` Robert Dewar 1999-09-25 0:00 ` Robert Dewar @ 1999-09-25 0:00 ` Robert Dewar 1999-09-27 0:00 ` Ted Dennison 3 siblings, 0 replies; 31+ messages in thread From: Robert Dewar @ 1999-09-25 0:00 UTC (permalink / raw) In article <37ebb120@eeyore.callnetuk.com>, "Nick Roberts" <nickroberts@callnetuk.com> wrote: > Fruits: constant array (Positive range <>) of Unbounded_String := > (To_Unbounded_String("Apple"), > To_Unbounded_String("Orange"), > To_Unbounded_String("Pear"), > ...); > > This technique suffers from the same heavy syntax of the allocator > technique, Well as I noted in an earlier message, the "light" syntax of C hides a lot of sins, it is always puzzling to people who are using C at first, that they cannot declare the Fruits array as in our example, and then say if (Fruits [j] == "abc") ... of course they *can* say it, it is perfectly legal and well defined in C, it just does not do what the programmer expects (generally the result will be false). If you really get so upset by reading To_Unbounded_String, then replace it with a unary "+" as in my previous example (I actually wanted the unary "+" in the standard here, but that proposal did not attract enough support). Indeed both Jean Ichbiah and I have always liked the idea of using unary plus as a quietish, but still explicit, conversion operator, and we both pushed for adding one extra unary operator (obvious choice the pillow or currency conversion symbol) which would have no predefined meaning, but would be specifically intended as a conversion operator of this kind, but that again did not attract enough support. > and while it saves having to explicitly declare an access > type, it's almost certain to have an implementation that > involves dynamic allocation (together with the further baggage > of a controlled type). Sure, but you would be surprised what a large percentage of string processing stuff is quite happy with such overhead (think of SPITBOL, and even Java). > A very clever optimiser might be able to perform > pre-allocation (as mentioned in > other posts in this thread), but I suspect that most Ada compilers, in > reality, would not. Waste of time I would think ... Robert Dewar Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-24 0:00 ` Nick Roberts ` (2 preceding siblings ...) 1999-09-25 0:00 ` Robert Dewar @ 1999-09-27 0:00 ` Ted Dennison 1999-09-27 0:00 ` Pascal Obry 1999-09-28 0:00 ` Robert Dewar 3 siblings, 2 replies; 31+ messages in thread From: Ted Dennison @ 1999-09-27 0:00 UTC (permalink / raw) In article <37ebb120@eeyore.callnetuk.com>, "Nick Roberts" <nickroberts@callnetuk.com> wrote: > To use the fructuous example of another post in this thread, in Ada 95 > one would have to declare: > > Fruits: constant array (Positive range <>) of Unbounded_String := > (To_Unbounded_String("Apple"), > To_Unbounded_String("Orange"), > To_Unbounded_String("Pear"), > ...); Actually, that hides a bit of information. If I were writing it, it would look more like: Fruits : constant array (Positive range <>) of Ada.Strings.Unbounded.Unbounded_String := (Ada.Strings.Unbounded.To_Unbounded_String("Apple"), Ada.Strings.Unbounded.To_Unbounded_String("Orange"), Ada.Strings.Unbounded.To_Unbounded_String("Pear"), ...); > I would be delighted for the ARG to consider my ragged array > proposal, if it comes within the group's remit. I will endeavour to While I'm beginning to think the idea may have merit, I think it would be too drastic of a change to even think of retroactively incorporating into the current standard. If it is considered at all, it should be for a 20xx language revision. -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-27 0:00 ` Ted Dennison @ 1999-09-27 0:00 ` Pascal Obry 1999-09-28 0:00 ` Ted Dennison 1999-09-28 0:00 ` Robert Dewar 1 sibling, 1 reply; 31+ messages in thread From: Pascal Obry @ 1999-09-27 0:00 UTC (permalink / raw) > > Actually, that hides a bit of information. If I were writing it, it > would look more like: > > Fruits : constant array (Positive range <>) of > Ada.Strings.Unbounded.Unbounded_String := > (Ada.Strings.Unbounded.To_Unbounded_String("Apple"), > Ada.Strings.Unbounded.To_Unbounded_String("Orange"), > Ada.Strings.Unbounded.To_Unbounded_String("Pear"), > ...); > Well Ada.Strings.Unbounded is a package that has been designed to be used with a use clause. Look above at all the redundant infos. Really I think that a use in this case is just nice. Pascal. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-27 0:00 ` Pascal Obry @ 1999-09-28 0:00 ` Ted Dennison 1999-09-28 0:00 ` Robert Dewar 0 siblings, 1 reply; 31+ messages in thread From: Ted Dennison @ 1999-09-28 0:00 UTC (permalink / raw) In article <01bf0919$67bbb350$022a6282@dieppe>, "Pascal Obry" <pascal_obry@csi.com> wrote: > > > > > Actually, that hides a bit of information. If I were writing it, it > > would look more like: > > > > Fruits : constant array (Positive range <>) of > > Ada.Strings.Unbounded.Unbounded_String := > > (Ada.Strings.Unbounded.To_Unbounded_String("Apple"), > > Ada.Strings.Unbounded.To_Unbounded_String("Orange"), > > Ada.Strings.Unbounded.To_Unbounded_String("Pear"), > > ...); > > > > Well Ada.Strings.Unbounded is a package that has been designed to > be used with a use clause. Look above at all the redundant infos. There is no "redundant info" above, unless you count the redundant info that the designers of the unbounded string package purposely put in there. :-) But that's not the issue here. We are talking about presenting an example comparing the syntactic weight of the current approach to that of a proposed approach. Unless you include the "use Ada.Strings.Unbounded;" statement in your example, then I argue that you *must* write the example this way. As others have pointed out, you can further shorten (and thus hide away) some of the syntax using renames clauses and unary operators. The fact that you can use tricks to hide some of the inherent ugliness in the above approach is beside the point. The fact that folks would object to someone *not* using such tricks practicly makes Nick's point for him. -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-28 0:00 ` Ted Dennison @ 1999-09-28 0:00 ` Robert Dewar 1999-09-29 0:00 ` Geoff Bull 0 siblings, 1 reply; 31+ messages in thread From: Robert Dewar @ 1999-09-28 0:00 UTC (permalink / raw) In article <7sqo26$b5t$1@nnrp1.deja.com>, Ted Dennison <dennison@telepath.com> wrote: > But that's not the issue here. We are talking about presenting an > example comparing the syntactic weight of the current approach to that > of a proposed approach. Unless you include the "use > Ada.Strings.Unbounded;" statement in your example, then I argue that you > *must* write the example this way. It is not a "trick" to use a USE clause here but just good usage, and certainly not something unfamiliar to a C programmer who would expect to use a #include for a header in a similar situation. If you like the "+" notation, then of course you would with and use (or even use type :-) the package that defined and reexported the adjusted string stuff. I can't imagine anyone writing the fully expanded names here, so implying that this is reasonable code is definitely misleading. I do understand that some people operate in environments that forbid USE clauses, but such environments which mandate the use of a subset of Ada are not the source of inspiration about what the best style is when using the *whole* Ada language. Almost anything carried to extremes is a bad thing. Almost everyone would agree that completely eliminating use clauses or mandating their use everywhere would both be a bad idea. So for most people we find a happy medium, and for most people Ada.Strings.Unbounded.To_Unbounded_String repeated over and over is not the way to do things! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-28 0:00 ` Robert Dewar @ 1999-09-29 0:00 ` Geoff Bull 0 siblings, 0 replies; 31+ messages in thread From: Geoff Bull @ 1999-09-29 0:00 UTC (permalink / raw) Robert Dewar wrote: > > So for most people we find a happy medium, and for most people > > Ada.Strings.Unbounded.To_Unbounded_String > > repeated over and over is not the way to do things! To right! ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Ragged Array Proposal 1999-09-27 0:00 ` Ted Dennison 1999-09-27 0:00 ` Pascal Obry @ 1999-09-28 0:00 ` Robert Dewar 1 sibling, 0 replies; 31+ messages in thread From: Robert Dewar @ 1999-09-28 0:00 UTC (permalink / raw) In article <7so0i4$d8j$1@nnrp1.deja.com>, > Fruits : constant array (Positive range <>) of > Ada.Strings.Unbounded.Unbounded_String := > (Ada.Strings.Unbounded.To_Unbounded_String("Apple"), > Ada.Strings.Unbounded.To_Unbounded_String("Orange"), > Ada.Strings.Unbounded.To_Unbounded_String("Pear"), > ...); I can't *imagine* why you think that obviously redundant qualification makes your code more readable. It is obvious that the names in Unbounded have been chosen to be appropriate for use with USE clauses (otherwise the name would have been something like From_String, without the Unbounded in the name). I perfectly understand the thought that generally likes to avoid USE clauses, but I must say when people carry this to absurd extremes like the above, it is hard to understand the thought process involved. Clearly no one would reuse the name To_Unbounded_String in a user defined package (if they had any sense at all), so the unqualified name is perfectly clear in practice. Certainly we cannot buy an argument for a feature which goes like this: 1. I refuse to use USE clauses 2. Therefore some code I have to write looks awful 3. Therefore I need some special feature in the language to allow me to do this in some special way :-) Of course in this particular case, even the simple name To_Unbounded_String is heavy, which is why the idea of a light conversion operator makes good sense (the unary "+" suggestion). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~1999-09-29 0:00 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <37e7c08e@eeyore.callnetuk.com> 1999-09-22 0:00 ` Ragged Array Proposal Ted Dennison 1999-09-22 0:00 ` Ray Blaak 1999-09-23 0:00 ` Tucker Taft 1999-09-23 0:00 ` Nick Roberts 1999-09-23 0:00 ` Hyman Rosen 1999-09-24 0:00 ` Nick Roberts 1999-09-24 0:00 ` Hyman Rosen 1999-09-25 0:00 ` Robert Dewar 1999-09-27 0:00 ` Hyman Rosen 1999-09-27 0:00 ` Brian Rogoff 1999-09-28 0:00 ` Robert Dewar 1999-09-24 0:00 ` Robert Dewar 1999-09-24 0:00 ` Wes Groleau 1999-09-25 0:00 ` Robert Dewar 1999-09-25 0:00 ` Robert Dewar 1999-09-24 0:00 ` Ted Dennison 1999-09-24 0:00 ` Nick Roberts 1999-09-24 0:00 ` Robert Dewar 1999-09-23 0:00 ` Ted Dennison 1999-09-24 0:00 ` Robert Dewar 1999-09-23 0:00 ` Robert I. Eachus 1999-09-24 0:00 ` Nick Roberts 1999-09-25 0:00 ` Robert Dewar 1999-09-25 0:00 ` Robert Dewar 1999-09-25 0:00 ` Robert Dewar 1999-09-27 0:00 ` Ted Dennison 1999-09-27 0:00 ` Pascal Obry 1999-09-28 0:00 ` Ted Dennison 1999-09-28 0:00 ` Robert Dewar 1999-09-29 0:00 ` Geoff Bull 1999-09-28 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox