* XML DOM Binding for Ada 95 - matter of style @ 2003-07-30 11:32 DENNY VRANDECIC 2003-07-30 12:33 ` Martin Dowie 2003-07-30 17:54 ` tmoran 0 siblings, 2 replies; 47+ messages in thread From: DENNY VRANDECIC @ 2003-07-30 11:32 UTC (permalink / raw) Hello group, I am writing an XML DOM Binding for Ada 95 (as part of my master thesis) - not really the whole parser, just a binding to a parser that is more complete (i.e. implements more modules of the DOM Spec) than the otherwise great XmlAda by ACT. The binding will be given to the community for free under a BSD-like license. I'd love to write the binding in such a way, that later the user may easily switch to a native DOM Implementation (like a further developed XmlAda), which I'm sure will finally come. But for that I have to make one hard decision: which standard to follow? On the one hand, the W3C published IDLs in their standards, and I may choose just to stick close to these IDL-Specs. The result doesn't have an Ada-like feeling - the procedures names are written in one word, the exception handling is cumbersome, and more. But I follow the W3C standard closely, and that's a good thing, isn't it? And most of the interface could be created automatically. There would be less discussions on the details of this way, as their is a standard IDL describing the interface and a standard mapping of IDL to Ada 95. Everything is standard, everything is fine. On the other hand, I could adhere to the Ada style guide, and make the binding feel very Adaesque. Ada users would learn it easier, it would better fit in the program, the stylecheckers would appreciate it and much more. But with creating this interface I would probably have to make much more decisions, which could be questioned, and thus this way would harder lead to an accepted standard interface, thus making switching the implementation later harder. It's a Catch-22, so I'd love to draw on your experience. I will deliver a talk on Friday at the University of Stuttgart, Germany, about this, and discuss it with the people there to form a stronger opinion about it, and I would love to hear your opinion on it beforehand and afterwards. I like to make this decision with you, as eventually this binding is done for the community. Sorry for my bad english, I'm no native speaker. If you have further questions or comment, that or not of interest to many, you may also send them via eMail (denny_at_nodix.de). Thanks for your time, Denny Vrandecic Student of computer science, University Stuttgart ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-07-30 11:32 XML DOM Binding for Ada 95 - matter of style DENNY VRANDECIC @ 2003-07-30 12:33 ` Martin Dowie 2003-07-30 15:20 ` Denny Vrandecic 2003-07-30 17:54 ` tmoran 1 sibling, 1 reply; 47+ messages in thread From: Martin Dowie @ 2003-07-30 12:33 UTC (permalink / raw) "DENNY VRANDECIC" <nodix@tiscali.de> wrote in message news:bg8ac5$20i3$1@ulysses.news.tiscali.de... > On the one hand, the W3C published IDLs in their standards, and I may choose [snip] How about providing both? One as a wrapper to the other. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-07-30 12:33 ` Martin Dowie @ 2003-07-30 15:20 ` Denny Vrandecic 2003-07-30 16:33 ` Stephen Leake 2003-07-30 16:34 ` Martin Dowie 0 siblings, 2 replies; 47+ messages in thread From: Denny Vrandecic @ 2003-07-30 15:20 UTC (permalink / raw) Denny Vrandecic wrote: > > On the one hand, the W3C published IDLs in their standards, and I may >> choose >>[snip] Martin Dowie answered > How about providing both? One as a wrapper to the other. Simply put: double work, same pay. There is no easy way of wrapping one around the other, especially Exception Handling is a rather tricky issue that differs tremendously between the IDL- and the Ada-way. To avoid double work and still write the one binding that is most useful for the Ada-Community I ask here for your opinion and advice. Thanks though, Denny ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-07-30 15:20 ` Denny Vrandecic @ 2003-07-30 16:33 ` Stephen Leake 2003-07-31 10:57 ` Marin David Condic 2003-07-30 16:34 ` Martin Dowie 1 sibling, 1 reply; 47+ messages in thread From: Stephen Leake @ 2003-07-30 16:33 UTC (permalink / raw) "Denny Vrandecic" <nodix@tiscali.de> writes: > Denny Vrandecic wrote: > > > On the one hand, the W3C published IDLs in their standards, and I may > >> choose > >>[snip] > Martin Dowie answered > > How about providing both? One as a wrapper to the other. > > Simply put: double work, same pay. Well, same pay for you in the short run (one thesis), but significant gain for both you and the community in the long run. > There is no easy way of wrapping one around the other, especially > Exception Handling is a rather tricky issue that differs > tremendously between the IDL- and the Ada-way. To avoid double work > and still write the one binding that is most useful for the > Ada-Community I ask here for your opinion and advice. You should start with a thin binding (the IDL way). That will allow easy upgrade to any future versions of the DOM spec. Then anyone who wants to use it will write a partial thick binding (the Ada way). Eventually, all those people will get together and write a common thick binding. -- -- Stephe ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-07-30 16:33 ` Stephen Leake @ 2003-07-31 10:57 ` Marin David Condic 2003-07-31 11:27 ` Preben Randhol 0 siblings, 1 reply; 47+ messages in thread From: Marin David Condic @ 2003-07-31 10:57 UTC (permalink / raw) Another argument against that notion is that you then have yet another proliferation of a different "standard". I'm looking at Trudy Levine's column in the most recent Ada Letters and noticing the wide proliferation of possible container libraries out there and I'm sure this is not a comprehensive list mentioning every one that is publically available. (Not to mention all those sitting in private libraries that were home grown but not distributed.) Do we really need to see yet more variations of a library where the fundamental purpose and functionality has not changed? My opinion is this: The XML standard for document content is the only real compatibility one needs to maintain. The interface to access it ought to be treated more as a "suggestion" with what is natural for the language of implementation being the deciding factor. Don't be different just for the sake of being different - keep names of things similar/recognizable and provide mostly the same operations, etc. - but do it in a way that makes sense for Ada. BTW: I never really liked the XMLAda approach of using discriminated records and thought it should have been built in a more Object Oriented way using tagged records. (Thus giving fuel to the C++/Java critics of Ada where they can observe that given an object oriented design, Ada apparently can't implement it in an object oriented way with inheritance, etc.) It would be a good thing to look to fix in any enhanced interface to the XML-DOM. MDC Stephen Leake wrote: > > > Well, same pay for you in the short run (one thesis), but significant > gain for both you and the community in the long run. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "In general the art of government consists in taking as much money as possible from one class of citizens to give to the other." -- Voltaire ====================================================================== ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-07-31 10:57 ` Marin David Condic @ 2003-07-31 11:27 ` Preben Randhol 2003-07-31 13:10 ` Matthew Heaney 2003-08-01 11:46 ` Marin David Condic 0 siblings, 2 replies; 47+ messages in thread From: Preben Randhol @ 2003-07-31 11:27 UTC (permalink / raw) Marin David Condic wrote: > BTW: I never really liked the XMLAda approach of using discriminated > records and thought it should have been built in a more Object Oriented > way using tagged records. What is the gain? I thought one of the problems with Booch was that it was using tagged types too much. Does Charles also use this approach? -- Ada95 is good for you. http://www.crystalcode.com/codemage/MainMenu/Coding/Ada/IntroducingAda.php ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-07-31 11:27 ` Preben Randhol @ 2003-07-31 13:10 ` Matthew Heaney 2003-07-31 19:04 ` Simon Wright 2003-07-31 20:25 ` Randy Brukardt 2003-08-01 11:46 ` Marin David Condic 1 sibling, 2 replies; 47+ messages in thread From: Matthew Heaney @ 2003-07-31 13:10 UTC (permalink / raw) "Preben Randhol" <randhol+abuse@pvv.org> wrote in message news:slrnbihv85.4jd.randhol+abuse@kiuk0152.chembio.ntnu.no... > Marin David Condic wrote: > > BTW: I never really liked the XMLAda approach of using discriminated > > records and thought it should have been built in a more Object Oriented > > way using tagged records. > > What is the gain? > > I thought one of the problems with Booch was that it was using tagged > types too much. Does Charles also use this approach? One problem is that you have to make two instantiations: one for the root package, in which the root type is declared, and another, for the child package in which the actual container (derived) type is declared. This is a royal pain. Charles deliberately avoided this technique, because no inheritance is necessary. Static mechanisms are used instead, which are simpler and more general. So don't use a tagged type hierarchy when there's a simpler mechanism available. I haven't seen the XMLAda approach, but I am totally sympathetic to approaches that do *not* use tagged records. I'm not against tagged type ("object-oriented") programming, it's just that many programmers seem to treat this as a hammer looking for a nail, and automatically use a tagged type to solve a problem that is better solved other ways. Look for a new release of Charles early next week. http://home.earthlink.net/~matthewjheaney/charles/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-07-31 13:10 ` Matthew Heaney @ 2003-07-31 19:04 ` Simon Wright 2003-08-02 14:40 ` Matthew Heaney 2003-07-31 20:25 ` Randy Brukardt 1 sibling, 1 reply; 47+ messages in thread From: Simon Wright @ 2003-07-31 19:04 UTC (permalink / raw) "Matthew Heaney" <matthewjheaney@earthlink.net> writes: > "Preben Randhol" <randhol+abuse@pvv.org> wrote in message > news:slrnbihv85.4jd.randhol+abuse@kiuk0152.chembio.ntnu.no... > > I thought one of the problems with Booch was that it was using > > tagged types too much. Does Charles also use this approach? > > One problem is that you have to make two instantiations: one for the > root package, in which the root type is declared, and another, for > the child package in which the actual container (derived) type is > declared. This is a royal pain. ^^^^^^^^^^ I would say "mildly tedious", but then I would, wouldn't I! It's not clear to me that this is a consequence of using tagged types?? perhaps .. anyway, what people complain about, until they've got used to it or developed a tool to generate the code for them, is the instantiating, not the taggedness. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-07-31 19:04 ` Simon Wright @ 2003-08-02 14:40 ` Matthew Heaney 0 siblings, 0 replies; 47+ messages in thread From: Matthew Heaney @ 2003-08-02 14:40 UTC (permalink / raw) "Simon Wright" <simon@pushface.org> wrote in message news:x7vn0eu4iwc.fsf@smaug.pushface.org... > > It's not clear to me that this is a consequence of using tagged > types?? perhaps .. anyway, what people complain about, until they've > got used to it or developed a tool to generate the code for them, is > the instantiating, not the taggedness. But you have to perform the instantiation because the type you really need is a derivation. If there were no derivation (no inheritance), then there would be no need for the second instantiation and the problem would disappear. The other issue is that iteration can only be done using a class-wide type, which means all operations are dynamically bound. Not only is this less efficient, it is unnecessary, because all the types are known statically. The only time it would make sense to use dynamic binding is if the type of the container object weren't known until run-time. But this is very atypical. There is also a space penalty, because each iterator object must also carry a tag, in addition to the internal pointer. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-07-31 13:10 ` Matthew Heaney 2003-07-31 19:04 ` Simon Wright @ 2003-07-31 20:25 ` Randy Brukardt 1 sibling, 0 replies; 47+ messages in thread From: Randy Brukardt @ 2003-07-31 20:25 UTC (permalink / raw) "Matthew Heaney" <matthewjheaney@earthlink.net> wrote in message news:Ly8Wa.716$jg7.380@newsread3.news.pas.earthlink.net... > "Preben Randhol" <randhol+abuse@pvv.org> wrote in message > news:slrnbihv85.4jd.randhol+abuse@kiuk0152.chembio.ntnu.no... > > I thought one of the problems with Booch was that it was using tagged > > types too much. Does Charles also use this approach? You can't use tagged types too much. IMHO, virtually everything should be derived from Controlled or Limited_Controlled (which by definition makes them a tagged type). But... > One problem is that you have to make two instantiations: one for the root > package, in which the root type is declared, and another, for the child > package in which the actual container (derived) type is declared. This is a > royal pain. > > Charles deliberately avoided this technique, because no inheritance is > necessary. Static mechanisms are used instead, which are simpler and more > general. Right. *Inheritance* is what can easily be overused. It has its place, but it can easily be overused. And users have a hard time understanding "overriding", which is usually necessary to use these sorts of types. We did Claw that way mainly because we wanted to be able to say that it was "Object-Oriented"; if I was designing it with no marketing implications, we may have chosen a different structure. (I'm not sure, because we never did any analysis on non-O-O choices.) In the specific case of container libraries, if it takes more than one instantiation to get a basic container, it is too hard to use. If it's much more complex than that, I'd rather build my own from scratch (none of them are that much work to implement, especially as you almost never need the full generality). And I don't think it is important to have a version for every need. A version that works well for most needs is enough -- if you have truly critical needs, you ought to build something custom that meets those needs exactly. But most container needs aren't that critical. It's more important to be able to use them to quickly build a solution that you can profile to find out whether it is good enough or not. Randy. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-07-31 11:27 ` Preben Randhol 2003-07-31 13:10 ` Matthew Heaney @ 2003-08-01 11:46 ` Marin David Condic 2003-08-02 3:40 ` Matthew Heaney 1 sibling, 1 reply; 47+ messages in thread From: Marin David Condic @ 2003-08-01 11:46 UTC (permalink / raw) Well, if one believes that there is no value in the Object Oriented Design methodology, then I suppose there is no gain. :-) First, the code would reflect the design. Everything in the XML DOM description is done with an eye towards an object oriented implementation - a base level node from which all the other nodes are derived, overriding and extension of operations, etc. You don't have to implement it as object oriented code utilizing tagged records, etc. Its just the most natural expression of the design. Second, should there be extensions in the form of adding new node types or new operations to the DOM, the Object Oriented approach makes the extension less painful than it would be to modify the discriminated record implementation. Maybe it never changes, so maybe that's not a gain. Do you really think the standards committee is going to disband and declare XML & the DOM frozen for all time? Tagged record implementation would sure make it easier for someone else to build upon it if the need should arise. IMHO, something like the DOM - an OOD expression of a desired functionality - is exactly the reason Ada invented tagged records. To implement it with discriminated records (a feature I always found to have too many "gotchas!" built into it anyway) seems awkward and clumsy. If you don't think using tagged records to implement something like this design is appropriate, what are you saving them for? :-) MDC Preben Randhol wrote: > Marin David Condic wrote: > >>BTW: I never really liked the XMLAda approach of using discriminated >>records and thought it should have been built in a more Object Oriented >>way using tagged records. > > > What is the gain? > > I thought one of the problems with Booch was that it was using tagged > types too much. Does Charles also use this approach? > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "In general the art of government consists in taking as much money as possible from one class of citizens to give to the other." -- Voltaire ====================================================================== ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-01 11:46 ` Marin David Condic @ 2003-08-02 3:40 ` Matthew Heaney 2003-08-02 12:08 ` Marin David Condic 0 siblings, 1 reply; 47+ messages in thread From: Matthew Heaney @ 2003-08-02 3:40 UTC (permalink / raw) "Marin David Condic" <nobody@noplace.com> wrote in message news:3F2A5303.6080902@noplace.com... > > IMHO, something like the DOM - an OOD expression of a desired > functionality - is exactly the reason Ada invented tagged records. The purpose of tagged records is to implement dynamic binding. If the problem calls for dynamic binding, then maybe a tagged type is appropriate (but maybe not). If the problem does not require dynamic binding of operations, then you probably don't need tagged types. > To > implement it with discriminated records (a feature I always found to > have too many "gotchas!" built into it anyway) seems awkward and clumsy. > If you don't think using tagged records to implement something like this > design is appropriate, what are you saving them for? :-) I have never had a problem with discriminated records, so I don't know what "gotchas" you're referring to. Tagged types are one tool among many. Use them when they make sense. It probably doesn't make sense to use a tagged type when there is no dynamic binding. Even when there is dynamic binding, using case statements or subprogram pointers is often simpler. It depends on the problem. Note that the Charles library implements the full view of the container type as tagged, but only to add controlledness to the type, so that memory management is automatic. The partial view of the type is not tagged, and there is no dynamic binding. http://home.earthlink.net/~matthewjheaney/charles/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-02 3:40 ` Matthew Heaney @ 2003-08-02 12:08 ` Marin David Condic 2003-08-02 14:46 ` Matthew Heaney 2003-08-03 16:42 ` Matthew Heaney 0 siblings, 2 replies; 47+ messages in thread From: Marin David Condic @ 2003-08-02 12:08 UTC (permalink / raw) So things like type extension don't count? :-) I see tagged types as the way to fully implement the Object Oriented paradigm in Ada. Other mechanisms in Ada could be used to support parts of the OO paradigm - sometimes they have to be brutally flogged into that service - but none really creates the full OO paradigm as do tagged types. Not all programs require OO nor are they best expressed in the OO method. I work on software like that every day. But if you have an OO design, I'd think that trying to beat it into submission with the blunt instrument of a discriminated record is not the best approach. If it is an OO design, create an OO implementation with the correct Ada idiom for that - the tagged record and its surrounding package components. MDC Matthew Heaney wrote: > > > The purpose of tagged records is to implement dynamic binding. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "In general the art of government consists in taking as much money as possible from one class of citizens to give to the other." -- Voltaire ====================================================================== ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-02 12:08 ` Marin David Condic @ 2003-08-02 14:46 ` Matthew Heaney 2003-08-02 21:25 ` Ed Falis 2003-08-05 19:59 ` Marin David Condic 2003-08-03 16:42 ` Matthew Heaney 1 sibling, 2 replies; 47+ messages in thread From: Matthew Heaney @ 2003-08-02 14:46 UTC (permalink / raw) "Marin David Condic" <nobody@noplace.com> wrote in message news:3F2BA9C8.9030700@noplace.com... > So things like type extension don't count? :-) The type extension exists in order to implement the dynamically bound operation. > I see tagged types as the way to fully implement the Object Oriented > paradigm in Ada. Other mechanisms in Ada could be used to support parts > of the OO paradigm - sometimes they have to be brutally flogged into > that service - but none really creates the full OO paradigm as do tagged > types. Except for the private derivation needed to get controlledness, Charles manages to be "object-oriented" without using inheritance. There is no brutal flogging. In fact Charles could be ported to Ada83 without much pain. > Not all programs require OO nor are they best expressed in the OO > method. I work on software like that every day. But if you have an OO > design, I'd think that trying to beat it into submission with the blunt > instrument of a discriminated record is not the best approach. If it is > an OO design, create an OO implementation with the correct Ada idiom for > that - the tagged record and its surrounding package components. Tagged types are one tool among many. Use the tool that makes sense for your problem. If it's appropriate to use a tagged type, then by all means do so. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-02 14:46 ` Matthew Heaney @ 2003-08-02 21:25 ` Ed Falis 2003-08-05 19:59 ` Marin David Condic 1 sibling, 0 replies; 47+ messages in thread From: Ed Falis @ 2003-08-02 21:25 UTC (permalink / raw) On Sat, 02 Aug 2003 14:46:36 GMT "Matthew Heaney" <matthewjheaney@earthlink.net> wrote: > Except for the private derivation needed to get controlledness, > Charles manages to be "object-oriented" without using inheritance. > There is no brutal flogging. > This is an interesting discussion. I think part of it depends on how extensively one uses inheritance to deal with variation. For instance, using Eiffel, with its (IMO) very expressive facilities for multiple inheritance, one is likely to use inheritance more than one would in Ada, which tends to leave a lot of plumbing hanging out to use the same kind of style. I had a very interesting experience in this regard only recently. I wanted to develop some test suites for a restricted Ada runtime system, intended for DO-178B Level B applications. I wanted to use AUnit for it. But when I wrote AUnit, I used an Eiffel-style lists package that was implemented over tagged types: no way was it going to run in that environment. I decided to try out Charles for the same purpose, and it worked admirably. No changes necessary. - Ed ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-02 14:46 ` Matthew Heaney 2003-08-02 21:25 ` Ed Falis @ 2003-08-05 19:59 ` Marin David Condic 1 sibling, 0 replies; 47+ messages in thread From: Marin David Condic @ 2003-08-05 19:59 UTC (permalink / raw) You can use type extension without adding anything "dynamic" to a system. Its a perfectly good way of adding things to a record type that already exists. The "dynamic" part happens only if you are using dispatching in some way. AFAIK, you can add subprograms with a type extension that can be determined statically. They just can't be used as class-wide operations. People have different styles. I don't object to discriminated records totally - it can be made to work and in some cases, it is a reasonable reflection of a given design. However, since Ada got tagged records and is capable of making classes, I think it has diminished the need for things like discriminated records because tagged records are so much more powerful and they address the same need. In the case of the XML DOM, I thought they were a more natural reflection of the design. You may have done it differently and it may work fine, but I don't think it lines up well with the intent of the DOM spec - at least not as well as tagged records would have. MDC Matthew Heaney wrote: > > > The type extension exists in order to implement the dynamically bound > operation. > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "In general the art of government consists in taking as much money as possible from one class of citizens to give to the other." -- Voltaire ====================================================================== ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-02 12:08 ` Marin David Condic 2003-08-02 14:46 ` Matthew Heaney @ 2003-08-03 16:42 ` Matthew Heaney 2003-08-04 8:04 ` Dmitry A. Kazakov 2003-08-05 20:05 ` Marin David Condic 1 sibling, 2 replies; 47+ messages in thread From: Matthew Heaney @ 2003-08-03 16:42 UTC (permalink / raw) "Marin David Condic" <nobody@noplace.com> wrote in message news:3F2BA9C8.9030700@noplace.com... > > I see tagged types as the way to fully implement the Object Oriented > paradigm in Ada. To help convince you that inheritance-oriented programming is not the solution to all problems, I suggest you read this interview with Stepanov: http://www.stlport.org/resources/StepanovUSA.html Here are the money quotes: "I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong." Asked what he thought of Java, he replied that "...It keeps all the stuff that I never use in C++ - inheritance, virtuals - OO gook - and removes the stuff that I find useful." He says later that "...I spent years trying to find some use for inheritance and virtuals, before I understood why that mechanism was fundamentally flawed and should not be used." ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-03 16:42 ` Matthew Heaney @ 2003-08-04 8:04 ` Dmitry A. Kazakov 2003-08-05 8:00 ` Georg Bauhaus 2003-08-05 20:05 ` Marin David Condic 1 sibling, 1 reply; 47+ messages in thread From: Dmitry A. Kazakov @ 2003-08-04 8:04 UTC (permalink / raw) On Sun, 03 Aug 2003 16:42:26 GMT, "Matthew Heaney" <matthewjheaney@earthlink.net> wrote: >"Marin David Condic" <nobody@noplace.com> wrote in message >news:3F2BA9C8.9030700@noplace.com... >> >> I see tagged types as the way to fully implement the Object Oriented >> paradigm in Ada. > >To help convince you that inheritance-oriented programming is not the >solution to all problems, I suggest you read this interview with Stepanov: > >http://www.stlport.org/resources/StepanovUSA.html > >Here are the money quotes: > >"I find OOP technically unsound. It attempts to decompose the world in terms >of interfaces that vary on a single type. To deal with the real problems you >need multisorted algebras - families of interfaces that span multiple types. >I find OOP philosophically unsound. It claims that everything is an object. >Even if it is true it is not very interesting - saying that everything is an >object is saying nothing at all. I find OOP methodologically wrong." > >Asked what he thought of Java, he replied that "...It keeps all the stuff >that I never use in C++ - inheritance, virtuals - OO gook - and removes the >stuff that I find useful." > >He says later that "...I spent years trying to find some use for inheritance >and virtuals, before I understood why that mechanism was fundamentally >flawed and should not be used." 1. What Stepanov addresses is actually not OO, or better to say not ADT, but its existing implementations in the languages like C++ and Ada. 2. Maybe dynamic polymorphism is flawed, but then the static has to be as well. 3. To say that everything is object, was indeed silly, but this was rather a mantra than a concept. I hope that nobody took it seriosly. (:-)) Fortunately, presently one hears this rubbish not so frequently as it was pair years ago. I think that his decision to switch to macros (aka C++ templates) was caused merely by the state of ADT, which was too underdeveloped then and remains underdeveloped now. It is easy to see that "families of interfaces" is again an interface and that "multiple types" constitute a type [a class-wide type, many thanks to Ada for this clarification]. Anyway, what could be an alternative? An untyped language? Who wants that again? --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-04 8:04 ` Dmitry A. Kazakov @ 2003-08-05 8:00 ` Georg Bauhaus 2003-08-05 11:46 ` Dmitry A. Kazakov 0 siblings, 1 reply; 47+ messages in thread From: Georg Bauhaus @ 2003-08-05 8:00 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : Anyway, what could be an alternative? Signatures? ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-05 8:00 ` Georg Bauhaus @ 2003-08-05 11:46 ` Dmitry A. Kazakov 2003-08-05 13:34 ` Georg Bauhaus 0 siblings, 1 reply; 47+ messages in thread From: Dmitry A. Kazakov @ 2003-08-05 11:46 UTC (permalink / raw) On Tue, 5 Aug 2003 08:00:08 +0000 (UTC), Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> wrote: >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >: Anyway, what could be an alternative? > >Signatures? Isn't signature just another word for interface? Does not a set of subroutines with compatible signatures constitute an interface for some abstract/real type? One could long for a better way to describe and manage interfaces, but there is no real alternative to them. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-05 11:46 ` Dmitry A. Kazakov @ 2003-08-05 13:34 ` Georg Bauhaus 2003-08-06 9:03 ` Dmitry A. Kazakov 2003-08-07 12:28 ` Matthew Heaney 0 siblings, 2 replies; 47+ messages in thread From: Georg Bauhaus @ 2003-08-05 13:34 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : Isn't signature just another word for interface? Does not a set of : subroutines with compatible signatures constitute an interface for : some abstract/real type? One could long for a better way to describe : and manage interfaces, but there is no real alternative to them. You don't need to know about them during the design process, but you can construct "signature instances" like so: generic type X is private; function count(thing: X) return Natural; procedure stretch(thing: in out X); ... and then instantiate "..." with whatever actuals seem fit. This doesn't require that the provider of the units from which X, count, etc. are taken, has to know beforehand that his/her types, functions, or whatever will be used this way. Actually, you can pass operations of a tagged type as actuals. Can this be done with virtual member functions in C++? Georg ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-05 13:34 ` Georg Bauhaus @ 2003-08-06 9:03 ` Dmitry A. Kazakov 2003-08-06 18:15 ` signature like constructions (was: Re: XML DOM Binding for Ada 95 - matter of style) Georg Bauhaus 2003-08-07 12:52 ` XML DOM Binding for Ada 95 - matter of style Matthew Heaney 2003-08-07 12:28 ` Matthew Heaney 1 sibling, 2 replies; 47+ messages in thread From: Dmitry A. Kazakov @ 2003-08-06 9:03 UTC (permalink / raw) On Tue, 5 Aug 2003 13:34:09 +0000 (UTC), Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> wrote: >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >: Isn't signature just another word for interface? Does not a set of >: subroutines with compatible signatures constitute an interface for >: some abstract/real type? One could long for a better way to describe >: and manage interfaces, but there is no real alternative to them. > >You don't need to know about them during the design process, Really? >but you can construct "signature instances" like so: > >generic > type X is private; > function count(thing: X) return Natural; > procedure stretch(thing: in out X); >... > >and then instantiate "..." with whatever actuals seem fit. >This doesn't require that the provider of the units from which >X, count, etc. are taken, has to know beforehand that his/her types, >functions, or whatever will be used this way. It is an illusion of freedom. In fact, from the specification above, it is clear that X is private, i.e. has a default constructor, a copy constructor, an assignment, count, stretch. So it is pretty much said about possible X, and it is in fact an *interface*. Then when you instantiate, the actual type is checked against that interface. Now, how it differs from interface inheritance, except from techical details? It does not. Keep in mind, that present implementations of inheritance are very limited in many aspects. You cannot create supertypes, disallow methods, have by-value semantics, have multiple dispatch etc. I do not argue that things like STL can be implemented without templates. What I am saying is that it will be possible in the future with advantages of being: - safer - clearer - far more checkable - as efficient as macros in static cases - working in dynamic cases (with some bounded memory/time penalty) >Actually, you can pass operations of a tagged type as actuals. Yes, this is a great disadvantage of generics. You have to explicitly specify everything you need. Compare it with inheritance, you just specify a base type. This is because Ada's generics try to pretend to have some contract. C++ does not, it openly says that what you become is your own business. BTW, C++ is consistent in its approach: int Something; // Maybe it has enough range to keep our values, launch and enjoy! template <class Element>void Sort ...; // Guess, what I have used here this week, "<=" or ">="? >Can this be done with virtual member functions in C++? You mean to pass a dispatching operation to a template? --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 47+ messages in thread
* signature like constructions (was: Re: XML DOM Binding for Ada 95 - matter of style) 2003-08-06 9:03 ` Dmitry A. Kazakov @ 2003-08-06 18:15 ` Georg Bauhaus 2003-08-07 10:12 ` Dmitry A. Kazakov 2003-08-07 12:52 ` XML DOM Binding for Ada 95 - matter of style Matthew Heaney 1 sibling, 1 reply; 47+ messages in thread From: Georg Bauhaus @ 2003-08-06 18:15 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: : On Tue, 5 Aug 2003 13:34:09 +0000 (UTC), Georg Bauhaus : <sb463ba@d2-hrz.uni-duisburg.de> wrote: : :>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: :>: Isn't signature just another word for interface? Does not a set of :>: subroutines with compatible signatures constitute an interface for :>: some abstract/real type? One could long for a better way to describe :>: and manage interfaces, but there is no real alternative to them. :> :>You don't need to know about them during the design process, : Really? Yes. See below. :>but you can construct "signature instances" like so: :> :>generic :> type X is private; :> function count(thing: X) return Natural; :> procedure stretch(thing: in out X); :>... :> :>and then instantiate "..." with whatever actuals seem fit. :>This doesn't require that the provider of the units from which :>X, count, etc. are taken, has to know beforehand that his/her types, :>functions, or whatever will be used this way. : : It is an illusion of freedom. In fact, from the specification above, : it is clear that X is private, i.e. has a default constructor, a copy : constructor, an assignment, count, stretch. So it is pretty much said : about possible X, and it is in fact an *interface*. Uhm, that says something about the formals, but not everything about the things you put inside the "signature package". If you have generic type X is private; with function count(thing: X) return Natural; package Foo is type Y is record nfrob: Natural; wrapped: X; end record; -- ... function calculate_mythical_number(item: Y) return Float; -- this is the interesting measure of all the incompatible -- X items in the world end Foo; Then when you instantiate, this package will offer an interface to Y, in a general sense, because it is a natural thing for a package to have one ;-). But ... : instantiate, the actual type is checked against that interface. Uhm, against that interface is not what I've had in mind, I think I have failed to explain. So, instead, the interface is the "result" of the "signature package" instantiation. : how it differs from interface inheritance, except from techical : details? It does not. I think it does, if you think of this kind of interface. Anything that can be used as actual for X (and count) can be used without having to fit in some inheritance tree (or graph). It can, but it _need_ not, which IIRC is the point of this kind of "signature". You construct items that have some interface by way of the subprograms of the *instance*. The provider of X does _not_ have to know this. :>Actually, you can pass operations of a tagged type as actuals. : : Yes, this is a great disadvantage of generics. You have to explicitly : specify everything you need. In view of the above, how is this a disadvantage? In another view, if you want something, call it T, that can be compared to another T, or which needs to be hashed, then the generic actuals for comparison or hashing need not be associated with T, which I find can be an advantage. The provider of T does not have to make T "comparable" or "hashable" by adding operations to T. :>Can this be done with virtual member functions in C++? : : You mean to pass a dispatching operation to a template? Exactly. (This way, you get a collection of virtual "service routines" from actual parameters, which can be used to provide the functionality needed in the package's subprograms.) Georg ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions (was: Re: XML DOM Binding for Ada 95 - matter of style) 2003-08-06 18:15 ` signature like constructions (was: Re: XML DOM Binding for Ada 95 - matter of style) Georg Bauhaus @ 2003-08-07 10:12 ` Dmitry A. Kazakov 2003-08-07 16:22 ` signature like constructions Georg Bauhaus 0 siblings, 1 reply; 47+ messages in thread From: Dmitry A. Kazakov @ 2003-08-07 10:12 UTC (permalink / raw) On Wed, 6 Aug 2003 18:15:03 +0000 (UTC), Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> wrote: >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >: On Tue, 5 Aug 2003 13:34:09 +0000 (UTC), Georg Bauhaus >: <sb463ba@d2-hrz.uni-duisburg.de> wrote: >: >:>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >:>: Isn't signature just another word for interface? Does not a set of >:>: subroutines with compatible signatures constitute an interface for >:>: some abstract/real type? One could long for a better way to describe >:>: and manage interfaces, but there is no real alternative to them. >:> >:>You don't need to know about them during the design process, > >: Really? > >Yes. See below. Iiterally read - no interfaces needed in a design process! Maybe, you meant a hacking process. (:-)) >:>but you can construct "signature instances" like so: >:> >:>generic >:> type X is private; >:> function count(thing: X) return Natural; >:> procedure stretch(thing: in out X); >:>... >:> >:>and then instantiate "..." with whatever actuals seem fit. >:>This doesn't require that the provider of the units from which >:>X, count, etc. are taken, has to know beforehand that his/her types, >:>functions, or whatever will be used this way. >: >: It is an illusion of freedom. In fact, from the specification above, >: it is clear that X is private, i.e. has a default constructor, a copy >: constructor, an assignment, count, stretch. So it is pretty much said >: about possible X, and it is in fact an *interface*. > >Uhm, that says something about the formals, but not everything about >the things you put inside the "signature package". If you have > >generic > type X is private; > with function count(thing: X) return Natural; >package Foo is > > type Y is record > nfrob: Natural; > wrapped: X; > end record; > > -- ... > function calculate_mythical_number(item: Y) return Float; > -- this is the interesting measure of all the incompatible > -- X items in the world >end Foo; > >Then when you instantiate, this package will offer an interface >to Y, in a general sense, because it is a natural thing for a >package to have one ;-). But ... How this is better than (if were possible) type X is abstract ...; function count (thing: X) return Natural is abstract; type Y is record nfrob : Natural; wrapped : X'Class; end record; You claim that different X are incompatible, but have you asked yourself, to what they are? The interface tells nothing about it. On the contrary it tells how they *are* compatible, they all are copyable, have "count" etc. Now the only incompatibility is a limitation that a class-wide object cannot be a member. But this has nothing to do with interfaces. It is an implementation detail. And after all why not: type Y is new X with record nfrob : Natural; end record; >: instantiate, the actual type is checked against that interface. > >Uhm, against that interface is not what I've had in mind, I think >I have failed to explain. So, instead, the interface is the "result" >of the "signature package" instantiation. I hope you do not propose "write-first" approach. (:-)) Interface is not a result, it is the starting point when we are thinking about a program. You can either formalize it in the code if a language helps, or leave it for a reader to try to figure interface out. >: how it differs from interface inheritance, except from techical >: details? It does not. > >I think it does, if you think of this kind of interface. >Anything that can be used as actual for X (and count) can >be used without having to fit in some inheritance tree (or graph). If you use it, then it fits. If it does not, then you cannot use it. It is no matter whether you state it explicitly or implicitly. But it well matters for a reader. >It can, but it _need_ not, which IIRC is the point of this kind >of "signature". You construct items that have some interface >by way of the subprograms of the *instance*. The provider of X >does _not_ have to know this. I do not see any difference. With inheritance the provider does not know whether you derive or not. Instantiation can be viewed as sort of inheritance from some implicitly declared abstract type with a consequent type cloning (to avoid mixing of siblings). >:>Actually, you can pass operations of a tagged type as actuals. >: >: Yes, this is a great disadvantage of generics. You have to explicitly >: specify everything you need. > >In view of the above, how is this a disadvantage? My generic package implementing fuzzy numbers has about 30 formal parameters. >In another view, if you want something, call it T, that can be >compared to another T, or which needs to be hashed, then the >generic actuals for comparison or hashing need not be associated >with T, which I find can be an advantage. The provider of T does not >have to make T "comparable" or "hashable" by adding operations >to T. My point is, "to provide a function to compare" = "to make comparable". It is SAME. You might object, that one should foresee whether a type should be comparable or that making comparable is "global". This all are just limitations of ADT implementations we presently have. For example, with supertyping and multiple inheritance you can always make one given type a subtype of another given type. >:>Can this be done with virtual member functions in C++? >: >: You mean to pass a dispatching operation to a template? > >Exactly. (This way, you get a collection of virtual >"service routines" from actual parameters, which >can be used to provide the functionality needed in the package's >subprograms.) But a class-wide parameter already does the trick. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-07 10:12 ` Dmitry A. Kazakov @ 2003-08-07 16:22 ` Georg Bauhaus 2003-08-08 8:31 ` Dmitry A. Kazakov 0 siblings, 1 reply; 47+ messages in thread From: Georg Bauhaus @ 2003-08-07 16:22 UTC (permalink / raw) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: Newsgroups: comp.lang.ada References: <slrnbihv85.4jd.randhol+abuse@kiuk0152.chembio.ntnu.no> <apGWa.1581$jp.254@newsread4.news.pas.earthlink.net> <3F2BA9C8.9030700@noplace.com> <SXaXa.5251$jg7.4768@newsread3.news.pas.earthlink.net> <ti3sivgstvvmh3j7399j0prvlifsm8j5it@4ax.com> <bgno68$lpd$1@a1-hrz.uni-duisburg.de> <qp5viv8jdbasoc2s83hrrv0f4mtfvp0mnn@4ax.com> <bgoboh$pae$1@a1-hrz.uni-duisburg.de> <egd1jvc6pe888e4ug683tis6a5q5ua12ml@4ax.com> <bgrgj7$38u$1@a1-hrz.uni-duisburg.de> <jr24jv8sdug2s1ru7kf6vkspj8kh9oltvj@4ax.com> Organization: GMUGHDU User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/831)) Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: :>:>You don't need to know about them during the design process, :> :>: Really? :> :>Yes. See below. : : Iiterally read - no interfaces needed in a design process! Maybe, you : meant a hacking process. (:-)) Why should I add hash(x: Point) to the interface of a 2D point? In the generics case, the "interface of the type", and the "interface of the package instance" need not be too closely coupled. Hashing can be provided elsewhere. (Matthew Heaney has explained that you might anticipate possible uses of your types, but do I have to expect and design my (x, y) pairs so that they can become part of a data structure that requires a hash value for them? Just to stay in inheritance land?) :>generic :> type X is private; :> with function count(thing: X) return Natural; :>package Foo is :> :> type Y is record :> nfrob: Natural; :> wrapped: X; :> end record; :> :> -- ... :> function calculate_mythical_number(item: Y) return Float; :> -- this is the interesting measure of all the incompatible :> -- X items in the world :>end Foo; :> :>Then when you instantiate, this package will offer an interface :>to Y, in a general sense, because it is a natural thing for a :>package to have one ;-). But ... : : How this is better than (if were possible) : type X is abstract ...; : function count (thing: X) return Natural is abstract; It is better because it is possible :-) : You claim that different X are incompatible, but have you asked : yourself, to what they are? The interface tells nothing about it. On : the contrary it tells how they *are* compatible, they all are : copyable, have "count" etc. No. Count need not be an operation of X. It might as well be implemented elsewhere, for example using two inquiry functions from the "interface" of the actual for X, or three from another, unrelated actual. Also, generic type X is private; type Y is private; with function between(this_one: X; that_one: Y) return Float; package ... How do I do this using your next example, and do it in Ada, that is, not in CLOS, Smalltalk, or Haskell, with MI of interfaces? : type Y is new X with record : nfrob : Natural; : end record; :>Uhm, against that interface is not what I've had in mind, I think :>I have failed to explain. So, instead, the interface is the "result" :>of the "signature package" instantiation. : : I hope you do not propose "write-first" approach. (:-)) Interface is : not a result, it is the starting point when we are thinking about a : program. I design the "signature package", which has the interface I want (mostly after the keyword "package"). The focus is not necessarily on the formal type's restrictions. :>Anything that can be used as actual for X (and count) can :>be used without having to fit in some inheritance tree (or graph). : : If you use it, then it fits. It need not even be of a tagged type, so why will it fit? And if you consider X and Y above, they need not be part of the same type tree. Say we had full MI. Would you prefer to to have type T is new X and Y with private; -- not Ada function between(combined: T) return Float; and then name clash resolution all over the place? :>:>Actually, you can pass operations of a tagged type as actuals. :>: :>: Yes, this is a great disadvantage of generics. You have to explicitly :>: specify everything you need. :> :>In view of the above, how is this a disadvantage? : : My generic package implementing fuzzy numbers has about 30 formal : parameters. Your type will have about 30 things delcared, too, won't it? (I'm not advocating the replacement of OO with generics BTW, just trying to point out that you can, conceptually, escape the type hierarchy using generics, and then use the instance's subprograms, thinking of them as an interface.) : My point is, "to provide a function to compare" = "to make : comparable". It is SAME. : : You might object, that one should foresee whether a type should be : comparable or that making comparable is "global". Indeed I will will be forced to foresee this in Ada. : This all are just : limitations of ADT implementations we presently have. For example, : with supertyping and multiple inheritance you can always make one : given type a subtype of another given type. Some Questions: AFAICS, there might be multiple inheritance of interfaces, but not MI in Ada 200X? If I don't want to see but three operation of type X, and two of Y, how can I limit the visibility of the others? Use export lists like in Eiffel? How about libraries without the possibility of changing the base types? Georg ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-07 16:22 ` signature like constructions Georg Bauhaus @ 2003-08-08 8:31 ` Dmitry A. Kazakov 2003-08-08 10:12 ` Robert I. Eachus 0 siblings, 1 reply; 47+ messages in thread From: Dmitry A. Kazakov @ 2003-08-08 8:31 UTC (permalink / raw) On Thu, 7 Aug 2003 16:22:34 +0000 (UTC), Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> wrote: >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >Newsgroups: comp.lang.ada >References: <slrnbihv85.4jd.randhol+abuse@kiuk0152.chembio.ntnu.no> <apGWa.1581$jp.254@newsread4.news.pas.earthlink.net> <3F2BA9C8.9030700@noplace.com> <SXaXa.5251$jg7.4768@newsread3.news.pas.earthlink.net> <ti3sivgstvvmh3j7399j0prvlifsm8j5it@4ax.com> <bgno68$lpd$1@a1-hrz.uni-duisburg.de> <qp5viv8jdbasoc2s83hrrv0f4mtfvp0mnn@4ax.com> <bgoboh$pae$1@a1-hrz.uni-duisburg.de> <egd1jvc6pe888e4ug683tis6a5q5ua12ml@4ax.com> <bgrgj7$38u$1@a1-hrz.uni-duisburg.de> <jr24jv8sdug2s1ru7kf6vkspj8kh9oltvj@4ax.com> >Organization: GMUGHDU >User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/831)) > >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >:>:>You don't need to know about them during the design process, >:> >:>: Really? >:> >:>Yes. See below. >: >: Iiterally read - no interfaces needed in a design process! Maybe, you >: meant a hacking process. (:-)) > >Why should I add hash(x: Point) to the interface of a 2D point? You should not. >In the generics case, the "interface of the type", and the "interface >of the package instance" need not be too closely coupled. >Hashing can be provided elsewhere. No you create a *new* interface derived from one of 2D point. It is absolutely same as you do with instantiations: A. Declaration of an interface: 1a. Generics: generic type X is private; procedure Hash (Item : X); -- X has Hash procedure Foo (Item : X); -- Foo uses Hash This describes an interface or a class of types having Hash. It also declares a class-wide (works for all class) procedure Foo. 2a. Tagged: type X is abstract tagged ...; procedure Hash (Item : X) is abstract; -- X has Hash procedure Foo (Item : X'Class); -- Foo uses Hash This also describes an interface. X'Class is a closure of a class of types having Hash. Foo is a class-wide procedure. B. Use of an interface: type Point_2D is ...; 1b. Generics: procedure Hash (Item : Point_2D); procedure NewFoo is new Foo (X, Hash); This makes Point2D an element of the class and instantiates Foo. 2b. Tagged (non-Ada!) type Hashed_Point_2D is new subtype X and supertype Point_2D; procedure Hash (Item : Hashed_Point_2D); This creates a new interface from two interfaces of Point_2D and of X. Hashed_Point_2D is both a subtype of X and a supertype of Point_2D, so Point_2D in effect becomes a subtype of X in the scope of Hashed_Point_2D. And thus Foo can be called on Point_2D in that scope. >(Matthew Heaney has explained that you might anticipate possible >uses of your types, but do I have to expect and design my (x, y) pairs >so that they can become part of a data structure that requires a >hash value for them? Just to stay in inheritance land?) Of course no, it should be dynamic, see above. >:>generic >:> type X is private; >:> with function count(thing: X) return Natural; >:>package Foo is >:> >:> type Y is record >:> nfrob: Natural; >:> wrapped: X; >:> end record; >:> >:> -- ... >:> function calculate_mythical_number(item: Y) return Float; >:> -- this is the interesting measure of all the incompatible >:> -- X items in the world >:>end Foo; >:> >:>Then when you instantiate, this package will offer an interface >:>to Y, in a general sense, because it is a natural thing for a >:>package to have one ;-). But ... >: >: How this is better than (if were possible) > >: type X is abstract ...; >: function count (thing: X) return Natural is abstract; > >It is better because it is possible :-) Hey, I have already said that STL is presently impossible with tagged types! Stepanov's point quoted by Matthew was that ADT is *inherently* flawed and unsuitable for generic (class-wide) programming. My point is that generic programming could and should be done without generics using class-wide types instead. >: You claim that different X are incompatible, but have you asked >: yourself, to what they are? The interface tells nothing about it. On >: the contrary it tells how they *are* compatible, they all are >: copyable, have "count" etc. > >No. Count need not be an operation of X. It might as well be implemented >elsewhere, for example using two inquiry functions from the "interface" >of the actual for X, or three from another, unrelated actual. Count is an operation of X if it takes an argument of X. >Also, > >generic > type X is private; > type Y is private; > with function between(this_one: X; that_one: Y) return Float; >package ... > >How do I do this using your next example, and do it in Ada, that is, >not in CLOS, Smalltalk, or Haskell, with MI of interfaces? That is multiple dispatch, it has to be supported. >: type Y is new X with record >: nfrob : Natural; >: end record; > >:>Uhm, against that interface is not what I've had in mind, I think >:>I have failed to explain. So, instead, the interface is the "result" >:>of the "signature package" instantiation. >: >: I hope you do not propose "write-first" approach. (:-)) Interface is >: not a result, it is the starting point when we are thinking about a >: program. > >I design the "signature package", which has the interface >I want (mostly after the keyword "package"). The focus is not >necessarily on the formal type's restrictions. But you have to have some picture in mind, which types should work with the package. The set of all those types is a type class. Its closure is a class-wide type. Description of its root type is an interface. >:>Anything that can be used as actual for X (and count) can >:>be used without having to fit in some inheritance tree (or graph). >: >: If you use it, then it fits. > >It need not even be of a tagged type, so why will it fit? Every specific type has to be a tagged type, even Boolean. Tagged here means that Boolean'Class has a tag, Boolean itself has no tag. Embedded tags was a mistake. >And if you consider X and Y above, they need not be part of the same >type tree. With multiple dispatch you can dispatch on type tuples. >Say we had full MI. Would you prefer to to have > > type T is new X and Y with private; -- not Ada > function between(combined: T) return Float; > >and then name clash resolution all over the place? Generics have more problems with that, because they rely on overloading, which is far less controllable than overriding [could be]. >:>:>Actually, you can pass operations of a tagged type as actuals. >:>: >:>: Yes, this is a great disadvantage of generics. You have to explicitly >:>: specify everything you need. >:> >:>In view of the above, how is this a disadvantage? >: >: My generic package implementing fuzzy numbers has about 30 formal >: parameters. > >Your type will have about 30 things delcared, too, won't it? No, the number comes from a geometric explosion of signatures when several interfaces are mixed: 1. plain number 2. interval 3. fuzzy set With proper ADT I could just use that interfaces which exist anyway. The problem is that generic interfaces cannot be reused in new interfaces. >(I'm not advocating the replacement of OO with generics BTW, >just trying to point out that you can, conceptually, escape the >type hierarchy using generics, and then use the instance's >subprograms, thinking of them as an interface.) This is a traditional vew, which I disagree. Sets of subprograms constitute type interfaces no matter whether you declare it explicitly. A type hierarchy also exists independently on our wishes. Types are related, and a binary relation is a graph. >: My point is, "to provide a function to compare" = "to make >: comparable". It is SAME. >: >: You might object, that one should foresee whether a type should be >: comparable or that making comparable is "global". > >Indeed I will will be forced to foresee this in Ada. > >: This all are just >: limitations of ADT implementations we presently have. For example, >: with supertyping and multiple inheritance you can always make one >: given type a subtype of another given type. > >Some Questions: > >AFAICS, there might be multiple inheritance of interfaces, but not MI >in Ada 200X? It is difficult to believe in. See below. >If I don't want to see but three operation of type X, and two of Y, >how can I limit the visibility of the others? Operation disallowing. >Use export lists like in Eiffel? > >How about libraries without the possibility of changing the base types? One could specify that a particular operation cannot be overriden. --- The actual problem is that we know very little about future ADT. Before we start to implement MI, MD, supertyping, op-disallowing etc in Ada, we should clearly understand how it supposed to work. We cannot just make Ada++ and leave programmers with that. It should be consistent, easy to understand and efficient. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-08 8:31 ` Dmitry A. Kazakov @ 2003-08-08 10:12 ` Robert I. Eachus 2003-08-08 13:29 ` Dmitry A. Kazakov 2003-08-09 8:32 ` Simon Wright 0 siblings, 2 replies; 47+ messages in thread From: Robert I. Eachus @ 2003-08-08 10:12 UTC (permalink / raw) Dmitry A. Kazakov wrote: > The actual problem is that we know very little about future ADT. > Before we start to implement MI, MD, supertyping, op-disallowing etc > in Ada, we should clearly understand how it supposed to work. We > cannot just make Ada++ and leave programmers with that. It should be > consistent, easy to understand and efficient. I definitely agree, but I think you are heading in the wrong direction. Multiple inheritance of interfaces will probably be a feature of Ada0Y, but the issues being discussed in this article will not be 'fixed' by interface inheritance. It is the old saw about if all you have is a hammer, every problem starts to look like a nail. But since Ada already offers several different fasteners, part of the solution has to be educating users. Let's look at the example from the right perspective. The problem is not "I need to be able to associate hash values with 2D points." That is a solution. The problem statement/requirement looks something like: The system shall have a representation of cartesian points with assoicated data for... There shall a method to create sets of cartesian points. There shall be an efficient method to determine if a particular point is a member of a set... Now we are getting some meat to deal with. Three issues should immediately come to mind, and should be resolved in the requirements stage: Can the co-ordinates of the cartesian point objects vary? If so, how do you determine the identity of an object? Can a particular cartesian point be a member of more than one set? If so, is there a limit on how many sets it can be a member of? Is there any requirement to easily determine whether a point is not a member of a particular set? The answer to the first question leads to two different potential solutions. It should be obvious that if the point's co-ordinates can change without losing its identity, the hash value, if that is the solution chosen, must be precalculated and stored in the object. Or the hash value has to be based on some other attribute of the object which doesn't change, perhaps its address. The second question deals with a issue going the other direction. If an object can be a member of several different sets, then any solution that embeds the links in the cartesian point objects will be at best, a kludge. The third question is one of assumptions. If the author of the requirements has a hash table implementation in mind, then there may be a 'hidden' requirement. There may be an algorithm where affirmatively determining membership is easy but the negation is hard. For example, if you use a small number of hash values pointing at linked lists, then the time to determine an element is not there will on average be twice what it is to determine that it is there. Of course, you can maintain the lists in sorted order, and the average times will be the same. In fact you could go the other way. Have two hash functions. (For this example assume that the 'real' hash function omits the last five bits.) Now the fine grained hash maps to a bit vector. If the corresponding bit is off, the point is not in the set. If it is set, then you have to walk the linked list. Now the average response to a query is much faster when the point is not in the set. If you don't ask the right question, you won't know which implementation is preferred. Only after you have resolved these requirements issues is it possible to decide what are the best data structures and relationships to use. It may be that there is a "better" solution in some language other than Ada. I got sick 20 years ago of playing the game where someone would design a problem to show off the superiority of some language or other. Then I would propose a better solution, usually stated in Ada, and they would go back to the drawing board to fix the problem statement. The people who played this game never figured out that I would always win. Not because Ada was a superior programming language, but because I was able to look at the problem WITHOUT going through the filter of a particular programming language. Of course, from their point of view, "and it must be programmed in C" would be cheating on their part. But since I and others forced to play the game were much better at finding the right algorithms and data structures because we didn't limit ourselves to a single programming view. My favorite example involved the LALR parser generator on Multics. Pat Prange was about to go through the gory effort to allow an array of Boolean data to span multiple segments. I asked why he didn't use a packed representation, and he answered at length. But once we got all the requirements written down, it turned out that the major operation on the array was a search in a particular row for the first set bit. After another half hour of discussion Pat ran off to implement the new version. To make a long story short, it used the translate and test instruction in the character string processing unit. The single instruction generated used a 512-element table to look up the first non-zero (9-bit) byte detected, and of course the values in the table were the index of the first set bit. Six lines of PL/I carefully written so the code generator would emit a single instruction! The net result was to decrease the running time for the tool by over 90%, from just over 20 minutes to generate an optimized LALR1 parser for Ada, to just under two minutes. But the point to take away is not that PL/I was great for this purpose, or Multics. I could write the same code in COBOL for an IBM mainframe, or C for an x86 or 680x0 chip. (Or in Ada, or just about any language that let you get close to the metal when necessary.) The expertise required is in first figuring out the actual machine code you want generated, then knowing the compiler internals well enough to make it happen. -- "As far as I'm concerned, war always means failure." -- Jacques Chirac, President of France "As far as France is concerned, you're right." -- Rush Limbaugh ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-08 10:12 ` Robert I. Eachus @ 2003-08-08 13:29 ` Dmitry A. Kazakov 2003-08-08 19:37 ` Robert I. Eachus 2003-08-08 23:44 ` Alexander Kopilovitch 2003-08-09 8:32 ` Simon Wright 1 sibling, 2 replies; 47+ messages in thread From: Dmitry A. Kazakov @ 2003-08-08 13:29 UTC (permalink / raw) On Fri, 08 Aug 2003 10:12:47 GMT, "Robert I. Eachus" <rieachus@attbi.com> wrote: >Dmitry A. Kazakov wrote: > >> The actual problem is that we know very little about future ADT. >> Before we start to implement MI, MD, supertyping, op-disallowing etc >> in Ada, we should clearly understand how it supposed to work. We >> cannot just make Ada++ and leave programmers with that. It should be >> consistent, easy to understand and efficient. > >I definitely agree, but I think you are heading in the wrong direction. I do not think that we really are in a big disagreement. (:-)) > Multiple inheritance of interfaces will probably be a feature of >Ada0Y, but the issues being discussed in this article will not be >'fixed' by interface inheritance. It is the old saw about if all you >have is a hammer, every problem starts to look like a nail. But since >Ada already offers several different fasteners, part of the solution has >to be educating users. > >Let's look at the example from the right perspective. The problem is >not "I need to be able to associate hash values with 2D points." That >is a solution. The problem statement/requirement looks something like: > >The system shall have a representation of cartesian points with >assoicated data for... > >There shall a method to create sets of cartesian points. > >There shall be an efficient method to determine if a particular point is >a member of a set... Yes. But the example provided by Georg, as far as I understand it, aims at a case where there is already an implementation of 2D points, which has to be reused. He wished to show that it is problematic with tagged types, but still works with generics. Your example is a case of monolitic design, all from scratch, which is clean and desirable, but becomes less and less frequent in modern times. It is a right perspective, but there is a little chance that we would climb so high. (:-)) >Now we are getting some meat to deal with. Three issues should >immediately come to mind, and should be resolved in the requirements stage: > >Can the co-ordinates of the cartesian point objects vary? If so, how do >you determine the identity of an object? Points as objects usually have no identity. Why should they have any? One of real problems of OO is overuse of objects with identity. >Can a particular cartesian point be a member of more than one set? If >so, is there a limit on how many sets it can be a member of? > >Is there any requirement to easily determine whether a point is not a >member of a particular set? > >The answer to the first question leads to two different potential >solutions. It should be obvious that if the point's co-ordinates can >change without losing its identity, the hash value, if that is the >solution chosen, must be precalculated and stored in the object. Or the >hash value has to be based on some other attribute of the object which >doesn't change, perhaps its address. > >The second question deals with a issue going the other direction. If an >object can be a member of several different sets, then any solution that >embeds the links in the cartesian point objects will be at best, a kludge. > >The third question is one of assumptions. If the author of the >requirements has a hash table implementation in mind, then there may be >a 'hidden' requirement. There may be an algorithm where affirmatively >determining membership is easy but the negation is hard. For example, >if you use a small number of hash values pointing at linked lists, then >the time to determine an element is not there will on average be twice >what it is to determine that it is there. Of course, you can maintain >the lists in sorted order, and the average times will be the same. > >In fact you could go the other way. Have two hash functions. (For this >example assume that the 'real' hash function omits the last five bits.) > Now the fine grained hash maps to a bit vector. If the corresponding >bit is off, the point is not in the set. If it is set, then you have to >walk the linked list. Now the average response to a query is much >faster when the point is not in the set. If you don't ask the right >question, you won't know which implementation is preferred. > >Only after you have resolved these requirements issues is it possible to >decide what are the best data structures and relationships to use. It >may be that there is a "better" solution in some language other than Ada. This is true, but again unrealistic in a large, distributed, long living project. In which case a "better" solution is one which requires only maintainable changes in the existing infrastructure and still works somehow... >I got sick 20 years ago of playing the game where someone would design a >problem to show off the superiority of some language or other. Then I >would propose a better solution, usually stated in Ada, and they would >go back to the drawing board to fix the problem statement. The people >who played this game never figured out that I would always win. Not >because Ada was a superior programming language, but because I was able >to look at the problem WITHOUT going through the filter of a particular >programming language. Of course, from their point of view, "and it must >be programmed in C" would be cheating on their part. But since I and >others forced to play the game were much better at finding the right >algorithms and data structures because we didn't limit ourselves to a >single programming view. > >My favorite example involved the LALR parser generator on Multics. Pat >Prange was about to go through the gory effort to allow an array of >Boolean data to span multiple segments. I asked why he didn't use a >packed representation, and he answered at length. But once we got all >the requirements written down, it turned out that the major operation on >the array was a search in a particular row for the first set bit. After >another half hour of discussion Pat ran off to implement the new >version. To make a long story short, it used the translate and test >instruction in the character string processing unit. The single >instruction generated used a 512-element table to look up the first >non-zero (9-bit) byte detected, and of course the values in the table >were the index of the first set bit. Six lines of PL/I carefully >written so the code generator would emit a single instruction! > >The net result was to decrease the running time for the tool by over >90%, from just over 20 minutes to generate an optimized LALR1 parser for >Ada, to just under two minutes. But the point to take away is not that >PL/I was great for this purpose, or Multics. I could write the same >code in COBOL for an IBM mainframe, or C for an x86 or 680x0 chip. (Or >in Ada, or just about any language that let you get close to the metal >when necessary.) The expertise required is in first figuring out the >actual machine code you want generated, then knowing the compiler >internals well enough to make it happen. This is a question of balance between understanding of the problem and understanding of the software tools used to solve it. From the dawn of computers to present day, the first component prevailed, allowing to implement "everything [problem] in anything [language]". But in a long-term perspective, I am talking about 20-100 years, the balance will definitely change, otherwise we will be unable to maintain the complexity of software [not the algorithms, note]. It will be a virtual reality with its own virtual problems, if you wish. (:-)) And the question is whether templates are the right tool to deal with ever increasing complexitiy. I do not think so. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-08 13:29 ` Dmitry A. Kazakov @ 2003-08-08 19:37 ` Robert I. Eachus 2003-08-09 0:58 ` Alexander Kopilovitch 2003-08-11 10:25 ` Dmitry A. Kazakov 2003-08-08 23:44 ` Alexander Kopilovitch 1 sibling, 2 replies; 47+ messages in thread From: Robert I. Eachus @ 2003-08-08 19:37 UTC (permalink / raw) Dmitry A. Kazakov wrote: > I do not think that we really are in a big disagreement. (:-)) Agreed. I wasn't really picking on you, but targeting the discussion as a whole. > Yes. But the example provided by Georg, as far as I understand it, > aims at a case where there is already an implementation of 2D points, > which has to be reused. He wished to show that it is problematic with > tagged types, but still works with generics. > > Your example is a case of monolitic design, all from scratch, which is > clean and desirable, but becomes less and less frequent in modern > times. It is a right perspective, but there is a little chance that we > would climb so high. (:-)) Ah, here we do disagree. When the requirements change, that is not a reason not to understand and document the current requirements. And if one of those requirements is to live within a body of existing code, that is from one point of view just another requirement. Of course, when I do requirements analysis, as far as I am concerned, figuring out which requirements are likely to change and preparing for that evolution is part of the process. This is why I keep saying you should program in the problem space rather than some solution space. The problem space evolves much more slowly than the problems you are asked to solve. > This is true, but again unrealistic in a large, distributed, long > living project. In which case a "better" solution is one which > requires only maintainable changes in the existing infrastructure and > still works somehow... See above. Incidently, another issue that should never be overlooked in the design process is version skew. If I write a program in Ada that uses say Charles and gtkAda, that is three potential versions to worry about (Ada compiler, Charles, and gtkAda). That is three potential versions that may change and get out of alignment, and that is about the limit for anything you are going to maintain. Since the potential version conflicts increase as n*(n+1)/2. So with just the compiler, that is 1, with two libraries as above, that is 6, when you get to four interfaces, and the OS interface if you program to it counts as well, that is 15, and next to impossible to keep up with. This is one reason I argued in favor of the Annexes in Ada 95, each Annex could eliminate one version from that equation. In the next version I hope to see a database binding, perhaps to ODBC added. I'd like to see a standard graphics library as well, but I don't think we are to the point where that can happen. (And a container library will surely happen, I hope it is Charles.) There is nothing wrong with deciding that a certain interface has not yet reached stability and leaving it out of the standard, but the more interfaces that can be "built-in" the larger the domain of problems that can be easily dealt with. > This is a question of balance between understanding of the problem and > understanding of the software tools used to solve it. From the dawn of > computers to present day, the first component prevailed, allowing to > implement "everything [problem] in anything [language]". But in a > long-term perspective, I am talking about 20-100 years, the balance > will definitely change, otherwise we will be unable to maintain the > complexity of software [not the algorithms, note]. It will be a > virtual reality with its own virtual problems, if you wish. (:-)) And > the question is whether templates are the right tool to deal with ever > increasing complexitiy. I do not think so. I personally see it as an advantage to understanding not only the languages you may program in, but how they map to machine code, and how the actual computer implements that ISA. If you need efficient code, you need to understand all of these. Unfortunately today finding people who understand the problem domain and the programming language is hard enough. Adding an understanding of ISAs and machine architecture to that is very rare--but it can work seeming miracles. There are a lot of features in Ada 95 that were added soley to allow drilling through Ada and reaching certain ISA or machine architecture features. If you are used to working in a language which doesn't have those features, you can't compete. The recent discussions here of how to implement latitude and longitude are a case in point. A lot of work went into both defining the language so that fixed-point types could be used efficiently for implementing various angle measures. Further work went into the compilers to make those features work. But the result is that in Ada you can implement angles as degrees and fractions of a degree, radians, thousanths of a second, or grads or whatever you need, and get the best possible machine code for it. Similarly, the Information Systems Annex allows efficient implementations of money, and so on. But the whole concept of programming in the large is to allow those things that need implementation close to the machine to be packaged and all of the nitty gritty to be packaged in a single unit, and the user can work with a higher level of abstraction. A good example is the Atlas tool for generating implementations of LINPACK. It generates an implementation level that is tuned for the particular hardware, while the used can call the higher level primitives without worrying about optimization strategies. -- "As far as I'm concerned, war always means failure." -- Jacques Chirac, President of France "As far as France is concerned, you're right." -- Rush Limbaugh ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-08 19:37 ` Robert I. Eachus @ 2003-08-09 0:58 ` Alexander Kopilovitch 2003-08-09 7:39 ` Robert I. Eachus 2003-08-11 10:25 ` Dmitry A. Kazakov 1 sibling, 1 reply; 47+ messages in thread From: Alexander Kopilovitch @ 2003-08-09 0:58 UTC (permalink / raw) Robert I. Eachus wrote: > When the requirements change, that is not a > reason not to understand and document the current requirements. And if > one of those requirements is to live within a body of existing code, > that is from one point of view just another requirement. Of course, > when I do requirements analysis, as far as I am concerned, figuring out > which requirements are likely to change and preparing for that evolution > is part of the process. This is why I keep saying you should program in > the problem space rather than some solution space. The problem space > evolves much more slowly than the problems you are asked to solve. Do you mean that the "Paradise may be regained"... if not for average programmer then at least for an average star -:) ? That is, that by training yourself in that direction, and keeping your nerve, it is possible to follow even rapidly and rather randomly changing requirements with proper documentation and analysis in real time, inside a not very friendly environment? Do you mean that the common defensive strategy against probable but unpredictable changes of requirements -- that is, keeping yourself not too near to them, and more relying upon agreed tools (which seem less vulnerable for spontaneuos customer's or management's dances) -- is not the best strategy, and that it is really possible to chase a moving/jumping problem, all the time at near distance, without significant delay? > [...] > I personally see it as an advantage to understanding not only the > languages you may program in, but how they map to machine code, and how > the actual computer implements that ISA. If you need efficient code, > you need to understand all of these. Unfortunately today finding people > who understand the problem domain and the programming language is hard > enough. Adding an understanding of ISAs and machine architecture to > that is very rare--but it can work seeming miracles. You have seen the miracles being used more that in one or two cases -- so you are lucky. I think that most of us feel that the miracles, if happen, will be most probably betrayed. That's why "Adding an understanding of ISAs and machine architecture to that is very rare" indeed. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-09 0:58 ` Alexander Kopilovitch @ 2003-08-09 7:39 ` Robert I. Eachus 2003-08-10 1:30 ` Alexander Kopilovitch 0 siblings, 1 reply; 47+ messages in thread From: Robert I. Eachus @ 2003-08-09 7:39 UTC (permalink / raw) Alexander Kopilovitch wrote: > Do you mean that the "Paradise may be regained"... if not for average programmer > then at least for an average star -:) ? That is, that by training yourself > in that direction, and keeping your nerve, it is possible to follow even > rapidly and rather randomly changing requirements with proper documentation > and analysis in real time, inside a not very friendly environment? No, I mean that I have worked directly on projects that could not have been completed without rigorous control over the (evolving) requirements. You have to have religion, or something. One of my favorite examples was a project actually written in Ada, but that is almost a detail. The original schedule called for a three year development cycle, in C and assembler. Two years in, that group admitted total failure. I'll get back to why in a minute. Another group volunteered to take over the project and do it in 11 months to meet the original schedule--if they could use Ada and modern software development methods. They got the go ahead on a plan which called for six months of requirements analysis and design, two months of detailed design, two months of coding and one of testing. At the end of detailed design, eight months in, they decided that a significant portion of the original design need to be scrapped and redone. They finished coding a week behind schedule, but completed the formal testing in two days--the test suite has been developed as part of the entire process, and coded by a separate test group within the project. The manager in charge called it management by heart attack. It is one thing to logically accept that starting coding too early will be a disaster, but to finally start coding in the ninth month of an eleven month project can stress a manager out. But it works. In fact the rest of the operating system that it was part of slipped three months, so that all of the features that had been postponed to version two were in there when it released. But they actually formally did keep those additions as a second version in the configuration management system, and tell marketing that they would get it all when release two was ready but nothing before then. That allowed the first version kept bug free during beta test under version control so they didn't get involved in fighting fires. I said I would get back to why the first group failed. They actually had a "working" system at one point. But it had some major bugs, and every bug fix created more bugs than it fixed. The system as a whole had too much coupling. In other words this subsystem was too big for the project management tools and methods they were using. As for the Ada version? The interfaces between the various modules and sub-components were all defined in less than one thousand lines of Ada package specifications. All of the bodies, except one that got near 650 lines were under five-hundred lines long. Each package came with a test program for that package, and was unit tested before being put under version control. Is it any wonder that the system ran the first time with only minor errors left to fix. (There were 17 bugs found in system testing. Fourteen of them were misspellings, poor punctuation or missing accents in the foreign language messages. The program had a localization package that supported US, British, French, German, Spanish, and Italian. Most of the complaints during the beta testing was about Quebecois usage from French testers. Release 2 made French Canadian a separate localization file. ;-) > Do you mean that the common defensive strategy against probable but unpredictable > changes of requirements -- that is, keeping yourself not too near to them, and > more relying upon agreed tools (which seem less vulnerable for spontaneuos > customer's or management's dances) -- is not the best strategy, and that it is > really possible to chase a moving/jumping problem, all the time at near distance, > without significant delay? No. If you don't understand the real requirements, you will get blind sided again and again during development. But if you do the work to "develop" the requirements, you simply won't have that problem. Another project which was actually for the same OS release as the project above, resulted in an even better example. It was a menu subsystem to provide a consistent look and feel to all of the office automation packages. (This was for the Honeywell DPS6, Mod 400 release 3.) There was a two-day review to decide if the product was ready for release. This was more than just a did it meet the requirements review. At these reviews, marketing could and did on occasion sent the software "back to the drawing boards. Not because it did not meet the agreed requirements but because marketing thought they couldn't sell it in the current market environment. During the first day the marketing team realized that it would be nice if there was a standard option just for backing out of transactions, as well as the key that took you to the top of the current menu hierarchy. This wasn't considered a show stopper, but marketing wanted an estimate on the cost of adding the feature. The review finished early on the second day, and they were going over action items. The manager of the project was able to tell them that the changes had been made, a new version compiled overnight, and was now on its way to the Distribution and Test group for their blessing. In the meantime, it had been installed on one of the test machines if they wanted to check it out. You might think that the developers had anticipated this change request and had it all designed in. But that wasn't how it worked. Since the main requirement for the subsystem was to present a consistent interface to the user, the design of the system was a rule based engine that generated the screens. The change to the code was three lines, because the system did model the problem space. Something like: if In_Transaction then Bind_Key(F6, Exit_Transaction); end if; (It was only three lines because there was already a "cancel transaction" entry in the localization files. But if the new messages had to be added to the localization files, it still would not have been a big deal.) You can see how designing the system from the getgo to model the problem space meant that there were not hundreds of different menu templates that needed to be changed. Since the REAL requirement was for a consistent user interface, designing the system this way meant that consistency was automatic. > You have seen the miracles being used more that in one or two cases -- so you > are lucky. I think that most of us feel that the miracles, if happen, will be > most probably betrayed. That's why "Adding an understanding of ISAs and machine > architecture to that is very rare" indeed. And I have also seen disasters where this sort of discipline was necessary due to the scope of the project, but was not put in place. In fact I may finally get around to publishing that paper. (Basically how to tell when the project is dead beyond all hope of recovery from analyzing the reports in the bug tracking system. The earlier you can determine that a project will fail, the less money you waste.) As for the miracle approach, on one very large project, I had to determine if the money should be spent at all. Relatively quickly I determined that the success or failure of the radar upgrade would depend on whether a particular problem could be solved. We called it the formation flight problem, but it could be a lot of airliners on the same course between beacons at the same speed, or a dozen other sorts of coincidences. The proposed solution was to partition the target detections into clusters then resolve each cluster separately. Of course this would have to be done in real-time in a few milliseconds before the next set of pulse doppler data arrived. At the end of six months I couldn't prove that the partitioning could be done in the time available, or that it couldn't. But I did find a way to solve the problem without partitioning the data, so the contract was awarded. -- "As far as I'm concerned, war always means failure." -- Jacques Chirac, President of France "As far as France is concerned, you're right." -- Rush Limbaugh ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-09 7:39 ` Robert I. Eachus @ 2003-08-10 1:30 ` Alexander Kopilovitch 2003-08-10 4:11 ` Robert I. Eachus 0 siblings, 1 reply; 47+ messages in thread From: Alexander Kopilovitch @ 2003-08-10 1:30 UTC (permalink / raw) Robert I. Eachus wrote: > One of my > favorite examples was a project actually written in Ada, but that is > almost a detail. The original schedule called for a three year > development cycle, in C and assembler. Two years in, that group > admitted total failure. I'll get back to why in a minute. > > Another group volunteered to take over the project and do it in 11 > months to meet the original schedule--if they could use Ada and modern > software development methods. They got the go ahead on a plan which > called for six months of requirements analysis and design, two months of > detailed design, two months of coding and one of testing. At the end of > detailed design, eight months in, they decided that a significant > portion of the original design need to be scrapped and redone. They > finished coding a week behind schedule, but completed the formal testing > in two days--the test suite has been developed as part of the entire > process, and coded by a separate test group within the project. > > The manager in charge called it management by heart attack. It is one > thing to logically accept that starting coding too early will be a > disaster, but to finally start coding in the ninth month of an eleven > month project can stress a manager out. But it works. In fact the rest > of the operating system that it was part of slipped three months, so > that all of the features that had been postponed to version two were in > there when it released. But they actually formally did keep those > additions as a second version in the configuration management system, > and tell marketing that they would get it all when release two was ready > but nothing before then. That allowed the first version kept bug free > during beta test under version control so they didn't get involved in > fighting fires. Just curious about the difference or similarity between the cultures: from my former Soviet experience (I have seen somehow similar cases, although possibly of lesser scale) I can guess that that too successful group was rewarded, praised and then dissolved for they could never repeat such unnatural performances any more. Was the outcome the same (or similar) in the case? Or this group was permitted to exist for years after that performance? > During the first day the marketing team realized that it would be nice > if there was a standard option just for backing out of transactions, as > well as the key that took you to the top of the current menu hierarchy. > This wasn't considered a show stopper, but marketing wanted an > estimate on the cost of adding the feature. The review finished early > on the second day, and they were going over action items. The manager > of the project was able to tell them that the changes had been made, a > new version compiled overnight, and was now on its way to the > Distribution and Test group for their blessing. In the meantime, it had > been installed on one of the test machines if they wanted to check it out. > > You might think that the developers had anticipated this change request > and had it all designed in. But that wasn't how it worked. Since the > main requirement for the subsystem was to present a consistent interface > to the user, the design of the system was a rule based engine that > generated the screens. The change to the code was three lines, because > the system did model the problem space. Note, though, that relying upon specific tools - such as problem-oriented languages (SNOBOL, APL, COBOL, Fortran, Prolog etc.) or libraries is actually a "poor man solution" for the desire to operate in the problem space. I mean that if you can't obtain (or even "develop") more or less precise and stable requirements, and even worse, you can't go deep into the real problem (all that is common case), and therefore you can't develop proper custom representation of the problem space, the best strategy may be to rely upon the tools already widely used for that class of problems. With this strategy you have at least good chance for operating not too far from the proper problem space (because the tools will bring you there). > > You have seen the miracles being used more that in one or two cases -- so you > > are lucky. I think that most of us feel that the miracles, if happen, will be > > most probably betrayed. That's why "Adding an understanding of ISAs and machine > > architecture to that is very rare" indeed. > > And I have also seen disasters where this sort of discipline was > necessary due to the scope of the project, but was not put in place. In > fact I may finally get around to publishing that paper. (Basically how > to tell when the project is dead beyond all hope of recovery from > analyzing the reports in the bug tracking system. The earlier you can > determine that a project will fail, the less money you waste.) Well, if you actually publish that paper then, perhaps, it will be rare case of a text about programming for which I believe that Russian translation is desirable -;) Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-10 1:30 ` Alexander Kopilovitch @ 2003-08-10 4:11 ` Robert I. Eachus 0 siblings, 0 replies; 47+ messages in thread From: Robert I. Eachus @ 2003-08-10 4:11 UTC (permalink / raw) Alexander Kopilovitch wrote: > Just curious about the difference or similarity between the cultures: from my > former Soviet experience (I have seen somehow similar cases, although possibly > of lesser scale) I can guess that that too successful group was rewarded, > praised and then dissolved for they could never repeat such unnatural > performances any more. Was the outcome the same (or similar) in the case? > Or this group was permitted to exist for years after that performance? After they finished the second version with all the features that were postponed out of the first, they were asked to take on another project in trouble, but this time write it in C. The group manager laid resignations from all the members of the group on his manager's desk, with his on top. So they got permission to use Ada. About that time I got a "godfather" offer from another company, so I left. (I while I was saying I'd have to check with my wife, they raised the offer by 10% and threw in some additional stock options.) -- "As far as I'm concerned, war always means failure." -- Jacques Chirac, President of France "As far as France is concerned, you're right." -- Rush Limbaugh ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-08 19:37 ` Robert I. Eachus 2003-08-09 0:58 ` Alexander Kopilovitch @ 2003-08-11 10:25 ` Dmitry A. Kazakov 1 sibling, 0 replies; 47+ messages in thread From: Dmitry A. Kazakov @ 2003-08-11 10:25 UTC (permalink / raw) On Fri, 08 Aug 2003 19:37:02 GMT, "Robert I. Eachus" <rieachus@attbi.com> wrote: >Dmitry A. Kazakov wrote: > >> Your example is a case of monolitic design, all from scratch, which is >> clean and desirable, but becomes less and less frequent in modern >> times. It is a right perspective, but there is a little chance that we >> would climb so high. (:-)) > >Ah, here we do disagree. When the requirements change, that is not a >reason not to understand and document the current requirements. And if >one of those requirements is to live within a body of existing code, >that is from one point of view just another requirement. Of course, >when I do requirements analysis, as far as I am concerned, figuring out >which requirements are likely to change and preparing for that evolution >is part of the process. This is why I keep saying you should program in >the problem space rather than some solution space. The problem space >evolves much more slowly than the problems you are asked to solve. I have formulated it not very precisely, so you catched me. (:-)) No, imagine that the requirements do not change, they do not exist! How could something unexisting change? (:-)) The problem space is so remote, layered that nobody takes care to understand it. This is not an excuse, it is awful, but we have to live with that. >> This is true, but again unrealistic in a large, distributed, long >> living project. In which case a "better" solution is one which >> requires only maintainable changes in the existing infrastructure and >> still works somehow... > >See above. Incidently, another issue that should never be overlooked in >the design process is version skew. If I write a program in Ada that >uses say Charles and gtkAda, that is three potential versions to worry >about (Ada compiler, Charles, and gtkAda). That is three potential >versions that may change and get out of alignment, and that is about the > limit for anything you are going to maintain. Since the potential >version conflicts increase as n*(n+1)/2. So with just the compiler, >that is 1, with two libraries as above, that is 6, when you get to four >interfaces, and the OS interface if you program to it counts as well, >that is 15, and next to impossible to keep up with. > >This is one reason I argued in favor of the Annexes in Ada 95, each >Annex could eliminate one version from that equation. In the next >version I hope to see a database binding, perhaps to ODBC added. I'd >like to see a standard graphics library as well, but I don't think we >are to the point where that can happen. (And a container library will >surely happen, I hope it is Charles.) There is nothing wrong with >deciding that a certain interface has not yet reached stability and >leaving it out of the standard, but the more interfaces that can be >"built-in" the larger the domain of problems that can be easily dealt >with. But this does not solve the problem. You simply push it to the compiler developer side. So they shall manage all the complexity. If in my scenario all living beings will soon or later become application programmers, then in yours, everyone will be a compiler developer. That's even worse! In any case a catastrophe is ahead. I tend to agree with Martin Condic. Let's make language small, but powerful enough to implement most of the Annexes. Instead of Unbounded_String, a better type system which would make it easy to do. >> This is a question of balance between understanding of the problem and >> understanding of the software tools used to solve it. From the dawn of >> computers to present day, the first component prevailed, allowing to >> implement "everything [problem] in anything [language]". But in a >> long-term perspective, I am talking about 20-100 years, the balance >> will definitely change, otherwise we will be unable to maintain the >> complexity of software [not the algorithms, note]. It will be a >> virtual reality with its own virtual problems, if you wish. (:-)) And >> the question is whether templates are the right tool to deal with ever >> increasing complexitiy. I do not think so. > >I personally see it as an advantage to understanding not only the >languages you may program in, but how they map to machine code, and how >the actual computer implements that ISA. If you need efficient code, >you need to understand all of these. Unfortunately today finding people >who understand the problem domain and the programming language is hard >enough. Adding an understanding of ISAs and machine architecture to >that is very rare--but it can work seeming miracles. Ask a manager what is better: a bird in the hand or two in the bush. They do not want to wait for miracles, and, well, if miracles do happen, then, you know, people usually crucify that unfortunate miracle-makers! --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-08 13:29 ` Dmitry A. Kazakov 2003-08-08 19:37 ` Robert I. Eachus @ 2003-08-08 23:44 ` Alexander Kopilovitch 2003-08-11 9:54 ` Dmitry A. Kazakov 1 sibling, 1 reply; 47+ messages in thread From: Alexander Kopilovitch @ 2003-08-08 23:44 UTC (permalink / raw) Dmitry A. Kazakov wrote: > This is a question of balance between understanding of the problem and > understanding of the software tools used to solve it. From the dawn of > computers to present day, the first component prevailed, And certainly will always prevail. Essentially, by definition: if the software world becomes more significant than traditional real world -:) then there will be just new class of the problems - concerning the software world, and no more than that. So we'll still look at the problems at first. > allowing to implement "everything [problem] in anything [language]". No, this is too inexact statement: even 3 decades ago it was not possible to implement real-time control program in RPG language. So, not in "anything", but in "any universal language" - and with this more precise wording the statement becomes trivially true. > But in a long-term perspective, I am talking about 20-100 years, 20 years ago no one can predict our current power of computing technology and its presence everywhere in just 2000. Given that the explosion still continues, how can you guess about 20 and even 100 future years? > the balance > will definitely change, otherwise we will be unable to maintain the > complexity of software [not the algorithms, note]. What we will unable to maintain will certainly crash. And we will not make such too complex software any more (after several attempts with sound failures). That's simple. Just the same reasons as for not to build a 100km-high tower. > It will be a > virtual reality with its own virtual problems, if you wish. (:-)) Well, virtual reality is not so big challenge actually. Even nanotechnologies constitute substantially bigger challenge, because they may easily ruin much more our "axioms of impossible", which may appear vital for our implicit logic. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-08 23:44 ` Alexander Kopilovitch @ 2003-08-11 9:54 ` Dmitry A. Kazakov 2003-08-11 14:59 ` Alexander Kopilovitch 0 siblings, 1 reply; 47+ messages in thread From: Dmitry A. Kazakov @ 2003-08-11 9:54 UTC (permalink / raw) On 8 Aug 2003 16:44:04 -0700, aek@vib.usr.pu.ru (Alexander Kopilovitch) wrote: >Dmitry A. Kazakov wrote: > >> This is a question of balance between understanding of the problem and >> understanding of the software tools used to solve it. From the dawn of >> computers to present day, the first component prevailed, > >And certainly will always prevail. Essentially, by definition: if the software >world becomes more significant than traditional real world -:) then there will >be just new class of the problems - concerning the software world, and no more >than that. So we'll still look at the problems at first. OK, but those problems are not ones we presently count for real. >> allowing to implement "everything [problem] in anything [language]". > >No, this is too inexact statement: even 3 decades ago it was not possible >to implement real-time control program in RPG language. So, not in "anything", >but in "any universal language" - and with this more precise wording the >statement becomes trivially true. What we count for "universal" is changing, depending on which problems are of "universal" concern. I give you a funny example. One student was unable to tell me how to calculate a distance between two points in cartesian co-ordinates! He naturally knew nothing about Euclidean distance, space etc. Now the most amazing thing. This student had successfuly modified a 3D-simulation program in OpenGL! (:-)) It is a catastrophe, would you say. Yes, but it is also a triumph of software developing tools. Let me foretell that new generations of programmes will even know nothing about arithmetics! (:-)) >> But in a long-term perspective, I am talking about 20-100 years, > >20 years ago no one can predict our current power of computing technology and >its presence everywhere in just 2000. Given that the explosion still continues, >how can you guess about 20 and even 100 future years? I can guess the plume of that explosion ... >> the balance >> will definitely change, otherwise we will be unable to maintain the >> complexity of software [not the algorithms, note]. > >What we will unable to maintain will certainly crash. And we will not make >such too complex software any more (after several attempts with sound failures). This will stop nobody. There are much worse things people are doing, being well aware of the consequences. >That's simple. Just the same reasons as for not to build a 100km-high tower. That tower is already built. Its name is internet! (:-)) >> It will be a >> virtual reality with its own virtual problems, if you wish. (:-)) > >Well, virtual reality is not so big challenge actually. Even nanotechnologies >constitute substantially bigger challenge, because they may easily ruin much >more our "axioms of impossible", which may appear vital for our implicit logic. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-11 9:54 ` Dmitry A. Kazakov @ 2003-08-11 14:59 ` Alexander Kopilovitch 2003-08-12 9:54 ` Dmitry A. Kazakov 0 siblings, 1 reply; 47+ messages in thread From: Alexander Kopilovitch @ 2003-08-11 14:59 UTC (permalink / raw) >>> allowing to implement "everything [problem] in anything [language]". >> >>No, this is too inexact statement: even 3 decades ago it was not possible >>to implement real-time control program in RPG language. So, not in "anything", >>but in "any universal language" - and with this more precise wording the >>statement becomes trivially true. > >What we count for "universal" is changing, depending on which problems >are of "universal" concern. Not so conformistic, I think. Perhaps you underestimate the generality and deepness of the works of logicians and "founding fathers" of programming (like Turing and other great names). I can agree that all their stuff may seem somehow "basic only" at first sight, but this impression will quickly fade and disappear if you try to make an alternative yourself. >I give you a funny example. One student was unable to tell me how to >calculate a distance between two points in cartesian co-ordinates! He >naturally knew nothing about Euclidean distance, space etc. Now the >most amazing thing. This student had successfuly modified a >3D-simulation program in OpenGL! (:-)) No problem with that. Well, for a native English speaker the spoken language appears before the written language, but for foreigner the sequence is usually reverse. (For example. because of this I can communicate in written English -- well, with many errors, but still usually succesfully -- but I can't say so about my spoken English. So, an "phonetically illiterate" foreigner differs radically from an illiterate native speaker -:) . So for that you student. While for us the Euclidean distance appeared before 3D-simulation and OpenGL, for that student the sequence is opposite -- surely, if he will continue his works with 3D-simulation and OpenGL, he inevitably will learn about Euclidean distance, sooner or later. >It is a catastrophe, would you say. Yes, but it is also a triumph of >software developing tools. No more than public success of some good book on cooking is a catastrophe for biochemisrty -:) > Let me foretell that new generations of >programmes will even know nothing about arithmetics! (:-)) Well, there was a short novel about exactly that, by famous science fiction writer Isaac Asimov. In fact, that was probably the first Asimov's novel published in Soviet Union (in early sixties, I think), and it immediately made Asimov well-known in Soviet scientific circles (at least among physicists). In that novel, in far future the Earth is involved in endless war with another civilization; on both sides humans forgot arithmetics long ago, and the war is totally computerized; the problem is that the computers on both sides appeared "synchronized" -- they develop and upgrade themselves at the same speed, so nobody can win, and the war can't go to the end. The hero of the novel re-invents arithmetics from scratch, and the President becomes happy with new perspective -- to escape the deadlock and defeat the enemy using this non-conventional way. >>What we will unable to maintain will certainly crash. And we will not make >>such too complex software any more (after several attempts with sound failures). > >This will stop nobody. There are much worse things people are doing, >being well aware of the consequences. Well, than it will crash. Don't worry -;) , just don't stay under it -:) > >>That's simple. Just the same reasons as for not to build a 100km-high tower. > >That tower is already built. Its name is internet! (:-)) Why do you think so? Do you think the same about radio, TV, phones? Perhaps you were too much impressed by unprecedented freedom in Internet... well this time is almost over, the freedom in Internet will surely decrease to a normal level quite soon (although not so much as some governments dream now -- thanks China -:). Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-11 14:59 ` Alexander Kopilovitch @ 2003-08-12 9:54 ` Dmitry A. Kazakov 2003-08-13 22:28 ` Alexander Kopilovitch 0 siblings, 1 reply; 47+ messages in thread From: Dmitry A. Kazakov @ 2003-08-12 9:54 UTC (permalink / raw) On 11 Aug 2003 07:59:12 -0700, aek@vib.usr.pu.ru (Alexander Kopilovitch) wrote: >>>> allowing to implement "everything [problem] in anything [language]". >>> >>>No, this is too inexact statement: even 3 decades ago it was not possible >>>to implement real-time control program in RPG language. So, not in "anything", >>>but in "any universal language" - and with this more precise wording the >>>statement becomes trivially true. >> >>What we count for "universal" is changing, depending on which problems >>are of "universal" concern. > >Not so conformistic, I think. Perhaps you underestimate the generality and >deepness of the works of logicians and "founding fathers" of programming >(like Turing and other great names). I can agree that all their stuff may >seem somehow "basic only" at first sight, but this impression will quickly >fade and disappear if you try to make an alternative yourself. These basics are not concern. Compare this with the basics of mathematics. There are lot of problems with that, yet 99.9% of people using mathematics just do not care. Not because they are ignorant. They have other problems to solve. >>I give you a funny example. One student was unable to tell me how to >>calculate a distance between two points in cartesian co-ordinates! He >>naturally knew nothing about Euclidean distance, space etc. Now the >>most amazing thing. This student had successfuly modified a >>3D-simulation program in OpenGL! (:-)) > >No problem with that. Well, for a native English speaker the spoken language >appears before the written language, but for foreigner the sequence is usually >reverse. (For example. because of this I can communicate in written English >-- well, with many errors, but still usually succesfully -- but I can't say so >about my spoken English. So, an "phonetically illiterate" foreigner differs >radically from an illiterate native speaker -:) . > >So for that you student. While for us the Euclidean distance appeared before >3D-simulation and OpenGL, for that student the sequence is opposite -- surely, >if he will continue his works with 3D-simulation and OpenGL, he inevitably >will learn about Euclidean distance, sooner or later. I think that the analogy is invalid. OpenGL cannot supersede analytic geometry. I would say that one can play an electic piano, knowing nothing about electricity. >>It is a catastrophe, would you say. Yes, but it is also a triumph of >>software developing tools. > >No more than public success of some good book on cooking is a catastrophe for >biochemisrty -:) To me it is a disaster. I understand Rober Eachus, how can someone write a program without any understanding of the underlying problem? In fact, one can and will. That's the dawn of an industrial age of programming. (:-() >> Let me foretell that new generations of >>programmes will even know nothing about arithmetics! (:-)) > >Well, there was a short novel about exactly that, by famous science fiction >writer Isaac Asimov. In fact, that was probably the first Asimov's novel >published in Soviet Union (in early sixties, I think), and it immediately made >Asimov well-known in Soviet scientific circles (at least among physicists). >In that novel, in far future the Earth is involved in endless war with another >civilization; on both sides humans forgot arithmetics long ago, and the war is >totally computerized; the problem is that the computers on both sides appeared >"synchronized" -- they develop and upgrade themselves at the same speed, so >nobody can win, and the war can't go to the end. The hero of the novel re-invents >arithmetics from scratch, and the President becomes happy with new perspective >-- to escape the deadlock and defeat the enemy using this non-conventional way. Happy end. (:-)) But the true story is that re-invented arithmetics did not help them. See Matrix movie paraphrasing the anecdote about Sergeant and banana - all problems can solved merely by jumping higher than others could. (:-)) >>>What we will unable to maintain will certainly crash. And we will not make >>>such too complex software any more (after several attempts with sound failures). >> >>This will stop nobody. There are much worse things people are doing, >>being well aware of the consequences. > >Well, than it will crash. Don't worry -;) , just don't stay under it -:) Exactly! (:-)) >>>That's simple. Just the same reasons as for not to build a 100km-high tower. >> >>That tower is already built. Its name is internet! (:-)) > >Why do you think so? It is an example of how a very bad technology could serve a great purpose. Just because of its size it could take years to collapse. Like in the old Roman empire, generations may come and go and not notice that it falls. > Do you think the same about radio, TV, phones? Perhaps >you were too much impressed by unprecedented freedom in Internet... well this >time is almost over, the freedom in Internet will surely decrease to a normal >level quite soon (although not so much as some governments dream now -- thanks >China -:). Thanks to RIAA! I can expect communists fighting freedom of speech, but Mickey Mouse? Indeed, history repeats twice ... --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-12 9:54 ` Dmitry A. Kazakov @ 2003-08-13 22:28 ` Alexander Kopilovitch 0 siblings, 0 replies; 47+ messages in thread From: Alexander Kopilovitch @ 2003-08-13 22:28 UTC (permalink / raw) Dmitry A. Kazakov wrote: >>>I give you a funny example. One student was unable to tell me how to >>>calculate a distance between two points in cartesian co-ordinates! He >>>naturally knew nothing about Euclidean distance, space etc. Now the >>>most amazing thing. This student had successfuly modified a >>>3D-simulation program in OpenGL! (:-)) >> >>No problem with that. Well, for a native English speaker the spoken language >>appears before the written language, but for foreigner the sequence is usually >>reverse. (For example. because of this I can communicate in written English >>-- well, with many errors, but still usually succesfully -- but I can't say so >>about my spoken English. So, an "phonetically illiterate" foreigner differs >>radically from an illiterate native speaker -:) . >> >>So for that you student. While for us the Euclidean distance appeared before >>3D-simulation and OpenGL, for that student the sequence is opposite -- surely, >>if he will continue his works with 3D-simulation and OpenGL, he inevitably >>will learn about Euclidean distance, sooner or later. > >I think that the analogy is invalid. OpenGL cannot supersede analytic >geometry. If you think that written English supersedes spoken English (and even for those who cannot reproduce proper sounds from written words) then you are wrong, sad to say. It may be true or almost true for very poor English, but no more than that. > I would say that one can play an electic piano, knowing >nothing about electricity. If API is comprehensive and needed library functions are supplied as smoothly as electricity then why not? Well, I'll try to explain why that is not enough: You may be unaware about electricity and still play an electric piano succesfully, but for that you must be aware of music. That is, you must somehow understand your problem domain - music. You must know something about tunes, tones, durations etc. So for OpenGL applications: your student will recognize that he must learn Euclidean distance when he discovers that without it he can't understand enough 3D-something problems he is facing. Very annoying situation, indeed: you are ready to solve the problem, but you can't get what is needed; you customer is surely ignorant and idiot for he can't give you problem statement in proper (suitable for OpenGL) terms, and he is talking all the time about those damned distances... but money is on his side, and you are facing the bitter choice: either learn distances or lose opportunity of earning money. >>> Let me foretell that new generations of >>>programmes will even know nothing about arithmetics! (:-)) >> >>Well, there was a short novel about exactly that, by famous science fiction >>writer Isaac Asimov. In fact, that was probably the first Asimov's novel >>published in Soviet Union (in early sixties, I think), and it immediately made >>Asimov well-known in Soviet scientific circles (at least among physicists). >>In that novel, in far future the Earth is involved in endless war with another >>civilization; on both sides humans forgot arithmetics long ago, and the war is >>totally computerized; the problem is that the computers on both sides appeared >>"synchronized" -- they develop and upgrade themselves at the same speed, so >>nobody can win, and the war can't go to the end. The hero of the novel re-invents >>arithmetics from scratch, and the President becomes happy with new perspective >>-- to escape the deadlock and defeat the enemy using this non-conventional way. > >Happy end. (:-)) Not so happy - at the end of the novel the inventor committed suicide when became aware of that his invention will be used exclusively for military purposes. > But the true story is that re-invented arithmetics >did not help them. See Matrix movie paraphrasing the anecdote about >Sergeant and banana - all problems can solved merely by jumping higher >than others could. (:-)) I think that public referencing of the Matrix movie is inappropriate in any context which isn't related to mass entertainment. Let's differentiate good science fiction from something like mental beer. (Why such a strong reaction? Just because you implied that reader should have seen that movie, so you became an agent of it.) >>>>That's simple. Just the same reasons as for not to build a 100km-high tower. >>> >>>That tower is already built. Its name is internet! (:-)) >> >>Why do you think so? > >It is an example of how a very bad technology could serve a great >purpose. Quite strange claim (about "very bad technology"), I think. Certainly, one can list many drawbacks of current Internet technologies (thus don't do that here. please -:) , but knowing that the current Internet as a whole could not be *designed* anyway, I can't understand any blames of this kind. Besides that, what a strange criteria for "good" and "bad" you must use for that your claim. The Internet succeeded in many aspects, it was adopted worldwide, and that its spreading takes effectively less than two decades. Well, I would understand if someone says that automobile technology is very bad because it claims hundreds of thousands lives worldwide every year... or that smoking technology is bad - for similar reasons; but I don't see any great harm directly caused by that Internet technology. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-08 10:12 ` Robert I. Eachus 2003-08-08 13:29 ` Dmitry A. Kazakov @ 2003-08-09 8:32 ` Simon Wright 2003-08-09 15:32 ` Robert I. Eachus 1 sibling, 1 reply; 47+ messages in thread From: Simon Wright @ 2003-08-09 8:32 UTC (permalink / raw) "Robert I. Eachus" <rieachus@attbi.com> writes: > My favorite example involved the LALR parser generator on Multics. > Pat Prange was about to go through the gory effort to allow an array > of Boolean data to span multiple segments. I asked why he didn't > use a packed representation, and he answered at length. But once we > got all the requirements written down, it turned out that the major > operation on the array was a search in a particular row for the > first set bit. After another half hour of discussion Pat ran off to > implement the new version. To make a long story short, it used the > translate and test instruction in the character string processing > unit. The single instruction generated used a 512-element table to > look up the first non-zero (9-bit) byte detected, and of course the > values in the table were the index of the first set bit. Six lines > of PL/I carefully written so the code generator would emit a single > instruction! > > The net result was to decrease the running time for the tool by over > 90%, from just over 20 minutes to generate an optimized LALR1 parser > for Ada, to just under two minutes. But the point to take away is > not that PL/I was great for this purpose, or Multics. I could write > the same code in COBOL for an IBM mainframe, or C for an x86 or > 680x0 chip. (Or in Ada, or just about any language that let you get > close to the metal when necessary.) The expertise required is in > first figuring out the actual machine code you want generated, then > knowing the compiler internals well enough to make it happen. At some point you need (a) a machine-independent solution to the problem, (b) a machine-dependent optimisation. Clearly it's good if the machine-independent solution is also efficient, but it seems to me like overkill to write 6 very clever lines in the hope that the compiler (and future revisions) will always emit one machine code instruction. Why not use an assembler insert? ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: signature like constructions 2003-08-09 8:32 ` Simon Wright @ 2003-08-09 15:32 ` Robert I. Eachus 0 siblings, 0 replies; 47+ messages in thread From: Robert I. Eachus @ 2003-08-09 15:32 UTC (permalink / raw) Simon Wright wrote: > At some point you need (a) a machine-independent solution to the > problem, (b) a machine-dependent optimisation. Clearly it's good if > the machine-independent solution is also efficient, but it seems to me > like overkill to write 6 very clever lines in the hope that the > compiler (and future revisions) will always emit one machine code > instruction. Why not use an assembler insert? The LALR tool was used by Honeywell to make compiler front ends. If others in the compiler group made a change to the Multics PL/I compiler that would break it, it would be regarded as a serious bug that would prevent the new compiler version from being installed in the development hierarchy, let alone as part of a shipping compiler. I guess it is just a different way of thinking when you are part of the compiler development team. For example, any changes I make to my code that is part of GNAT will only pass the regression tests if it compiles and runs correctly on all supported systems. Similarly, I can count on any code that works once and makes it into GNAT working always because it will be part of the regression test suite. It is not a joke that the automated regression test suite, which may take hours to run, is one of the most valuable tools a compiler group has. In many cases it would cost less to recreate a compiler from scratch, given the regression suite, than to create a new set of regression tests and the tools to run them. -- "As far as I'm concerned, war always means failure." -- Jacques Chirac, President of France "As far as France is concerned, you're right." -- Rush Limbaugh ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-06 9:03 ` Dmitry A. Kazakov 2003-08-06 18:15 ` signature like constructions (was: Re: XML DOM Binding for Ada 95 - matter of style) Georg Bauhaus @ 2003-08-07 12:52 ` Matthew Heaney 2003-08-07 15:03 ` Dmitry A. Kazakov 1 sibling, 1 reply; 47+ messages in thread From: Matthew Heaney @ 2003-08-07 12:52 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:egd1jvc6pe888e4ug683tis6a5q5ua12ml@4ax.com... > On Tue, 5 Aug 2003 13:34:09 +0000 (UTC), Georg Bauhaus > <sb463ba@d2-hrz.uni-duisburg.de> wrote: > > >Actually, you can pass operations of a tagged type as actuals. > > Yes, this is a great disadvantage of generics. You have to explicitly > specify everything you need. This is a feature, not a flaw. The Ada generics were deliberately designed this way, because you get better error checking. > Compare it with inheritance, you just > specify a base type. This is because Ada's generics try to pretend to > have some contract. I don't know what you mean by "pretend" to have a contract: Ada generics do have a contract. In fact it's called the "generic contract model." > C++ does not, it openly says that what you become > is your own business. Well, yes and no. You don't just design ex nihilo, but with the expection that the generic actual type will have a specific set of operations, even if those operations are only loosely specified. > template <class Element>void Sort ...; > // Guess, what I have used here this week, "<=" or ">="? No. Sort will only use operator<. It will never use operator<= or operator>=, because those can be derived from the canonical operator<. You should always define relational operators in terms of the less-than operatior: function "<" (L, R : T) return Boolean is ...; function ">" (L, R : T) return Boolean is begin return R < L; end; function ">=" (L, R : T) return Boolean is begin return not (L < R); end; function ">=" (L, R : T) return Boolean is begin return R <= L; end; In the STL and in Charles, you even use the less-then operator for computing "equivalence" of keys: function Is_Equivalent (L, R : T) return Boolean is begin return not (L < R) and not (R < L); end; The equality operator "=" for elements is only used to compute the value of container equality. > >Can this be done with virtual member functions in C++? > > You mean to pass a dispatching operation to a template? I showed how to do this in Ada in a previous post. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-07 12:52 ` XML DOM Binding for Ada 95 - matter of style Matthew Heaney @ 2003-08-07 15:03 ` Dmitry A. Kazakov 0 siblings, 0 replies; 47+ messages in thread From: Dmitry A. Kazakov @ 2003-08-07 15:03 UTC (permalink / raw) On Thu, 07 Aug 2003 12:52:44 GMT, "Matthew Heaney" <matthewjheaney@earthlink.net> wrote: >"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >news:egd1jvc6pe888e4ug683tis6a5q5ua12ml@4ax.com... >> On Tue, 5 Aug 2003 13:34:09 +0000 (UTC), Georg Bauhaus >> <sb463ba@d2-hrz.uni-duisburg.de> wrote: >> >> >Actually, you can pass operations of a tagged type as actuals. >> >> Yes, this is a great disadvantage of generics. You have to explicitly >> specify everything you need. > >This is a feature, not a flaw. The Ada generics were deliberately designed >this way, because you get better error checking. Yes. Better error checking is because of a better contract specification. Flaw is that with generics one cannot inherit the contract and extend/modify it. There are actually two ways to make something close to that: 1. To define a generic package with "interface" functions and pass its instance as formal parameter to another generic package. 2. To use child generic packages. Both are far not so flexible and easy to use as classical interface inheritance. >> Compare it with inheritance, you just >> specify a base type. This is because Ada's generics try to pretend to >> have some contract. > >I don't know what you mean by "pretend" to have a contract: Ada generics do >have a contract. In fact it's called the "generic contract model." A very limited one. There are many things, which cannot be [precisely] specified in the contract. For example, you cannot have user-defined type classes, you have to stick to the predefined ones, like "(<>)", "range <>", "mod <>", "private". There are problems with information hiding when generics are used. etc Anyway, if one wish to argue for generics against tagged types, one should rather consider C++ templates. All (mosty mythical) advantages over tagged types appear when one departs from the contract model. Stricter we make contracts lesser difference we will notice. As a prophecy, in the end, tagged types will completely supersede generics. >> C++ does not, it openly says that what you become >> is your own business. > >Well, yes and no. You don't just design ex nihilo, but with the expection >that the generic actual type will have a specific set of operations, even if >those operations are only loosely specified. > >> template <class Element>void Sort ...; >> // Guess, what I have used here this week, "<=" or ">="? > >No. Sort will only use operator<. It will never use operator<= or >operator>=, because those can be derived from the canonical operator<. The contract states neither this nor otherwise. It is a clear flaw. One could argue that it is an advantage, because "every reasonable programmer would make so", but then I would argue that one need no type system at all, because "every reasonable programmer will never mix incompatible types". >You should always define relational operators in terms of the less-than >operatior: > >function "<" (L, R : T) return Boolean is ...; > >function ">" (L, R : T) return Boolean is >begin > return R < L; >end; > >function ">=" (L, R : T) return Boolean is >begin > return not (L < R); >end; > >function ">=" (L, R : T) return Boolean is >begin > return R <= L; >end; > >In the STL and in Charles, you even use the less-then operator for computing >"equivalence" of keys: > >function Is_Equivalent (L, R : T) return Boolean is >begin > return not (L < R) and not (R < L); >end; > >The equality operator "=" for elements is only used to compute the value of >container equality. How does this support templates? However this is a point for future Ada revisions. If the compiler derives "/=" from "=", why doesn't it for "<"? Similar thing is commutative operations like "+" and "*". One could wish to derive "+" (Left : Y; Right : X) from "+" (Left : X; Right : Y) instead of a geometric explosion of specifications in case of many types. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-05 13:34 ` Georg Bauhaus 2003-08-06 9:03 ` Dmitry A. Kazakov @ 2003-08-07 12:28 ` Matthew Heaney 1 sibling, 0 replies; 47+ messages in thread From: Matthew Heaney @ 2003-08-07 12:28 UTC (permalink / raw) "Georg Bauhaus" <sb463ba@d2-hrz.uni-duisburg.de> wrote in message news:bgoboh$pae$1@a1-hrz.uni-duisburg.de... > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > > You don't need to know about them during the design process, > but you can construct "signature instances" like so: > > generic > type X is private; > function count(thing: X) return Natural; > procedure stretch(thing: in out X); > ... > > and then instantiate "..." with whatever actuals seem fit. This is exactly how the generic algorithms in Charles work. Something like: generic type Iterator_Type is private; with function Succ (I : Iterator_Type) return Iterator_Type is <>; with function Is_Less (L, R : Iterator_Type) return Boolean is <>; ... function Generic_O (First, Back : Iterator_Type) return Iterator_Type; There are only a few algorithms in there, because I'm still busy working on the containers. > This doesn't require that the provider of the units from which > X, count, etc. are taken, has to know beforehand that his/her types, > functions, or whatever will be used this way. To a point. But often, you design a type anticipating that that type will the used as a generic actual. For example, in Charles, all the iterator types (indeed, all the containers) have an identical interface (meaning that all the operation names are the same). This allows you pass "default" subprogram actuals, e.g. function Op is new Generic_Op (Iterator_Type); --This works because Succ and Is_Less are directly --visible at the point of instantiation. > Actually, you can pass operations of a tagged type as actuals. > Can this be done with virtual member functions in C++? Well, yes and no. You can dispatch on the operation, which would be the only point of doing it, e.g. generic type T (<>) is abstract tagged limited private; with function Op (O : in T) is <>; procedure Generic_Dispatch (O : in T'Class); procedure Generic_Dispatch (O : in T'Class) is begin Op (O); --illegal end; To do generic dispatching, you have to use a trick, um, I mean "technique," which involves passing a class-wide operation instead: generic type T (<>) is limited private; with procedure Op (O : in T) is <>; procedure Generic_Dispatch (O : in T) is begin Op (O); end; Now suppose we have a tagged type: package P is type T is tagged limited null record; procedure Op (O : T); --primitive end; Somehow we'd like to pass an object of type T'Class as a parameter to the instantion, and dispatch Op. The way to do this is create a little wrapper subprogram for Op: procedure P.Call_Op (O : in T'Class) is begin Op (O); --dispatches end; Now we have everything we need to instantiation generic op. The solution to the problem is to pass type T'Class as the generic actual type: procedure Dispatch is new Generic_Dispatch (T => T'Class, Op => Call_Op); Now when we do this: procedure Op2 (O : T'Class) is begin Dispatch (O); end; then the primitive operation Op will dispatch according to the tag of O. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-08-03 16:42 ` Matthew Heaney 2003-08-04 8:04 ` Dmitry A. Kazakov @ 2003-08-05 20:05 ` Marin David Condic 1 sibling, 0 replies; 47+ messages in thread From: Marin David Condic @ 2003-08-05 20:05 UTC (permalink / raw) I don't recall saying that inheritance-oriented programming is the solution to all problems. :-) IIRC I said that I thought it was a better technique for reflecting the design of the XML DOM. I regularly work with software that does not use OOP and if it had to support inheritance, it would lead to unacceptable inefficiencies. That software is not "bad" by any definition of the word. I have used discriminated records in a wide variety of circumstances - including hard realtime apps. So I'm not a chauvanistic supporter of OOP or a total enemy of discriminated records. I just think they were the *wrong* implementation choice for the design under discussion. MDC Matthew Heaney wrote: > "Marin David Condic" <nobody@noplace.com> wrote in message > news:3F2BA9C8.9030700@noplace.com... > >>I see tagged types as the way to fully implement the Object Oriented >>paradigm in Ada. > > > To help convince you that inheritance-oriented programming is not the > solution to all problems, I suggest you read this interview with Stepanov: > -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "In general the art of government consists in taking as much money as possible from one class of citizens to give to the other." -- Voltaire ====================================================================== ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-07-30 15:20 ` Denny Vrandecic 2003-07-30 16:33 ` Stephen Leake @ 2003-07-30 16:34 ` Martin Dowie 1 sibling, 0 replies; 47+ messages in thread From: Martin Dowie @ 2003-07-30 16:34 UTC (permalink / raw) "Denny Vrandecic" <nodix@tiscali.de> wrote in message news:bg8noh$22ti$1@ulysses.news.tiscali.de... > Simply put: double work, same pay. > There is no easy way of wrapping one around the other, especially Exception > Handling is a rather tricky issue that differs tremendously between the IDL- > and the Ada-way. > To avoid double work and still write the one binding that is most useful for > the Ada-Community I ask here for your opinion and advice. In that case I'd go with the W3C and then hope someone puts a convenient Ada-ish wrapper on top for you someday. :-) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: XML DOM Binding for Ada 95 - matter of style 2003-07-30 11:32 XML DOM Binding for Ada 95 - matter of style DENNY VRANDECIC 2003-07-30 12:33 ` Martin Dowie @ 2003-07-30 17:54 ` tmoran 1 sibling, 0 replies; 47+ messages in thread From: tmoran @ 2003-07-30 17:54 UTC (permalink / raw) >just to stick close to these IDL-Specs. The result doesn't have an Ada-like >feeling - the procedures names are written in one word, the exception >... >binding feel very Adaesque. Ada users would learn it easier, it would better >fit in the program, The first is called a "thin" binding, the latter a "thick" binding. For some comments on the tradeoffs, see the Introduction and section 2.1 in our TriAda paper "CLAW, a High Level, Portable, Ada 95 Binding for Microsoft Windows", available on-line at www.rrsoftware.com Also see IEEE Std 1003.5-1992 "POSIX Ada language Interfaces", search c.l.a. for "thick" or "thin", or search www.adaic.org/site/wide-search.html ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2003-08-13 22:28 UTC | newest] Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-07-30 11:32 XML DOM Binding for Ada 95 - matter of style DENNY VRANDECIC 2003-07-30 12:33 ` Martin Dowie 2003-07-30 15:20 ` Denny Vrandecic 2003-07-30 16:33 ` Stephen Leake 2003-07-31 10:57 ` Marin David Condic 2003-07-31 11:27 ` Preben Randhol 2003-07-31 13:10 ` Matthew Heaney 2003-07-31 19:04 ` Simon Wright 2003-08-02 14:40 ` Matthew Heaney 2003-07-31 20:25 ` Randy Brukardt 2003-08-01 11:46 ` Marin David Condic 2003-08-02 3:40 ` Matthew Heaney 2003-08-02 12:08 ` Marin David Condic 2003-08-02 14:46 ` Matthew Heaney 2003-08-02 21:25 ` Ed Falis 2003-08-05 19:59 ` Marin David Condic 2003-08-03 16:42 ` Matthew Heaney 2003-08-04 8:04 ` Dmitry A. Kazakov 2003-08-05 8:00 ` Georg Bauhaus 2003-08-05 11:46 ` Dmitry A. Kazakov 2003-08-05 13:34 ` Georg Bauhaus 2003-08-06 9:03 ` Dmitry A. Kazakov 2003-08-06 18:15 ` signature like constructions (was: Re: XML DOM Binding for Ada 95 - matter of style) Georg Bauhaus 2003-08-07 10:12 ` Dmitry A. Kazakov 2003-08-07 16:22 ` signature like constructions Georg Bauhaus 2003-08-08 8:31 ` Dmitry A. Kazakov 2003-08-08 10:12 ` Robert I. Eachus 2003-08-08 13:29 ` Dmitry A. Kazakov 2003-08-08 19:37 ` Robert I. Eachus 2003-08-09 0:58 ` Alexander Kopilovitch 2003-08-09 7:39 ` Robert I. Eachus 2003-08-10 1:30 ` Alexander Kopilovitch 2003-08-10 4:11 ` Robert I. Eachus 2003-08-11 10:25 ` Dmitry A. Kazakov 2003-08-08 23:44 ` Alexander Kopilovitch 2003-08-11 9:54 ` Dmitry A. Kazakov 2003-08-11 14:59 ` Alexander Kopilovitch 2003-08-12 9:54 ` Dmitry A. Kazakov 2003-08-13 22:28 ` Alexander Kopilovitch 2003-08-09 8:32 ` Simon Wright 2003-08-09 15:32 ` Robert I. Eachus 2003-08-07 12:52 ` XML DOM Binding for Ada 95 - matter of style Matthew Heaney 2003-08-07 15:03 ` Dmitry A. Kazakov 2003-08-07 12:28 ` Matthew Heaney 2003-08-05 20:05 ` Marin David Condic 2003-07-30 16:34 ` Martin Dowie 2003-07-30 17:54 ` tmoran
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox