Depending on passing mechanism

Depending on passing mechanism

[Andre Spiegel]

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

Re: Depending on passing mechanism

[Matthew Heaney]

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

Re: Depending on passing mechanism

[Robert Dewar]

<<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.

Re: Depending on passing mechanism

[Henry Baker]

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.

Re: Depending on passing mechanism

[JP Thornley]

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                           |
------------------------------------------------------------------------

Re: Depending on passing mechanism

[Geert Bosch]

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

Re: Depending on passing mechanism

[Henry Baker]

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.

Re: Depending on passing mechanism

[Robert Dewar]

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?

Re: Depending on passing mechanism

[Jon S Anthony]

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

Re: Depending on passing mechanism

[Brian Rogoff]

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

Re: Depending on passing mechanism

[Henry Baker]

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'.

Re: Depending on passing mechanism

[Brian Rogoff]

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

Re: Depending on passing mechanism

[Matthew Heaney]

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

Re: Depending on passing mechanism

[Brian Rogoff]

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

Re: Depending on passing mechanism

[Robert A Duff]

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

Re: Depending on passing mechanism

[Robert Dewar]

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

Re: Depending on passing mechanism

[Brian Rogoff]

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

Re: Depending on passing mechanism

[Brian Rogoff]

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

Re: Depending on passing mechanism

[Henry Baker]

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.)

Re: Depending on passing mechanism

[Brian Rogoff]

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

Re: Depending on passing mechanism

[Fergus Henderson]

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.

Re: Depending on passing mechanism

[Brian Rogoff]

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

Re: Depending on passing mechanism

[Fergus Henderson]

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.

Re: Depending on passing mechanism

[Henry Baker]

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.

Re: Depending on passing mechanism

[Tucker Taft]

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

Re: Depending on passing mechanism

[Geert Bosch]

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

Re: Depending on passing mechanism

[Fergus Henderson]

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.

Re: Depending on passing mechanism

[Robert Dewar]

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.

Re: Depending on passing mechanism

[Brian Rogoff]

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

Re: Depending on passing mechanism

[Robert Dewar]

<<        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.

Re: Depending on passing mechanism

[Henry Baker]

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.

Re: Depending on passing mechanism

[Robert Dewar]

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.)

Re: Depending on passing mechanism

[Andre Spiegel]

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

Re: Depending on passing mechanism

[Henry Baker]

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.

Re: Depending on passing mechanism

[Robert I. Eachus]

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...

Re: Depending on passing mechanism

[Jon S Anthony]

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

Re: Depending on passing mechanism

[Robert A Duff]

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

Re: Depending on passing mechanism

[Peter Hermann]

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)

Re: Depending on passing mechanism

[Robert A Duff]

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

Re: Depending on passing mechanism

[Brian Rogoff]

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

Re: Depending on passing mechanism

[Henry Baker]

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.

Re: Depending on passing mechanism

[Robert Dewar]

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!

Re: Depending on passing mechanism

[Brian Rogoff]

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

Re: Depending on passing mechanism

[Jon S Anthony]

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

Re: Depending on passing mechanism

[Robert A Duff]

(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

Re: Depending on passing mechanism

[Henry Baker]

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.)

Re: Depending on passing mechanism

[Matthew Heaney]

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

Re: Depending on passing mechanism

[Simon Wright]

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

Re: Depending on passing mechanism

[Henry Baker]

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!

Re: Depending on passing mechanism

[Pat Rogers]

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!
> 

Re: Depending on passing mechanism

[Robert Dewar]

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.

Re: Depending on passing mechanism

[Robert A Duff]

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

Re: Depending on passing mechanism

[Keith Thompson]

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

Re: Depending on passing mechanism

[Robert Dewar]

<<  * 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.