* Depending on passing mechanism @ 1997-10-13 0:00 Andre Spiegel 1997-10-13 0:00 ` Matthew Heaney ` (2 more replies) 0 siblings, 3 replies; 54+ messages in thread From: Andre Spiegel @ 1997-10-13 0:00 UTC (permalink / raw) This has been discussed before, but I couldn't find the information I need on DejaNews... In Ada, compilers may choose to pass certain types either by reference or by copy (see RM95 6.2). This allows for greater efficiency (bit arrays may be passed in registers, etc.), but under some circumstances, this can change program semantics (RM95 6.2(12)). I know that it is not possible to forbid these problematic cases altogether, because detecting them would be equivalent to solving the halting problem. Question: Could anyone give me references to papers, books, or web pages where this is discussed? Particularly, I'm looking for * the proof that it's equivalent to the halting problem. (I could do it myself, but I'd like to reference it in a paper.) * a discussion as to how far compilers can reasonably go, i.e. which cases can in fact be detected, and under what cost. Please reply by e-mail, I'll summarize. Thanks, Andre Spiegel Free University of Berlin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-13 0:00 Depending on passing mechanism Andre Spiegel @ 1997-10-13 0:00 ` Matthew Heaney 1997-10-14 0:00 ` Robert Dewar 1997-10-14 0:00 ` Robert Dewar 2 siblings, 0 replies; 54+ messages in thread From: Matthew Heaney @ 1997-10-13 0:00 UTC (permalink / raw) In article <x2hgal3jxa.fsf@moon.inf.fu-berlin.de>, Andre Spiegel <spiegel@inf.fu-berlin.de> wrote: >Question: Could anyone give me references to papers, books, or web >pages where this is discussed? Particularly, I'm looking for > > * the proof that it's equivalent to the halting problem. (I could > do it myself, but I'd like to reference it in a paper.) > > * a discussion as to how far compilers can reasonably go, i.e. which > cases can in fact be detected, and under what cost. I don't know about the halting problem issue, but you may want to contact Henry Baker. He's been critical of Ada parameter passing mechanisms (notably that limited types always be passed by reference - a problem largely fixed in Ada 95), so maybe he can give you some pointers. <ftp://ftp.netcom.com/pub/hb/hbaker/home.html> <mailto:hbaker@netcom.com> Post your results when you're done - I'd be interested in learning that myself. Matt -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-13 0:00 Depending on passing mechanism Andre Spiegel 1997-10-13 0:00 ` Matthew Heaney @ 1997-10-14 0:00 ` Robert Dewar 1997-10-14 0:00 ` Henry Baker 1997-10-21 0:00 ` Keith Thompson 1997-10-14 0:00 ` Robert Dewar 2 siblings, 2 replies; 54+ messages in thread From: Robert Dewar @ 1997-10-14 0:00 UTC (permalink / raw) <<In Ada, compilers may choose to pass certain types either by reference or by copy (see RM95 6.2). This allows for greater efficiency (bit arrays may be passed in registers, etc.), but under some circumstances, this can change program semantics (RM95 6.2(12)). >> No, this cannot change program semantics, since the semantics is formally non-deterministic (that is a change in Ada 95). Yes, it may change program behavior, but program behavior is occasionally non-deterministic in Ada, and this is one of those cases. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-14 0:00 ` Robert Dewar @ 1997-10-14 0:00 ` Henry Baker 1997-10-15 0:00 ` JP Thornley ` (2 more replies) 1997-10-21 0:00 ` Keith Thompson 1 sibling, 3 replies; 54+ messages in thread From: Henry Baker @ 1997-10-14 0:00 UTC (permalink / raw) In article <dewar.876842858@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > <<In Ada, compilers may choose to pass certain types either by reference > or by copy (see RM95 6.2). This allows for greater efficiency (bit > arrays may be passed in registers, etc.), but under some > circumstances, this can change program semantics (RM95 6.2(12)). > >> > > No, this cannot change program semantics, since the semantics is formally > non-deterministic (that is a change in Ada 95). Yes, it may change program > behavior, but program behavior is occasionally non-deterministic in Ada, > and this is one of those cases. It should be comforting to you when your Boeing 777 crashes that its Ada code met the standard.... This is another one of those cases that give standards bodies such a bad name -- the behavior is well-defined as 'non-deterministic', but non-functional. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-14 0:00 ` Henry Baker @ 1997-10-15 0:00 ` JP Thornley 1997-10-15 0:00 ` Geert Bosch 1997-10-21 0:00 ` Robert A Duff 2 siblings, 0 replies; 54+ messages in thread From: JP Thornley @ 1997-10-15 0:00 UTC (permalink / raw) In article: <hbaker-1410971205270001@10.0.2.1> hbaker@netcom.com (Henry Baker) writes: > > It should be comforting to you when your Boeing 777 crashes that its Ada code > met the standard.... > > This is another one of those cases that give standards bodies such a > bad name -- the behavior is well-defined as 'non-deterministic', but > non-functional. > Well now, the Ada-based language SPARK (Ada subset plus annotations) solved this problem a long time ago. Phil -- ------------------------------------------------------------------------ | JP Thornley EMail jpt@diphi.demon.co.uk | | phil.thornley@acm.org | ------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-14 0:00 ` Henry Baker 1997-10-15 0:00 ` JP Thornley @ 1997-10-15 0:00 ` Geert Bosch 1997-10-15 0:00 ` Henry Baker 1997-10-15 0:00 ` Robert Dewar 1997-10-21 0:00 ` Robert A Duff 2 siblings, 2 replies; 54+ messages in thread From: Geert Bosch @ 1997-10-15 0:00 UTC (permalink / raw) Robert Dewar <dewar@gnat.com> wrote: ``Yes, it may change program behavior, but program behavior is occasionally non-deterministic in Ada, and this is one of those cases.'' Henry Baker <hbaker@netcom.com> replied: ``This is another one of those cases that give standards bodies such a bad name -- the behavior is well-defined as 'non-deterministic', but non-functional.'' Although it would be nice te remove non-determinism from programming languages I do not believe this is practical even for programs with a single thread of control. For example, large data-structures have to be passed by reference for efficiency reasons. A fundamental problem in this case is aliasing of subprogram parameters. When a subprogram is called with two parameters that are passed by reference and these actually refer to the same object the program execution may be non-deterministic. In general this cannot be detected at compile time. Solving this aliasing problem in the language (for example using reference counting) will result in significant extra complexity and distributed overhead. This added complexity and overhead would be two strong reasons not to use the "improved" language for embedded systems like those in the Boeing 777 you mentioned. Do you have a proposal to remove the non-determinism without affecting performance and flexibility too much? I think many readers in this group might be interested in such ideas, at least I am. Regards, Geert ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-15 0:00 ` Geert Bosch @ 1997-10-15 0:00 ` Henry Baker 1997-10-15 0:00 ` Robert Dewar ` (2 more replies) 1997-10-15 0:00 ` Robert Dewar 1 sibling, 3 replies; 54+ messages in thread From: Henry Baker @ 1997-10-15 0:00 UTC (permalink / raw) In article <622b4t$nhe$1@gonzo.sun3.iaf.nl>, Geert Bosch <geert@gonzo.sun3.iaf.nl> wrote: > In general this cannot be detected at compile time. Solving this > aliasing problem in the language (for example using reference > counting) will result in significant extra complexity and distributed > overhead. This added complexity and overhead would be two strong > reasons not to use the "improved" language for embedded systems > like those in the Boeing 777 you mentioned. > > Do you have a proposal to remove the non-determinism without affecting > performance and flexibility too much? I think many readers in this > group might be interested in such ideas, at least I am. > > Regards, > Geert Yes. There are 3 solutions, any of which is better than the current Ada 'non deterministic' solution. 1. _Always_ pass by reference. This can be forced in C/C++ by certain coding styles. Any aliasing is assumed to be programmer-intended, and has a relatively simple programming model. (You may have to liberally sprinkle 'volatile'-type thingy's around as well.) There is a certain cost, but on modern microprocessors the cost is not exorbitant, and certainly less than the cost of a 777. 2. _Always_ pass by value. This is really possible only in a 100% functional language like Haskell. 3. Add a new concept to your language: 'linear'/'unique' types. These objects are guaranteed to be singly referenced because this is enforced by the type system. Poof! No aliasing! This concept was pioneered by NIL/Hermes, and has recently been incorporated into some logical (prolog-like) languages and some functional languages ('Clean' from KU Leaven). There is a large and growing body of mathematics called 'linear logic' that puts linear types on a firm theoretical foundation. The NIL/Hermes people tried to get people in the Ada community to pay attention, but they were completely ignored, and Ada95 suffered for it. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-15 0:00 ` Henry Baker @ 1997-10-15 0:00 ` Robert Dewar 1997-10-15 0:00 ` Jon S Anthony 1997-10-16 0:00 ` Brian Rogoff 2 siblings, 0 replies; 54+ messages in thread From: Robert Dewar @ 1997-10-15 0:00 UTC (permalink / raw) 1. _Always_ pass by reference. This can be forced in C/C++ by certain coding styles. Any aliasing is assumed to be programmer-intended, and has a relatively simple programming model. (You may have to liberally sprinkle 'volatile'-type thingy's around as well.) There is a certain cost, but on modern microprocessors the cost is not exorbitant, and certainly less than the cost of a 777. This is VERY difficult in distributed environments where there is no shared memory between caller and callee, and prohibitively expensive. (The 777 rhetoric hardly impresses us with the validity of your arguments) It is of course possible to force this same effect in Ada 95, by the use of access parameters. 2. _Always_ pass by value. This is really possible only in a 100% functional language like Haskell. Nonsense, it is always possible to pass by value, I have no idea what Henry is talking about when he says this. Certainly not Ada. The penalty for passing by value is simply the cost of copying (once for in parameters, twice for in out), but these copies can be prohibitively expensive for large arrays. 3. Add a new concept to your language: 'linear'/'unique' types. These objects are guaranteed to be singly referenced because this is enforced by the type system. Poof! No aliasing! This concept was pioneered by NIL/Hermes, and has recently been incorporated into some logical (prolog-like) languages and some functional languages ('Clean' from KU Leaven). There is a large and growing body of mathematics called 'linear logic' that puts linear types on a firm theoretical foundation. Pretty much irrelevant theoretical nonsense with respect to the specific issue at hand, but this and to some extent the previous two responses tend to suggest a rather irrelevant approach that is not grounded in the specific Ada question at hand. The NIL/Hermes people tried to get people in the Ada community to pay attention, but they were completely ignored, and Ada95 suffered for it. Complete nonsense One has to wonder if Henry knows Ada when he writes this? ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-15 0:00 ` Henry Baker 1997-10-15 0:00 ` Robert Dewar @ 1997-10-15 0:00 ` Jon S Anthony 1997-10-16 0:00 ` Brian Rogoff 2 siblings, 0 replies; 54+ messages in thread From: Jon S Anthony @ 1997-10-15 0:00 UTC (permalink / raw) hbaker@netcom.com (Henry Baker) writes: > There are 3 solutions, any of which is better than the current Ada 'non > deterministic' solution. I pretty much agree - certainly with respect to limited types. > 1. _Always_ pass by reference. This can be forced in C/C++ by > certain coding styles. Any aliasing is assumed to be > programmer-intended, and has a relatively simple programming model. > (You may have to liberally sprinkle 'volatile'-type thingy's around > as well.) There is a certain cost, but on modern microprocessors > the cost is not exorbitant, and certainly less than the cost of a > 777. Right. Again, certainly wrt limited types. You can "force this" in Ada95 now with 'Access. This is basically what I have done in the GC subsystem suite that I have constructed in order to get around the very "Baker in out side effect problem" described in a couple of your papers. > 3. Add a new concept to your language: 'linear'/'unique' types. > These objects are guaranteed to be singly referenced because this is > enforced by the type system. Poof! No aliasing! This concept was > pioneered by NIL/Hermes, and has recently been incorporated into > some logical (prolog-like) languages and some functional languages > ('Clean' from KU Leaven). There is a large and growing body of > mathematics called 'linear logic' that puts linear types on a firm > theoretical foundation. Certainly this stuff is interesting. I'm not quite sure how it would have fit into Ada. > The NIL/Hermes people tried to get people in the Ada community to pay > attention, but they were completely ignored, and Ada95 suffered for it. Did you actually propose something along these lines during Ada9X??? /Jon -- Jon Anthony STL, Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-15 0:00 ` Henry Baker 1997-10-15 0:00 ` Robert Dewar 1997-10-15 0:00 ` Jon S Anthony @ 1997-10-16 0:00 ` Brian Rogoff 1997-10-17 0:00 ` Henry Baker 2 siblings, 1 reply; 54+ messages in thread From: Brian Rogoff @ 1997-10-16 0:00 UTC (permalink / raw) On Wed, 15 Oct 1997, Henry Baker wrote: > In article <622b4t$nhe$1@gonzo.sun3.iaf.nl>, Geert Bosch > <geert@gonzo.sun3.iaf.nl> wrote: > > ... about non-determinism and Ada parameter passing ... > > > > Do you have a proposal to remove the non-determinism without affecting > > performance and flexibility too much? I think many readers in this > > group might be interested in such ideas, at least I am. > > > > Regards, > > Geert > > 3. Add a new concept to your language: 'linear'/'unique' types. These > objects are guaranteed to be singly referenced because this is enforced > by the type system. Poof! No aliasing! This concept was pioneered by > NIL/Hermes, and has recently been incorporated into some logical (prolog-like) > languages and some functional languages ('Clean' from KU Leaven). There is a > large and growing body of mathematics called 'linear logic' that puts linear > types on a firm theoretical foundation. I remember reading something about NIL a long time ago (this is from Bell Labs, right?) and their notion of "typestates", which I think what I think you are talking about, and I thought that they stated that there was a fairly significant performance overhead in their use, and hence they wouldn't be really suitable in the role that you are proposing for them in Ada. Anyone have different information? -- Brian ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-16 0:00 ` Brian Rogoff @ 1997-10-17 0:00 ` Henry Baker 1997-10-18 0:00 ` Brian Rogoff 1997-10-18 0:00 ` Fergus Henderson 0 siblings, 2 replies; 54+ messages in thread From: Henry Baker @ 1997-10-17 0:00 UTC (permalink / raw) In article <Pine.BSF.3.96.971016131014.2530A-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > On Wed, 15 Oct 1997, Henry Baker wrote: > > In article <622b4t$nhe$1@gonzo.sun3.iaf.nl>, Geert Bosch > > <geert@gonzo.sun3.iaf.nl> wrote: > > > ... about non-determinism and Ada parameter passing ... > > > > > > Do you have a proposal to remove the non-determinism without affecting > > > performance and flexibility too much? I think many readers in this > > > group might be interested in such ideas, at least I am. > > > > > > Regards, > > > Geert > > > > 3. Add a new concept to your language: 'linear'/'unique' types. These > > objects are guaranteed to be singly referenced because this is enforced > > by the type system. Poof! No aliasing! This concept was pioneered by > > NIL/Hermes, and has recently been incorporated into some logical (prolog-like) > > languages and some functional languages ('Clean' from KU Leaven). There is a > > large and growing body of mathematics called 'linear logic' that puts linear > > types on a firm theoretical foundation. > > I remember reading something about NIL a long time ago (this is from Bell > Labs, right?) and their notion of "typestates", which I think what I > think you are talking about, and I thought that they stated that there was > a fairly significant performance overhead in their use, and hence they > wouldn't be really suitable in the role that you are proposing for them in > Ada. Anyone have different information? > > -- Brian NIL/Hermes was from IBM. There was no performance overhead that I heard of. On the contrary, by performing the typing analysis at compile time, there was no runtime overhead. NIL/Hermes was not doing rocket science, but merely doing 'right' what people in the real-time and OS communities had been doing for years already. NIL/Hermes put in type-checking to make sure that when something is supposed to be used/referenced only once, the compiler can prove this mathematically. I'll bet that nearly every Ada program has objects that are intended to be used/referenced only once, but since there is no compiler support for this notion, the software cannot be checked at compile time, and is vulnerable to programmers later doing 'maintenance'. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-17 0:00 ` Henry Baker @ 1997-10-18 0:00 ` Brian Rogoff 1997-10-18 0:00 ` Matthew Heaney 1997-10-19 0:00 ` Fergus Henderson 1997-10-18 0:00 ` Fergus Henderson 1 sibling, 2 replies; 54+ messages in thread From: Brian Rogoff @ 1997-10-18 0:00 UTC (permalink / raw) On Fri, 17 Oct 1997, Henry Baker wrote: > > NIL/Hermes was from IBM. Right, my mistake. > There was no performance overhead that I heard of. On the contrary, by > performing the typing analysis at compile time, there was no runtime > overhead. I'll have to find the ref where I thought I read about this. In any case, simply having a strong static type system does not guarantee no runtime overhead; you suggested the Haskell approach as a valid one. While Haskell code looks nice on paper the current compiler implementations are far from producing comparable code to gcc for similar problems. What I would like to be convinced is (1) An actual pseudo-Ada syntax for "unique" types in Ada. Starting from there I could see exactly how your proposal would interact with the the current Ada. (2) An implementation :-). Seeing as how GNAT is out there, there is plenty of opportunity for malcontents to lead the way by making Ada variants. You post elsewhere that Ada's flaws are well known everywhere but inside the Ada community. I think the opposite is true, lots of "flaws" in Ada, including those mentioned in your papers, are discussed on c.l.a., but the knowledge of Ada elsewhere is simplistic (ADA is kitchen sink language designed by DOD committee) and I've rarely seen useful criticisms from "outside", except for those of Ada-83 tasking. I still haven't found a widely useful language without serious flaws. The main competitor for Ada in its class is C++, and I prefer Ada. -- Brian ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-18 0:00 ` Brian Rogoff @ 1997-10-18 0:00 ` Matthew Heaney 1997-10-19 0:00 ` Brian Rogoff 1997-10-19 0:00 ` Fergus Henderson 1 sibling, 1 reply; 54+ messages in thread From: Matthew Heaney @ 1997-10-18 0:00 UTC (permalink / raw) In article <Pine.BSF.3.96.971018110638.11035B-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: Brian, to Henry: >You post elsewhere that Ada's flaws are well known everywhere but inside >the Ada community. I think the opposite is true, lots of "flaws" in Ada, >including those mentioned in your papers, are discussed on c.l.a., but the >knowledge of Ada elsewhere is simplistic (ADA is kitchen sink language >designed by DOD committee) and I've rarely seen useful criticisms from >"outside", except for those of Ada-83 tasking. I still haven't found a >widely useful language without serious flaws. The main competitor for Ada >in its class is C++, and I prefer Ada. Matt, to Brain and Henry: OK, I think we can all agree that aliasing can break a limited abstraction. But in Ada 95 the programmer can implement the full view of a limited private type as a by-reference type, either by 1. Implementing the type as a record marked as limited, or 2. Privately implementing the type as tagged. In code, something like private type LT is limited record O : <your favorite copy-in, copy-out type here> end record; end; or private type LT is tagged record O : <your fave scalar type here> end record; end; We could even combine these ideas: private type LT is tagged limited record O : T; end record; end; My question is, Why is this considered a "serious flaw" in Ada? Don't the implementation techniques listed above solve the aliasing problem? Perhaps the area of contention is the fact that the language doesn't require a limited private type to be implemented using a by-reference type (ie Baker's limited bank account is implemented as a scalar, fixed point type, which must be passed copy-in, copy-out). Is that the case? Can we solve that issue, by requiring compiler warnings, or a suitable invokation of pragma Restrictions? -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-18 0:00 ` Matthew Heaney @ 1997-10-19 0:00 ` Brian Rogoff 1997-10-21 0:00 ` Robert A Duff 0 siblings, 1 reply; 54+ messages in thread From: Brian Rogoff @ 1997-10-19 0:00 UTC (permalink / raw) On Sat, 18 Oct 1997, Matthew Heaney wrote: > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > Brian, to Henry: > > >You post elsewhere that Ada's flaws are well known everywhere but inside > >the Ada community. I think the opposite is true, lots of "flaws" in Ada, > >including those mentioned in your papers, are discussed on c.l.a., but the > >knowledge of Ada elsewhere is simplistic (ADA is kitchen sink language > >designed by DOD committee) and I've rarely seen useful criticisms from > >"outside", except for those of Ada-83 tasking. I still haven't found a > >widely useful language without serious flaws. The main competitor for Ada > >in its class is C++, and I prefer Ada. > > Matt, to Brain and Henry: Matt, I'm agnostic about the seriousness of this "flaw". Jon Anthony mentioned that he thought it was pretty bad (even still in Ada 95), so I'm waiting for his arguments. I haven't written code yet where the limited view stuff you mention would not be an acceptable workaround, but I am working on different things, The Ada flaws in Henry Bakers papers that I personally find just as annoying in (the non-concurrent subset of ) Ada 95 are (1) No out mode in functions (2) No ability to interleave public and private parts in package specs (3) No mutually recursion across package specs (4) No "downward funargs" (fixed in GNAT with Unrestricted_Access attribute) and even though Henry Baker didn't mention it, I wish there was some form of automatic instantiation for Ada generics a la Shen and Cormack. OTOH, the existence of Ada.Interfaces packages is way more important than any of these "flaws". I'm pragmatic too. -- Brian ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-19 0:00 ` Brian Rogoff @ 1997-10-21 0:00 ` Robert A Duff 1997-10-22 0:00 ` Robert Dewar 1997-10-23 0:00 ` Brian Rogoff 0 siblings, 2 replies; 54+ messages in thread From: Robert A Duff @ 1997-10-21 0:00 UTC (permalink / raw) In article <Pine.BSF.3.96.971019135319.3201C-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> wrote: > The Ada flaws in Henry Bakers papers that I personally find >just as annoying in (the non-concurrent subset of ) Ada 95 are > > (1) No out mode in functions > (2) No ability to interleave public and private parts in > package specs > (3) No mutually recursion across package specs > (4) No "downward funargs" (fixed in GNAT with Unrestricted_Access > attribute) I agree those are annoying. I don't think GNAT "fixes" number (4) properly, though. 'Unrestricted_Access is inherently unsafe -- you can create dangling pointers with it. This is unfortunate, since it's easy to design a feature that provides downward closures without that problem. Several such alternatives were proposed during the Ada 9X project. For example, limited access types. By the way, here's one of my gripes about Ada's limited types: For a non-limited record, you can initialize an object in a way that guarantees you don't forget any components: X := new T'(Comp1 => This, Comp2 => That, Comp3 => The_Other); If I add a Comp4 component to type T, but forget to modify the above assignment, I'll be told about it at compile time, which is nice. Unfortunately, there's no such feature for limited records -- aggregates are illegal. Of course, since most languages don't even *have* limited types, the above complaint has to be considered minor. - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-21 0:00 ` Robert A Duff @ 1997-10-22 0:00 ` Robert Dewar 1997-10-22 0:00 ` Brian Rogoff 1997-10-23 0:00 ` Henry Baker 1997-10-23 0:00 ` Brian Rogoff 1 sibling, 2 replies; 54+ messages in thread From: Robert Dewar @ 1997-10-22 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> wrote: > The Ada flaws in Henry Bakers papers that I personally find >just as annoying in (the non-concurrent subset of ) Ada 95 are > > (1) No out mode in functions > (2) No ability to interleave public and private parts in > package specs > (3) No mutually recursion across package specs > (4) No "downward funargs" (fixed in GNAT with Unrestricted_Access > attribute) Interesting list. Let's look at them. (1) No out mode in functions This restriction is there because of a pretty clear consensus that it would be a bad idea to allow out mode in functions. Yes, it is true that Robert Dewar, and Bob Duff, and Brian as well disagree, but we are in a clear minority. Furthermore a significant section of the majority is VERY vocal on this issue. When the Ada 9X requirements were written, we included removing this restriction as an example of a possible restriction to be removed. The only reactions we got at all from the general list on the requirements were several violent reactions against this suggestion. When the matter was discussed several times in WG9, there was always a very strong majority against any change. So you may not like this, but it is pretty clear what people's taste is here. Note that in GNAT, we have implemented the Valued_Procedure pragmas from DEC Ada, which allow you to at least solve the most pressing case of this problem in connection with imported functions that have out parameters (you can even use this with convention Ada, but that would be a bit naughty). (2) No ability to interleave public and private parts in package specs Again, this is a very strong and intentional part of the design, for which there has never been any consensus for change (though certainly implementors would far prefer a style in which individual declarations were marked private :-) (3) No mutually recursion across package specs Extensively discussed. As per these discussions, not such an easy problem to solve, but Tuck's "with type" proposal is interesting. As a point of interest, not one of our customers has even suggested this as a desirable extension to GNAT, let alone suggested that they would be willing to pay for it, so I wonder just how much it affects things in practice. One thing to remember about CLA, is that most Ada programmers do not spend time reading it. The population of CLA is very heavily over- weighted with people who like to play with the language, and debate entertaining uses of abstractions, as opposed to people actually building large applications, who tend to have different concerns. (4) No "downward funargs" (fixed in GNAT with Unrestricted_Access attribute) This was a quite different case. It arose from concern about existing implementations using displays for implementing subprograms. It is quite clear to me that in Ada 83, displays are definitely more efficient than static links. This is because you only pay an overhead for calling a subprogram that *contains* nested subprograms, rather than an overhead for calling a nested subprogram. The former is dyanamically much less common than the latter. Steelman in fact understood the efficiency gain to be obtained here, and one of many reasons for Steelman prohibiting subprogram pointers was to avoid inefficiencies in uplevel reference handling, since Steelman correctly anticipates that nested subprograms would be very common in Ada programs. Since major implementations did in fact use displays, and would have been significantly impacted by a decision that would require a change. In particular, the Alsys implementations (now Object Ada) would have been negatively impacted, and indeed it is interesting to note that there is no simple way for Object Ada to provide the equivalent of GNAT's Unrestricted_Access. Was this the right decision? Hard to say. Certainly GNAT uses static links anyway, since GNU C made this decision (after all C does most certainly have function pointers :-) But Object Ada could well have been significantly affected. Remember that the Ada 9X revision was already large enough to knock one major player out of the ring (as Bevin will tell you, the extent of the Ada 95 changes was a major factor in DEC's decision to withdraw from the Ada implementation arena). As for Bob Duff's concerns about the inherent lack of safety in Unrestricted_Access, I think in practice it is more theory than practice. One tends to use Unrestricted_Access in very stylized manners within abstractions where it is safe. We have not seen one bug in our own code, or in customers code, from the use of this attribute in GNAT. Robert Dewar Ada Core Technologies ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-22 0:00 ` Robert Dewar @ 1997-10-22 0:00 ` Brian Rogoff [not found] ` <dewar.877601826@merv> 1997-10-23 0:00 ` Henry Baker 1 sibling, 1 reply; 54+ messages in thread From: Brian Rogoff @ 1997-10-22 0:00 UTC (permalink / raw) On 22 Oct 1997, Robert Dewar wrote: > Brian Rogoff <bpr@shell5.ba.best.com> wrote: > > The Ada flaws in Henry Bakers papers that I personally find > >just as annoying in (the non-concurrent subset of ) Ada 95 are ... deleted ... > > Interesting list. Let's look at them. ... deleted ... > (2) No ability to interleave public and private parts in > package specs > > Again, this is a very strong and intentional part of the design, for > which there has never been any consensus for change (though certainly > implementors would far prefer a style in which individual declarations > were marked private :-) Was it ever brought up, and violently reacted too? As was pointed out this restriction is a nuisance in Ada 95 in that it makes it clumsier to use generic signature packages. > (3) No mutually recursion across package specs > > Extensively discussed. As per these discussions, not such an easy > problem to solve, but Tuck's "with type" proposal is interesting. > As a point of interest, not one of our customers has even suggested > this as a desirable extension to GNAT, let alone suggested that they > would be willing to pay for it, so I wonder just how much it affects > things in practice. Your customers are probably clustered about some application domain, such as emdedded applications. I believe Tucker Taft said he started working on the "with type" stuff because of issues interfacing to Java. > (4) No "downward funargs" (fixed in GNAT with Unrestricted_Access > attribute) I'll note that after I read the arguments on this I agreed that omitting this was correct, though I am still annoyed. > As for Bob Duff's concerns about the inherent lack of safety in > Unrestricted_Access, I think in practice it is more theory than > practice. One tends to use Unrestricted_Access in very stylized > manners within abstractions where it is safe. We have not seen > one bug in our own code, or in customers code, from the use of > this attribute in GNAT. I'd prefer a standardized alternative, but I have no problem being tied to GNAT for now. As far as safety, I rather agree with Bob Duff but an unsafe implementation beats a safer proposal. :-) -- Brian ^ permalink raw reply [flat|nested] 54+ messages in thread
[parent not found: <dewar.877601826@merv>]
* Re: Depending on passing mechanism [not found] ` <dewar.877601826@merv> @ 1997-10-23 0:00 ` Brian Rogoff 0 siblings, 0 replies; 54+ messages in thread From: Brian Rogoff @ 1997-10-23 0:00 UTC (permalink / raw) On 23 Oct 1997, Robert Dewar wrote: > <<Your customers are probably clustered about some application domain, such > as emdedded applications>> > > Not at all, we have some customers who do embedded applications, but, as > you would expect from the wide availability of GNAT on many targets, and > the fact that it is still the only 100% complete implementation of Ada 95, > it is widely used in all domains. OK, you would say then that your customers are fairly evenly distributed and there is no significant majority of customer application domains? > What is true is that our customers fit the profile of trying to solve > real problems, rather than fiddling around with neat things you can do > in the language, and in that kind of environment, you keep things simple, > and stay away from the "look what neat abstrctions we can build" style > of thinking. I often notice a big gap between real Ada users, and the > CLA contributors, and with rare execptions, it is interesting to note > that almost none of our customers read CLA regularly. Certainly true in my case, I'm an Ada hacker :-) at home only, the number of Ada jobs in my geographic location (Silicon Valley) and in my specialty fields is negligible. C and C++ are far more popular, with Java also making inroads. -- Brian ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-22 0:00 ` Robert Dewar 1997-10-22 0:00 ` Brian Rogoff @ 1997-10-23 0:00 ` Henry Baker 1 sibling, 0 replies; 54+ messages in thread From: Henry Baker @ 1997-10-23 0:00 UTC (permalink / raw) In article <dewar.877514974@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > Interesting list. Let's look at them. > > (1) No out mode in functions > > This restriction is there because of a pretty clear consensus that it > would be a bad idea to allow out mode in functions. The academics who wrote this into the original specifications for Ada were more interested in doing research in _automatic_ software verification than in actually programming real systems that did real things. Their research failed miserably, but we are left with their misguided attempts to simplify their efforts in Ada. You will notice that in other languages where people actually had to get programs written and systems delivered, this restriction has been dropped, mainly because of my previous posting -- that the language wasn't sophisticated enough to distinguish between 'benign'/'hidden' side-effects and not-so-hidden side-effects. This is an example of a 'fascist' attitude for style over substance that Dilbert gets so much mileage out of. > (2) No ability to interleave public and private parts in > package specs > > Again, this is a very strong and intentional part of the design, for > which there has never been any consensus for change (though certainly > implementors would far prefer a style in which individual declarations > were marked private :-)\ As I have shown through examples before, this is not merely a stylistic issue. If it were, I would be much less adamant. But through the various non-orthogonal interactions of the features of Ada, you actually lose significant expressive power. This is another example of style over substance. > (3) No mutually recursion across package specs > > Extensively discussed. As per these discussions, not such an easy > problem to solve, but Tuck's "with type" proposal is interesting. > As a point of interest, not one of our customers has even suggested > this as a desirable extension to GNAT, let alone suggested that they > would be willing to pay for it, so I wonder just how much it affects > things in practice. This is a most insidious restriction, because one spends a huge amount of time performing very unnatural acts upon packages to try to get around it. It is a serious flaw, that reduces the amount of intelligence that one can put into buttoned-up, prepackaged, off-the-shelf solutions for others. > (4) No "downward funargs" (fixed in GNAT with Unrestricted_Access > attribute) > This was a quite different case. It arose from concern about existing > implementations using displays for implementing subprograms. It is > quite clear to me that in Ada 83, displays are definitely more efficient > than static links. This is because you only pay an overhead for calling > a subprogram that *contains* nested subprograms, rather than an > overhead for calling a nested subprogram. The former is dyanamically > much less common than the latter. You haven't seen 'lambda-lifting', have you. > Steelman in fact understood the efficiency gain to be obtained here, > and one of many reasons for Steelman prohibiting subprogram pointers > was to avoid inefficiencies in uplevel reference handling, since > Steelman correctly anticipates that nested subprograms would be > very common in Ada programs. Ada people didn't listen to their critics in this case. SRI and MIT evaluated Ada and specifically pointed out this lack (in writing) as a serious problem for large scale systems. Without closures -- even downward closures -- you can't do call-backs. (They weren't called call-backs in the mid-1970's, but they were extensively used, non-the-less.) ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-21 0:00 ` Robert A Duff 1997-10-22 0:00 ` Robert Dewar @ 1997-10-23 0:00 ` Brian Rogoff 1 sibling, 0 replies; 54+ messages in thread From: Brian Rogoff @ 1997-10-23 0:00 UTC (permalink / raw) On Tue, 21 Oct 1997, Robert A Duff wrote: > > By the way, here's one of my gripes about Ada's limited types: For a > non-limited record, you can initialize an object in a way that > guarantees you don't forget any components: > > X := new T'(Comp1 => This, Comp2 => That, Comp3 => The_Other); > > If I add a Comp4 component to type T, but forget to modify the above > assignment, I'll be told about it at compile time, which is nice. > Unfortunately, there's no such feature for limited records -- aggregates > are illegal. Yes, I always wondered if initialization should be decoupled from assignment in the case of limited types. -- Brian ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-18 0:00 ` Brian Rogoff 1997-10-18 0:00 ` Matthew Heaney @ 1997-10-19 0:00 ` Fergus Henderson 1997-10-19 0:00 ` Brian Rogoff 1997-10-20 0:00 ` Henry Baker 1 sibling, 2 replies; 54+ messages in thread From: Fergus Henderson @ 1997-10-19 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> writes: >On Fri, 17 Oct 1997, Henry Baker wrote: >> >> NIL/Hermes was from IBM. > >Right, my mistake. > >> There was no performance overhead that I heard of. On the contrary, by >> performing the typing analysis at compile time, there was no runtime >> overhead. > >I'll have to find the ref where I thought I read about this. In any case, >simply having a strong static type system does not guarantee no runtime >overhead; you suggested the Haskell approach as a valid one. While Haskell >code looks nice on paper the current compiler implementations are far from >producing comparable code to gcc for similar problems. The differences in efficiency are mostly due to unrelated factors: - laziness - different coding styles Haskell code often allocates lots of garbage, makes significant use of higher-order functions, etc. But a language which does have some support for unique types and which generates code which is often comparable with gcc, assuming similar coding styles in the source code, is Mercury <http://www.cs.mu.oz.au/mercury>. How close do you have to get to be "comparable"? >What I would like >to be convinced is > >(1) An actual pseudo-Ada syntax for "unique" types in Ada. Starting from > there I could see exactly how your proposal would interact with the > the current Ada. Well, I'd go for unique modes, rather than unique types. In addition to "in", "out", and "inout", add "unique_in", "destructive_in", "unique_out", and "unique_inout", with semantics similar to the unique modes in Mercury. Some work would be required to specify the semantics precisely... -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-19 0:00 ` Fergus Henderson @ 1997-10-19 0:00 ` Brian Rogoff 1997-10-20 0:00 ` Fergus Henderson 1997-10-20 0:00 ` Henry Baker 1 sibling, 1 reply; 54+ messages in thread From: Brian Rogoff @ 1997-10-19 0:00 UTC (permalink / raw) On 19 Oct 1997, Fergus Henderson wrote: > Brian Rogoff <bpr@shell5.ba.best.com> writes: > >I'll have to find the ref where I thought I read about this. In any case, > >simply having a strong static type system does not guarantee no runtime > >overhead; you suggested the Haskell approach as a valid one. While Haskell > >code looks nice on paper the current compiler implementations are far from > >producing comparable code to gcc for similar problems. > > The differences in efficiency are mostly due to unrelated factors: > - laziness > - different coding styles > Haskell code often allocates lots of garbage, > makes significant use of higher-order functions, > etc. By laziness, I assume Fergus here means that Haskell uses lazy evaluation, (expressions are not evaluated until their values are needed) not that Haskell compiler writers are a lazy bunch :-). > But a language which does have some support for unique types > and which generates code which is often comparable with gcc, > assuming similar coding styles in the source code, is Mercury > <http://www.cs.mu.oz.au/mercury>. OK, reading about Mercury was on my "to do" list, I guess now is the time. > How close do you have to get to be "comparable"? No "distributed overhead", by which I mean a program not using "unique modes" is not any worse off than it would be if there were no unique modes at all, modulo increased compile time if it isn't too much. Mercury is a logic programming language; would you use it for applications which require lots of in place array manipulation (numerical linear algebra, image proceesing, raster graphics, ...)? I'll read some of your papers; I just want to get a sense of whether Mercury is a very general purpose compiled language (like Ada or C++) or if it is mostly for symbolic processing. > >What I would like > >to be convinced is > > > >(1) An actual pseudo-Ada syntax for "unique" types in Ada. Starting from > > there I could see exactly how your proposal would interact with the > > the current Ada. > > Well, I'd go for unique modes, rather than unique types. > In addition to "in", "out", and "inout", add > "unique_in", "destructive_in", "unique_out", and "unique_inout", > with semantics similar to the unique modes in Mercury. Yes, that makes much more sense, especially considering (negatively) Ada's limited types. > Some work would be required to specify the semantics precisely... What I worry about is that there might be odd feature interactions. The devil is in the details I suppose. -- Brian ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-19 0:00 ` Brian Rogoff @ 1997-10-20 0:00 ` Fergus Henderson 0 siblings, 0 replies; 54+ messages in thread From: Fergus Henderson @ 1997-10-20 0:00 UTC (permalink / raw) Brian Rogoff <bpr@shell5.ba.best.com> writes: >Fergus Henderson wrote: >> How close do you have to get to be "comparable"? > >No "distributed overhead", by which I mean a program not using "unique >modes" is not any worse off than it would be if there were no unique modes >at all, modulo increased compile time if it isn't too much. That is indeed the case. It is just a compile-time analysis that rejects certain programs. There's no run-time overhead. >Mercury is a logic programming language; would you use it for applications >which require lots of in place array manipulation (numerical linear >algebra, image proceesing, raster graphics, ...)? I'll read some of your >papers; I just want to get a sense of whether Mercury is a very general >purpose compiled language (like Ada or C++) or if it is mostly for >symbolic processing. Mercury is intended to be a general purpose compiled language, though probably not _quite_ as general as Ada and C++. Mercury is a bit higher-level than Ada or C++ -- for example, it has garbage collection, and (like Java) there is no stack allocation. Mercury doesn't go to so much effort in supporting low-level code -- for example, it has no equivalent to Ada's record representation specs. But (looking only at the languages, and ignoring issues like availability of compilers, libraries, etc.) Mercury should be a reasonable choice for most of the things where say Java is a reasonable choice. Regarding in place update, well, that is exactly what unique modes are used for in Mercury. Since Mercury is a single-assignment language, there is no direct equivalent to Ada's "inout" mode. Instead, you use a pair of arguments, one with mode "in" and the other with mode "out". If you want in place update, then you use "destructive_in" and "unique_out" instead of "in" and "out". Mercury was designed to make it possible to write code that needs lots of in place update. As to whether it is _easier_ to write that sort of code in a language like Mercury (which is quite amenable to formal methods) or in a language which has more direct support for updates with side effects (which can consequently make it a bit more difficult to reason about programs), I think it is still an open question. There are probably lots of languages which currently have better library support for things like numerical linear algebra, image processing, etc., starting with Fortran. But certainly it is quite _possible_ to write that sort of thing in Mercury. And our initial experiences with this have been pretty positive. For example, we have an OpenGL interface, and we have written some programs using this; from memory, I think profiling showed that most of the time was spent inside the OpenGL primitives, so we are efficient enough for this application, at least. Anyway, enough advertising for one day ;-) -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-19 0:00 ` Fergus Henderson 1997-10-19 0:00 ` Brian Rogoff @ 1997-10-20 0:00 ` Henry Baker 1997-10-20 0:00 ` Tucker Taft 1 sibling, 1 reply; 54+ messages in thread From: Henry Baker @ 1997-10-20 0:00 UTC (permalink / raw) In article <62ckao$827@mulga.cs.mu.OZ.AU>, fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) wrote: > Well, I'd go for unique modes, rather than unique types. > In addition to "in", "out", and "inout", add > "unique_in", "destructive_in", "unique_out", and "unique_inout", > with semantics similar to the unique modes in Mercury. This points up a 'meta' level problem with Ada83, which wasn't really fixed in Ada95: Ada separated the issues of parameter-passing 'modes' from 'types'. Unfortunately, the author of a private/limited type wants to control the way it is passed and returned, and allowing the user of the type to make this choice is asking for trouble. I seem to recall one of Tucker Taft's early proposals in which a solution to this problem was attempted. Apparently, this proposal got soundly blasted, and it sank without much of a trace. Pity. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-20 0:00 ` Henry Baker @ 1997-10-20 0:00 ` Tucker Taft 1997-10-21 0:00 ` Geert Bosch 0 siblings, 1 reply; 54+ messages in thread From: Tucker Taft @ 1997-10-20 0:00 UTC (permalink / raw) Henry Baker (hbaker@netcom.com) wrote: : ... : This points up a 'meta' level problem with Ada83, which wasn't really fixed : in Ada95: Ada separated the issues of parameter-passing 'modes' from : 'types'. Unfortunately, the author of a private/limited type wants to : control the way it is passed and returned, and allowing the user of the : type to make this choice is asking for trouble. I seem to recall one of : Tucker Taft's early proposals in which a solution to this problem was : attempted. Apparently, this proposal got soundly blasted, and it sank : without much of a trace. Pity. As others have pointed out, in Ada 95 you *do* have control when implementing a type to either force by-reference (by making the underlying type tagged, protected, task, or limited record), to force by-copy (by making the underlying type elementary), or to indicate you "don't care" by using some other kind of type. This seems to provide all the control you need to solve the problems Henry identified in his paper on stealing from limited types that (might) use by-copy. The other kind of stealing is associated with unsynchronized simultaneous access, and in that case, by making the underlying type "protected," you get both exclusive access and by-reference parameter passing. I don't think Ada 95 has a problem in this area any more. The implementor of a type has full control. -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-20 0:00 ` Tucker Taft @ 1997-10-21 0:00 ` Geert Bosch 0 siblings, 0 replies; 54+ messages in thread From: Geert Bosch @ 1997-10-21 0:00 UTC (permalink / raw) Tucker Taft <stt@houdini.camb.inmet.com> wrote: ``As others have pointed out, in Ada 95 you *do* have control when implementing a type to either force by-reference (by making the underlying type tagged, protected, task, or limited record)'' For those cases where you do not want a type to be limited, but you want to enforce passing-by-reference semantics, it is also possible to use a record with a volatile component. type Volatile_Type is null record; pragma Volatile (Volatile_Type); type Account is record Force_By_Reference : Volatile_Type; Amount : Currency_Type; end record; This enforces pass-by-reference semantics for any object of type account without extra space or time overhead and without limiting assignment. Regards, Geert ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-17 0:00 ` Henry Baker 1997-10-18 0:00 ` Brian Rogoff @ 1997-10-18 0:00 ` Fergus Henderson 1 sibling, 0 replies; 54+ messages in thread From: Fergus Henderson @ 1997-10-18 0:00 UTC (permalink / raw) hbaker@netcom.com (Henry Baker) writes: > 3. Add a new concept to your language: 'linear'/'unique' types. These > objects are guaranteed to be singly referenced because this is enforced > by the type system. Poof! No aliasing! This concept was pioneered by > NIL/Hermes, and has recently been incorporated into some logical > (prolog-like) languages and some functional languages ('Clean' from KU > Leaven). There is a large and growing body of mathematics called > 'linear logic' that puts linear types on a firm theoretical foundation. Minor correction: I think the language Clean comes from KU (Katholieke Universiteit) Nijmegan in the Netherlands, not KU Leuven in Belgium. For more info on Clean, see <http://www.cs.kun.nl/~clean>. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-15 0:00 ` Geert Bosch 1997-10-15 0:00 ` Henry Baker @ 1997-10-15 0:00 ` Robert Dewar 1997-10-15 0:00 ` Robert Dewar 1997-10-15 0:00 ` Brian Rogoff 1 sibling, 2 replies; 54+ messages in thread From: Robert Dewar @ 1997-10-15 0:00 UTC (permalink / raw) Henry Baker <hbaker@netcom.com> replied: ``This is another one of those cases that give standards bodies such a bad name -- the behavior is well-defined as 'non-deterministic', but non-functional.'' Anyone who thinks that non-determinisitc = non-functional has some strqange misconceptions. In practice, for languages designed for efficiency, you often leave some apsects of behavior non-deterministic for very good reasons. The case at hand is a good example. To specify call by value or call by reference for arrays can lead to highly inefficient code in some circumstances. Similarly, over-constraining the order of evaluation (which affects only programs with strange side effects) can significantly damange the efficiency of generated code. In a later note to me (perhaps posted here I don't know), Henry commented that the amazing Java eliminates non-determinism. This is true, but the cost is very substantial in terms of the effect on efficiency of generated code. For example, the requirement for absolute adherence to IEEE would create efficiency catastrophes on machines like the Alpha and R10000, which are very nearly IEEE compliant but not quite. I say "would" because in practice Java implementations are quite cavalier about such details (you may remember a student who was studying fpt portability posting a note here that summarized his experience -- Ada good, Java terrible). Yes, if you don't care much about efficiency you can eliminate some but not all non-determinism (if you have tasking of some time, you cannot go all the way to eliminating ND, though certainly Ada's annex D goes pretty far along this route, about as far as is practical). As for non-determinism causing lack of functionality, it is certainly true that incompetent programmers who do not understand the language can create non-portable programs this way, but I must say that the particular example here is not one which seems to cause difficulties in practice. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-15 0:00 ` Robert Dewar @ 1997-10-15 0:00 ` Robert Dewar 1997-10-17 0:00 ` Andre Spiegel 1997-10-15 0:00 ` Brian Rogoff 1 sibling, 1 reply; 54+ messages in thread From: Robert Dewar @ 1997-10-15 0:00 UTC (permalink / raw) Henry suggests <<1. _Always_ pass by reference. This can be forced in C/C++ by certain coding styles. Any aliasing is assumed to be programmer-intended, and has a relatively simple programming model. (You may have to liberally sprinkle 'volatile'-type thingy's around as well.) There is a certain cost, but on modern microprocessors the cost is not exorbitant, and certainly less than the cost of a 777.>> This is VERY difficult in distributed environments where there is no shared memory between caller and callee, and prohibitively expensive. (The 777 rhetoric does not make this problem go away!) It is of course possible to force this same effect in Ada 95, by the use of access parameters, or by-reference types. <<2. _Always_ pass by value. This is really possible only in a 100% functional language like Haskell.>> Nonsense, it is always possible to pass by value, I have no idea what Henry is talking about when he says this. Certainly not Ada. The penalty for passing by value is simply the cost of copying (once for in parameters, twice for in out), but these copies can be prohibitively expensive for large arrays. <<3. Add a new concept to your language: 'linear'/'unique' types. These objects are guaranteed to be singly referenced because this is enforced by the type system. Poof! No aliasing! This concept was pioneered by NIL/Hermes, and has recently been incorporated into some logical (prolog-like) languages and some functional languages ('Clean' from KU Leaven). There is a large and growing body of mathematics called 'linear logic' that puts linear types on a firm theoretical foundation.>> Well certainly not relevant to the issue at hand, and I find the attempt to connect the foundation of this programming language idea, which is shaky, with linear logic, which is not, tenuous at best! <<The NIL/Hermes people tried to get people in the Ada community to pay attention, but they were completely ignored, and Ada95 suffered for it.>> The contribution was not relevant, and the price is imaginary. Not clear that this has much to do with the actual problem at hand, which is figuring out the desirable semantics for parameter passing in Ada 95. Note incidentally that Ada 95 is very different from Ada 83 here. In Ada 83, an execution whose effect depended on the parameter passing mechanism was erroneous, but effect was ill-defined. In Ada 95, the semantics of programs that depend on the passing mechanism is simply non-deterministic. Note that almost no reasonably written program will depend on the passing mechanism -- indeed the SPARK subset which someone alluded to does not eliminate the non-determinism in a formal sense, it just makes sure that it could not affect the results, which will typically be achieved in most programs in any case.) ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-15 0:00 ` Robert Dewar @ 1997-10-17 0:00 ` Andre Spiegel 1997-10-17 0:00 ` Henry Baker 0 siblings, 1 reply; 54+ messages in thread From: Andre Spiegel @ 1997-10-17 0:00 UTC (permalink / raw) Regarding parameter passing mechanisms, particularly in Distributed Systems, I think there are two possible approaches. (1) Leave it up to the programmer to chose by-copy vs. by-reference for each subprogram parameter explicitly. This way, the programmer can chose the passing mechanism that best fits a given situation. For example, if the call goes across a distribution boundary, by-copy might be preferable, etc. Drawback: the decisions for one particular setting, machine, compiler might not be optimal for another one. For example, if the call that used to go across a distribution boundary becomes a local call at a later stage, by-copy might impose an unnecessary cost. Also, the programmer might not have enough information to make the right decision, or simply not care. The advantage of this scheme, however, is that program behavior never changes if you move to a different target, compiler, or distribution scenario. It might become less efficient and sub-optimal, but nothing worse. Some of the proposed schemes for CORBA "Objects-by-Value" work this way. Ada does not let you do it -- at least not quite, see below. (2) Let the compiler make the decision. The programmer specifies the "intent" of the parameter in a more abstract way. This is what Ada always did, through "in", "out", and "in out". The advantage is higher efficiency. Passing mechanisms may be employed automatically in an optimal way to make use of hardware characteristics, and to support given distribution scenarios. The drawback is non-deterministic program behavior, if only in rare circumstances that could well be called pathological. However, Ada 95 does alleviate this somewhat, through "access" parameters. If the programmer uses "in out", he says in fact that he is willing to accept the non-determinism, and leaves the optimal decision to the compiler. But if for some reason he needs clear-cut behavior, "access" parameters can be used to guarantee by-reference semantics, no matter what. There is no corresponding means to force _by-copy_ semantics in Ada 95. However, one might say that "in out" parameters are conceptually closer to by-copy than to by-reference. The reason is that if an "in out" parameter is passed by reference, the callee does not "see" this reference, and hence, cannot store it anywhere to create additional aliasing. If the parameter is copied, the _value_ is in fact copied, and the reference broken. I think this way of handling parameters makes Ada particularly suitable for distributed systems with a high degree of transparency, i.e. where the programmer does not necessarily know where distribution boundaries will be at run-time. Andre Spiegel Free University of Berlin ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-17 0:00 ` Andre Spiegel @ 1997-10-17 0:00 ` Henry Baker 1997-10-17 0:00 ` Robert I. Eachus ` (2 more replies) 0 siblings, 3 replies; 54+ messages in thread From: Henry Baker @ 1997-10-17 0:00 UTC (permalink / raw) In article <x2yb3simp9.fsf@moon.inf.fu-berlin.de>, Andre Spiegel <spiegel@inf.fu-berlin.de> wrote: > (2) Let the compiler make the decision. The programmer specifies > the "intent" of the parameter in a more abstract way. This is > what Ada always did, through "in", "out", and "in out". The > advantage is higher efficiency. Passing mechanisms may be > employed automatically in an optimal way to make use of hardware > characteristics, and to support given distribution scenarios. > The drawback is non-deterministic program behavior, if only in > rare circumstances that could well be called pathological. > I think this way of handling parameters makes Ada particularly > suitable for distributed systems with a high degree of transparency, > i.e. where the programmer does not necessarily know where distribution > boundaries will be at run-time. > > Andre Spiegel > Free University of Berlin My paper (ftp://ftp.netcom.com/pub/hb/hbaker/LimitedRobbery.html) shows how copy-in, copy-out semantics violates the notion of limited private types, and is therefore a dangerous idea. I don't expect to change anyone's mind, but you should be aware that Ada has serious flaws that are visible to those outside the Ada community, although (apparently) are not visible to those within the community. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-17 0:00 ` Henry Baker @ 1997-10-17 0:00 ` Robert I. Eachus 1997-10-17 0:00 ` Jon S Anthony 1997-10-21 0:00 ` Robert A Duff 2 siblings, 0 replies; 54+ messages in thread From: Robert I. Eachus @ 1997-10-17 0:00 UTC (permalink / raw) In article <hbaker-1710970939160001@10.0.2.1> hbaker@netcom.com (Henry Baker) writes: > My paper (ftp://ftp.netcom.com/pub/hb/hbaker/LimitedRobbery.html) shows > how copy-in, copy-out semantics violates the notion of limited private > types, and is therefore a dangerous idea. > I don't expect to change anyone's mind, but you should be aware that > Ada has serious flaws that are visible to those outside the Ada community, > although (apparently) are not visible to those within the community. Ada 95 RM 6.2(4..10): "A type is a _by-reference_ type if it is a descendent of one of the following: ... a nonprivate type with the reserved word limited in its declaration; a composite type with a subcomponent of a by-reference type; a private type whoes full type is a by-reference type; A parameter of a by-reference type is passed by reference..." To everyone other than Henry Baker this says that there is no problem of copy-in copy-out semantics in Ada 95 for limited private types since it isn't allowed. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-17 0:00 ` Henry Baker 1997-10-17 0:00 ` Robert I. Eachus @ 1997-10-17 0:00 ` Jon S Anthony 1997-10-21 0:00 ` Robert A Duff 2 siblings, 0 replies; 54+ messages in thread From: Jon S Anthony @ 1997-10-17 0:00 UTC (permalink / raw) hbaker@netcom.com (Henry Baker) writes: > My paper (ftp://ftp.netcom.com/pub/hb/hbaker/LimitedRobbery.html) shows > how copy-in, copy-out semantics violates the notion of limited private > types, and is therefore a dangerous idea. Yes, that's correct. It was this paper in particular that made me force the issue with access parameters for the limited types I use in the GC asset suite I've constructed. Yes, it kinda sucks because it forces a lot of explicitly "aliased" junk. > I don't expect to change anyone's mind, but you should be aware that > Ada has serious flaws that are visible to those outside the Ada > community, although (apparently) are not visible to those within the > community. Well, I certainly understand and appreciate what you are saying here. This particular cock-up made my top list of goofs in a previous thread... /Jon -- Jon Anthony Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-17 0:00 ` Henry Baker 1997-10-17 0:00 ` Robert I. Eachus 1997-10-17 0:00 ` Jon S Anthony @ 1997-10-21 0:00 ` Robert A Duff 1997-10-21 0:00 ` Peter Hermann 1997-10-22 0:00 ` Henry Baker 2 siblings, 2 replies; 54+ messages in thread From: Robert A Duff @ 1997-10-21 0:00 UTC (permalink / raw) In article <hbaker-1710970939160001@10.0.2.1>, Henry Baker <hbaker@netcom.com> wrote: >My paper (ftp://ftp.netcom.com/pub/hb/hbaker/LimitedRobbery.html) shows >how copy-in, copy-out semantics violates the notion of limited private >types, and is therefore a dangerous idea. I read this paper some time ago, and it was quite correct with respect to Ada 83. But in Ada 95, one can declare limited records, which are always passed by reference, and returned from functions by reference, so the programmer of the abstraction *can* solve the problem. Admittedly, the programmer can screw up, but the point is that if the programmer of the abstraction does it right, then the *clients* can't do the "limited robbery" thing pointed out in this paper. So, Henry, do you claim that that this Ada 83 problem is still present in Ada 95? I claim it's been fixed as best it could, given upward compatibility concerns. >I don't expect to change anyone's mind, but you should be aware that >Ada has serious flaws that are visible to those outside the Ada community, >although (apparently) are not visible to those within the community. Grr. *I'm* not claiming that Ada is God's gift (though some might). IMHO, Ada is a horrible programming language -- but many others (including *all* the popular ones) are far worse! ;-) When you gripe about some supposed flaw in Ada, you should make it clear what you're comparing it to -- C? C++? Common Lisp? Some obscure functional language? Some ideal language in your head? -- all of those can be valuable criticisms, but it's helpful to know whether "Ada's limited types suck" is said in relation to a language that even *has* a concept of limited types! - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-21 0:00 ` Robert A Duff @ 1997-10-21 0:00 ` Peter Hermann 1997-10-22 0:00 ` Robert A Duff 1997-10-22 0:00 ` Henry Baker 1 sibling, 1 reply; 54+ messages in thread From: Peter Hermann @ 1997-10-21 0:00 UTC (permalink / raw) this thread has become very interesting due to a couple of valuable contributions. thank you all. You really have upvalued comp.lang.ada for a while. I am wondering why the SPARK approach (J.Barnes) has not been mentioned in this context. (unfortunately I am not yet through the book) -- Peter Hermann Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen Team Ada: "C'mon people let the world begin" (Paul McCartney) ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-21 0:00 ` Peter Hermann @ 1997-10-22 0:00 ` Robert A Duff 1997-10-22 0:00 ` Brian Rogoff 0 siblings, 1 reply; 54+ messages in thread From: Robert A Duff @ 1997-10-22 0:00 UTC (permalink / raw) In article <62hpvc$1v5m@info4.rus.uni-stuttgart.de>, Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> wrote: >this thread has become very interesting due to >a couple of valuable contributions. >thank you all. You really have upvalued comp.lang.ada for a while. >I am wondering why the SPARK approach (J.Barnes) >has not been mentioned in this context. I think it *was* mentioned. The problem with SPARK is that it's such a *severe* subset of Ada. Sure, it solves the problem of by-copy vs by-ref parameters, and others, but it cuts out 90% of the language features. So, although I think it's a fine idea for safety-critical apps, I think it cuts out too much for general-purpose apps. - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-22 0:00 ` Robert A Duff @ 1997-10-22 0:00 ` Brian Rogoff 0 siblings, 0 replies; 54+ messages in thread From: Brian Rogoff @ 1997-10-22 0:00 UTC (permalink / raw) On Wed, 22 Oct 1997, Robert A Duff wrote: > Peter Hermann <ica2ph@alpha1.csv.ica.uni-stuttgart.de> wrote: > >this thread has become very interesting due to > >a couple of valuable contributions. > >thank you all. You really have upvalued comp.lang.ada for a while. > >I am wondering why the SPARK approach (J.Barnes) > >has not been mentioned in this context. > > I think it *was* mentioned. > > The problem with SPARK is that it's such a *severe* subset of Ada. > Sure, it solves the problem of by-copy vs by-ref parameters, and others, > but it cuts out 90% of the language features. So, although I think it's > a fine idea for safety-critical apps, I think it cuts out too much for > general-purpose apps. Just to amplify, SPARK is roughly Ada - {generics, exceptions, tasking, "use", access types, goto} + {various annotations} and I agree with Bob Duff that it is missing too much for general purpose programming. -- Brian ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-21 0:00 ` Robert A Duff 1997-10-21 0:00 ` Peter Hermann @ 1997-10-22 0:00 ` Henry Baker 1997-10-21 0:00 ` Robert Dewar ` (2 more replies) 1 sibling, 3 replies; 54+ messages in thread From: Henry Baker @ 1997-10-22 0:00 UTC (permalink / raw) In article <EIDpr3.ut@world.std.com>, bobduff@world.std.com (Robert A Duff) wrote: > When you gripe about some supposed flaw in Ada, you should make it clear > what you're comparing it to -- C? C++? Common Lisp? Some obscure > functional language? Some ideal language in your head? -- all of those > can be valuable criticisms, but it's helpful to know whether "Ada's > limited types suck" is said in relation to a language that even *has* a > concept of limited types! Ada was the product of forcing a number of ill-conceived and inconsistent requirements (Steelman) into a single language. Many additional inelegancies were added during the period prior to 1983 by torturing the syntax and semantics in unnatural ways. Due to the requirements of compatibility, Ada95 was not allowed to actually _fix_ any of the really bad things in Ada83, but did allow many program-arounds due to additional new features which interacted in non-orthogonal ways with the old features. This is not to take anything away from those who worked on this process. In many ways, they were too clever for their own good. Instead of forcing certain things to be discarded or fixed, they managed to live with them. If one believes that more code will be programmed in the future than in the past, this unwillingness to fix old code is penny-wise and pound-foolish, because all new code pays for the mistakes of the past. In any _real_ system, the overall goals of portability and tool sharing cannot be obtained, because one can never trust the new compilers on the old code during maintenance, thus forcing the DoD to keep around not only lots of old code, but also lots of old code tools, compilers, workstations, etc. If Ada is like any other language, you can't even find a modern workstation that will run circa 1985 compilers without recompiling the compiler, and how many people have the resources and access to the code to do this? The whole Ada process was an interesting experiment, but the process was fundamentally flawed. You can't design a language without writing a huge number of applications at the same time. Ada's attempt to define _and then cast in concrete_ a language before a significant literature of applications had been programmed was fatal. Furthermore, the early (negative) feedback from actual programmers was not taken seriously, and the process had acquired such political momentum that it could not be redirected. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-22 0:00 ` Henry Baker @ 1997-10-21 0:00 ` Robert Dewar 1997-10-22 0:00 ` Jon S Anthony 1997-10-22 0:00 ` Brian Rogoff 2 siblings, 0 replies; 54+ messages in thread From: Robert Dewar @ 1997-10-21 0:00 UTC (permalink / raw) Henry Baker says <<The whole Ada process was an interesting experiment, but the process was fundamentally flawed. You can't design a language without writing a huge number of applications at the same time. Ada's attempt to define _and then cast in concrete_ a language before a significant literature of applications had been programmed was fatal. Furthermore, the early (negative) feedback from actual programmers was not taken seriously, and the process had acquired such political momentum that it could not be redirected.>> Well by this I assume that "actual programmers" = Henry Baker, and as you know from Henry's style, this equation makes sense to him :-) In fact the early feedback from actual programmers with regard to the language (separating out early implementation difficulties) was almost uniformly positive. Not so surprising, since a lot of code was written during the T&E phase of the process, and these same people who had positive reactions during the T&E phrase went on to use Ada for all sorts of real applications very successfully. Yes, we all know that Henry doesn't like Ada, fair enough, anyone is entitled to their own opinions, but the attempt to equate Henry's dislike with general dislike is I am afraid wishful thinking on his part. I happen to think that Henry's technical views on Ada are almost consistently warped by some very specific, rather odd, technical viewpoints, and almost always the exact things he likes are exactly the things that I most dislike in language designs. An excellent example of this is Henry's recent embrace of a viewpoint that prefers side effects in expressions to be well defined and portable, while I take the viwe that this is wholly evil! By the way, it would be interesting to know what Henry thinks of Algol-68, since this is a language that, unlike Ada, was "designed without writing a huge number of applications, in fact virtually no testing of this kind was done on the design". Henry, is A68 fundamentally flawed as well. For that matter is any widely used language reasonable from your point of view, or is it one of these cases where 99% of the programming world is wrong and you are right? Interesting incidentally how a technical argument with Henry almost always ends up with him going off on a philosophical binge about how terrible the whole of Ada is :-) Odd that he wastes his time even reading CLA! ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-22 0:00 ` Henry Baker 1997-10-21 0:00 ` Robert Dewar @ 1997-10-22 0:00 ` Jon S Anthony 1997-10-22 0:00 ` Brian Rogoff 2 siblings, 0 replies; 54+ messages in thread From: Jon S Anthony @ 1997-10-22 0:00 UTC (permalink / raw) hbaker@netcom.com (Henry Baker) writes: > Ada was the product of forcing a number of ill-conceived and inconsistent [...and then on and on and on...] Henry, you have a real tendency to go way over the top. Most of this sort of generalized criticism can be leveled against _all_ computer languages - including your beloved Lisp(s). Certainly CL is _full_ of this sort of stuff. BTW, we use _both_ Ada and CL here because it makes sense and provides certain optimal (IMO) advantages. /Jon -- Jon Anthony Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-22 0:00 ` Henry Baker 1997-10-21 0:00 ` Robert Dewar 1997-10-22 0:00 ` Jon S Anthony @ 1997-10-22 0:00 ` Brian Rogoff 2 siblings, 0 replies; 54+ messages in thread From: Brian Rogoff @ 1997-10-22 0:00 UTC (permalink / raw) On Wed, 22 Oct 1997, Henry Baker wrote: > In article <EIDpr3.ut@world.std.com>, bobduff@world.std.com (Robert A > Duff) wrote: > > When you gripe about some supposed flaw in Ada, you should make it clear > > what you're comparing it to -- C? C++? Common Lisp? Some obscure > > functional language? Some ideal language in your head? -- all of those > > can be valuable criticisms, but it's helpful to know whether "Ada's > > limited types suck" is said in relation to a language that even *has* a > > concept of limited types! I have no idea why this question was included, since the it isn't answered. Which language, or process for achieving consensus leads to results that make everyone happy? I can't get 4 people to agree where to go to dinner without disappointing someone! > This is not to take anything away from those who worked on this process. > In many ways, they were too clever for their own good. Instead of forcing > certain things to be discarded or fixed, they managed to live with them. > If one believes that more code will be programmed in the future than in > the past, this unwillingness to fix old code is penny-wise and pound-foolish, > because all new code pays for the mistakes of the past. No, code is like any other man made thing in that compatibility with previous technology is very important, far more important than some people think. If you change the underlying language dramatically every few years the retooling effort overwhelms everyone. Unfortunately, that means that widely used programming languages accumulate features. It also means that features like FFIs (foreign function interfaces) outweigh cool gadgets like unique modes in most applications. -- Brian ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-15 0:00 ` Robert Dewar 1997-10-15 0:00 ` Robert Dewar @ 1997-10-15 0:00 ` Brian Rogoff 1997-10-19 0:00 ` Robert Dewar 1 sibling, 1 reply; 54+ messages in thread From: Brian Rogoff @ 1997-10-15 0:00 UTC (permalink / raw) On 15 Oct 1997, Robert Dewar wrote: > ... about procedure argument passing ... > > Similarly, over-constraining the order of evaluation (which > affects only programs with strange side effects) can significantly damange > the efficiency of generated code. I have seen this particular claim challenged by several other compiler writers and no evidence was advanced to support it. Do you have evidence that leaving order of evaluation arbitrary is a performance enabler? FWIW, one of my favorite languages (Sather) has order of evaluation of defined in its specification, and the designers definitely wanted a language which could be compiled to fast code with existing compiler technology. -- Brian ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-15 0:00 ` Brian Rogoff @ 1997-10-19 0:00 ` Robert Dewar 1997-10-22 0:00 ` Henry Baker 0 siblings, 1 reply; 54+ messages in thread From: Robert Dewar @ 1997-10-19 0:00 UTC (permalink / raw) << I have seen this particular claim challenged by several other compiler writers and no evidence was advanced to support it. Do you have evidence that leaving order of evaluation arbitrary is a performance enabler?>> It is always hard to get specific data across the complete spectrum of application domains. IBM comes closest to having the necessary trace data to do this kind of study, but that data is closely held. Obviously it is easy to construct examples where it can make a big difference. For example, consider: a + f(x) If you demand strict left to right evaluation in a language with unrestricted side effects, then the code has to load and save the value of A over the function call, just in case the function call disturbs the value of A. Certainly you will see an effect on the Specmarc if you constrain the order of evaluation. The real point is the following. We know that constrainining the order of evaluation will hurt the performance of some code. We know that constraining the order of evaluation will only affect code that uses side effects in a particularly nasty way. We don't want people writing code of that kind anyway. However, without banning side effects completely, a bad idea (*), we don't know any easy way of disallowing the "bad" side effects. We don't feel like damaging the efficiency of code just for the benefit of those who want to make nasty use of side effects. On the contrary, leaving the order of evaluation undefined will actively discourage the use of such side effects, a good thing! (*) everynow and then, someone wants to ban side effects completely in functions (some people even want to ban functions, if I remember right, one of Per Brinch Hanson's simplified Pascal-like languages went in this direction). However, this is a bad idea, which, once the full issues are examined, never gets more than a splinter of support. The trouble is that there are many legitimate uses for functions with side effects, an obvious example among many being the use of memo functions. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-19 0:00 ` Robert Dewar @ 1997-10-22 0:00 ` Henry Baker 0 siblings, 0 replies; 54+ messages in thread From: Henry Baker @ 1997-10-22 0:00 UTC (permalink / raw) In article <dewar.877269740@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > On the contrary, leaving the order of evaluation undefined will actively > discourage the use of such side effects, a good thing! > > However, this is a bad idea, which, once the full issues are examined, never > gets more than a splinter of support. The trouble is that there are many > legitimate uses for functions with side effects, an obvious example among > many being the use of memo functions. The problem with side-effects is that people want to _encapsulate_ side-effects in order to produce functions. Furthermore, things that _look_ like side-effects to a compiler -- e.g., 'cons' in Lisp -- turn out not to be side-effects at the next level up in abstraction. So unless your language offers a really good understanding of abstraction and encapsulation, it should punt and assume that the programmer knows what he/she is doing. ---- The problem with Bob's comments about discouraging side-effects with non-determinism is that this is a terrible thing to do to 90% of the code which doesn't care about performance. You should annotate for the 10% which cares about performance, and _not_ annotate for the rest. Unfortunately, the specmark stuff forces the exact opposite behavior. By not allowing annotations (except in the form of incomprehensible and never-used compile-time 'switches'), they force bad programming styles for the bulk of the code which is not performance sensitive. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-14 0:00 ` Henry Baker 1997-10-15 0:00 ` JP Thornley 1997-10-15 0:00 ` Geert Bosch @ 1997-10-21 0:00 ` Robert A Duff 1997-10-22 0:00 ` Henry Baker 2 siblings, 1 reply; 54+ messages in thread From: Robert A Duff @ 1997-10-21 0:00 UTC (permalink / raw) (e-mailed and posted) In article <hbaker-1410971205270001@10.0.2.1>, Henry Baker <hbaker@netcom.com> wrote: >It should be comforting to you when your Boeing 777 crashes that its Ada code >met the standard.... > >This is another one of those cases that give standards bodies such a >bad name -- the behavior is well-defined as 'non-deterministic', but >non-functional. Henry, I'm surprised you still lurk here. ;-) I'm inclined to agree with you that this (by-copy vs. by-ref) is a bad thing to leave "nondeterministic". On the other hand, what the heck do you want? Lots of languages leave lots of things ill-defined/non-deterministic. Do you want Boeing to use C instead, to make 777's fly?! C has far more nondeterministic stuff than Ada (although this particular thing is nailed down better in C than in Ada -- with some efficiency cost). The state of the art is for the average programmer (in both C and Ada) to assume that "what my current compiler does today is law", and for the better-than-average programmer to accidentally trip over nondeterminism. The advantage of Ada here is that there's less of it. Then there's Java, which is about as deterministic as you can get -- namely, the core language allows nondeterminism only for concurrent threads (btw Ada does better here). But the libraries do whatever who-knows-who's windowing library likes, and of course some sort of "nondeterminism" is introduced by the fact that various Java compilers don't obey the Java standard (often deliberately). But at least the semantics of plain old integer arithmetic and similar mundane operations are nailed down. But Java pays an efficiency price for avoiding non-determinism. If I were designing a language from scratch, I think I would try to get the best of both worlds: nail things down, but give the compiler enough information to optimize. In the case we're talking about here (by-copy vs by-ref), define the semantics as by-copy, but make sure the compiler knows about side effects and exceptions well enough to do by-ref in the vast majority of cases when it's both safe and more efficient. Perhaps that's a pipe dream. If so, IMHO the Pascal semantics is better, where the programmer chooses by-copy vs by-ref (and loses when that choice is bad for a particular machine). The point is: the vast majority of calls don't do any troublesome aliasing. So do you go the Ada(*)/Fortran way, which says that the compiler can *assume* that, even if it's not true, or do you go the Java/C way, which is deterministic, but inefficient? My wish is: neither -- I want determinism *and* efficiency. (And by the way, I wouldn't go the "pure functional" route.) (*) Ada doesn't actually assume no aliasing. It's a bit more conservative than Fortran. Not much. So anyway, I agree with your criticism of Ada, in this particular respect, but I'm not quite sure why you criticize Ada in particular (as opposed to lots of other mainstream languages that choose non-determinism for efficiency reasons). - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-21 0:00 ` Robert A Duff @ 1997-10-22 0:00 ` Henry Baker 1997-10-21 0:00 ` Matthew Heaney 1997-10-23 0:00 ` Robert A Duff 0 siblings, 2 replies; 54+ messages in thread From: Henry Baker @ 1997-10-22 0:00 UTC (permalink / raw) In article <EIDp0s.F4y@world.std.com>, bobduff@world.std.com (Robert A Duff) wrote: > I'm surprised you still lurk here. ;-) 'lurk' is probably an appropriate word ;-) > Then there's Java, which is about as deterministic as you can get -- > namely, the core language allows nondeterminism only for concurrent > threads (btw Ada does better here). But the libraries do whatever > who-knows-who's windowing library likes, and of course some sort of > "nondeterminism" is introduced by the fact that various Java compilers > don't obey the Java standard (often deliberately). But at least the > semantics of plain old integer arithmetic and similar mundane operations > are nailed down. > > But Java pays an efficiency price for avoiding non-determinism. The problem with standards is that there are too many of them. (I don't know who said this first, but I agree with him/her wholeheartedly.) The major problem with 'loose' standards is that they serve the goals of the implementors (compiler vendors A,B,C,etc.) instead of the goals of the users. Compiler vendors want to make it _seem_ like there is a standard so that purchasing agents can do their check-box things, but compiler vendors want to be enough different so that they can a) grab the customer in the first place with some special feature, and then b) keep the customer through more-or-less gratuitous incompatibilities that would cost a fortune to track down, root out, and recertify. Java started out as a user's dream -- software that runs anywhere/everywhere without recompilation. But then every Java implementor starts jockeying for position, and M$ starts to either steal the show, or at least torpedo the progress by adding gratuitous incompatibilities of their own. Marketeers can't _stand_ highly flexible, retargetable, portable, scalable products, because they can't charge different customers different prices for the same thing. So they make restricted, non-portable products which are tightly constrained to live in a tiny box, so they can keep the customer similarly constrained. I never thought I would live to see the day when computer software -- the ultimate in scalable, emulable, portable stuff (thanks to Turing's Thesis) -- could be bottled, de-natured and emasculated the way it has recently been done by M$. Turing-capable 'shell languages', which could be used to make up for a lot of crappy user interfaces, have now been replaced with GUI's that can't be programmed at all, and repeated commands must now be physically given with a user's hands. No wonder we're all getting carpal tunnel syndrome! No wonder the Commerce Dept can't find any evidence that computer 'investments' produce any economic return! (Sorry about the free-association, but it is important to understand that technical issues are now completely irrelevant in the choice of computer languages or their features.) ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-22 0:00 ` Henry Baker @ 1997-10-21 0:00 ` Matthew Heaney 1997-10-22 0:00 ` Simon Wright 1997-10-23 0:00 ` Henry Baker 1997-10-23 0:00 ` Robert A Duff 1 sibling, 2 replies; 54+ messages in thread From: Matthew Heaney @ 1997-10-21 0:00 UTC (permalink / raw) In article <hbaker-2110971616360001@10.0.2.1>, hbaker@netcom.com (Henry Baker) wrote: >(Sorry about the free-association, but it is important to understand that >technical issues are now completely irrelevant in the choice of computer >languages or their features.) I'm going to tell you a story, Henry. It's called, What I Did At Work Today. We have a piece of external hardware, to which we communicate via an RS-422 serial port. We send and receive messages of a certain format, as a byte stream. On this piece of hardware is a thermocouple, which measures the temperature of the hardware. We can configure the hardware to shut down when it gets too hot or too cold, and so we periodically ask for the temperature to see if we're getting close to the extremes. The temperature is measured in degrees Celsius, having a range from -55 C to 125 C. The temperature is a real type, 9 bits long, and with an LSB of 0.5 C. We recieve the temperature as 2 bytes worth of a larger message. The first byte contains the low order 8 bits of the temperature, and the LSB of the second byte contains the MSB of the temperature. That's 9 total bits of temperature, embedded within 2 bytes. Now, here's how I was able to convert this data using Ada. You can decide whether the Ada solution is "too complex." Temperature_In_Celsius_Delta : constant := 0.5; type Temperature_In_Celsius_Base is delta Temperature_In_Celsius_Delta range -128.0 .. 127.5; for Temperature_in_Celsius_Base'Small use Temperature_in_Celsius_Delta; subtype Temperature_in_Celsius is Temperature_In_Celsius_Base range -55.0 .. 125.0; type Temperature_As_Record is record Temperature : Temperature_in_Celsius_Base; end record; for Temperature_As_Record use record Temperature at 0 range 7 .. 15; end record; for Temperature_As_Record'Size use 16; subtype Temperature_As_Byte_Array is Byte_Array (1 .. 2); function To_Temperature_As_Record is new Unchecked_Conversion (Temperature_As_Byte_Array, Temperature_As_Record); function Get_Temperature (Message : Message_Type) return Temperature_In_Celsius is Temperature_Message : Byte_Array renames Message.Temperature; Temperature_Bytes : constant Temperature_As_Byte_Array := (1 => Temperature_Message (2), 2 => Temperature_Messsage (1)); Temperature_Record : constant Temperature_As_Record := To_Temperature_As_Record (Temperature_Bytes); Temperature : Temperature_In_Celsius_Base renames Temperature_Record.Temperature; begin if Temperature not in Temperature_in_Celsius then raise Temperature_Out_Of_Range; end if; return Temperature; end Get_Temperature; Now, that was a real problem at my real job. Do you feel that that was too difficult? Dijkstra admonished us 20 years ago that we need to "minimize the intellectual distance" between a problem and the solution to that problem. Doesn't this solution capture the qualities of the problem directly? o I can directly declare a real number type that exactly matches the accuracy and size of the hardware, and comprising all possible values the can come from the hardware. type Temperature_In_Celsius_Base is delta 0.5 range -128.0 .. 127.5; for Temperature_In_Celsius_Base'Size use 9; This seems pretty clear to me. Is there some easier way? o I can directly declare another type that denotes the exact range of values - fewer in number than what is theoretically possible - that the thermocouple advertises it can return. I can check that the hardware documentation isn't lying to me, or that perhaps the hardware is just flaky today, by using a simple membership test: subtype Temperature_in_Celsius is Temperature_In_Celsius_Base range -55.0 .. 125.0; if Temperature not in Temperature_In_Celsius then raise Out_of_Range; end if; I don't understand how you could be more clear than that. o I was able to assemble the bits, spread out over 2 bytes in reverse order, into a 9 bit temperature type, without much trouble, using our old friend Unchecked_Conversion. I'm an open-minded guy, and if you've got some better way to translate the data from this thermocouple, using another language besides Ada, then I'd love to hear about it. Despite the "horrible experiment" that was Ada, a "baroque language" the product of a "flawed design process," I'm still able to solve nasty problems interfacing to hardware with relative ease, using Ada solutions that have, dare I say (gasp!), a certain elegance. I think the technical issues definately do affect my choice of language. For the work I do (embedded, real-time systems), Ada's advantages seem to outweigh its putative flaws. -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-21 0:00 ` Matthew Heaney @ 1997-10-22 0:00 ` Simon Wright 1997-10-23 0:00 ` Henry Baker 1 sibling, 0 replies; 54+ messages in thread From: Simon Wright @ 1997-10-22 0:00 UTC (permalink / raw) mheaney@ni.net (Matthew Heaney) writes: > type Temperature_As_Record is > record > Temperature : Temperature_in_Celsius_Base; > end record; > > for Temperature_As_Record use > record > Temperature at 0 range 7 .. 15; > end record; I guess I would have put this part at least inside the function and included something about System.Default_Bit_Order .. if System."=" (System.Default_Bit_Order, System.Low_Order_First) then declare type Little_Endian_Temperature_As_Record is new Temperature_As_Record; for Little_Endian_Temperature_As_Record use record Temperature at 0 range 0 .. 8; end record; for Little_Endian_Temperature_As_Record'Size use ... function Convert is new Unchecked_Conversion (..., Little_Endian_Temperature_As_Record); begin Result := Temperature_As_Record (Convert (...)); end; else ... -- Simon Wright Work Email: simon.j.wright@gecm.com GEC-Marconi Radar & Defence Systems Voice: +44(0)1705-701778 Command & Information Systems Division FAX: +44(0)1705-701800 ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-21 0:00 ` Matthew Heaney 1997-10-22 0:00 ` Simon Wright @ 1997-10-23 0:00 ` Henry Baker 1997-10-23 0:00 ` Pat Rogers 1997-10-24 0:00 ` Robert Dewar 1 sibling, 2 replies; 54+ messages in thread From: Henry Baker @ 1997-10-23 0:00 UTC (permalink / raw) In article <mheaney-ya023680002110972333400001@news.ni.net>, mheaney@ni.net (Matthew Heaney) wrote: > I'm going to tell you a story, Henry. It's called, What I Did At Work Today. > Now, that was a real problem at my real job. Do you feel that that was too > difficult? Dijkstra admonished us 20 years ago that we need to "minimize > the intellectual distance" between a problem and the solution to that > problem. Doesn't this solution capture the qualities of the problem > directly? I agree that Ada's attempts to provide accurate ranges of numbers are laudable. But PL/I and Cobol offered equally (some would say more equally) powerful capabilities. But the history of Ada indicates a deep disconnect between people like yourselves that have to deal with real hardware and real data formats and the academics. The academics were worried about something totally different, and in fact, it first appeared as though Ada would not be able to properly specify exact hardware formats at all. This is one case where 'real' programmers were able to prevail. The academic notion of number ranges was not wrong, but it was not carried through. Even a cursory glance at the 'interpretation' of the Ada standard shows that they missed by a mile. For example, there was no guarantee that a variable with a particular range could be guaranteed to always have a value in that range! There were no tools for Ada that would allow one to step through a program and verify symbolically where range constraints were met, and where they weren't met. Such a tool would be invaluable in the verification of a real-time embedded system. Instead, Ada people spent all this time on the semantics of exceptions, which people who actually had to program reliable real-time embedded systems promptly turned off! ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-23 0:00 ` Henry Baker @ 1997-10-23 0:00 ` Pat Rogers 1997-10-24 0:00 ` Robert Dewar 1 sibling, 0 replies; 54+ messages in thread From: Pat Rogers @ 1997-10-23 0:00 UTC (permalink / raw) The History of Ada, by Henry Baker. It would be nice to see an IMHO somewhere in these many posts... Henry Baker <hbaker@netcom.com> wrote in article <hbaker-2310970735010001@10.0.2.1>... [snip of previous quote from another individual] > I agree that Ada's attempts to provide accurate ranges of numbers are > laudable. But PL/I and Cobol offered equally (some would say more > equally) powerful capabilities. But the history of Ada indicates a > deep disconnect between people like yourselves that have to deal with > real hardware and real data formats and the academics. The academics > were worried about something totally different, and in fact, it first > appeared as though Ada would not be able to properly specify exact > hardware formats at all. This is one case where 'real' programmers > were able to prevail. > > The academic notion of number ranges was not wrong, but it was not > carried through. Even a cursory glance at the 'interpretation' of > the Ada standard shows that they missed by a mile. > > For example, there was no guarantee that a variable with a particular > range could be guaranteed to always have a value in that range! > > There were no tools for Ada that would allow one to step through a > program and verify symbolically where range constraints were met, and > where they weren't met. Such a tool would be invaluable in the verification > of a real-time embedded system. Instead, Ada people spent all this time > on the semantics of exceptions, which people who actually had to program > reliable real-time embedded systems promptly turned off! > ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-23 0:00 ` Henry Baker 1997-10-23 0:00 ` Pat Rogers @ 1997-10-24 0:00 ` Robert Dewar 1 sibling, 0 replies; 54+ messages in thread From: Robert Dewar @ 1997-10-24 0:00 UTC (permalink / raw) Henry says <<I agree that Ada's attempts to provide accurate ranges of numbers are laudable. But PL/I and Cobol offered equally (some would say more equally) powerful capabilities>> This is technical nonsense. I assume it means that Henry does not know COBOL. In COBOL, you can specify the precision of a number only by giving the number of digits (i.e. equivalent to the digits phrase in an Ada decimal declaration). There is no capability to declare a specific range, i.e. there is no equivalent in COBOL of the Ada declaration: type x is delta 0.01 digits 5 range 1.00 .. 123.67; The nearest that COBOL can come is PICTURE S999V99. which captures the delta and digits but not the range. In the binary case, the situation is even worse, since one can still only specify a range in decimal digits. The normal technique in COBOL is to write: 05 FIELD1 COMP-4 PICTURE S9(4). and know that really the range of FIELD1 will be 16-bits signed and therefore have a range of -32768 .. +32767. All arithmetic with FIELD1 will be done without using the ON SIZE ERROR, and everything works out OK, but without proper error checking. Note also the limitation that in COBOL, even the decimal range is enforced only if every arithmetic operation specifies ON SIZE ERROR. The situation in PL/1 with respect to decimal types is identical to COBOL. The binary situation is better, since ranges can at least be given in powers of 2, but it is still not possible (at least in ANSI PL/1, who knows what has happened since) to specify specific binary ranges. Anyone would say that COBOL and PL/1 offer "more powerful" capabilities in this area must presumably be as ignorant about COBOL and PL/1 as Henry obviously is. ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-22 0:00 ` Henry Baker 1997-10-21 0:00 ` Matthew Heaney @ 1997-10-23 0:00 ` Robert A Duff 1 sibling, 0 replies; 54+ messages in thread From: Robert A Duff @ 1997-10-23 0:00 UTC (permalink / raw) In article <hbaker-2110971616360001@10.0.2.1>, Henry Baker <hbaker@netcom.com> wrote: >The problem with standards is that there are too many of them. (I don't >know who said this first, but I agree with him/her wholeheartedly.) Perhaps you're referring to this quote, from Grace Murray Hopper: The wonderful thing about standards is that there are so many of them to choose from. - Bob ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-14 0:00 ` Robert Dewar 1997-10-14 0:00 ` Henry Baker @ 1997-10-21 0:00 ` Keith Thompson 1 sibling, 0 replies; 54+ messages in thread From: Keith Thompson @ 1997-10-21 0:00 UTC (permalink / raw) Robert I. Eachus (eachus@spectre.mitre.org) wrote: > Ada 95 RM 6.2(4..10): > > "A type is a _by-reference_ type if it is a descendent of one of > the following: > > ... > a nonprivate type with the reserved word limited in its declaration; > > a composite type with a subcomponent of a by-reference type; > > a private type whoes full type is a by-reference type; > > A parameter of a by-reference type is passed by reference..." > > To everyone other than Henry Baker this says that there is no > problem of copy-in copy-out semantics in Ada 95 for limited private > types since it isn't allowed. Not quite, I'm afraid. For example, type Foo in the following is not a by-reference type: ... type Foo is limited private; private type Foo is record X : Integer; end record; ... To make it by-reference, you'd have to add the word "limited" to the full type declaration. This problem is acknowledged in AARM-6.2(10.g): We say "by-reference" above because these statements are not always true for limited private types whose underlying type is nonlimited (unfortunately). -- Keith Thompson (The_Other_Keith) kst@cts.com <*> ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H San Diego, California, USA "Simba, you have forgotten me. I am your father. This is CNN." -- JEJ ^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Depending on passing mechanism 1997-10-13 0:00 Depending on passing mechanism Andre Spiegel 1997-10-13 0:00 ` Matthew Heaney 1997-10-14 0:00 ` Robert Dewar @ 1997-10-14 0:00 ` Robert Dewar 2 siblings, 0 replies; 54+ messages in thread From: Robert Dewar @ 1997-10-14 0:00 UTC (permalink / raw) << * the proof that it's equivalent to the halting problem. (I could do it myself, but I'd like to reference it in a paper.) >> I doubt there is a paper, since it is trivially obvious that this is the case, since it depends on being able to compute possible paths at run time, which is obviously equivalent to the halting problem. ^ permalink raw reply [flat|nested] 54+ messages in thread
end of thread, other threads:[~1997-10-24 0:00 UTC | newest] Thread overview: 54+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-10-13 0:00 Depending on passing mechanism Andre Spiegel 1997-10-13 0:00 ` Matthew Heaney 1997-10-14 0:00 ` Robert Dewar 1997-10-14 0:00 ` Henry Baker 1997-10-15 0:00 ` JP Thornley 1997-10-15 0:00 ` Geert Bosch 1997-10-15 0:00 ` Henry Baker 1997-10-15 0:00 ` Robert Dewar 1997-10-15 0:00 ` Jon S Anthony 1997-10-16 0:00 ` Brian Rogoff 1997-10-17 0:00 ` Henry Baker 1997-10-18 0:00 ` Brian Rogoff 1997-10-18 0:00 ` Matthew Heaney 1997-10-19 0:00 ` Brian Rogoff 1997-10-21 0:00 ` Robert A Duff 1997-10-22 0:00 ` Robert Dewar 1997-10-22 0:00 ` Brian Rogoff [not found] ` <dewar.877601826@merv> 1997-10-23 0:00 ` Brian Rogoff 1997-10-23 0:00 ` Henry Baker 1997-10-23 0:00 ` Brian Rogoff 1997-10-19 0:00 ` Fergus Henderson 1997-10-19 0:00 ` Brian Rogoff 1997-10-20 0:00 ` Fergus Henderson 1997-10-20 0:00 ` Henry Baker 1997-10-20 0:00 ` Tucker Taft 1997-10-21 0:00 ` Geert Bosch 1997-10-18 0:00 ` Fergus Henderson 1997-10-15 0:00 ` Robert Dewar 1997-10-15 0:00 ` Robert Dewar 1997-10-17 0:00 ` Andre Spiegel 1997-10-17 0:00 ` Henry Baker 1997-10-17 0:00 ` Robert I. Eachus 1997-10-17 0:00 ` Jon S Anthony 1997-10-21 0:00 ` Robert A Duff 1997-10-21 0:00 ` Peter Hermann 1997-10-22 0:00 ` Robert A Duff 1997-10-22 0:00 ` Brian Rogoff 1997-10-22 0:00 ` Henry Baker 1997-10-21 0:00 ` Robert Dewar 1997-10-22 0:00 ` Jon S Anthony 1997-10-22 0:00 ` Brian Rogoff 1997-10-15 0:00 ` Brian Rogoff 1997-10-19 0:00 ` Robert Dewar 1997-10-22 0:00 ` Henry Baker 1997-10-21 0:00 ` Robert A Duff 1997-10-22 0:00 ` Henry Baker 1997-10-21 0:00 ` Matthew Heaney 1997-10-22 0:00 ` Simon Wright 1997-10-23 0:00 ` Henry Baker 1997-10-23 0:00 ` Pat Rogers 1997-10-24 0:00 ` Robert Dewar 1997-10-23 0:00 ` Robert A Duff 1997-10-21 0:00 ` Keith Thompson 1997-10-14 0:00 ` Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox