Two ideas for the next Ada standard

Two ideas for the next Ada standard

[Van Snyder]

1.  Allow the "mode" of an "access to procedure" or "access to function"
    formal argument to be "limited".  Interpret this to mean "you can only
    use this argument to access the subprogram, or pass it as an actual
    argument to a formal argument of `limited' mode."  This would prevent
    one from storing the "pointer" into an "access to procedure" variable,
    and thereby allow safely passing internal procedures as actual arguments.

2.  Allow an "out" "mode" for variables in specification parts, or fields
    in records.  The interpretation is that any one can read the variables,
    but only procedures in (or the initialization part of) the body of the
    package can write them, or pass them to other than "in" mode formal
    arguments in different packages.  Given this, one can safely expose
    variables containing values one wishes to expose, but to which one does
    not want to permit willy-nilly changes, without the need to write a
    one-line function.
-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

Re: Two ideas for the next Ada standard

[Dale Stanbrough]

...and given someone has started this thread :-)

I presume the occasional murmers of unhappiness about the lack of utility
of private packages is due to the fact that they can't be 'with'ed by
a public {package|subprogram} spec because of the possibility of 
revealing private details (is this right?).

If this is the case then could we have...


	with private fred; -- this does not mean fred is private!
	                   -- perhaps "private with fred;" would be
	                   -- better?
	
	package mary is
	
		...
	private
		-- can only use resources from fred in
		-- the private section, e.g. for renames,
		-- type completions etc.
	end mary;

?

Gee, this is fun! :-).


Dale

Re: Two ideas for the next Ada standard

[Robert A Duff]

In article <503sbo$j45@goanna.cs.rmit.edu.au>,
Dale Stanbrough  <dale@goanna.cs.rmit.EDU.AU> wrote:
>...and given someone has started this thread :-)
>
>I presume the occasional murmers of unhappiness about the lack of utility
>of private packages is due to the fact that they can't be 'with'ed by
>a public {package|subprogram} spec because of the possibility of 
>revealing private details (is this right?).

Perhaps people would be happier if they were called "body packages" -- a
private child of X is more like the body of X, than the private part of
X, in terms of visibility.  In any case, I'm pretty happy with the rules
as they are.

>If this is the case then could we have...
>
>
>	with private fred; -- this does not mean fred is private!
>	                   -- perhaps "private with fred;" would be
>	                   -- better?

Independent of the question of child packages, it is definitely an
annoyance that a with_clause has to go up at the top, when you really
only want it for the private part.  The mistake, I think, is that the
syntax requires with_clauses outside the unit -- it makes more sense to
me, to put them inside:

    package X is
        with Y;
        ...
    private
        with Z;
        ...
    end X;

But that ain't Ada.

It's interesting that during the Ada 9X design, somebody proposed the
exact same syntax you propose here, but with a totally different
meaning.  In particular, "with private Stuff;" would mean I can see the
private part of Stuff -- it was proposed as an *alternative* to child
units.

>	package mary is
>	
>		...
>	private
>		-- can only use resources from fred in
>		-- the private section, e.g. for renames,
>		-- type completions etc.
>	end mary;

>Gee, this is fun! :-).

Language design is a *lot* of fun.

- Bob

Re: Two ideas for the next Ada standard

[Adam Beneschan]

bobduff@world.std.com (Robert A Duff) writes:

 >Independent of the question of child packages, it is definitely an
 >annoyance that a with_clause has to go up at the top, when you really
 >only want it for the private part.  The mistake, I think, is that the
 >syntax requires with_clauses outside the unit -- it makes more sense to
 >me, to put them inside:
 >
 >    package X is
 >        with Y;
 >        ...
 >    private
 >        with Z;
 >        ...
 >    end X;

To me, the mistake is that private parts have to be put in package
specs at all.  Ideally, if you declare a type "private" in the package
spec, you should be able to define the complete type in the package
body, which is the normal place to put things that you don't want
visible to other packages that use the package.  

The only reason it isn't in the body, as far as I can see, is that it
makes life more difficult for compilers, who would like to know how
big a type is before they compile other packages that use the spec.
This means that things like stack offsets and record component offsets
aren't known at compile time.  But it shouldn't be that difficult to
arrange things so that the linker can generate the correct offsets at
link time.  It may require a more sophisticated linker or more
sophisticated relocation information in the object file.  

I'm running into this problem right now.  I'm defining some new
private types, but I cannot define them in the private part, because
this would lead to recursive package dependencies.  (The types are in
package X, and package Y's spec WITH's package X, but I'd like to put
some data defined in Y in the definition of the private type.  Since I
can't do that without creating recursive dependencies, I've resorted
to the old trick of making the private type an access to a record
structure that's defined in X's body.  This works, but opens up a can
of worms related to memory allocation and garbage collection.

So my suggestion for the next Ada standard is to allow private types
to be completed in the package body, instead of requiring them to be
completed in the "private" part.  (If this would cause serious
difficulties for other language rules, or if there would be major
problems implementing this suggestion in some cases, I'm not aware of
the problem but would appreciate having someone point it out to me.)

(I know that someone [I don't remember who] made the same argument
around 1980 or 1981, pointing out that we'd all benefit from more
sophisticated linkers.  It's possible that the original Ada proposals
allowed you to complete private types in the package body, but that
this was changed at the request of implementors, leading someone to
argue against the change.  But my memory is hazy.)

                                -- Adam

Re: Two ideas for the next Ada standard

[Robert A Duff]

In article <507akg$t9u@krusty.irvine.com>,
Adam Beneschan <adam@irvine.com> wrote:
>To me, the mistake is that private parts have to be put in package
>specs at all.  Ideally, if you declare a type "private" in the package
>spec, you should be able to define the complete type in the package
>body, which is the normal place to put things that you don't want
>visible to other packages that use the package.  

Quite true.  Private parts are primarily an efficiency hack.  But this
change would be much more sweeping than my idea of allowing the private
part to have its own with_clauses.  (I think putting the with_clauses
inside things makes more sense anyway, independent of your idea.)

>The only reason it isn't in the body, as far as I can see, is that it
>makes life more difficult for compilers, who would like to know how
>big a type is before they compile other packages that use the spec.
>This means that things like stack offsets and record component offsets
>aren't known at compile time.  But it shouldn't be that difficult to
>arrange things so that the linker can generate the correct offsets at
>link time.  It may require a more sophisticated linker or more
>sophisticated relocation information in the object file.  

I think making Ada depend on a more sophisticated linker (and, more
importantly, a non-standard object file format) would be a Really Bad
Idea!  Ada has enough trouble fitting in with the rest of the software
world as it is.  Ada requires some sort of pre-linker to figure out
elaboration order (and complain about circularities), which causes some
trouble, but it's not nearly as bad as fooling with relocation
information, which is the heart of the linker, and really needs to be
standardized across languages.

Also, doing more work at link time is bad, because link time is a
bottleneck.  To modify one body, you have to recompile one thing, but
re-link the entire program.  At least, that's the way typical
implementations work.  (I wouldn't mind having an incremental linker!
But I can't blame the designers of Ada for assuming the more traditional
sort of tools (batch mode compiler, followed by link-it-all).)

Another possibility would be to have the compiler generate inefficient
code (i.e. assume all private types are dynamic-sized) by default.  Then
have a pragma along the lines of pragma Inline, which tells the compiler
to peek at the body, and generate better code (but making compile-time
slower due to extra dependences).

Another possibility would be to split a package into three parts --
visible, private, and body.  Semantic dependencies would be on the
visible part only, but compilation dependencies would be on the visible
and private parts.  Actually, I think the GNAT folks are planning to
implement something like this -- they want to allow a "source
representation" that puts the private part in a separate file.  This
seems like a nice feature, but has some drawbacks: The private part
doesn't start with the name of the package, so the private part file is
less readable.  Also, it depends heavily on GNAT's rule about file names
matching package names.  Also, exotic source representations can hurt
portability.  Although the GNAT folks are fond of pointing out that the
RM does not define source representation, it seems best if people can
stick to something simple and obvious, like one compilation per source
file.

>I'm running into this problem right now.  I'm defining some new
>private types, but I cannot define them in the private part, because
>this would lead to recursive package dependencies.  (The types are in
>package X, and package Y's spec WITH's package X, but I'd like to put
>some data defined in Y in the definition of the private type.  Since I
>can't do that without creating recursive dependencies, I've resorted
>to the old trick of making the private type an access to a record
>structure that's defined in X's body.  This works, but opens up a can
>of worms related to memory allocation and garbage collection.

Yes.  At least in Ada 95 you can wrap the access type in a controlled
type, thus solving the garbage collection problem.  If the feature were
built in, instead of being done by hand like this, then it could be more
efficient, since the unknown-sized thing could be allocated on the
stack, rather than on the heap.

Other solutions to this circularity problem have been discussed on this
newsgroup.

>So my suggestion for the next Ada standard is to allow private types
>to be completed in the package body, instead of requiring them to be
>completed in the "private" part.  (If this would cause serious
>difficulties for other language rules, or if there would be major
>problems implementing this suggestion in some cases, I'm not aware of
>the problem but would appreciate having someone point it out to me.)

There are some problems.  For one thing, Ada 95 child units don't fit in
well with this scheme, since they can't see into bodies.  You don't want
to force people to choose between two nice features that ought to be
orthogonal (I could put this thing in the body, but then I can't extend
it in a child package -- grr).

Another issue is what to do about access-before-elaboration.  When
something is declared in two pieces, the language has to worry about
what happens when some code references the first piece, when at run
time, the second piece has not yet been elaborated.  This kind of
operation generally makes no sense, so the language must prevent it.
For private type vs. full type, the language uses the freezing rules for
this purpose, and these rules are checked at compile time.  For spec vs
body of a subprogram, the language uses run-time checks.  The
compile-time checks don't work when the thing being split in two is
split across compilation units (given the current Ada model, where
compilation units can float around in the elab order).  Now, run-time
checks on every procedure call are somewhat inefficient, but run-time
checks on every reference to a type sound much worse.  So this seems
like reasonable rationale for why private types must be completed in the
spec, whereas procedures are completed in the body.

On the other hand, one could argue that the run-time checks on
procedures are intolerable, and a better solution to that problem is
required.  Such a solution could presumably deal with types as well.
One could argue that the *programmer* should decide this efficiency
issue -- why should Jean Ichbiah decide that run-time checks on calls
are tolerable, but on types are intolerable, when he hasn't seen *my*
program, where there are lots of calls to procedure P, but few
references to type T?  Two approaches are: (1) use run-time checks, but
make sure it's feasible to optimize them away in the vast majority of
cases.  This kind of optimization is actually rather hard to do in Ada
as it stands.  (2) Do some analysis at link time (again, link-time work
causes trouble, but at least it's a pre-linker pass, rather than
meddling with the internals of existing linkers).

>(I know that someone [I don't remember who] made the same argument
>around 1980 or 1981, pointing out that we'd all benefit from more
>sophisticated linkers.

I don't remember that.  Anyway, that sort of arrogance seemed sensible
back in 1980, when Ada folks believed that Ada would take over the
world.  (The same sort of attitude produced the KAPSE/MAPSE ideas --
we've got a new language, so lets have a new OS as well.)  It didn't
happen.  Nowadays, Ada has to interface to other languages, so saying
"Ada needs a different sort of linker" would mean "Let's not use Ada",
rather than "Let's have better linkers".  Sad, perhaps.  Linkers are
indeed pretty awful.  The typical linker of 1996 contains design
decisions that were originally driven by compatibility with linkers of
the 1960's, and it's hard to break away from that.

>...  It's possible that the original Ada proposals
>allowed you to complete private types in the package body, but that
>this was changed at the request of implementors, leading someone to
>argue against the change.  But my memory is hazy.)

I don't remember any such version, but you could be right.

- Bob

Re: Two ideas for the next Ada standard

[Robert Dewar]

Bob Duff said

"Quite true.  Private parts are primarily an efficiency hack.  But this
change would be much more sweeping than my idea of allowing the private
part to have its own with_clauses.  (I think putting the with_clauses
inside things makes more sense anyway, independent of your idea.)"

Note that there is no requirement in Ada that the private part be in the
same file as the rest of the spec. 

Two things we have considered adding as options to GNAT, which are not
extensions, merely source representation issues, are to allow the 
private part to appear in a separate file, or to allow it to appear
in the body.

The one glitch, which is a little uneasy, and is where some language help
would have been nice, is if you could have with statements that applied
only to the private part.

Re: Two ideas for the next Ada standard

[Dennison]

Robert Dewar wrote:
> 

> Two things we have considered adding as options to GNAT, which are not
> extensions, merely source representation issues, are to allow the
> private part to appear in a separate file, or to allow it to appear
> in the body.

Wouldn't that make package bodies dependant on the BODIES of every package
that they "with" (even indirectly)? It seems like that could really balloon
compilation times. How would the inevitable circular dependancies be handled?

-- 
T.E.D.
email    - mailto:dennison@iag.net
homepage - http://www.iag.net/~dennison

Re: Two ideas for the next Ada standard

[Robert Dewar]

T.E.D. asked, replying to me:

"> Two things we have considered adding as options to GNAT, which are not
> extensions, merely source representation issues, are to allow the
> private part to appear in a separate file, or to allow it to appear
> in the body.

Wouldn't that make package bodies dependant on the BODIES of every package
that they "with" (even indirectly)? It seems like that could really balloon
compilation times. How would the inevitable circular dependancies be handled?"

Well you are dependent on bodies anyway if there is any inlining or any
generic subprograms.

The GNAT sourced based model COMPLETELY eliminates the problems of circular
dependencies. That's something important that you have missed. 

Indeed one of the big advantages of GNAT is that inline dependencies do not
have this problem.

Consider:

  package A with's B, and inlines from it
  package B with's A, and inlines from it

In a traditional library model you can only get inlining in one direction,
depending on the order of compilation. With the GNAT sourced based approach,
you get inlining in both directions, regardless of the order of the
compilation.

Dependencies can never be circular, because in GNAT, dependencies are of
objects on sources, not, as in a library model, of units on other units.

Re: Two ideas for the next Ada standard

[Dennison]

Robert Dewar wrote:
> 
> T.E.D. asked, replying to me:
> 
> "> Two things we have considered adding as options to GNAT, which are not
> > extensions, merely source representation issues, are to allow the
> > private part to appear in a separate file, or to allow it to appear
> > in the body.
> 
> Wouldn't that make package bodies dependant on the BODIES of every package
> that they "with" (even indirectly)? It seems like that could really balloon
> compilation times. How would the inevitable circular dependancies be handled?"
> 
> Well you are dependent on bodies anyway if there is any inlining or any
> generic subprograms.

True, but only on the body of the inlined or generic subprogram. The proposed
change would make compilation units dependant on every spec and body "with"ed
in every spec AND BODY (recursively). In my experience, package bodies tend to
have a LOT more "with"'s than specs. Compilations that now take hours might end
up taking DAYS!

Then again, I guess there is a limiting factor (ie: the total # of specs and
bodies in the system). This would just drasticly increase the % of 
compilation units in the entire project that the average compilation unit
depends on.

-- 
email    - mailto:dennison@iag.net
homepage - http://www.iag.net/~dennison

Re: Two ideas for the next Ada standard

[Robert Dewar]

T.E.D. says

"True, but only on the body of the inlined or generic subprogram. The proposed
change would make compilation units dependant on every spec and body "with"ed
in every spec AND BODY (recursively). In my experience, package bodies tend to
have a LOT more "with"'s than specs. Compilations that now take hours might end
up taking DAYS!

Then again, I guess there is a limiting factor (ie: the total # of specs and
bodies in the system). This would just drasticly increase the % of
compilation units in the entire project that the average compilation unit
depends on."


That's very confused. Putting the text of the private part in the same
file as the body creates a source dependence it is true, meaning that if
you modify a body, you have to recompile clients, but it does not mean 
that a client has to compile the body (that is only needed in the presence
of inlining or generics), so the presence of with's in the body is quite
irrelevant.

So the effect is indeed to increase amount of compilation, but there is
no significant increase in the compilation time of any one unit (a very
small effect from opening more files, that's all).

As for compilations taking DAYS (with a shout), this is like political
campaign rhetoric, it results in FUD but is short on technical facts :-)

Early on people used to assume that the source based approach would mean
that GNAT was much slower than xxx compiler, but you can never make facile
assumptions like this without actually measuring things.

GNAT compiles things pretty fast, especially when it comes to client
specs, which only go through part of the compilation process (no code
is generated for such specs of course). For example, when I compile
the DEC Starlet package on my 133MHz Pentium note book, it takes just
over a minute to compile a client that with's this package. Starlet is
62,000 lines of code with 45,000 lines non-comment non-blank.

Furthermore, that time is with the slow debugging checks on version of
the compiler (this is still the only version of the compiler that we
distribute, although we are coming close to the point of distributing
the fast version).

To find a GNAT compilation that took days, you would either have to have
an abysmally slow machine (perhaps a 386 with 4K bytes of memory), or
you would need hundreds of millions of lines of Ada code!

Re: Two ideas for the next Ada standard

[Dennison]

Robert Dewar wrote:
> 
> That's very confused. Putting the text of the private part in the same
> file as the body creates a source dependence it is true, meaning that if
> you modify a body, you have to recompile clients, but it does not mean
> that a client has to compile the body (that is only needed in the presence
> of inlining or generics), so the presence of with's in the body is quite
> irrelevant.

You're right. I am confused. Let's try an example. Supose unit A withs spec
B. Spec B withs units C and D, and body B withs units E-K (7 extra units).

Now with private parts in the spec, the only time A has to be recompiled is
when A, the spec of B, C or D changes. But if B has a private part in the 
BODY, it seems to me that A would have to be recompiled whenever A, the spec
of B, the body of B, or C, D, E, F, H, I, J, or K change. Thus this change
(assuming even distribution) makes A nearly 3 times more likely to be 
obsoleted by a source change. If we start adding with's to units C-K, the
odds get even worse.

So what am I missing here?


> As for compilations taking DAYS (with a shout), this is like political
> campaign rhetoric, it results in FUD but is short on technical facts :-)

Obviously this could only happen if a recompile of the entire system took
that long. Admittedly, the most extreme I have ever seen was 1 day. But
if they hadn't used a dedicated VAX with 2 processors, it could easily have
taken twice as long.

-- 
email    - mailto:dennison@iag.net
homepage - http://www.iag.net/~dennison

Re: Two ideas for the next Ada standard

[Robert Dewar]

Ted Dennison said

You're right. I am confused. Let's try an example. Supose unit A withs spec
B. Spec B withs units C and D, and body B withs units E-K (7 extra units).

Now with private parts in the spec, the only time A has to be recompiled is
when A, the spec of B, C or D changes. But if B has a private part in the
BODY, it seems to me that A would have to be recompiled whenever A, the spec
of B, the body of B, or C, D, E, F, H, I, J, or K change. Thus this change
(assuming even distribution) makes A nearly 3 times more likely to be
obsoleted by a source change. If we start adding with's to units C-K, the
odds get even worse.

So what am I missing here?

  What you are missing is that the spec of A is not dependent on the body
  that is stored in the body file, so it does not transitively pick up
  the source dependencies of the body. Indeed the compiler won't even look
  at the body, it will look at the private part.

  It is just for packaging convenience that one would even consider having
  the private part in the body, simply to avoid yet another file, but there
  is no implication that the compiler would look at the body, just because
  it is in the same file!

  The upside is that you have one less file, and the private part is
  simply part of the implementation. Indeed think of the adb file now
  as an implementation file which contains two items, the private part
  and the body.

  The downside, not nearly so severe as you worry about above, is that
  if you modify the body, then you have to recompile specs, but you do
  not have to recompile if all you changed was a package on which the
  body depended (except in the inline case, where of course it is
  inevitable that this be the case).

Obviously this could only happen if a recompile of the entire system took
that long. Admittedly, the most extreme I have ever seen was 1 day. But
if they hadn't used a dedicated VAX with 2 processors, it could easily have
taken twice as long.

  Well what model of VAX? These are pretty slow machines by todays standards.
  After all the VAX/780 has a spec marc of 1 by definition, and you can't
  buy a PC with a spec marc less than about 50!

Re: Two ideas for the next Ada standard

[Norman H. Cohen]

In article <dewar.841529656@schonberg>, dewar@cs.nyu.edu (Robert Dewar)
writes: 

|> Two things we have considered adding as options to GNAT, which are not
|> extensions, merely source representation issues, are to allow the
|> private part to appear in a separate file, or to allow it to appear
|> in the body.
|>
|> The one glitch, which is a little uneasy, and is where some language help
|> would have been nice, is if you could have with statements that applied
|> only to the private part.

Surely that could also be explained away as a "source representation
issue":  A with clause in a .adp file (a separately compiled private
part) is just a representation of the identical with clause appearing on
the entire package spec.

The source-representation argument can be used to justify any language
extension whose use can be transformed statically into what we would all
recognize as standard Ada.  The argument is easily abused, and I think
that anyone applying that argument too extremely will lose his
credibility.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Two ideas for the next Ada standard

[Robert Dewar]

Norm said

"Surely that could also be explained away as a "source representation
issue":  A with clause in a .adp file (a separately compiled private
part) is just a representation of the identical with clause appearing on
the entire package spec.

The source-representation argument can be used to justify any language
extension whose use can be transformed statically into what we would all
recognize as standard Ada.  The argument is easily abused, and I think
that anyone applying that argument too extremely will lose his
credibility."


Right, with the balance between credibility loss and functionality being
judged partly on the value of the added functionality.

My view is that simply allowing the private part in a separate file is
clearly within bounds. Your suggestion with respect to the context
clauses is pushing it, but we would plan on doing that as well.

Of course the problem is that the with clause that is buried in some
separate file applies to the visible spec, which is unclean. It would
be nice if the language ad with clauses that applied only to the private
part.

Re: Two ideas for the next Ada standard

[Robert A Duff]

In article <50q1b8$1c0a@watnews1.watson.ibm.com>,
Norman H. Cohen <ncohen@watson.ibm.com> wrote:
>Surely that could also be explained away as a "source representation
>issue":  A with clause in a .adp file (a separately compiled private
>part) is just a representation of the identical with clause appearing on
>the entire package spec.

But what if the private part says "with P", but the visible part
references P?  Ada says this is legal, but one would expect it to be
illegal.

I'm curious as to the intended syntax of the private part.  Is it just
the stuff after "private"?  So the file starts with some (indented)
declarations?  Quite legal, but a bit ugly, especially since its
semantics depends on its file name (just like in C, heh, heh).

>The source-representation argument can be used to justify any language
>extension whose use can be transformed statically into what we would all
>recognize as standard Ada.  The argument is easily abused, and I think
>that anyone applying that argument too extremely will lose his
>credibility.

If this person provides a computer program that can translate from the
weird source representation into a more recognizable one, then that
would go a long way toward preserving that person's credibility!

- Bob

Re: Two ideas for the next Ada standard

[Robert Dewar]

Bob Duff asks

"I'm curious as to the intended syntax of the private part.  Is it just
the stuff after "private"?  So the file starts with some (indented)
declarations?  Quite legal, but a bit ugly, especially since its
semantics depends on its file name (just like in C, heh, heh)."

You know the syntax, it is in the RM, I think you are asking "what is
the intended source representation of the private part", and the answer
is that we have not decided yet.

Probably you need a header line of some kind, but we have not decided
yet.

Re: Two ideas for the next Ada standard

[Norman H. Cohen]

In article <DxC1Lv.BtL@world.std.com>, bobduff@world.std.com (Robert A Duff)
writes: 

|> In article <50q1b8$1c0a@watnews1.watson.ibm.com>,
|> Norman H. Cohen <ncohen@watson.ibm.com> wrote: 
|> >Surely that could also be explained away as a "source representation
|> >issue":  A with clause in a .adp file (a separately compiled private
|> >part) is just a representation of the identical with clause appearing on
|> >the entire package spec.
|>
|> But what if the private part says "with P", but the visible part
|> references P?  Ada says this is legal, but one would expect it to be
|> illegal.

One would only expect it to be illegal if he had not read gnatinfo.txt
carefully. ;-)

(I am referring, of course, to a hypothetical version of gnatinfo.txt
that would describe this hypothetical change to GNAT's treatment of with
clauses.)

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Two ideas for the next Ada standard

[Keith Thompson]

In <50q1b8$1c0a@watnews1.watson.ibm.com> ncohen@watson.ibm.com (Norman H. Cohen) writes:
> Surely that could also be explained away as a "source representation
> issue":  A with clause in a .adp file (a separately compiled private
> part) is just a representation of the identical with clause appearing on
> the entire package spec.

I don't think it's quite that simple.  For example, is the following
legal?

foo.ads:

    package Foo is
        type My_Address is new System.Address;  -- ?

foo.adp:

    with System;
    private
        -- ...
    end Foo;

If the language really supported separately compiled private parts, a
with clause on the private part would not apply to the visible part.
If it's interpreted as a "source representation", it does apply.
(I suppose the compiler could issue a warning for cases like this.)

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
"As the most participatory form of mass speech yet developed, the Internet
deserves the highest protection from government intrusion." -- ACLU v. Reno

Re: Two ideas for the next Ada standard

[Robert Dewar]

Keith said

"I don't think it's quite that simple.  For example, is the following
legal?

foo.ads:

    package Foo is
        type My_Address is new System.Address;  -- ?

foo.adp:

    with System;
    private
        -- ...
    end Foo;

If the language really supported separately compiled private parts, a
with clause on the private part would not apply to the visible part.
If it's interpreted as a "source representation", it does apply.
(I suppose the compiler could issue a warning for cases like this.)
"

Keith either you are not thread following, or your news handler delivers
stuff late, or you missed reading some of my messages :-) :-)

Of course this is legal. There is no possible "source interpretation" which
would make this legal, and indeed I have explicitly noted in my previous
posts that this is a (minor) disadvantage of this approach. I think minor
in practice ...
\x1adp

Re: Two ideas for the next Ada standard

[Geert Bosch]

Robert A Duff (bobduff@world.std.com) wrote:

`` Quite true.  Private parts are primarily an efficiency hack.  But this
   change would be much more sweeping than my idea of allowing the private
   part to have its own with_clauses.  (I think putting the with_clauses
   inside things makes more sense anyway, independent of your idea.) ''

You shouldn't put with_clauses inside things! Currently you can easily see
what packages a compilation module depends on, since with_clauses are
right at the start of the file. It would be a really bad idea if it was
possible to, for example, hide an instantiation of an Unchecked_Conversion
somewhere in the package spec.

I agree although that private parts belong in the body of the package.
Linkers should be smarter indeed. Even thinking about the way C programmers
rely on the linker makes me shiver...
-- 
E-Mail: geert@sun3.iaf.nl    
      ``I think there is a world market for maybe five computers.''
        Thomas Watson,  chairman of IBM, 1943

Re: Two ideas for the next Ada standard

[Robert A Duff]

In article <50d2nb$eko@fozzie.sun3.iaf.nl>,
Geert Bosch <geert@fozzie.sun3.iaf.nl> wrote:
>You shouldn't put with_clauses inside things! Currently you can easily see
>what packages a compilation module depends on, since with_clauses are
>right at the start of the file.

Yeah, but you can't easily tell what the name of the thing is, or
whether it's a package spec or body or procedure or whatever, because
there are 20 lines of with_clauses first.  IMHO the *name* of the thing
is it's most important property, and should therefore come first.

>... It would be a really bad idea if it was
>possible to, for example, hide an instantiation of an Unchecked_Conversion
>somewhere in the package spec.

Agreed.  I really meant "inside, but right at the top".  Similar to the
rule for where a pragma Pure goes.  Or maybe with special syntax marking
that start and finish of the "imports part" or some such thing.  Not
scattered all over in the middle of the package.

- Bob

Re: Two ideas for the next Ada standard

[Peter Hermann]

Are there proposals for the project name of the new standard
similar to Ada9X, such as Ada200X, Ada2000, Ada0X, etc. ?
I am expecting the new standard will come out in 2005
with a much smaller delta as it was from 83 to 95.

Van Snyder (vsnyder@math.jpl.nasa.gov) wrote:
: 1.  Allow the "mode" of an "access to procedure" or "access to function"
:     formal argument to be "limited".  Interpret this to mean "you can only
:     use this argument to access the subprogram, or pass it as an actual
:     argument to a formal argument of `limited' mode."  This would prevent
:     one from storing the "pointer" into an "access to procedure" variable,
:     and thereby allow safely passing internal procedures as actual arguments.

In Ada95, I would help myself (if really needed) by setting the internal
state of the calling environment such that an inexpected call from
outside would report or raise an exception.

: 2.  Allow an "out" "mode" for variables in specification parts, or fields
:     in records.  The interpretation is that any one can read the variables,
:     but only procedures in (or the initialization part of) the body of the
:     package can write them, or pass them to other than "in" mode formal
:     arguments in different packages.  Given this, one can safely expose
:     variables containing values one wishes to expose, but to which one does
:     not want to permit willy-nilly changes, without the need to write a
:     one-line function.

"out" is not (yet ;-) my taste. I see the designers ponder over
syntactic optima, e.g. "half constant" :-) , "not constant"
within the body in order to cancel a constant in the spec,
"protected", "half private" :-) , "read_only", or last but not least
"out". The problem with out is the perspective of view :-(  .
Certainly it is a good idea to use existing keywords.

I welcome ideas for the new standard which really should be gathered
somewhere. but where? The AALC mechanism was a sponsored activity, AFAIK.

--
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: Two ideas for the next Ada standard

[Michael F Brenner]

In additions to these two ideas, we should consider two more:     

(1) Efficiencies required for systems programming:
(1a) Permit placing a variable at an absolute physical machine
address (as opposed to a gnat virtual address).
(1b) Correct the language design error that CHECKED conversion 
between signed and unsigned integers may overflow or raise constraint_error.
(1c) Add logical operations (AND, OR, etc.) on signed numbers.
(1d) Make software reuse through generics efficient by REQUIRING
all expressions that would have been static in a non-generic package
to remain static when the package is made generic. In Ada-95, 
you lose staticness all over, and, consequently, you lose compile
time computation of most expressions, when you make a package generic.
(1e) Mandate a compiler-independent way to identify a procedure as the
interrupt handler for a given interrupt number. 
(1f) Mandate a standardized way to identify that an INTERFACE
parameter is to be passed by reference.
(1g) Legalize a compiler-independent way to overlay two variables. 
This could be accomplished without offending non-system-programming
purists, who are rightfully concerned with the safety violation
implied by overlaid variables in two steps as follows. First, mandate
that unchecked_conversions generate no code, and recommend that
they be optimized away whenever the compiler detects the possibility 
of doing so. Second, in the tradition of searchable keywords like
SYSTEM, CLASS, and UNCHECKED_DEALLOCATION, use pragma OVERLAID to 
document the fact that a variable MUST be optimized away. Alternately,
just change the wording of the manual from making overlaid variables
erroneous to making them a safety concern that must be tested carefully.
(1h) A FAST, mandatory, standarized way to put a stream of bytes out to 
a file, with no intermediate packages or code between the
Ada call and the underlying file system WRITE and READ commands,
giving random access to standard_input and the same I/O speed as 
competing languages, which now requires compiler dependent code.

(2) Make packages into second-class objects; currently they are
third-class objects, forbidding arrays of packages and forbidding
passing packages as generic parameters; a second-class package
would permit passing non-generic packages as generic parameters, which
permit an easy-to-read, easy-to-implement, very efficient method of 
creating iterators with a single level of generics across a wide
set of data structures. 

(3) I suggest calling the next version 2kX, in honor of the year 2000 problem
which will be biting CALENDAR software whose date limitations arise in the
neighborhood of 1999 plus or minus a hundred year sliding window.

Re: Two ideas for the next Ada standard

[Robert A Duff]

In article <506svr$h1v@linus.mitre.org>,
Michael F Brenner <mfb@mbunix.mitre.org> wrote:
>In additions to these two ideas, we should consider two more:     
>
>(1) Efficiencies required for systems programming:
>(1a) Permit placing a variable at an absolute physical machine
>address (as opposed to a gnat virtual address).

This seems like an implementation issue.  On systems where physical
addresses make sense, an Ada implementation is free to support them.
I don't see any advantage in saying something about it in the language
standard, since it's highly nonportable anyway.

>(1b) Correct the language design error that CHECKED conversion 
>between signed and unsigned integers may overflow or raise constraint_error.

I'm not so sure this is a design error.  Anyway, why do you call this an
"efficiency" issue?

>(1c) Add logical operations (AND, OR, etc.) on signed numbers.

Why?

>(1d) Make software reuse through generics efficient by REQUIRING
>all expressions that would have been static in a non-generic package
>to remain static when the package is made generic. In Ada-95, 
>you lose staticness all over, and, consequently, you lose compile
>time computation of most expressions, when you make a package generic.

This is confused.  Losing staticness does not imply losing compile-time
evaluation.  Any compiler that uses the macro-expension model of
generics will do what you ask here.  And of course if you're sharing
code, you can't do it, in general.

>(1e) Mandate a compiler-independent way to identify a procedure as the
>interrupt handler for a given interrupt number. 

Please explain why the protected-procedures-as-handlers model is
insufficient.

>(1f) Mandate a standardized way to identify that an INTERFACE
>parameter is to be passed by reference.

Sounds useful, but you can always use an access type.

>(1g) Legalize a compiler-independent way to overlay two variables. 

Using address clauses to achieve overlays was erroneous in Ada 83, but
the Ada 95 RM no longer says that.  Nonetheless, you have to make sure
your addresses are valid, and that is somewhat implementation dependent.
I think you very badly want it that way, since otherwise the compiler
would have to generate *very* poor code.

>This could be accomplished without offending non-system-programming
>purists, who are rightfully concerned with the safety violation
>implied by overlaid variables in two steps as follows. First, mandate
>that unchecked_conversions generate no code, ...

This makes no sense to me.  The RM has no notion of "generate code", so
how can it possibly say anything about it?  How could you test a
compiler to see if it obeyed?  I don't know of any language definition
that tries to address that sort of issue (except for assembly
languages).  E.g., the C standard doesn't prevent a cast from generating
code.  Generating code is a compiler issue -- if you think the compiler
is generating too much code, complain to the compiler writer.

I agree that unchecked conversions between like-sized things should not
generate code.  And Ada 95 facilitates that by making various things
erroneous, and by allowing by-reference return (13.9(12)).  But anything
beyond that seems like a quality-of-implementation issue.

>...and recommend that
>they be optimized away whenever the compiler detects the possibility 
>of doing so.

I'm not sure what you mean.  What's the difference between "generate no
code" and "optimize away"?  And why is one mandated and the other
recommended?  In any case, this sort of recommendation is silly --
compiler writers *know* they should eliminate unnecessary code when they
can make the compiler detect that possibility.  Shall we also recommend
that assignment not use an exponential algorithm?

>... Second, in the tradition of searchable keywords like
>SYSTEM, CLASS, and UNCHECKED_DEALLOCATION, use pragma OVERLAID to 
>document the fact that a variable MUST be optimized away. Alternately,
>just change the wording of the manual from making overlaid variables
>erroneous to making them a safety concern that must be tested carefully.

I think the RM95 *did* do just that.  But you really have to know what
you're doing to take advantage of it.

>(1h) A FAST, mandatory, standarized way to put a stream of bytes out to 
>a file, with no intermediate packages or code between the
>Ada call and the underlying file system WRITE and READ commands,
>giving random access to standard_input and the same I/O speed as 
>competing languages, which now requires compiler dependent code.

A fair comment.

>(2) Make packages into second-class objects; currently they are
>third-class objects, forbidding arrays of packages and forbidding
>passing packages as generic parameters; a second-class package
>would permit passing non-generic packages as generic parameters, which
>permit an easy-to-read, easy-to-implement, very efficient method of 
>creating iterators with a single level of generics across a wide
>set of data structures. 

This would not be easy to do.  For example, you have to define what it
means to have two copies of the "same" type.

Please show an example of what you mean about iterators.

>(3) I suggest calling the next version 2kX, in honor of the year 2000 problem
>which will be biting CALENDAR software whose date limitations arise in the
>neighborhood of 1999 plus or minus a hundred year sliding window.

I don't see a smily there...  Do you think Ada will still be around in
2099?

- Bob

Re: Two ideas for the next Ada standard

[Robert Dewar]

Michael F Brenner <mfb@mbunix.mitre.org> wrote:

>In additions to these two ideas, we should consider two more:
>
>(1) Efficiencies required for systems programming:
>(1a) Permit placing a variable at an absolute physical machine
>address (as opposed to a gnat virtual address).

   This is not a language issue, what on earth is a physical or virtual
   address? At the language semantic level it is a nonsense concept!
   Address values are implementation dependent. On many systems the
   concept of a physical address is meaningless at the problem program
   level. On an implementation where it makes sense, it can be supported.

   On most systems you cannot just let a program specify a physical
   address, since you have to explicitly map the address. The normal
   approach would be to use an expressoin like map(physical-address)
   as the expression in the address clause.

>(1b) Correct the language design error that CHECKED conversion
>between signed and unsigned integers may overflow or raise constraint_error.

   I disagree that this is a design error, I have no idea of what probably
   implementation dependent semantics you have for the result, but it
   seems a bad idea to follow this idea.

>(1c) Add logical operations (AND, OR, etc.) on signed numbers.

   What for, the result is unpleasantly implementation dependent. If
   implementations want to allow this, fine (GNAT does), but I don't
   think it should be in the language.

      In GNAT:

         with Text_IO; use Text_IO;
         procedure q is
         
            function shift_right (a : integer; b : natural) return integer;
            pragma import (intrinsic, shift_right);
         
            x,y : integer;
         begin
            x := 24;
            y := shift_right (x,3);
            put_line (y'img);
         end;

>(1d) Make software reuse through generics efficient by REQUIRING
>all expressions that would have been static in a non-generic package
>to remain static when the package is made generic. In Ada-95,
>you lose staticness all over, and, consequently, you lose compile
>time computation of most expressions, when you make a package generic.

   I do not understand your point here, it seems confused. You do not lose
   any compile time computation of expressions in generics, and indeed
   compile time computatoin has little to do with staticness (you are
   confusing two separate concepts, one which has semantic significance
   and one which is purely an implementation issue).

>(1g) Legalize a compiler-independent way to overlay two variables.
>This could be accomplished without offending non-system-programming
>purists, who are rightfully concerned with the safety violation
>implied by overlaid variables in two steps as follows. First, mandate
>that unchecked_conversions generate no code, ...

   What does generate code mean? Nothing at all semantically. I think you
   are badly confusing the notion of language definition and implementation
   requirements. As a matter of fact, many unchecked conversions MUST
   generate code even when conversion between identical sized types
   is involved, or you get the wrong results. A typical example is
   that a biased value, unbiased in a register, must be rebiased for
   an unchecked conversion.

>(1h) A FAST, mandatory, standarized way to put a stream of bytes out to
>a file, with no intermediate packages or code between the
>Ada call and the underlying file system WRITE and READ commands,
>giving random access to standard_input and the same I/O speed as
>competing languages, which now requires compiler dependent code.

   This seems very curious to me. There are no consistent "underlying
   file system WRITE and READ commands" that are consistent across
   operating systems. If you mean that you want access to some particular
   set of routines (e.g. Unix fread and fwrite, which are of course not
   available on all systems), then call these routines.

   random access to standard input is a highly implementation dependent
   concept.

   how would you map your ideas here into the file system of the IBM
   mainframe, or the VMS record manager?

">(2) Make packages into second-class objects; currently they are
>third-class objects, forbidding arrays of packages and forbidding
>passing packages as generic parameters; a second-class package
>would permit passing non-generic packages as generic parameters, which
>permit an easy-to-read, easy-to-implement, very efficient method of
>creating iterators with a single level of generics across a wide
>set of data structures.

   That's a much harder feature to define than you think. 

Re: Two ideas for the next Ada standard

[Robert A Duff]

>Michael F Brenner <mfb@mbunix.mitre.org> wrote:
>>(1h) A FAST, mandatory, standarized way to put a stream of bytes out to
>>a file, with no intermediate packages or code between the
>>Ada call and the underlying file system WRITE and READ commands,
>>giving random access to standard_input and the same I/O speed as
>>competing languages, which now requires compiler dependent code.

It seems to me that Ada.Streams.Stream_IO and Ada.Text_IO.Text_Streams
address the issue.  They provide a very low-level I/O interface
(transfer an array of bytes to a file, and so forth).  The latter allows
access to standard input and output files.

- Bob

Re: Two ideas for the next Ada standard

[Robert Dewar]

iBob Duff said

"It seems to me that Ada.Streams.Stream_IO and Ada.Text_IO.Text_Streams
address the issue.  They provide a very low-level I/O interface
(transfer an array of bytes to a file, and so forth).  The latter allows
access to standard input and output files."

Yes and no, if your idea is that C is nice because you can call fread and
fwrite directly with not one instruction in between, then I think the
proper Ada response is that in Ada you can call fread and fwrite directly
with not one instructoin in between!

Re: Two ideas for the next Ada standard

[Robert A Duff]

In article <dewar.841529787@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Yes and no, if your idea is that C is nice because you can call fread and
>fwrite directly with not one instruction in between, then I think the
>proper Ada response is that in Ada you can call fread and fwrite directly
>with not one instructoin in between!

But the original poster said he wanted a standard/portable mechanism.

- Bob

Re: Two ideas for the next Ada standard

[Robert Dewar]

Peter Herman says

"Are there proposals for the project name of the new standard
similar to Ada9X, such as Ada200X, Ada2000, Ada0X, etc. ?
I am expecting the new standard will come out in 2005
with a much smaller delta as it was from 83 to 95."

There is no new standard
There is no project
There is no project name
There is no expectation of a new standard as soon as 2005
(it is very rare for only 10 years to go by between standards, COBOL 66
to COBOL 74 was an exception, but a bogus one, because the 66 date was
really very late compared to the real date of introduction).

Peter also says that he thinks ideas for a new standard should be
gathered.

I disagree, far too early for that, concentrate on how to use the
current one for the next few years before wasting time ruminating
on new features when we don't really know Adqa 95 yet.

Re: Two ideas for the next Ada standard

[Robert A Duff]

In article <dewar.841529493@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Peter also says that he thinks ideas for a new standard should be
>gathered.
>
>I disagree, far too early for that, concentrate on how to use the
>current one for the next few years before wasting time ruminating
>on new features when we don't really know Adqa 95 yet.

I agree with Robert -- there's no point in "gathering" these ideas in
any official way.  On the other hand, it's harmles, and a lot of fun, to
speculate about alternate language designs (whether or not they are
realistic ideas for Ada 0X).

- Bob

Re: Two ideas for the next Ada standard

[Laurent Guerby]

Bob> [...] Private parts are primarily an efficiency hack. [...]

   I agree that this is true for Ada 83, but in Ada 95 a child unit
gains visibility (in their private part and body) to the declarations
in the private part of their parent, and this is an important semantic
feature, no longer only an efficiency hack.

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Two ideas for the next Ada standard

[Robert Dewar]

Laurent said, answering Bob Duff:

"Bob> [...] Private parts are primarily an efficiency hack. [...]

   I agree that this is true for Ada 83, but in Ada 95 a child unit
gains visibility (in their private part and body) to the declarations
in the private part of their parent, and this is an important semantic
feature, no longer only an efficiency hack."


Laurent, I think you are confused. The "hack" that Bob is referring to
is the fact that the private part is part of the spec, or more precisely
that the clients of the package have a dependency on the private part (since
as I pointed out previously, it is perfectly fine to put the private part
in the same file as the body). 

Obviously a child package with visibility to the private part MUST have
a dependency on the private part, so that is not an issue.

Really there are two slightly annoying things here

1. The fact that clients have a dependence on the private part
2. The fact that private parts do not have a separate with list

Re: Two ideas for the next Ada standard

[Laurent Guerby]

Robert> Laurent, I think you are confused. The "hack" that Bob is
Robert> referring to is the fact that the private part is part of the
Robert> spec, or more precisely that the clients of the package have a
Robert> dependency on the private part (since as I pointed out
Robert> previously, it is perfectly fine to put the private part in
Robert> the same file as the body).

   I was refering to the fact that in Ada 83, put aside efficiency
issues, you could have completly removed the notion of private part,
and put everything in the body without changing (too much) the
language, since nothing can gain visibility to the body (or to the
private part), so this private part could be considered as part of the
body.

   But in Ada 95, the visibilty model has been refined and child units
have visibility to something in the parent which is not the public
part, so you cannot remove this notion of private part without
changing the language (disallowing child units, or giving them full
visibilty to the body). Putting the private part elsewhere doesn't
change the fact that this notion has to exist for other reasons than
efficiency in Ada 95 (together with public and body).

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Two ideas for the next Ada standard

[Robert Dewar]

Laurent said

"   I was refering to the fact that in Ada 83, put aside efficiency
issues, you could have completly removed the notion of private part,
and put everything in the body without changing (too much) the
language, since nothing can gain visibility to the body (or to the
private part), so this private part could be considered as part of the
body.
"

OK, that makes sense. I had not realized that you (and Bob?) were suggesting
completely removing the notion of private part in Ada 83. I agree that is
technically sensible, but I find the notion of a private part useful from
an abstraction point of view in any case, even discounting your quite
correct observation that the private part plays an important new role
in Ada 95.

In fact in Ada 95, one of the things I found took some learning was that
private parts do indeed play a completely different role. If you simply
think of private parts as completing private stuff in the spec, and
then you see that child packages have access to this, that's interesting,
but misses a very important and powerful aspect of Ada 95 that has no
analog in Ada 83.

In Ada 95, it makes sense to put all sorts of stuff in private parts,
including types and subprograms that have nothing directly to do with
what is in the spec. You can even imagine an empty spec with a big
private part. The reason that all this stuff is in a private part is
to limit visibility to clients and permit visibility only to children.

For example, the official spec of package Ada is empty, but it is quite
reasonable for an implementation to add a private part to this package
that contains stuff needed by children of Ada in a particular
implementation. The same is true for System. GNAT does not do this,
but probably it should ...

Re: Two ideas for the next Ada standard

[Laurent Guerby]

Robert> OK, that makes sense. I had not realized that you (and Bob?)
Robert> were suggesting completely removing the notion of private part
Robert> in Ada 83. [...]

   My point was that "private part = primarily an efficiency hack" is
technically true in Ada 83 (since we can remove it, but I'm not
suggesting it should have been done ;-), but false in Ada 95 where a
private part has an important semantic role in visibility issues.

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Two ideas for the next Ada standard

[Robert Dewar]

Laurent says
"   My point was that "private part = primarily an efficiency hack" is
technically true in Ada 83 (since we can remove it, but I'm not
suggesting it should have been done ;-), but false in Ada 95 where a
private part has an important semantic role in visibility issues."

Now that I do not understand. The point of private parts in both Ada 83
and Ada 95 is to control visibility. If you remove private parts in
Ada 83, you lose the visibility control, the same is true in ada 95
(child units see the spec as well!)

Re: Two ideas for the next Ada standard

[Adam Beneschan]

In article <dewar.841801412@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
 
 >Laurent says
 >"   My point was that "private part = primarily an efficiency hack" is
 >technically true in Ada 83 (since we can remove it, but I'm not
 >suggesting it should have been done ;-), but false in Ada 95 where a
 >private part has an important semantic role in visibility issues."
 >
 >Now that I do not understand. The point of private parts in both Ada 83
 >and Ada 95 is to control visibility. If you remove private parts in
 >Ada 83, you lose the visibility control, the same is true in ada 95
 >(child units see the spec as well!)

I think we're getting off topic here.  When we were originally talking
about removing private parts in Ada 83, we were discussing moving the
full "private" definitions to the BODY, not leaving them visible in
the spec.  This is equivalent in terms of visibility (in Ada 83, that
is).  The "efficiency hack" referred to the problem that it's harder
to get the compiler to generate code when the full type definitions
are in the package body; presumably this is why they were moved to the
spec and put into a private part.

On an unrelated topic, I wonder whether the language designers would
have come up with a different terminology if they knew we were going
to have these discussions?  All this talk about "removing private
parts" is generating some disturbing visuals . . .

                                -- Adam

private parts (was: Two ideas for the next Ada standard)

[Arthur Evans Jr]

adam@irvine.com (Adam Beneschan) wrote:

> On an unrelated topic, I wonder whether the language designers would
> have come up with a different terminology if they knew we were going
> to have these discussions?  All this talk about "removing private
> parts" is generating some disturbing visuals . . .

I remember an Ada-83 Distinguished Reviewer meeting, probably about 1979
or 80 or so, at Intermetrics, chaired by Bill Carlson.  One of the DRs,
whom I'll refer to here as Joe Schmoe, had some important ideas about
changes to private parts that he wanted to discuss.  No problem, but
Bill had an agenda and that topic wasn't scheduled for discussion till
later on.

So, finally, we reached the point where we were ready for that
discussion.  "OK," Bill said, "now it's time to discuss Joe Schmoe's
private parts."  What a remarkable shade of red Joe Schmoe turned.

We worked hard at DR meetings, but they surely had their moments of fun.

Art Evans