* Generic procedures and their parameters @ 2006-09-06 8:51 Maciej Sobczak 2006-09-06 9:43 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: Maciej Sobczak @ 2006-09-06 8:51 UTC (permalink / raw) Hi, I have found the following signature for the sorting procedure: eneric type Index_Type is (<>); type Element_Type is private; type Array_Type is array (Index_Type range <>) of Element_Type; with function "<" (Left, Right : in Element_Type) return Boolean is <>; procedure Sort(To_Sort : in out Array_Type); My question is: what's the purpose of the third parameter (Array_Type)? Isn't it implied by the first two and therefore just redundant? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-06 8:51 Generic procedures and their parameters Maciej Sobczak @ 2006-09-06 9:43 ` Dmitry A. Kazakov 2006-09-06 12:36 ` Maciej Sobczak ` (2 more replies) 2006-09-06 12:56 ` Robert A Duff 2006-09-07 2:47 ` Steve 2 siblings, 3 replies; 27+ messages in thread From: Dmitry A. Kazakov @ 2006-09-06 9:43 UTC (permalink / raw) On Wed, 06 Sep 2006 10:51:48 +0200, Maciej Sobczak wrote: > eneric > type Index_Type is (<>); > type Element_Type is private; > type Array_Type is array (Index_Type range <>) of Element_Type; > with function "<" (Left, Right : in Element_Type) return Boolean is <>; > procedure Sort(To_Sort : in out Array_Type); > > My question is: what's the purpose of the third parameter (Array_Type)? > Isn't it implied by the first two and therefore just redundant? Reverse. Actually Index_Type and Element_Type are redundant. In a better Ada it should be: generic type Container_Type is array (<>) of <>; -- or "(<>) is limited private array" with function "<" (Left, Right : in Container_Type'Element) return Boolean is <>; procedure Sort (To_Sort : in out Container_Type); [ Even better it be non-generic: procedure Sort (To_Sort : in out Container_Of_Ordered'Class); where each container type (like an array) be a member of the class, if its elements are in Ordered'Class. ] Regarding Array_Type being implied, it is not. You can have any number of array types based on exactly same combination of index and element types. These types will be different types: type I is ...; type E is ...; type Array1 is array (I range <>) of E; type Array2 is array (I range <>) of E; The types Array1 and Array2 are distinct types. Sort must be instantiated for each of them (or else you have to convert types). The reverse is a different story. It is a pity that Ada does not have attributes to get the index and element types from the array type (container type). The next step would be getting "<" from the element type, which would eliminate a need to have Sort generic. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-06 9:43 ` Dmitry A. Kazakov @ 2006-09-06 12:36 ` Maciej Sobczak 2006-09-06 13:11 ` Robert A Duff 2006-09-06 13:02 ` Robert A Duff 2006-09-08 3:35 ` Randy Brukardt 2 siblings, 1 reply; 27+ messages in thread From: Maciej Sobczak @ 2006-09-06 12:36 UTC (permalink / raw) Dmitry A. Kazakov wrote: >> eneric >> type Index_Type is (<>); >> type Element_Type is private; >> type Array_Type is array (Index_Type range <>) of Element_Type; >> with function "<" (Left, Right : in Element_Type) return Boolean is <>; >> procedure Sort(To_Sort : in out Array_Type); >> >> My question is: what's the purpose of the third parameter (Array_Type)? >> Isn't it implied by the first two and therefore just redundant? > > Reverse. Actually Index_Type and Element_Type are redundant. In a better > Ada it should be: > > generic > type Container_Type is array (<>) of <>; > -- or "(<>) is limited private array" > with function "<" (Left, Right : in Container_Type'Element) > return Boolean is <>; > procedure Sort (To_Sort : in out Container_Type); OK, it makes perfect sense. > [ Even better it be non-generic: > > procedure Sort (To_Sort : in out Container_Of_Ordered'Class); > > where each container type (like an array) be a member of the class, if its > elements are in Ordered'Class. ] But then, you would need to have even such fundamental things like Integer belong to Ordered'Class. It's a shaky ground. > Regarding Array_Type being implied, it is not. You can have any number of > array types based on exactly same combination of index and element types. > These types will be different types: > > type I is ...; > type E is ...; > type Array1 is array (I range <>) of E; > type Array2 is array (I range <>) of E; > The types Array1 and Array2 are distinct types. And now I see. I'm still having troubles with the fact that "granularity" of type system in Ada can be much smaller than what can be achieved with structural differences only. > The reverse is a different story. It is a pity that Ada does not have > attributes to get the index and element types from the array type > (container type). Yes. > The next step would be getting "<" from the element type, > which would eliminate a need to have Sort generic. No, I disagree. There is a place for generic subprograms, otherwise we'd have everything in a single hierarchy with Object at the top. It's not a coincidence that "other languages" drift towards supporting generics, even if they already had such single-rooted hierarchies. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-06 12:36 ` Maciej Sobczak @ 2006-09-06 13:11 ` Robert A Duff 2006-09-06 14:14 ` Maciej Sobczak 0 siblings, 1 reply; 27+ messages in thread From: Robert A Duff @ 2006-09-06 13:11 UTC (permalink / raw) Maciej Sobczak <no.spam@no.spam.com> writes: > But then, you would need to have even such fundamental things like > Integer belong to Ordered'Class. It's a shaky ground. Why is that shaky? Integer IS ordered. > > Regarding Array_Type being implied, it is not. You can have any number of > > array types based on exactly same combination of index and element types. > > These types will be different types: > > type I is ...; > > type E is ...; > > type Array1 is array (I range <>) of E; > > type Array2 is array (I range <>) of E; > > > The types Array1 and Array2 are distinct types. > > And now I see. I'm still having troubles with the fact that > "granularity" of type system in Ada can be much smaller than what can be > achieved with structural differences only. It's a good thing that Ada allows Array1 and Array2 above to be different types. But sometimes, structural typing would be better. In fact, Ada has moved a bit in that direction -- anonymous access types use structural typing, more or less. > > The next step would be getting "<" from the element type, > > which would eliminate a need to have Sort generic. > > No, I disagree. There is a place for generic subprograms, otherwise we'd > have everything in a single hierarchy with Object at the top. It's not a > coincidence that "other languages" drift towards supporting generics, > even if they already had such single-rooted hierarchies. A hierarchy with Object at the top would be a Good Thing, IMHO. Trees are more aesthetically pleasing than forests. But you're right that you still need some sort of generic facility, so you can have strongly typed containers. But I think perhaps we should have generic types (i.e. parameterized types) rather than generic packages. That's what discriminants do, but they're severely limited. It would make sense to have a discriminant that is a type, so you could say: My_Sequence: Sequence(Element => Integer) := (1, 2, 3); - Bob ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-06 13:11 ` Robert A Duff @ 2006-09-06 14:14 ` Maciej Sobczak 2006-09-06 15:09 ` Dmitry A. Kazakov 2006-09-09 14:49 ` Robert A Duff 0 siblings, 2 replies; 27+ messages in thread From: Maciej Sobczak @ 2006-09-06 14:14 UTC (permalink / raw) Robert A Duff wrote: >> But then, you would need to have even such fundamental things like >> Integer belong to Ordered'Class. It's a shaky ground. > > Why is that shaky? Integer IS ordered. Is it also tagged? Do you want it to be? Or maybe there should be a special case for Integer (and its every subtype), so that it's semantically in Ordered'Class without being syntactically tagged? Is it really in the spirit of Ada? Integer is not only Ordered. It's also Summable, Subtractable, Multipliable, Divideable, Powerable, Incrementable, Decrementable, Comparable, Copyable, Assignable, Imageable and even Aspect_Clauseable, not mentioning Can_Be_Used_As_Array_Index. And it has some others as well. And all this is very important, since there might be other types that share only some of these properties but not others and surely we don't want our Container_Of_Incrementable_And_Divideable_And_Comparable to contain something that isn't, right? (sorry if any of the above is not proper English) ;-) And switching back to serious, I somehow don't like languages that try to apply object-orientedness to absolutely everything. In C++ the fact that int is ordered does not require that it relates to some Ordered class. Such properties - if needed - can be expressed in other ways. > A hierarchy with Object at the top would be a Good Thing, IMHO. Trees > are more aesthetically pleasing than forests. Opinions vary on this subject. :-) > But I think perhaps we should have generic types > (i.e. parameterized types) rather than generic packages. That's what > discriminants do, but they're severely limited. It would make sense to > have a discriminant that is a type, so you could say: > > My_Sequence: Sequence(Element => Integer) := (1, 2, 3); Yes, that would be fine. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-06 14:14 ` Maciej Sobczak @ 2006-09-06 15:09 ` Dmitry A. Kazakov 2006-09-06 16:35 ` Georg Bauhaus 2006-09-08 9:11 ` Maciej Sobczak 2006-09-09 14:49 ` Robert A Duff 1 sibling, 2 replies; 27+ messages in thread From: Dmitry A. Kazakov @ 2006-09-06 15:09 UTC (permalink / raw) On Wed, 06 Sep 2006 16:14:07 +0200, Maciej Sobczak wrote: >> Why is that shaky? Integer IS ordered. > > Is it also tagged? Do you want it to be? Not Integer, but Integer'Class. > Integer is not only Ordered. It's also Summable, Subtractable, [...] Yes, it is called multiple inheritance. > In C++ the fact > that int is ordered does not require that it relates to some Ordered > class. Which is unfortunate for both C++ and Ada, because "to be ordered" = "a member of Ordered class." There is no obvious reason why they should be different. >> A hierarchy with Object at the top would be a Good Thing, IMHO. Trees >> are more aesthetically pleasing than forests. > > Opinions vary on this subject. :-) One does not exclude other. Ada provides a powerful type cloning mechanism (I mean: type X is new Y, unfortunately not for types, which are visibly tagged). You can take a branch and plant it as a new tree. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-06 15:09 ` Dmitry A. Kazakov @ 2006-09-06 16:35 ` Georg Bauhaus 2006-09-07 7:32 ` Dmitry A. Kazakov 2006-09-08 9:11 ` Maciej Sobczak 1 sibling, 1 reply; 27+ messages in thread From: Georg Bauhaus @ 2006-09-06 16:35 UTC (permalink / raw) On Wed, 2006-09-06 at 17:09 +0200, Dmitry A. Kazakov wrote: > On Wed, 06 Sep 2006 16:14:07 +0200, Maciej Sobczak wrote: > > >> Why is that shaky? Integer IS ordered. > > > > Is it also tagged? Do you want it to be? > > Not Integer, but Integer'Class. > > > Integer is not only Ordered. It's also Summable, Subtractable, > [...] > > Yes, it is called multiple inheritance. A {PropA,PropB,...}able Integer has multiple interfaces, can act as any of them, etc, ok, but I think MI is inheritance of data as well, in the vernacular. Are you perhaps thinking of something like "aspect interfaces"? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-06 16:35 ` Georg Bauhaus @ 2006-09-07 7:32 ` Dmitry A. Kazakov 2006-09-07 6:48 ` Georg Bauhaus 0 siblings, 1 reply; 27+ messages in thread From: Dmitry A. Kazakov @ 2006-09-07 7:32 UTC (permalink / raw) On Wed, 06 Sep 2006 18:35:58 +0200, Georg Bauhaus wrote: > On Wed, 2006-09-06 at 17:09 +0200, Dmitry A. Kazakov wrote: >> On Wed, 06 Sep 2006 16:14:07 +0200, Maciej Sobczak wrote: >> >>>> Why is that shaky? Integer IS ordered. >>> >>> Is it also tagged? Do you want it to be? >> >> Not Integer, but Integer'Class. >> >>> Integer is not only Ordered. It's also Summable, Subtractable, >> [...] >> >> Yes, it is called multiple inheritance. > > A {PropA,PropB,...}able Integer has multiple interfaces, > can act as any of them, etc, ok, but I think MI is inheritance > of data as well, in the vernacular. Are you perhaps thinking > of something like "aspect interfaces"? I remember it is was a buzz word 2-3 years ago. (:-)) I don't think it makes any sense to separate interface and implementation inheritance. OK, in practice, there might be a granularity associated with the visibility issues. For Ada it would mean that you could publicly inherit from an interface and privately choose whether you inherit the implementation as well, or rather provide a completely new one. And, reverse, you don't inherit from interface, but, privately, do from the implementation. The later is widely used in Ada (it is type X is private;) But this all is independent on the question whether interface and implementation inheritances are different things. They are not. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-07 7:32 ` Dmitry A. Kazakov @ 2006-09-07 6:48 ` Georg Bauhaus 2006-09-07 10:19 ` Dmitry A. Kazakov 0 siblings, 1 reply; 27+ messages in thread From: Georg Bauhaus @ 2006-09-07 6:48 UTC (permalink / raw) Dmitry A. Kazakov wrote: > But this all is independent on the question whether interface and > implementation inheritances are different things. They are not. Suppose I have some complex number type C having a lengthy division operation that requires auxiliary components in the implementation. Now I want a type of complex numbers just like C but without a division operation. One way to do so might seem to inherit a D from C, and clear the division operation, type C is tagged private; ... procedure division(a, b: C; result: in out C); type D is new C with private; ... overriding procedure division(a, b: D; result: in out D) is null; (Is there anything better than null BTW? It won't remove division from D's interface...) This will leave the auxiliary components of C in D. But couldn't I do better? For example, by declaring the interface I want, and then requesting that the needed operations be "extracted" from C, dropping the division stuff (provided there is a way to mark components as being needed by only some set of operations.) I will loose view conversions to C. But if that is what I want? Just a composition of the interface I need in some scope? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-07 6:48 ` Georg Bauhaus @ 2006-09-07 10:19 ` Dmitry A. Kazakov 0 siblings, 0 replies; 27+ messages in thread From: Dmitry A. Kazakov @ 2006-09-07 10:19 UTC (permalink / raw) On Thu, 07 Sep 2006 08:48:21 +0200, Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: > >> But this all is independent on the question whether interface and >> implementation inheritances are different things. They are not. > > Suppose I have some complex number type C > having a lengthy division operation that requires > auxiliary components in the implementation. > > Now I want a type of complex numbers just like C > but without a division operation. Operation disallowing, it is an interesting beast... > One way to do so might seem to inherit a D from C, > and clear the division operation, > > type C is tagged private; > ... > procedure division(a, b: C; result: in out C); > > > type D is new C with private; > ... > overriding > procedure division(a, b: D; result: in out D) is null; > > (Is there anything better than null BTW? It won't remove > division from D's interface...) It cannot, because D is in C'Class. You need "/" there (minimally as a slot in the dispatching table), otherwise some class-wide operations of C would become erroneous. Actually "override with null" = "override with raise Some_Error." In static cases the compiler can catch it, but in general case it cannot, provided that T'Class exists. [And it shall, IMO, exist for all types, maybe for T'Class itself too (:-)) ] > This will leave the auxiliary components of C in D. > > But couldn't I do better? For example, by declaring > the interface I want, and then requesting that the needed > operations be "extracted" from C, dropping the division > stuff (provided there is a way to mark components as being > needed by only some set of operations.) This is quite straightforward. You declare somewhere an interface without division (Ring). Then you inherit D's interface from Ring and do D's implementation from C. That should work similarly to Ada's implementation by renaming and matching "is <>" formal generic subprograms. So C."+" would implement D."+" inherited from Ring."+", while C."/" will be dropped, because there is no Ring."/". Basically, it could be just an automated delegation. > I will loose view conversions to C. Publicly, privately you can still have them. It makes little sense not to have them privately, because "/" can be still reachable. You never know, if "+" does not call it. > But if that is what I want? Just a composition of > the interface I need in some scope? View conversions and other conversions (and attributes) are in fact primitive operations. As such they are a part of the interface. There is no magic in, if you have a different interface, then conversions are automatically different. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-06 15:09 ` Dmitry A. Kazakov 2006-09-06 16:35 ` Georg Bauhaus @ 2006-09-08 9:11 ` Maciej Sobczak 2006-09-08 10:19 ` Dmitry A. Kazakov 1 sibling, 1 reply; 27+ messages in thread From: Maciej Sobczak @ 2006-09-08 9:11 UTC (permalink / raw) Dmitry A. Kazakov wrote: >> In C++ the fact >> that int is ordered does not require that it relates to some Ordered >> class. > > Which is unfortunate for both C++ and Ada, because "to be ordered" = "a > member of Ordered class." There is no obvious reason why they should be > different. No obvious, but subtle, yes. Integer is Ordered, but so is String. Can you imagine a Sequence_Of_Ordered containing, say, 7, 123, "Dmitry", -5, "Maciej"? All these objects are Ordered. Just like Banana is Fruit and Apple is Fruit, right? Still, I can imagine a container of Fruits with Bananas mixed with Apples, but certainly not a container of Ordered - and the problem is that the values listed above don't really share much in common. Can you sort a Sequence_Of_Ordered? No. So - what does it really mean that Integer and String are both Ordered? OK, I know - we forgot that their "domains" of ordering are disjoint. But then - what's the point of having Ordered'Class? As far as I perceive it, the fact that Banana is Fruit and the fact that Integer is Ordered are two facts of *different kind*. The former is related to the "business disctionary" (nice buzz), whereas the latter is more an information about the type. For me, these two facts exist on separate levels and should not be mixed in the same inheritance hierarchy. Moreover, the language should give me distinct tools to express these distinct kinds of facts and for example in C++ I use class inheritance for Banana is Fruit, but type traits for Integer is Ordered. If I had to express these two in the same way (and in the same hierarchy) I would feel a bit uncomfortable. Kind of "weak type safety on the meta-level". There is another "small issue". Robert mentioned that trees are aesthetically pleasing. The problem is that with Ordered (Comparable, Summable, etc.) there is no tree any more because of massive proliferation of multiple inheritance that is then used to express facts about types. The only "pleasing" thing left in the resulting mess is that there are still no cycles. ;-) -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-08 9:11 ` Maciej Sobczak @ 2006-09-08 10:19 ` Dmitry A. Kazakov 0 siblings, 0 replies; 27+ messages in thread From: Dmitry A. Kazakov @ 2006-09-08 10:19 UTC (permalink / raw) On Fri, 08 Sep 2006 11:11:35 +0200, Maciej Sobczak wrote: > Dmitry A. Kazakov wrote: > >>> In C++ the fact >>> that int is ordered does not require that it relates to some Ordered >>> class. >> >> Which is unfortunate for both C++ and Ada, because "to be ordered" = "a >> member of Ordered class." There is no obvious reason why they should be >> different. > > No obvious, but subtle, yes. > Integer is Ordered, but so is String. Can you imagine a > Sequence_Of_Ordered containing, say, 7, 123, "Dmitry", -5, "Maciej"? > All these objects are Ordered. Just like Banana is Fruit and Apple is > Fruit, right? Still, I can imagine a container of Fruits with Bananas > mixed with Apples, but certainly not a container of Ordered - and the > problem is that the values listed above don't really share much in > common. Can you sort a Sequence_Of_Ordered? No. > > So - what does it really mean that Integer and String are both Ordered? > > OK, I know - we forgot that their "domains" of ordering are disjoint. > > But then - what's the point of having Ordered'Class? The notion of "order" is abstract, so the class Ordered should be. It is not required to have any instances of Ordered'Class. That is no different from other unconstrained types. You could ask what's the point in having array (Integer range <>) of Character, if String'Last is undefined? > As far as I perceive it, the fact that Banana is Fruit and the fact that > Integer is Ordered are two facts of *different kind*. The former is > related to the "business disctionary" (nice buzz), whereas the latter is > more an information about the type. For me, these two facts exist on > separate levels and should not be mixed in the same inheritance > hierarchy. Moreover, the language should give me distinct tools to > express these distinct kinds of facts and for example in C++ I use class > inheritance for Banana is Fruit, but type traits for Integer is Ordered. > If I had to express these two in the same way (and in the same > hierarchy) I would feel a bit uncomfortable. Kind of "weak type safety > on the meta-level". In my view it is just the difference is between inheritance from an interface (Ordered is an interface) and inheritance from both an interface and an implementation of (Fruit is a concrete type). Surely the language should allow interface-only inheritance from concrete types. So I agree with your point about language tools, but the point is irrelevant. Because the constraints you might wish to put on T'Class, on T'Class x T'Class, on T'Class x T'Class x T'Class..., on T'Class x W'Class and so on, is a different story (multimethods, multiple dispatch, parallel hierarchies and so on). > There is another "small issue". Robert mentioned that trees are > aesthetically pleasing. The problem is that with Ordered (Comparable, > Summable, etc.) there is no tree any more because of massive > proliferation of multiple inheritance that is then used to express facts > about types. The only "pleasing" thing left in the resulting mess is > that there are still no cycles. ;-) It is how our world was created. (:-)) But what is instead? The relations is-ordered, is-additive-group, is-ring, is-field etc are all here. They don't magically disappear when templates are used. They still exist implicitly. And in Ada, you should describe them ad-hoc in a quite awkward way of generic formal parameters. These generic specifications cannot be re-used, composed, inherited. They cannot be checked against the things they actually represent. In C++ it is even worse, because instead of specifications there is only "anything the compiler might find in the instantiation context." In fact, it is generics, which are "meta-weakly" typed, because they don't allow explicit specification of the meta-type Ordered, and because that meta-type is matched by structure. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-06 14:14 ` Maciej Sobczak 2006-09-06 15:09 ` Dmitry A. Kazakov @ 2006-09-09 14:49 ` Robert A Duff 2006-09-09 15:34 ` Dmitry A. Kazakov 2006-09-09 23:26 ` Jeffrey R. Carter 1 sibling, 2 replies; 27+ messages in thread From: Robert A Duff @ 2006-09-09 14:49 UTC (permalink / raw) Maciej Sobczak <no.spam@no.spam.com> writes: > Robert A Duff wrote: > > >> But then, you would need to have even such fundamental things like > >> Integer belong to Ordered'Class. It's a shaky ground. > > Why is that shaky? Integer IS ordered. > > Is it also tagged? Do you want it to be? Everything should be tagged. There should be no "tagged" keyword. But the compiler should not store the tag with every object, by default. Tags are only needed for class-wide objects, and perhaps aliased objects. >...Or maybe there should be a > special case for Integer (and its every subtype), so that it's > semantically in Ordered'Class without being syntactically tagged? Special-casing predefined things is usually a mistake. Note that the rule saying 'Class only works for tagged types is not necessary, and was not present in earlier versions of Ada 9X. In fact, universal_integer is really root_integer'Class, conceptually. Too bad you can't mention its name in a program. > Is it really in the spirit of Ada? No, apparently not. > Integer is not only Ordered. It's also Summable, Subtractable, > Multipliable, Divideable, Powerable, Incrementable, Decrementable, > Comparable, Copyable, Assignable, Imageable and even Aspect_Clauseable, > not mentioning Can_Be_Used_As_Array_Index. And it has some others as > well. > And all this is very important, since there might be other types that > share only some of these properties but not others and surely we don't > want our Container_Of_Incrementable_And_Divideable_And_Comparable to > contain something that isn't, right? > > (sorry if any of the above is not proper English) > > ;-) I understood it. Part of the problem (in most languages, including Ada) with all of the above classes is that you have to decide up front. It would be useful to be able to say "type T inherits from Mungable" without modifying the source code for T or Mungable. > And switching back to serious, I somehow don't like languages that try > to apply object-orientedness to absolutely everything. Why? Note that making everything tagged, and having a root Object type in the hierarchy doesn't really make everything OO. OO-ness really comes from 'Class, mainly. >... In C++ the fact > that int is ordered does not require that it relates to some Ordered > class. Such properties - if needed - can be expressed in other ways. > > > > A hierarchy with Object at the top would be a Good Thing, IMHO. Trees > > are more aesthetically pleasing than forests. > > Opinions vary on this subject. :-) Indeed. ;-) Of course, my comment about trees is somewhat bugus if multiple inheritance is allowed. > > But I think perhaps we should have generic types > > (i.e. parameterized types) rather than generic packages. That's what > > discriminants do, but they're severely limited. It would make sense to > > have a discriminant that is a type, so you could say: > > My_Sequence: Sequence(Element => Integer) := (1, 2, 3); > > Yes, that would be fine. - Bob ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-09 14:49 ` Robert A Duff @ 2006-09-09 15:34 ` Dmitry A. Kazakov 2006-09-09 23:26 ` Jeffrey R. Carter 1 sibling, 0 replies; 27+ messages in thread From: Dmitry A. Kazakov @ 2006-09-09 15:34 UTC (permalink / raw) On 09 Sep 2006 10:49:43 -0400, Robert A Duff wrote: > Everything should be tagged. There should be no "tagged" keyword. Amen! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-09 14:49 ` Robert A Duff 2006-09-09 15:34 ` Dmitry A. Kazakov @ 2006-09-09 23:26 ` Jeffrey R. Carter 2006-09-10 11:49 ` Robert A Duff 1 sibling, 1 reply; 27+ messages in thread From: Jeffrey R. Carter @ 2006-09-09 23:26 UTC (permalink / raw) Robert A Duff wrote: > > Note that making everything tagged, and having a root Object type in the > hierarchy doesn't really make everything OO. OO-ness really comes from > 'Class, mainly. OO-ness (object-oriented-ness) is a design attribute. You can have perfectly good OO-ness without type extension, dispatching, or 'Class. You can have it in Ada 83 or assembler. Similarly, the use of type extension, dispatching, or 'Class doesn't give you OO-ness. They give you programming by extension, which does not necessarily have anything to do with OO-ness. -- Jeff Carter "I blow my nose on you." Monty Python & the Holy Grail 03 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-09 23:26 ` Jeffrey R. Carter @ 2006-09-10 11:49 ` Robert A Duff 2006-09-10 19:43 ` Jeffrey R. Carter 0 siblings, 1 reply; 27+ messages in thread From: Robert A Duff @ 2006-09-10 11:49 UTC (permalink / raw) "Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes: > Robert A Duff wrote: > > Note that making everything tagged, and having a root Object type in > > the > > hierarchy doesn't really make everything OO. OO-ness really comes from > > 'Class, mainly. > > OO-ness (object-oriented-ness) is a design attribute. Well, yeah, that's true. I guess I'm focusing on language features that support OOP, as opposed to OOP itself. And I'm deliberately ignoring OOD and OOA, which are, to a large extent, snake oil. >... You can have > perfectly good OO-ness without type extension, dispatching, or > 'Class. You can have it in Ada 83 or assembler. Similarly, the use of > type extension, dispatching, or 'Class doesn't give you OO-ness. They > give you programming by extension, which does not necessarily have > anything to do with OO-ness. I'll quibble with the Ada 83 part. Part of OOP is the "open-closed principle", which means you can change/extend behavior of something without modifying its source code. That really requires dispatching, or something very much like it, and Ada 83 doesn't have any form of indirect call with which to similate that. Asssembly languages do, though. Of course, you can simulate (say) Smalltalk in Ada 83, and then do OOP using that, but then that's not quite Ada programming anymore. - Bob ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-10 11:49 ` Robert A Duff @ 2006-09-10 19:43 ` Jeffrey R. Carter 0 siblings, 0 replies; 27+ messages in thread From: Jeffrey R. Carter @ 2006-09-10 19:43 UTC (permalink / raw) Robert A Duff wrote: > > I'll quibble with the Ada 83 part. Part of OOP is the "open-closed > principle", which means you can change/extend behavior of something > without modifying its source code. That really requires dispatching, or > something very much like it, and Ada 83 doesn't have any form of > indirect call with which to similate that. Asssembly languages do, > though. OOP is not OO. OOP is a misnomer for programming by extension, which does not necessarily have anything to do with OO. -- Jeff Carter "Sons of a silly person." Monty Python & the Holy Grail 02 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-06 9:43 ` Dmitry A. Kazakov 2006-09-06 12:36 ` Maciej Sobczak @ 2006-09-06 13:02 ` Robert A Duff 2006-09-06 14:09 ` Dmitry A. Kazakov 2006-09-08 3:35 ` Randy Brukardt 2 siblings, 1 reply; 27+ messages in thread From: Robert A Duff @ 2006-09-06 13:02 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Wed, 06 Sep 2006 10:51:48 +0200, Maciej Sobczak wrote: > > > eneric > > type Index_Type is (<>); > > type Element_Type is private; > > type Array_Type is array (Index_Type range <>) of Element_Type; > > with function "<" (Left, Right : in Element_Type) return Boolean is <>; > > procedure Sort(To_Sort : in out Array_Type); > > > > My question is: what's the purpose of the third parameter (Array_Type)? > > Isn't it implied by the first two and therefore just redundant? > > Reverse. Actually Index_Type and Element_Type are redundant. In a better > Ada it should be: > > generic > type Container_Type is array (<>) of <>; > -- or "(<>) is limited private array" > with function "<" (Left, Right : in Container_Type'Element) > return Boolean is <>; > procedure Sort (To_Sort : in out Container_Type); > > [ Even better it be non-generic: > > procedure Sort (To_Sort : in out Container_Of_Ordered'Class); > > where each container type (like an array) be a member of the class, if its > elements are in Ordered'Class. ] I think you mean Sequence_Of_Ordered -- not all containers can be sorted. But I agree that it would be nice to have such a feature. It works for the built-in array types -- you magically get "and" if the component is Boolean, "<" if the component is discrete, ":=" if the component is non-limited. I don't know of a good way to do that sort of thing for user-defined containers. If generics could do that, then "array" could just be a generic, rather than having built-in syntax and semantics. Eiffel does it that way. - Bob ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-06 13:02 ` Robert A Duff @ 2006-09-06 14:09 ` Dmitry A. Kazakov 0 siblings, 0 replies; 27+ messages in thread From: Dmitry A. Kazakov @ 2006-09-06 14:09 UTC (permalink / raw) On 06 Sep 2006 09:02:51 -0400, Robert A Duff wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On Wed, 06 Sep 2006 10:51:48 +0200, Maciej Sobczak wrote: >> >>> eneric >>> type Index_Type is (<>); >>> type Element_Type is private; >>> type Array_Type is array (Index_Type range <>) of Element_Type; >>> with function "<" (Left, Right : in Element_Type) return Boolean is <>; >>> procedure Sort(To_Sort : in out Array_Type); >>> >>> My question is: what's the purpose of the third parameter (Array_Type)? >>> Isn't it implied by the first two and therefore just redundant? >> >> Reverse. Actually Index_Type and Element_Type are redundant. In a better >> Ada it should be: >> >> generic >> type Container_Type is array (<>) of <>; >> -- or "(<>) is limited private array" >> with function "<" (Left, Right : in Container_Type'Element) >> return Boolean is <>; >> procedure Sort (To_Sort : in out Container_Type); >> >> [ Even better it be non-generic: >> >> procedure Sort (To_Sort : in out Container_Of_Ordered'Class); >> >> where each container type (like an array) be a member of the class, if its >> elements are in Ordered'Class. ] > > I think you mean Sequence_Of_Ordered -- not all containers can be > sorted. Right, both the index type and the element types have to be ordered, and also the element type should be non-limited. > But I agree that it would be nice to have such a feature. It works for > the built-in array types -- you magically get "and" if the component is > Boolean, "<" if the component is discrete, ":=" if the component is > non-limited. I don't know of a good way to do that sort of thing for > user-defined containers. The user-defined container should implement the corresponding interface. As you said, the interface could have two type discriminants (physically type tags): Index : type Abstract_Ordered; Element : type Abstract_Ordered Because interfaces are MI, an array of Boolean could implement Lattice interface, which would give the user and, or, not etc. Upon declaration he would specify the interfaces his container promises to implement. The problems with that, as I can see: 1. inheritance/overriding/merging of discriminants (diamond diagram). Clearly Index and Element in all interfaces should be same. 2. an intelligent and effective elimination of statically-known discriminants at run-time. BTW, if that worked, we could remove built-in tagged types replacing them by an interface with the Tag discriminant. There is another interesting thing to investigate. If a type has many type-discriminants, then for each such discriminant (including its own tag), it should have a class. I.e. by analogy with T'First(n) attributes there will be Container'Class, Contrainer'Class(Index), Container'Class(Element). That would open a range of possibilities. For example one could derive from Container along the 'Element' axis. The result should be a class of containers with elements from Element'Class. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-06 9:43 ` Dmitry A. Kazakov 2006-09-06 12:36 ` Maciej Sobczak 2006-09-06 13:02 ` Robert A Duff @ 2006-09-08 3:35 ` Randy Brukardt 2006-09-08 7:21 ` Dmitry A. Kazakov 2 siblings, 1 reply; 27+ messages in thread From: Randy Brukardt @ 2006-09-08 3:35 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:w0vh1ugsvkj1$.2fnx5mt0tplm$.dlg@40tude.net... ... > The reverse is a different story. It is a pity that Ada does not have > attributes to get the index and element types from the array type > (container type). The next step would be getting "<" from the element type, > which would eliminate a need to have Sort generic. That doesn't really work. "<" is what controls how the items are sorted, and it is common to want to sort the same type in multiple ways. If you have employee records, you might want to sort them both on Social Security numbers and on date of employment, for example. Two generic instantiations work fine for that, but there isn't any way to have two "<" with different behaviors. We had this discussion when looking at the possibility of having a sorting interface. It just doesn't work well, because there can only be a single implementation. (That is a problem with any scheme based on inheritance.) That's why I view interfaces less as types and more as properties that are either present or absent on any individual specific type. Randy. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-08 3:35 ` Randy Brukardt @ 2006-09-08 7:21 ` Dmitry A. Kazakov 2006-09-09 1:29 ` Randy Brukardt 0 siblings, 1 reply; 27+ messages in thread From: Dmitry A. Kazakov @ 2006-09-08 7:21 UTC (permalink / raw) On Thu, 7 Sep 2006 22:35:44 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:w0vh1ugsvkj1$.2fnx5mt0tplm$.dlg@40tude.net... > ... >> The reverse is a different story. It is a pity that Ada does not have >> attributes to get the index and element types from the array type >> (container type). The next step would be getting "<" from the element type, >> which would eliminate a need to have Sort generic. > > That doesn't really work. "<" is what controls how the items are sorted, and > it is common to want to sort the same type in multiple ways. If you have > employee records, you might want to sort them both on Social Security > numbers and on date of employment, for example. Two generic instantiations > work fine for that, but there isn't any way to have two "<" with different > behaviors. > > We had this discussion when looking at the possibility of having a sorting > interface. It just doesn't work well, because there can only be a single > implementation. (That is a problem with any scheme based on inheritance.) > That's why I view interfaces less as types and more as properties that are > either present or absent on any individual specific type. Yes, that's when somebody wanted to have different orders. But that in my view is a different case, in which "<" should be better passed to Sort as a plain parameter, rather than generic or primitive subprogram. I think the difference between two scenarios is whether the order is arbitrary, ad-hoc or else involved in some loose set of operations. In the first case "<" should be a parameter in the latter case a part of the interface (be it generic or primitive operation). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-08 7:21 ` Dmitry A. Kazakov @ 2006-09-09 1:29 ` Randy Brukardt 2006-09-09 7:14 ` Dmitry A. Kazakov 2006-09-09 14:32 ` Robert A Duff 0 siblings, 2 replies; 27+ messages in thread From: Randy Brukardt @ 2006-09-09 1:29 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:g3c05xzf7uad$.wucggq0h6wuy$.dlg@40tude.net... ... > Yes, that's when somebody wanted to have different orders. But that in my > view is a different case, in which "<" should be better passed to Sort as a > plain parameter, rather than generic or primitive subprogram. We considered that, too, and decided not to do it because it because it doesn't work well in Ada. "<" is usually Intrinsic, and Intrinsic things cannot be passed as access-to-subprogram parameters. So you'd have to explicitly build a wrapper function, with all of the possibilities for error that that exposes. Generic instantiations don't have that limitation (as they are are considered more heavyweight than a simple 'Access). > I think the difference between two scenarios is whether the order is arbitrary, ad-hoc > or else involved in some loose set of operations. In the first case "<" > should be a parameter in the latter case a part of the interface (be it > generic or primitive operation). We really wanted to avoid having a lot of different sorting routines, because that then forces users to decide which one that they need to use. Most of the time, the choice is not particularly important (if it is not a critical operation), and excess choices just take mental energy away from solving the problem at hand. (That's why I'd be opposed to having multiple kinds of lists [like doubly and singly linked] in the Ada Containers library; the space and performance differences would be slight, but they'd add an additional complexity to deciding what container to use.) But you are correct that there usually is a "natural" comparison operation and then secondary orderings -- one could consider these as different cases, simply as one would be named "<" and the other would have some other name.. Randy. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-09 1:29 ` Randy Brukardt @ 2006-09-09 7:14 ` Dmitry A. Kazakov 2006-09-09 14:32 ` Robert A Duff 1 sibling, 0 replies; 27+ messages in thread From: Dmitry A. Kazakov @ 2006-09-09 7:14 UTC (permalink / raw) On Fri, 8 Sep 2006 20:29:20 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:g3c05xzf7uad$.wucggq0h6wuy$.dlg@40tude.net... > ... >> Yes, that's when somebody wanted to have different orders. But that in my >> view is a different case, in which "<" should be better passed to Sort as a >> plain parameter, rather than generic or primitive subprogram. > > We considered that, too, and decided not to do it because it because it > doesn't work well in Ada. "<" is usually Intrinsic, and Intrinsic things > cannot be passed as access-to-subprogram parameters. So you'd have to > explicitly build a wrapper function, with all of the possibilities for error > that that exposes. Generic instantiations don't have that limitation (as > they are are considered more heavyweight than a simple 'Access). Well, I never could understand why shouldn't we make procedural types and forget all that C-ish mess with access-to-procedure. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-09 1:29 ` Randy Brukardt 2006-09-09 7:14 ` Dmitry A. Kazakov @ 2006-09-09 14:32 ` Robert A Duff 1 sibling, 0 replies; 27+ messages in thread From: Robert A Duff @ 2006-09-09 14:32 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > We considered that, too, and decided not to do it because it because it > doesn't work well in Ada. "<" is usually Intrinsic, and Intrinsic things > cannot be passed as access-to-subprogram parameters. So you'd have to > explicitly build a wrapper function, with all of the possibilities for error > that that exposes. Generic instantiations don't have that limitation (as > they are are considered more heavyweight than a simple 'Access). Kludgery begets more kludgery. Surely you should be allowed to pass things like "<" as a parameter! Proof: see Randy's comment above. Making wrappers should be the compiler's job. Viewing downward closure as access values is overly implementation oriented. The "not null access" on the declaration, and the 'Access on all calls, are just noise. - Bob ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-06 8:51 Generic procedures and their parameters Maciej Sobczak 2006-09-06 9:43 ` Dmitry A. Kazakov @ 2006-09-06 12:56 ` Robert A Duff 2006-09-07 2:47 ` Steve 2 siblings, 0 replies; 27+ messages in thread From: Robert A Duff @ 2006-09-06 12:56 UTC (permalink / raw) Maciej Sobczak <no.spam@no.spam.com> writes: > Hi, > > I have found the following signature for the sorting procedure: > > eneric > type Index_Type is (<>); > type Element_Type is private; > type Array_Type is array (Index_Type range <>) of Element_Type; > with function "<" (Left, Right : in Element_Type) return Boolean is <>; > procedure Sort(To_Sort : in out Array_Type); > > My question is: what's the purpose of the third parameter (Array_Type)? > Isn't it implied by the first two and therefore just redundant? Well, if you simply erase the Array_Type formal, then the reference to Array_Type in the declaration of To_Sort would be in error. And you cannot say this: generic type Index_Type is (<>); type Element_Type is private; with function "<" (Left, Right : in Element_Type) return Boolean is <>; procedure Sort(To_Sort : in out array (Index_Type range <>) of Element_Type); -- Illegal syntax! because Ada uses "by name" type equivalence (mostly). In this case, structural equivalence might be more convenient. You could do it this way: generic type Index_Type is (<>); type Element_Type is private; with function "<" (Left, Right : in Element_Type) return Boolean is <>; package Sorting is type Array_Type is array (Index_Type range <>) of Element_Type; procedure Sort(To_Sort : in out Array_Type); end Sorting; but that's less flexible for the client, because it can't use it's own array type. - Bob ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-06 8:51 Generic procedures and their parameters Maciej Sobczak 2006-09-06 9:43 ` Dmitry A. Kazakov 2006-09-06 12:56 ` Robert A Duff @ 2006-09-07 2:47 ` Steve 2006-09-07 7:47 ` Dmitry A. Kazakov 2 siblings, 1 reply; 27+ messages in thread From: Steve @ 2006-09-07 2:47 UTC (permalink / raw) "Maciej Sobczak" <no.spam@no.spam.com> wrote in message news:edm273$fee$1@sunnews.cern.ch... > Hi, > > I have found the following signature for the sorting procedure: > > eneric > type Index_Type is (<>); > type Element_Type is private; > type Array_Type is array (Index_Type range <>) of Element_Type; > with function "<" (Left, Right : in Element_Type) return Boolean is <>; > procedure Sort(To_Sort : in out Array_Type); > > My question is: what's the purpose of the third parameter (Array_Type)? > Isn't it implied by the first two and therefore just redundant? > I prefer: generic type Index_Type is (<>); type Collection_Type is private; firstIndex : Index_Type; lastIndex : Index_Type; with function In_Order( list : Collection_Type; i, j : Index_Type ) return Boolean; procedure Swap( list : in out Collection_Type; i, j : Index_Type ); procedure Sort( list : in out Collection_Type ); This avoids the declaration of the array altogether, and is usable for any list that may be referenced by index. My 2 cents. Steve (The Duck) > > -- > Maciej Sobczak : http://www.msobczak.com/ > Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Generic procedures and their parameters 2006-09-07 2:47 ` Steve @ 2006-09-07 7:47 ` Dmitry A. Kazakov 0 siblings, 0 replies; 27+ messages in thread From: Dmitry A. Kazakov @ 2006-09-07 7:47 UTC (permalink / raw) On Wed, 6 Sep 2006 19:47:14 -0700, Steve wrote: > "Maciej Sobczak" <no.spam@no.spam.com> wrote in message > news:edm273$fee$1@sunnews.cern.ch... >> Hi, >> >> I have found the following signature for the sorting procedure: >> >> eneric >> type Index_Type is (<>); >> type Element_Type is private; >> type Array_Type is array (Index_Type range <>) of Element_Type; >> with function "<" (Left, Right : in Element_Type) return Boolean is <>; >> procedure Sort(To_Sort : in out Array_Type); >> >> My question is: what's the purpose of the third parameter (Array_Type)? >> Isn't it implied by the first two and therefore just redundant? > > I prefer: > > generic > type Index_Type is (<>); > type Collection_Type is private; > firstIndex : Index_Type; > lastIndex : Index_Type; > with function In_Order( list : Collection_Type; i, j : Index_Type ) > return Boolean; > procedure Swap( list : in out Collection_Type; i, j : Index_Type ); > procedure Sort( list : in out Collection_Type ); > > This avoids the declaration of the array altogether, and is usable for any > list that may be referenced by index. Ah, that's an "abstract generic array" thing. If more that just Sort is needed one goes as: generic type Index_Type is (<>); type Element_Type is private; Null_Element : Element_Type; type Collection_Type is private; with function First (X : Collection_Type) return Index_Type is <>; with function Last (X : Collection_Type) return Index_Type is <>; with function Get (X : Collection_Type) return Element_Type is <>; with procedure Set (X : in out Collection_Type; Y : Element_Type) is <>; package Generic_Collection is -- Nothing here. It is an "abstract" package end Generic_Collection; Then Sort becomes a child: generic with function "<" (Left, Right : Element_Type) return Boolean; procedure Generic_Collection.Sort (X : in out Collection_Type); Unfortunately, Element_Type reappears. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2006-09-10 19:43 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-09-06 8:51 Generic procedures and their parameters Maciej Sobczak 2006-09-06 9:43 ` Dmitry A. Kazakov 2006-09-06 12:36 ` Maciej Sobczak 2006-09-06 13:11 ` Robert A Duff 2006-09-06 14:14 ` Maciej Sobczak 2006-09-06 15:09 ` Dmitry A. Kazakov 2006-09-06 16:35 ` Georg Bauhaus 2006-09-07 7:32 ` Dmitry A. Kazakov 2006-09-07 6:48 ` Georg Bauhaus 2006-09-07 10:19 ` Dmitry A. Kazakov 2006-09-08 9:11 ` Maciej Sobczak 2006-09-08 10:19 ` Dmitry A. Kazakov 2006-09-09 14:49 ` Robert A Duff 2006-09-09 15:34 ` Dmitry A. Kazakov 2006-09-09 23:26 ` Jeffrey R. Carter 2006-09-10 11:49 ` Robert A Duff 2006-09-10 19:43 ` Jeffrey R. Carter 2006-09-06 13:02 ` Robert A Duff 2006-09-06 14:09 ` Dmitry A. Kazakov 2006-09-08 3:35 ` Randy Brukardt 2006-09-08 7:21 ` Dmitry A. Kazakov 2006-09-09 1:29 ` Randy Brukardt 2006-09-09 7:14 ` Dmitry A. Kazakov 2006-09-09 14:32 ` Robert A Duff 2006-09-06 12:56 ` Robert A Duff 2006-09-07 2:47 ` Steve 2006-09-07 7:47 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox