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

[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

[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

Re:Two ideas for the next Ada Standard

[dulman]

                                                                                
     As began debate concerning future of the language standard, I would        
     like to do some remarks to future ADA-0x.                                  
                                                                                
     1. ALIASED is more common notion then RENAMES  and  (it seams to me)       
        this key word needn't.                                                  
                                                                                
     2. OUT parameters have such chances as IN OUT                              
                                                                                
     3. Maybe  for calling entry in SELECT statement with  DELAY to write       
        in the form :                                                           
                                                                                
        <entry_name>(...)   WITH DELAY [UNTIL] <time>;                          
                                                                                
        ACCEPT <entry_name>(...) WITH DELAY [UNTIL] <time> DO ...   END;        
                                                                                
        This construction will  allow to expect rendezvous  up to a given       
        time moment, or given time interval.                                    
                                                                                
     4. To add the subroutine parameter type ALIASED, that will  allow to       
        use inside it reference to the subroutines with  " 'ACCESS " or         
        " 'UNCHECKED_ACCESS" parameters.                                        
                                                                                
     5. Nongeneric form of packages  DIRECT_IO and SEQUENTIAL_IO.               
        Parameter RECORD_SIZE to add for  parameter's  list in procedures       
        CREATE and OPEN                                                         
        (for example in form RECORD_SIZE:=<type's name>'size;).                 
                                                                                
     6. To specify use ACCESS and UNCHECKED_ACCESS attributes for aliased       
        variable. Now (in basic) it is necessary to use  UNCHECKED_ACCESS       
        attribute.                                                              
                                                                                
       Leonid Dulman (dulman@ibm.net)                                           

Re: Two ideas for the next Ada Standard

[Robert Dewar]

Incidentally I think random discussion of new ideas for Ada by email
or in this newsgroup is largely wasted effort. Note that the first
step in the Ada 9X effort was to collect revision suggestions in
a very formal form, with a formal submission procedure.

As I said before, I think this is premature anyway. People do not know
Ada 95 well enough to make useful suggestions yet, so the discussion
of new features will have a very high noise-to-signal ratio, with
a lot of suggestions simply reflecting a lack of understanding of
how Ada 95 can be used to solve the problems. At least 5 years needs
to go by before there is enough perspective to understand what, if
anything, that is really important, is missing or inconvenient in the
language.

Re: Two ideas for the next Ada Standard

[Larry Kilgallen]

In article <dewar.841590835@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
> Incidentally I think random discussion of new ideas for Ada by email
> or in this newsgroup is largely wasted effort. Note that the first
> step in the Ada 9X effort was to collect revision suggestions in
> a very formal form, with a formal submission procedure.

I beg to differ, in that the resultant discussion provides good review
for some of us regarding _why_ things are in the current state.

> As I said before, I think this is premature anyway. People do not know
> Ada 95 well enough to make useful suggestions yet, so the discussion
> of new features will have a very high noise-to-signal ratio, with
> a lot of suggestions simply reflecting a lack of understanding of
> how Ada 95 can be used to solve the problems. At least 5 years needs

But some of us look to this newsgroup as a way of gaining that
understanding.  Experts like Robert will be condemned to spending
some of their time being bored by what is obvious to them :-).

I have no interest in promoting change (and I take particular exception
to what I had read as a suggestion to change some reserved words, thus
causing havoc with old programs), but I find the _discussion_ of interest.

By contrast, "which languages is best" topics bore me, although they
might be attractive if titles were changed more often to really show
the current content.  "Comparing method invocation Syntax of C and Ada"
provides better guidance than "Whichever you prefer (was Which Language
should I Choose (was Help for Ada Newcomers))".

Larry Kilgallen

Re: Two ideas for the next Ada Standard

[Jonas Nygren]

Robert Dewar wrote:
> 
> Incidentally I think random discussion of new ideas for Ada by email
> or in this newsgroup is largely wasted effort. Note that the first
> step in the Ada 9X effort was to collect revision suggestions in
> a very formal form, with a formal submission procedure.
> 
> As I said before, I think this is premature anyway. People do not know
> Ada 95 well enough to make useful suggestions yet, so the discussion
> of new features will have a very high noise-to-signal ratio, with
> a lot of suggestions simply reflecting a lack of understanding of
> how Ada 95 can be used to solve the problems. At least 5 years needs
> to go by before there is enough perspective to understand what, if
> anything, that is really important, is missing or inconvenient in the
> language.

Well, I guess not all of us interested in this topic were involved in
the Ada95 standardisation effort or otherwise privy to the discussions
which led up to the exclusion of the feature of our delight.

Coming from a C/C++ background I have had a hard time to adjust to
many of the Ada features (geez, I have never casted so much before in
my programming life). All in all I have gone native. Ada is my sole
programming language today - well I like to make life difficult :-).
Still, there are some things I have a problem to adjust to. One is 
P(X) instead of the popular X.P notation. I do understand that in 
Ada83 the only way to derive a type was to use 'is new' and that it
seemed natural to follow the same notation for tagged types. Though,
I still prefer the X.P notation and believe it could have been 
integrated into Ada95 in a reasonably clean manner - oh yes, I have
read the Rationale on this and it sounds hollow and thin to me.

But it is not a question of only these big and 'religious' questions.
E.g. I can not understand why one cannot have an anonymous access
argument which refers to a constant, e.g P(X : access CONSTANT XT).
Why not? What ever could have been said against this? Premature?

So please let us keep on 'BS'ing on our favourite issues irregardless
if Robert Dewar tells us to 'shut up'. It would be more fun if Robert
and others who have been involved in the standardisation process for
Ada95 either said we excluded/included this feature because of this or
that or perhaps say we overlooked that feature.

Sorry for wasting the bandwidth,

/jonas

PS Perhaps Robert's postings would be more productive if

> a lot of suggestions simply reflecting a lack of understanding of
> how Ada 95 can be used to solve the problems. At least 5 years needs

they actually told us how DS

Re: Two ideas for the next Ada Standard

[Peter Hermann]

Jonas Nygren (jonas@joy.ericsson.se) wrote:
: So please let us keep on 'BS'ing on our favourite issues irregardless
: if Robert Dewar tells us to 'shut up'.

GNAT is indeed an excellent product which is now reaching maturity.
I am working with it and do appreciate it very much.
I am sharing your opinion above and I consider Robert's reaction
all too natural and well understandable as a business requirement
from his point of view: Freezing Ada95 as long as possible :-)
(this statement will certainly not shake him ;-)

: It would be more fun if Robert
: and others who have been involved in the standardisation process for
: Ada95 either said we excluded/included this feature because of this or
: that or perhaps say we overlooked that feature.

I don't know why you are not aware of Robert's contributions(?).
These are a lot of fun and learning although not gentle style ;-).

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

[Robert Dewar]

Peter said

"GNAT is indeed an excellent product which is now reaching maturity.
I am working with it and do appreciate it very much.
I am sharing your opinion above and I consider Robert's reaction
all too natural and well understandable as a business requirement
from his point of view: Freezing Ada95 as long as possible :-)
(this statement will certainly not shake him ;-)"


On the contrary, we are in a much better position at ACT to react to
changes in the language than our competitors are. After all GNAT
is well ahead in being the only Ada 95 compiler to implement the
full language including the annexes. If anything rapid change
would benefit us if we took a very narrow view.

However, we do not take such a narrow view. There are many reasons
why it will be a while before a new Ada standard appears, if one
ever does. It takes a long time to really learn what needs to be
changed and what does not. Many people in this forum make suggestions
before they fully understand the issues, which is perfectly fine, but
is not a useful part of a formal discussion of the requirements for
a future standard. 

It is fine to have informal discussions, but of necessity the Ada standard
will be stable for at least a decade, so the important thing to realize
is that discussions of possible changes to Ada 95 have pretty mjuch zero
impact on the real problems of how to get Ada 95 programs working (but
not to worry, most of the people I know actually working on Ada 95
programs are not reading CLA anyway :-)

My point was simply that there is no point in trying to regard these
discussions as somehow being part of teh formal process that might
eventually lead up to the next standard. For one thing that is far
too restrictive.

Note that one of the purposes of GNAT is to encourage experimentation
with the language, so one thing that I hope will happen is that we will
see announcements of actual experiments that take advantage of this.
For example, it would be nice to see a CLA post that said

"I think Ada should have multiple inheritance using the notation
     
    type x is new A and new B with ....

and on xyz internet site, you can get a version of GNAT that implements
this concept -- please play with it and see what you think."

The other thing to avoid is the broken record phenomenon. New people will
wander into the Ada fold over time, and will send messages saying things
like "gee I don't like the p(a) notation, I prefer a.p", and it would be
nice to simply be able to refer people to a CLA archive with some
apporpriate thread references. Is anyone maintaining anything approaching
such an archive.

Re: Two ideas for the next Ada Standard

[Larry Kilgallen]

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

> It is fine to have informal discussions, but of necessity the Ada standard
> will be stable for at least a decade, so the important thing to realize
> is that discussions of possible changes to Ada 95 have pretty mjuch zero
> impact on the real problems of how to get Ada 95 programs working (but

That is a shame.
Discussions in most newsgroups have enormous effect on the real world :-).

> The other thing to avoid is the broken record phenomenon. New people will
> wander into the Ada fold over time, and will send messages saying things
> like "gee I don't like the p(a) notation, I prefer a.p", and it would be
> nice to simply be able to refer people to a CLA archive with some
> apporpriate thread references. Is anyone maintaining anything approaching
> such an archive.

I think the first line of defense is a strongly worded FAQ for overly
discussed non-issues.  "This syntax differs from C++." has a one-word
answer - "Yes".  I am strongly reminded of the question "How do I zero
the new mail counter?" from another part of my life.  That requires a
strong FAQ entry despite being fully documented in the proper manual.

Larry Kilgallen

Re: Two ideas for the next Ada Standard

[Richard A. O'Keefe]

Jonas Nygren <jonas@joy.ericsson.se> writes:
>Coming from a C/C++ background I have had a hard time to adjust to
>many of the Ada features (geez, I have never casted so much before in
>my programming life).

This puzzles me greatly.  I've been hacking Ada for about two years now,
and *except when trying to interface to C code* find that I have very
few conversions.  (I take it that "casted"---IS there such a word
form?---refers to conversions.)  It would be interesting to know what
you are doing that makes conversion common.

>Still, there are some things I have a problem to adjust to. One is 
>P(X) instead of the popular X.P notation. 

The Pop family of languages has always identified F(X) and X.F.
Are you are happy to see x.sqrt.print instead of print(sqrt(x))?
If not, _why_ not?  In Smalltalk, after all, sqrt _is_ a method in
the floating point class...

Algol 68 and COBOL use "field OF record" instead of "record.field".
Is that _really_ such a big deal?

Hmm.  It would be interesting to determine the preferences of
 - people whose native language is SVO, like English
    Prediction: subject.method(object) preferred.

 - people whose native language is VSO
    Prediction:  method(subject, object) preferred

 - people whose native language is SOV (isn't Japanese like that?)
    Prediction:  somewhere in between the others.

I suppose it won't do any good to point out that the Ada approach
generalises nicely to overloaded operators, while the C++ approach
requires some ad hack kluging?

>E.g. I can not understand why one cannot have an anonymous access
>argument which refers to a constant, e.g P(X : access CONSTANT XT).
>Why not? What ever could have been said against this? Premature?

What exactly does this buy you that an "in" argument doesn't buy you?
It looks _awfully_ like a demand that Ada look like C++ (const ref).

>So please let us keep on 'BS'ing on our favourite issues irregardless
>if Robert Dewar tells us to 'shut up'. It would be more fun if Robert
>and others who have been involved in the standardisation process for
>Ada95 either said we excluded/included this feature because of this or
>that or perhaps say we overlooked that feature.

To some extent this is true, but as someone who uses GNAT every day
I don't want to see too much of Robert Dewar's time diverted from 
enhancing an already *wonderful* tool.  And his postings are already
darned productive (even when he disagrees with me).

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Two ideas for the next Ada Standard

[Robert A Duff]

In article <50gelc$2le@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>This puzzles me greatly.  I've been hacking Ada for about two years now,
>and *except when trying to interface to C code* find that I have very
>few conversions. ...

I gave an example in another post.

Another example is: You can't write a function that takes a parameter of
"any integer type".  This is a perfectly reasonable thing to do -- e.g.
a function that converts an integer to a string.  (I know 'Image does
that, but it does it wrong -- it leaves an extra space, and it doesn't
support hexadecimal, interspersed commas (as in 1,000,000), etc.)

One choice is to write a function that takes Longest_Integer, or
whatever, but then you have a bunch of bogus type conversions at all the
call sites.  These type conversions are just extra verbiage in my
opinion.  A type conversion ought to tell the reader "I'm going outside
the type system, doing something questionable, read this carefully."
But if you have a lot of "harmless" type conversions, it weaken the
effect -- it's like crying wolf.

Another choice is to use a generic.  This require even *more* excess
verbiage (all kinds of instantiations).  And it can lead to code bloat
on most implementations.

Another choice is to declare a root integer type, and declare the
function as primitive of that type, and inherit that function for all
your integer types.  But this requires everything to be derived from a
single root type, which inhibits code reuse.

Another choice is to use subtypes instead of types.  This reduces the
number of type conversions needed, but also reduces the amount of type
checking.

>Hmm.  It would be interesting to determine the preferences of
> - people whose native language is SVO, like English
>    Prediction: subject.method(object) preferred.
>
> - people whose native language is VSO
>    Prediction:  method(subject, object) preferred
>
> - people whose native language is SOV (isn't Japanese like that?)
>    Prediction:  somewhere in between the others.

I doubt it.  Programming languages are so different from natural
languages that I don't believe the above predictions.  FWIW, I'm a
counter example (native language is English, but prefer method(args).
I suspect there's more cross-over from grade-school math notations to
programming notations, than from one's native language.

>To some extent this is true, but as someone who uses GNAT every day
>I don't want to see too much of Robert Dewar's time diverted from 
>enhancing an already *wonderful* tool.  And his postings are already
>darned productive (even when he disagrees with me).

I suspect he has two keyboards on his desk, and fixes bugs in GNAT with
his right hand, while simultaneously posting to comp.lang.ada with his
left hand.

- Bob

Re: Two ideas for the next Ada Standard

[Adam Beneschan]

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

 >I suspect he has two keyboards on his desk, and fixes bugs in GNAT with
 >his right hand, while simultaneously posting to comp.lang.ada with his
 >left hand.

Well, Leonardo da Vinci did essentially the same thing, but the notes
he wrote with his left hand were in mirror image.  So shouldn't Robert
Dewar's posts look something like this:

gnitseggus erew (?boB dna) uoy taht dezilaer ton dah I .esnes sekam taht ,KO
si taht eerga I .38 adA ni trap etavirp fo noiton eht gnivomer yletelpmoc

.cte

                                -- Adam

Re: Re:Two ideas for the next Ada Standard

[Dale Stanbrough]

Robert A Duff writes:
"However, I don't think it's a big deal.  You can just use "in" and "in
 out" all the time, and use ".all" at the call site.  Two annoying things
 are: The syntax for ".all" is ugly -- I liked Pascal's "^".  And
 functions can't have "in out" params."

What was the original rationale for implicit dereferencing? I'm just
up to explaining it to our first year students - I find explaining why
ptr.record_field has the same syntax as rec.rec_field.

Dale

Re: Two ideas for the next Ada Standard

[Richard A. O'Keefe]

Dale Stanbrough <dale@goanna.cs.rmit.edu.au> writes:
>What was the original rationale for implicit dereferencing?

Wasn't it in Steelman?

For what it's worth, I note that the draft ANSI "Object Oriented Extensions
to Pascal" insists on the same things for objects.  Objects are "really"
pointers to records, but object.field acts like pointer^.field.

A historical reference:  IMP 77 had pointers, called "names", and did
exactly the same thing.  You had to use special syntax to talk about the
pointer;   Integer Name + 1  dereferenced "Integer Name".

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Two ideas for the next Ada Standard

[Robert Dewar]

Bob Duff said

"One choice is to write a function that takes Longest_Integer, or
whatever, but then you have a bunch of bogus type conversions at all the
call sites.  These type conversions are just extra verbiage in my
opinion.  A type conversion ought to tell the reader "I'm going outside
the type system, doing something questionable, read this carefully."
But if you have a lot of "harmless" type conversions, it weaken the
effect -- it's like crying wolf.
"

Sure there are a *few* examples of such functions, but very few. Even the
one you give is bordering on the bogus to me, since it seems at too low
a level. My opininion is that allowing integer'Class or somesuch would
weaken the typing in practice, and is undesirable. For the record note
that the design team *did* (very much) want to add such a feature, but
WG9 rejected the proposal. There were two arguments against it, one
was that it added confusion and complexity, the other was that it
weakened the typing model. I cannot say which of these two issues was
the more important in the thinking of the various delegations at the
time of the Villars meeting where this decision was made.

Still I find that in the Ada programs I write, there are very few typ3e
conversions around, so i cannot get excited about the problem. Of course
I certainly do NOT go writing junk type declarations all around the place :-)

Re: Two ideas for the next Ada Standard

[Richard A. O'Keefe]

bobduff@world.std.com (Robert A Duff) writes:
>Another example is: You can't write a function that takes a parameter of
>"any integer type".  This is a perfectly reasonable thing to do

Wearing my Lisp hat:  only because Ada doesn't actually support integers,
but a machine-dependent set of machine-dependent small bounded integers.

Wearing another hat:  Haskell type classes are one approach to this.

>One choice is to write a function that takes Longest_Integer, or
>whatever, but then you have a bunch of bogus type conversions

Well, yes, but when I use derived integer types in my Ada code,
it's because I _don't_ want to allow a whole lot of functions.
I _want_ those conversions to be required, because I _don't_ want
other people's functions coming in unless I say so.

>A type conversion ought to tell the reader "I'm going outside
>the type system, doing something questionable, read this carefully."
>But if you have a lot of "harmless" type conversions, it weaken the
>effect -- it's like crying wolf.

The point is, the author of the function cannot tell that it is harmless.
I guarantee you, if I have derived a new integral type, the chances are
pretty good that the *last* thing I want is your function automatically
being applicable.  If I wanted that, I'd use Integer.  In fact, I would
be happier if there were some simple way to switch off a lot of the
built-in Ada stuff.

>Another choice is to use a generic.  This require even *more* excess
>verbiage (all kinds of instantiations).  And it can lead to code bloat
>on most implementations.

Well, you may call it excess verbiage:  I call it not letting you
violate my privacy unless I give you explicit permission.  It may
be "excess", but it's only one or two lines, and I really value having
that explicit indication of what unusual things may be going on.

As for code bloat, we've had that in another thread.

	function Real_Foo(X: Longest_Integer) return Bar is
	... begin ... end;

	generic
	    type Number is range <>;
	function Generic_Foo(X: Number) return Bar;

	function Generic_Foo(X: Number) return Bar is
	    pragma Inline(Foo);
	begin
	    return Real_Foo(Longest_Integer(X));
	end;

Presto chango:  no bloat.  You get the same code you would have got
from writing the explicit conversions.  There is only one copy of
the real procedure.  I appreciate that this is compiler-dependent, but
even *C* compilers are automatically inlining things these days, and
GNAT can do this.

 The instantiation is no more than

	function Foo is new Generic_Foo(Integer);
	function Foo is new Generic_Foo(My_Derived_Integer);

which is not a _lot_ of verbiage to warn human beings that there is
an operation available for a type, an operation they might not otherwise
have been aware or OR WANTED.  If I minded trading a bit of verbosity for
a lot of confidence I wouldn't be using Ada.

This approach offers

 - type safety:  the operation cannot be forced on clients that don't
   authorise it
 - compact calls:  no conversions appear in the calls to Foo
 - no code bloat:  there is only one Real_Foo function

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Two ideas for the next Ada Standard

[Robert A Duff]

In article <50jk0f$krh@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>bobduff@world.std.com (Robert A Duff) writes:
>>Another example is: You can't write a function that takes a parameter of
>>"any integer type".  This is a perfectly reasonable thing to do
>
>Wearing my Lisp hat:  only because Ada doesn't actually support integers,
>but a machine-dependent set of machine-dependent small bounded integers.

That seems like an orthogonal issue.  One could imagine a language like
Ada, where the potential range of integers was essentially infinite, but
the type model would still be the same.

>Wearing another hat:  Haskell type classes are one approach to this.

Yes.

>Well, yes, but when I use derived integer types in my Ada code,
>it's because I _don't_ want to allow a whole lot of functions.
>I _want_ those conversions to be required, because I _don't_ want
>other people's functions coming in unless I say so.

I don't understand this.  When you write "type T is range 1..1000;" in a
package spec, you're allowing all clients to do anything you can do to
integers.  This includes add, multiply, subtract, 'Image, and all the
other built in stuff, plus anything you can build on top of those
things.  For example, a client of this package can write a function to
take the greatest common divisor (gcd) of two things of type T.  If you
think gcd is an evil thing to do on type T, then you should make it
private instead.  Whether gcd is written specifically for type T (by the
client), or as a generic instantiation, or if there's a
gcd-of-any-integer-type (not Ada!) available shouldn't matter -- you
can't *prevent* the client from doing a gcd operation on this type,
because you've exported the fact that it's an integer type.

>Well, you may call it excess verbiage:  I call it not letting you
>violate my privacy unless I give you explicit permission.  It may
>be "excess", but it's only one or two lines, and I really value having
>that explicit indication of what unusual things may be going on.

You're confusing the abstraction and the client of the abstraction.  If
the abstraction exports an integer type, the *client* can instantiate
whatever generics it wants, that take integer types.  The abstraction
gave that permission by saying "is range 0..100".  The only way to
prevent that is to use a private type.

>This approach offers
>
> - type safety:  the operation cannot be forced on clients that don't
>   authorise it

I don't understand what you mean by "forced on".  If I call "gcd(I, J)",
that doesn't mean I'm forced to do so.  And making me write:

    function gcd is new generic_gcd(my_int);
    ...
    gcd(I, J)

doesn't provide any extra type safety, as far as I can see.  It just
requires several times as many tokens for no good reason.  It's the
abstraction that ought to be doing the "authorizing", not the client.

Don't get me wrong -- I'm all for verbosity when it serves a useful
purpose (as it usually does in Ada).

- Bob

Re: Two ideas for the next Ada Standard

[Richard A. O'Keefe]

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

>I don't understand this.  When you write "type T is range 1..1000;" in a
>package spec, you're allowing all clients to do anything you can do to
>integers.

NONONONO.  *You're* writing the package.  You're the one writing
the universal-integer function, remember?  

*I'm* writing the client.  I am defining T for my own use, *not* for
export.  My package is "with"ing yours, and I *don't* want your code
getting its paws on my T.

*IF* I exported a derived integer type, then I agree that it would be
up to the client to decide what to do with it.  That is, if I didn't
say "only use the following operations".

That's one of the things I like about the old Russell type system:
you can derive a new type by weakening.  I can say "T is integer
except that it doesn't have these operations."

>This includes add, multiply, subtract, 'Image, and all the
>other built in stuff,

That is indeed a weakness in Ada.  It should be possible to exclude
such things.  It is presently possible to do that by exporting a
private type and replicating all and only the things I _do_ want to
offer, so I don't call it a defect.

>If you think gcd is an evil thing to do on type T, then you should make it
>private instead.

I do.  I *still* don't want to get some function I've never heard of
and isn't listed in the standard *automatically* being applicable to
an internal type I have no intention of exporting.

>You're confusing the abstraction and the client of the abstraction.  If
>the abstraction exports an integer type, the *client* can instantiate
>whatever generics it wants, that take integer types.  The abstraction
>gave that permission by saying "is range 0..100".  The only way to
>prevent that is to use a private type.

No, I'm not confused.  *You* are making up this stuff about exporting
an integral type, which has no relevance to my point.  *You* are the
one trying to export a function which will grab control over any
integral type in view, and I don't want that happening inside my
package body to stuff I have no intention of exporting, not without
my say-so.

>I don't understand what you mean by "forced on".  If I call "gcd(I, J)",
>that doesn't mean I'm forced to do so.

Think about the possibilities for masking errors.
Think about Beaujolais effects.

>    function gcd is new generic_gcd(my_int);
>    ...
>    gcd(I, J)

>doesn't provide any extra type safety, as far as I can see.  It just
>requires several times as many tokens for no good reason.

Well, _I_ can see the extra type safety.  You were talking about a
function that applies to _any_ integer type.  GCD only really makes
sense when I and J are the same kind of integer.  You would have
this go through if I were Short_Integer and J were Long_Integer;
if I want that kind of sloppiness I know where to find it.

There are other possibilities too.

>It's the
>abstraction that ought to be doing the "authorizing", not the client.

It should be both.  A legal contract, after all, requires *both*
'offer' (the abstraction) and 'acceptance' (the client).

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Two ideas for the next Ada Standard

[Robert Dewar]

Richard said

"That's one of the things I like about the old Russell type system:
you can derive a new type by weakening.  I can say "T is integer
except that it doesn't have these operations."

>This includes add, multiply, subtract, 'Image, and all the
>other built in stuff,

That is indeed a weakness in Ada.  It should be possible to exclude
such things.  It is presently possible to do that by exporting a
private type and replicating all and only the things I _do_ want to
offer, so I don't call it a defect."



Richard, you can't quite do 100% of what you want, since you cannot exclude
attributes like Image, but you are obviously missing an important capability
in Aa 95.

	type x is range 1..10;
        function "+" (a,b : x) return x is abstract;

causes the addition operator to be unavailable for this type.
This is how weakening is done in Ada 95.

In general it is a good idea to turn any statement of the form "You cannot
do xxx in Ada 95" to a question "How do you do xxx in Ada 95?" unless you
are very sure of your facts. That way you avoid stating misconceptions as
facts on the newsgroups.

It's an interesting point that it is a pity that there is no way to suppress
attributes. That's particularly true in the floating-point case, where there
are huge numbers of attributes, or in the enumeration type case, where it
would be nice to suppress Pos, Succ, and Pred.

The other operation that you cannot suppress is the ability to take
subranges, which, particularly in the enumeration type case, can be
unfortunate. The reason is that it allows clients to depend on the
order of items in the enumeration definition, which is really the
business of the defining package. You can supppress the comparison
operations, but not the IN and NOT IN operations on user defined
subtypes, which are essentially semanticaly equivalent to the
comparison operations.

Re: Two ideas for the next Ada Standard

[Richard A. O'Keefe]

dewar@cs.nyu.edu (Robert Dewar) writes:

>Richard, you can't quite do 100% of what you want, since you cannot exclude
>attributes like Image, but you are obviously missing an important capability
>in Aa 95.

>	type x is range 1..10;
>        function "+" (a,b : x) return x is abstract;

>causes the addition operator to be unavailable for this type.
>This is how weakening is done in Ada 95.

I had actually seen this in a thread earlier this year.  (comp.lang.ada
_is_ such good value.)  However, 'Image is one of the things that would
merit suppression:  it would be nice to export an enumeration type _as_
an enumeration type without having to provide all the names as strings.

So far the only way I've been able to figure out of exporting some
of the enumeration literals of an enumeration type is

	package foo is
	    type T is private;
	    function X return T;
	    function Z return T;
	private
	    type T is (X, Y, Z, W);
	end foo;

At least, I _thought_ it should work.  Enumeration literals are
parameterless functions returning values of the type, not so?
But gnat says that the declarations of X and Z in the private
part _conflict_ with the earlier declarations (instead of, as I
thought, matching them), and who am I to argue?

My reaction to this was not to look through the standard for the fine
print explaining why I can't do it this way, but to stop trying.
Exporting half an enumeration type is probably too silly.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Two ideas for the next Ada Standard

[Robert Dewar]

Richard said

"I had actually seen this in a thread earlier this year.  (comp.lang.ada
_is_ such good value.)  However, 'Image is one of the things that would
merit suppression:  it would be nice to export an enumeration type _as_
an enumeration type without having to provide all the names as strings.
"

Well pragma Discard_Names comes close to doing what you want. If there
is a Discard_Names pragma, then no strings need to be exported.

Re: Two ideas for the next Ada Standard

[Mark A Biggar]

In article <5137hi$9oq@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
>dewar@cs.nyu.edu (Robert Dewar) writes:
>>Richard, you can't quite do 100% of what you want, since you cannot exclude
>>attributes like Image, but you are obviously missing an important capability
>>in Aa 95.
>>	type x is range 1..10;
>>        function "+" (a,b : x) return x is abstract;
>>causes the addition operator to be unavailable for this type.
>>This is how weakening is done in Ada 95.
>I had actually seen this in a thread earlier this year.  (comp.lang.ada
>_is_ such good value.)  However, 'Image is one of the things that would
>merit suppression:  it would be nice to export an enumeration type _as_
>an enumeration type without having to provide all the names as strings.

Try: pragma Discard_Names(Enum_Type);  -- Ada95 only


--
Mark Biggar
mab@wdl.lmco.com

Re: Two ideas for the next Ada Standard

[Robert A Duff]

In article <50opma$kos@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>That's one of the things I like about the old Russell type system:
>you can derive a new type by weakening.  I can say "T is integer
>except that it doesn't have these operations."

Yes, or perhaps, "T is Integer with only these operations".
I agree that would be nice.  But it would add a fair amount
of complexity to the language (e.g. matching rules for generic
formal types).

Robert Dewar pointed out the "abstract" trick in another post.
It works, but it involves a fair amount of extra mumbo-jumbo.
If you want just "+" and "-" it's probably better to use
a private type, in most cases.  And as Robert pointed out,
it only works for operators -- not other notations like literals,
array indexing, membership tests, etc.

>No, I'm not confused.  *You* are making up this stuff about exporting
>an integral type, which has no relevance to my point.

OK, ok, I misunderstood you.  But...

>...  *You* are the
>one trying to export a function which will grab control over any
>integral type in view, and I don't want that happening inside my
>package body to stuff I have no intention of exporting, not without
>my say-so.

I still fail to see how a function lying around in the program library
can "grab control".  Functions don't normally cause calls to themselves
to be inserted at other points in the code!  To me, it's just like
having a generic lying around -- if you don't want to use it, don't
instantiate it.  (Don't even "with" it, if you don't like it.)  The
generic is not some evil beast lying in wait, which will 'with' itself
and instantiate itself upon you at inopportune times.  Likewise, a
function cannot cause you to call it.

>Think about Beaujolais effects.

I'm pretty confident that Ada 95 has no Baujolais effects.  (Even though
I'm not confident that I can spell "Beaujolais".)  I'm not sure with
absolute certainty, but I'm pretty sure.  I think I understand the sort
of preference rules that cause the problem, and I think we eliminated
them.  Also, the Language Precision Team did a formal proof.  Any of
this could be mistaken, but I don't think it is.

Furthermore, I think I would be capable of introducing untagged
class-wide types without introducing Beaujolais effects.

- Bob

Re: Two ideas for the next Ada Standard

[Robert Dewar]

Richard said

"Wearing my Lisp hat:  only because Ada doesn't actually support integers,
but a machine-dependent set of machine-dependent small bounded integers."

Actually that's not quite true, whether Ada supports arbitrary precision
integers is an implemention dependent issue.

Something that people don't know very well in Ada 95 is that there is a big
difference between integer'base and integer, which are quite different types.
The type integer'base has no constraints. An implementation is allowed, but
definitely NOT required to impose limits on the range of integers that
can be represented using this type.

Re: Two ideas for the next Ada Standard

[Richard A. O'Keefe]

dewar@cs.nyu.edu (Robert Dewar) writes:

>Richard said

>"Wearing my Lisp hat:  only because Ada doesn't actually support integers,
>but a machine-dependent set of machine-dependent small bounded integers."

>Actually that's not quite true, whether Ada supports arbitrary precision
>integers is an implemention dependent issue.

Thank you for the explanation.  I expect to be learning Ada 95 for a long
time.  However, Ada (the _standard_ language) can hardly be said to
"support" a feature that it allows but does not _require_ an implementation
to provide.  One of the few things I dislike about Scheme is that it has
this nice well-thought-out "numeric tower", but implementations aren't
required to provide all of it, so Scheme code _written to the standard_
that crunches complex numbers doesn't port.

I even feel as though I'm on thin ice when I use Long_Float.
The standard says "IF Long_Float is predefined ..."

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Two ideas for the next Ada Standard

[Jonas Nygren]

Richard A. O'Keefe wrote:
> 
> Jonas Nygren <jonas@joy.ericsson.se> writes:
> >Coming from a C/C++ background I have had a hard time to adjust to
> >many of the Ada features (geez, I have never casted so much before in
> >my programming life).
> 
> This puzzles me greatly.  I've been hacking Ada for about two years now,
> and *except when trying to interface to C code* find that I have very
> few conversions.  

I just state a fact of my own Ada code, it could be that I have 
not yet learnt how to write good Ada code. In Ada, pointers are 
distinct types which differs from C/C++,  eg:

type X1A is access X;
type X2A is access X;
X1P : X1A;
X2P : X2A;

To use X1P and X2P together often requires conversions.

X *x1p, *x2p;

In C/C++ there is only one pointer type for each object type. 
(if we disregard const, typedefs are just syntactical sugar). 

So in C/C++ you need not 'carry around' the pointer type for an
object - the one and only pointer type for that object is directly
available from the object type.

In Ada you have to carry around both object and pointer type
everywhere you might want to use it - if you don't you will
often need to do some conversion.

> 
> >Still, there are some things I have a problem to adjust to. One is
> >P(X) instead of the popular X.P notation.
> 
> The Pop family of languages has always identified F(X) and X.F.
> Are you are happy to see x.sqrt.print instead of print(sqrt(x))?
> If not, _why_ not?  In Smalltalk, after all, sqrt _is_ a method in
> the floating point class...
> 
> Algol 68 and COBOL use "field OF record" instead of "record.field".
> Is that _really_ such a big deal?
> 
> Hmm.  It would be interesting to determine the preferences of
>  - people whose native language is SVO, like English
>     Prediction: subject.method(object) preferred.
> 
>  - people whose native language is VSO
>     Prediction:  method(subject, object) preferred
> 
>  - people whose native language is SOV (isn't Japanese like that?)
>     Prediction:  somewhere in between the others.
> 
> I suppose it won't do any good to point out that the Ada approach
> generalises nicely to overloaded operators, while the C++ approach
> requires some ad hack kluging?

And dispatching on return values from functions. But I still like
X.P better than P(X) because I immediately can see what object I am
operating on. With P(X,Y) one would have to go back to the definition
of P to know if it dispatches on X or Y. But this is something one
have to adopt to - Ada will never change to X.P notation.
 
> 
> >E.g. I can not understand why one cannot have an anonymous access
> >argument which refers to a constant, e.g P(X : access CONSTANT XT).
> >Why not? What ever could have been said against this? Premature?
> 
> What exactly does this buy you that an "in" argument doesn't buy you?
> It looks _awfully_ like a demand that Ada look like C++ (const ref).

If you write code using tagged types you often want to use dynamically
allocated objects and hence use access values in function/procedure
calls. When one pass 'the object' as an access argument the 'object'
will always have mode 'in out', it is not possible to pass the
object with only 'in' mode. So if you want to provide functions
or procedures which restricts the update of 'the object' then
you have to provide an interface with a mix of 'access' and
'in' modes with the following confusion for the user of the interaface
who will need to use a mix of P1(XA) and P2(XA.all). It is very ugly
and confusing to use such interfaces.

(one could ask why one ever would use 'access constant' and I
would reply: for the very same reasons as we have for the 'in' mode)

I want the 'access constant' feature for practical reasons, not out of
C++ notsalgia.

> Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

/jonas

Re: Two ideas for the next Ada Standard

[Robert A Duff]

In article <322C40B1.534A@ehs.ericsson.se>,
Jonas Nygren  <ehsjony@ehs.ericsson.se> wrote:
>type X1A is access X;
>type X2A is access X;
>X1P : X1A;
>X2P : X2A;
>
>To use X1P and X2P together often requires conversions.

So don't do that.  ;-)  Just define one access type after each type, and
use a naming convention, and always use that particular type.

You *do* get "extra" type conversions, though, when using class-wide
types -- if T2 is derived from T1, then T1'Class covers T2'Class, but
the corresponding thing doesn't work for access-to-those-classwide-types.

>If you write code using tagged types you often want to use dynamically
>allocated objects and hence use access values in function/procedure
>calls. When one pass 'the object' as an access argument the 'object'
>will always have mode 'in out', it is not possible to pass the
>object with only 'in' mode. So if you want to provide functions
>or procedures which restricts the update of 'the object' then
>you have to provide an interface with a mix of 'access' and
>'in' modes with the following confusion for the user of the interaface
>who will need to use a mix of P1(XA) and P2(XA.all). It is very ugly
>and confusing to use such interfaces.

I suppose that's a valid criticism.  The reason there are no "access
constant" parameters is that we didn't think it was needed, which is not
usually a good language design principle -- the language should forbid
harmful things, but shouldn't forbid percieved-useless things,
especially since it's not always clear what will be useful to somebody.
I guess it depends on whether you think "access constant" params is an
additional feature, versus the lack of "access constant" params being an
additional restriction.

However, I don't think it's a big deal.  You can just use "in" and "in
out" all the time, and use ".all" at the call site.  Two annoying things
are: The syntax for ".all" is ugly -- I liked Pascal's "^".  And
functions can't have "in out" params.

You only need access parameters when the dispatching function wants to
store a pointer to the thing in some global data structure, which I
think is no common.  And when you have a function with side-effects,
which is also rare.  (Note that parameters of a tagged type are always
aliased, so you can do 'Access or 'Unchecked_Access, but the
accessibility rules make access parameters more friendly.)

And in any case, missing or extra ".all"'s and 'Accesses are caught at
compile time.

- Bob

Re: Two ideas for the next Ada Standard

[Richard A. O'Keefe]

Jonas Nygren <ehsjony@ehs.ericsson.se> writes:
>I just state a fact of my own Ada code, it could be that I have 
>not yet learnt how to write good Ada code. In Ada, pointers are 
>distinct types which differs from C/C++,  eg:

>type X1A is access X;
>type X2A is access X;
>X1P : X1A;
>X2P : X2A;

>To use X1P and X2P together often requires conversions.

But this is entirely a problem of your own creation.
If you *want* X1P and X2P to be compatible, use the same type for them.

>X *x1p, *x2p;

You can accomplish this by doing
    type X_Ptr is access X;
    X1P, X2P: X_Ptr;

>In C/C++ there is only one pointer type for each object type. 
>(if we disregard const, typedefs are just syntactical sugar). 

Well, there are actually 'const' and 'volatile' (which _does_
change the semantics) and it looks as though 'restrict' will
make it into the next revision (C9X); the SPARCompiler C 4.0
compiler already supports it.

So C89 has 4 incompatible flavours of pointer-to-X
and C9X will probably have 8 of them.

>In Ada you have to carry around both object and pointer type
>everywhere you might want to use it - if you don't you will
>often need to do some conversion.

Bear with me.  I am having real trouble understanding the problem.
Somewhere there is a package:

	package X is
	    type T is something or other;
	    type Ptr is access T;
	    ...
	end X;

So I don't "carry around" _either_ an object or a pointer type.
Whenever I want either type, I ask the package.

	Object: X.T;
	Pointer: X.Ptr;

The issue here is that if it makes _sense_ for the rest of the program
to manipulate both objects and pointers, then the package that exports
the object type should export both types.

>And dispatching on return values from functions. But I still like
>X.P better than P(X) because I immediately can see what object I am
>operating on. With P(X,Y) one would have to go back to the definition
>of P to know if it dispatches on X or Y. But this is something one
>have to adopt to - Ada will never change to X.P notation.

Um, in C++ you _don't_ know which argument the operation is really
dispatching on.  If you write 
	X.P(Y)
X.P can often be resolved at compile time (so no dispatch takes place)
while calls _inside_ P may dispatch on Y, and this may be important.

Consider for example

	Stream << Thing;

in C++.  What does _that_ dispatch on?  There is a combination of
overloading and dispatching going on, which are similar.  In fact
there can be both overloading and dispatching in any C++ method call,
so it really isn't as obvious as it looks.

In your own code, there is nothing to stop you adopting a convention
that you will only dispatch on the first argument.

Me, I _like_ being able to write both
	Add_Element(Set, Element)
	Is_Member(Element, Set)

>> >E.g. I can not understand why one cannot have an anonymous access
>> >argument which refers to a constant, e.g P(X : access CONSTANT XT).
>> >Why not? What ever could have been said against this? Premature?
>> 
>> What exactly does this buy you that an "in" argument doesn't buy you?
>> It looks _awfully_ like a demand that Ada look like C++ (const ref).

>If you write code using tagged types you often want to use dynamically
>allocated objects and hence use access values in function/procedure calls.

Ah *hah*!  Now I understand.

Simple answer:  you *really* don't want to do that.  If Stroustrup has
his way, C++ will become like Ada already is:  garbage collection is
allowed, but not required.  The only way you can be *sure* that storage
for a dynamically allocated object will be released is to do something
to that access value.  So what's happening here is that Ada is preventing
you adopting a coding style that guarantees massive storage leaks.
I can't regret that!

Either that or I have misunderstood again.

What stops you writing

	package X is
	    type T is
	    type Ptr is access T;
	    type Const_Ptr is access constant T;

	    function P(X: Const_Ptr, ...


>who will need to use a mix of P1(XA) and P2(XA.all). It is very ugly
>and confusing to use such interfaces.

Yes, but it is very ugly and confusing to use interfaces which
require the client to deal with both objects and pointers _anyway_.

Q: What do Simula 67, Smalltalk, Common Lisp Object System, YASOS,
   Java, NewtonScript, Self, Cecil, all have in common?

A: Clients always deal with *pointers* to objects, never with "bare"
   objects.

I note, for example, that the draft ANSI document "Object Oriented
Extensions to Pascal" (that's extensions to _modern_ Pascal, which
already has modules and type schemes) envisages a model in which
programs *cannot* access objects directly; so ANSI Object Pascal
(when it comes out) will join the list of OOP languages above.


It might be interesting to see a larger example.  I expect that I would
learn a lot from it.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Two ideas for the next Ada Standard

[Robert Dewar]

Jonas says

"I just state a fact of my own Ada code, it could be that I have
not yet learnt how to write good Ada code. In Ada, pointers are
distinct types which differs from C/C++,  eg:

type X1A is access X;
type X2A is access X;
X1P : X1A;
X2P : X2A;

To use X1P and X2P together often requires conversions."

OK, now we begin to see why you are using so many unnecessary conversions.
Why are X1A and X2A here separate types. They should only be separate types
if they are conceptually different types. If you have to convert from one
to the other at all frequently, this shows that they are NOT conceptually
different types, and you should either use a single type, or use subtypes.

Did you have a reason for making separate types? Or is it just that you
don
't know how subtypes work, or somehow feel that separate types for
everything is the Ada way? [it is not!]

If you want the effect of only a single access type for a given type, then
make a package that declares this type, and with it from everywhere that
needs to use this type. Often you can package up a bunch of related
types into a single package when following this approach.

It definitely sounds like the conversions around your program are
your own doing and not something that Ada is forcing on you!

Re: Two ideas for the next Ada Standard

[Robert I. Eachus]

In article <513vo7$g9b@watnews1.watson.ibm.com> ncohen@watson.ibm.com (Norman H. Cohen) writes:

  > However, a subprogram renaming declaration is allowed to serve as the
  > completion of a declaration, and can rename an enumeration literal, so
  > you can do the following: 

  >    package Foo is
  >	  type T is private;
  >	  function X return T;
  >	  function Z return T;
  >   private
  >	  type T is (X_Value, Y_Value, Z_Value, W_Value);
  >	  function X return T renames X_Value;
  >	  function Z return T renames Z_Value;
  >    end Foo;

  > (I gave the literals different names from the functions so that both
  > could be declared in the same package specification.)

  Why not:

      package Foo is
          type T is private;
  	  function X return T;
  	  function Z return T;
      private
          package Bar is
	    type Hidden is (X, Y, Z, W);
          end Bar;

          type T is new Bar.Hidden;
  	  function X return T is begin return T(Bar.X); end X;
  	  function Z return T is begin return T(Bar.Z); end Z;
          pragma Inline(X,Z);
      end Foo;

      Yes, I know that what he really wants is Discard_Names...

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Two ideas for the next Ada Standard

[Robert Dewar]

By the way, I have no objection to people discussing languge features in
free ranging form, and as you notice, I am happy to participate in such
discussions. My point was simply that suggestions of trying to formalize
such discussions into a project for the next standard are (a) premature
and (b) not appropriate anyway, since language design needs to be done
in a more studied and formal way thanb is possible on an unmoderated
newsgroup.

Incidentally, anyone is free to follow the more formal discussions of
the current standard in the appropriate forum, and to submit formal
comments (see RM for correct email address for formal comments).

Re: Two ideas for the next Ada Standard

[Robert Dewar]

Jonas said:

Coming from a C/C++ background

  It's always tricky to adjust to a second language. That's one of the
  reasons that programmers should know many languages well, so that they
  have a perspective on possible ways of doing things. People who speak
  English only have a hard time with German (for example) at first, but
  once you speak many natural languages, learning more becomes easier.

I have had a hard time to adjust to
many of the Ada features (geez, I have never casted so much before in
my programming life).

  If you are writing a lot of type conversions (I guess that is what you
  mean by using the Algol-68 term cast), then probably you are making
  a common beginner's mistake of using derived types *too* heavily.
  Yes, it is a strong point of Ada that you can use derived types
  to separate different kinds of types, but is a weak point of many
  Ada programs that they overuse this feature and use derived types
  where subtypes would be more appropriate.

  If you are talking about other kinds of conversions, let's see some
  examples.

I still prefer the X.P notation and believe it could have been
integrated into Ada95 in a reasonably clean manner - oh yes, I have
read the Rationale on this and it sounds hollow and thin to me.

  OK, probably you still have not fully understood the point here. This
  point has been *extensively* debated on comp.lang.ada (there is plenty
  of BS'ing of the kind you want to see more of here). I suggest you
  consult an archive of CLA and read this discussion. You may still
  disagree, but if you think the argument on the other side is hollow,
  you don't fully understand it.

PS Perhaps Robert's postings would be more productive if
they actually told us how DS

  Hmmm! I am completely unable to interprete this mysterious suggestion :-)

Re: Two ideas for the next Ada Standard

[Jon S Anthony]

In article <322B5BB0.422E@joy.ericsson.se> Jonas Nygren <jonas@joy.ericsson.se> writes:

> Coming from a C/C++ background I have had a hard time to adjust to
> many of the Ada features (geez, I have never casted so much before in
> my programming life). All in all I have gone native. Ada is my sole

By "casting" I presume you really mean conversion.  If you find that
you are doing this much at all, you are going about things the wrong
way.  In general, you should have little to no such "casting" going on
in Ada.


> Still, there are some things I have a problem to adjust to. One is 
> P(X) instead of the popular X.P notation. I do understand that in 

Yes, this is something that some people just don't get.  I find it
much nicer in general than the X.P notation.  The latter is
inflexible, sometimes clumsy, and gives the mis-impression that X is
an active agent (being commanded to do P).


> But it is not a question of only these big and 'religious' questions.
> E.g. I can not understand why one cannot have an anonymous access
> argument which refers to a constant, e.g P(X : access CONSTANT XT).
> Why not? What ever could have been said against this? Premature?

Maybe because you can?  It's trivial?  Readily done?  First, you are
showing your C++ coding mind set here and it is just inappropriate.
Typically the correct way of achieving the so called "const"
paramenter passing of C++ is to simply use an _in_ mode parameter:

procedure P ( X : Xt );

or if you want to be explicit:

procedure P ( X : in Xt );

This is basically the correct equivalent to C++

void p (const xt& x)

Don't worry about low level fiddling about concerning pass by
reference or value.  Rest assured that large _in_ mode things will be
passed by reference so you don't have to try to hack this as you need
to in C++.


If for some reason you really do want to have an access to constant,
then just write it:

    type Xt_Const_Ref is access constant Xt;

procedure P ( X : Xt_Const_Ref );


I think the problem here is that instead of learning and understanding
the Ada model, you are simply trying to write C++ in Ada.  A recipe
for frustration and annoyance and error if there ever was one.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Two ideas for the next Ada Standard

[Joel VanLaven]

Jon S Anthony (jsa@alexandria) wrote:
: procedure P ( X : Xt );

: or if you want to be explicit:

: procedure P ( X : in Xt );

: This is basically the correct equivalent to C++

: void p (const xt& x)

  While this is a minor point, it happens to be one that I am currently
involved with and so couldn't resist mentioning :)
  If Xt is a tagged type (ie. the c++ "type" is a class)

void p (const xt& x)

actually seems to be modeled more accurately by

procedure P ( X : in Xt'class );

  If xt is not a class then the simpler translation is correct, after all
if xt is not a class then

void p (const xt& x)

is the same as

void p (xt x)

except for possibly effieciency.  In the Ada world our compilers are
smart enough to decide on the most efficient way to do this sort of
parameter passing without our error-prone help :)
-- 
-- Joel VanLaven

Re: Two ideas for the next Ada Standard

[David Weller]

In article <JSA.96Sep3152930@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
>I think the problem here is that instead of learning and understanding
>the Ada model, you are simply trying to write C++ in Ada.  A recipe
>for frustration and annoyance and error if there ever was one.
>

True, but that's how many of us learn to migrate.  Right or Wrong,
it's important to understand
	1) A general syntactic mapping of what we want to do
	_then_
	2) The correct semantics/idiom for what were were once used
	to.

I think the time spent on 1, however, should be significantly short.
No more than 10 seconds with the correct motivation :-)

-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

Re: Two ideas for the next Ada Standard

[Jon S Anthony]

In article <322C40B1.534A@ehs.ericsson.se> Jonas Nygren <ehsjony@ehs.ericsson.se> writes:

> I just state a fact of my own Ada code, it could be that I have 
> not yet learnt how to write good Ada code.

I think that is getting at it.

> In Ada, pointers are 
> distinct types which differs from C/C++,  eg:
> 
> type X1A is access X;
> type X2A is access X;
> X1P : X1A;
> X2P : X2A;
> To use X1P and X2P together often requires conversions.
> 
> X *x1p, *x2p;

Well, why would you declare TWO access types to the same designated
type, unless you really DID want tow DIFFERENT types that were in fact
distinct????  If you just want to rename for some reason then use
the renaming for types - subtype:

subtype X2A is X1A;

X1P : X1A := ...
X2P : X2A := X1P; -- No problem or conversion...
 
> In C/C++ there is only one pointer type for each object type. 
> (if we disregard const, typedefs are just syntactical sugar).

Well, if this is what you want - just do it.  Nothing prevents you
from either A) only declaring the ONE access type or B) using subtype
renamings.  The C/C++ case is just a simple subset of what you can do.


> In Ada you have to carry around both object and pointer type
> everywhere you might want to use it - if you don't you will
> often need to do some conversion.

Not if you just do what you really seem to want.


> If you write code using tagged types you often want to use dynamically
> allocated objects and hence use access values in function/procedure
> calls. When one pass 'the object' as an access argument the 'object'
> will always have mode 'in out' , it is not possible to pass the
> object with only 'in' mode.

If you are really this concerned about this why not just make the type
limited private?  Clients can't access the state (except through the
interface) and they can't assign the things.  For _clients_, it is
strictly _in_ mode.

In the body of the primitive operations defined in the interface, you
can update the individual fields (if they are not limited) of the
object designated by the parameter, but you can't assign it.  This is
rather more secure than the analog C++ where you get a small piece of
this with const T* arguments.


> So if you want to provide functions or procedures which restricts
> the update of 'the object' then you have to provide an interface
> with a mix of 'access' and 'in' modes with the following confusion
> for the user of the interaface who will need to use a mix of P1(XA)
> and P2(XA.all). It is very ugly and confusing to use such
> interfaces.

I don't understand this at all.  You're correct - it is very
confusing...


> (one could ask why one ever would use 'access constant' and I
> would reply: for the very same reasons as we have for the 'in' mode)
>
> I want the 'access constant' feature for practical reasons, not out of
> C++ notsalgia.

That sounds correct as you never had what you really seem to want in
in C++ either.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Two ideas for the next Ada Standard

[Robert A Duff]

In article <JSA.96Sep3211341@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
>In article <322C40B1.534A@ehs.ericsson.se> Jonas Nygren <ehsjony@ehs.ericsson.se> writes:
>> type X1A is access X;
>> type X2A is access X;
>> X1P : X1A;
>> X2P : X2A;
>> To use X1P and X2P together often requires conversions.

Actually, unless you say "access all", the conversions aren't even
allowed.

>If you are really this concerned about this why not just make the type
>limited private?  Clients can't access the state (except through the
>interface) and they can't assign the things.  For _clients_, it is
>strictly _in_ mode.

But limited is not the same thing as constant.  An 'in' parameter is
constant -- it cannot be modified.  An 'in out' parameter of a limited
type is NOT constant -- it can be changed.  Saying clients can't change
it (except blah blah blah) isn't much help -- the fact is it *can* be
changed, and it's easy for the client to change it -- just call
something in the package that owns the type.

Also, what about the primitive operations of the type?  The whole point
of parameter modes is so that you can tell by looking at the spec,
whether or not a given parameter can be changed.

So, I don't buy the advice "use limited instead of access constant".

- Bob

Re: Two ideas for the next Ada Standard

[Jonas Nygren]

Jon S Anthony wrote:
> 
> In article <322C40B1.534A@ehs.ericsson.se> Jonas Nygren <ehsjony@ehs.ericsson.se> writes:
> 
> > I just state a fact of my own Ada code, it could be that I have
> > not yet learnt how to write good Ada code.
> 
> I think that is getting at it.
> 
> > In Ada, pointers are
> > distinct types which differs from C/C++,  eg:
> >
> > type X1A is access X;
> > type X2A is access X;
> > X1P : X1A;
> > X2P : X2A;
> > To use X1P and X2P together often requires conversions.
> >
> > X *x1p, *x2p;
> 
> Well, why would you declare TWO access types to the same designated
> type, unless you really DID want tow DIFFERENT types that were in fact
> distinct????  If you just want to rename for some reason then use
> the renaming for types - subtype:
> 
> subtype X2A is X1A;
> 
> X1P : X1A := ...
> X2P : X2A := X1P; -- No problem or conversion...
> 
> > In C/C++ there is only one pointer type for each object type.
> > (if we disregard const, typedefs are just syntactical sugar).
> 
> Well, if this is what you want - just do it.  Nothing prevents you
> from either A) only declaring the ONE access type or B) using subtype
> renamings.  The C/C++ case is just a simple subset of what you can do.
> 
> > In Ada you have to carry around both object and pointer type
> > everywhere you might want to use it - if you don't you will
> > often need to do some conversion.
> 
> Not if you just do what you really seem to want.

the following type of code is often found in Ada:

generic
   type T is private;
   type TA is access all T;   -- this is what I mean with carrying
package P is....              -- with you
                              
Suppose that we after the instantiation of this package
need to do some conversion to the access type passed to P,
when e g extending an existing application, using:

(2)
       generic
           type Object(<>) is limited private;
       package System.Address_To_Access_Conversions is
          pragma Preelaborate(Address_To_Access_Conversions);
(3)
          type Object_Pointer is access all Object;
          function To_Pointer(Value : Address) return Object_Pointer;
          function To_Address(Value : Object_Pointer) return Address;
(4)
          pragma Convention(Intrinsic, To_Pointer);
          pragma Convention(Intrinsic, To_Address);
       end System.Address_To_Access_Conversions;

How do we use Object_Pointer together with our existing access type
without conversion. Of course we could reorganise all our code
so that we instantiated the conversion package first. This is perhaps
not acceptable if we already have proven and tested code.

Further how do one end up with one and only one access type
if one have to instantiate multiple packages that declare their
own access types.

And no, renaming via subtypes don't help you.
> 
> > If you write code using tagged types you often want to use dynamically
> > allocated objects and hence use access values in function/procedure
> > calls. When one pass 'the object' as an access argument the 'object'
> > will always have mode 'in out' , it is not possible to pass the
> > object with only 'in' mode.
> 
> If you are really this concerned about this why not just make the type
> limited private?  Clients can't access the state (except through the
> interface) and they can't assign the things.  For _clients_, it is
> strictly _in_ mode.

This is too crude, an either-or approach. I want to be able to control 
the accessability for each call. 

> 
> In the body of the primitive operations defined in the interface, you
> can update the individual fields (if they are not limited) of the
> object designated by the parameter, but you can't assign it.  This is
> rather more secure than the analog C++ where you get a small piece of
> this with const T* arguments.

Well, I suppose you have missed the 'const T* const'. 

What I want is similar to C++'s:

struct T {
	void p1() const; // the object cannot be modified inside P1
	void p2();       // the object can be modified inside P2
...
};

calling: obj.p1(), obj.p2()
> 
> > So if you want to provide functions or procedures which restricts
> > the update of 'the object' then you have to provide an interface
> > with a mix of 'access' and 'in' modes with the following confusion
> > for the user of the interaface who will need to use a mix of P1(XA)
> > and P2(XA.all). It is very ugly and confusing to use such
> > interfaces.
> 
> I don't understand this at all.  You're correct - it is very
> confusing...

Yes, I guess so. The C++ example above but in Ada with access types:

type T is tagged....

procedure P1 (Obj : in T);     -- Obj cannot be modified inside P1
procedure P2 (Obj : access T); -- Obj can be modified inside P2

calling:  P1(Obj.all);
          P2(Obj);

Perhaps not a big deal, but the asymmetry of the solution is
very ugly in my eyes. 

If we could have written:

procedure P1 (Obj : access constant T);

We could then call P1(Obj). Everything would then have been
symmetrical and beautiful (again in my eyes).

And I can't see that it would have been too difficult to implement
in a compiler.

> 
> > (one could ask why one ever would use 'access constant' and I
> > would reply: for the very same reasons as we have for the 'in' mode)
> >
> > I want the 'access constant' feature for practical reasons, not out of
> > C++ notsalgia.
> 
> That sounds correct as you never had what you really seem to want in
> in C++ either.

In this case C++ have what I want. There are many other aspects 
of C++ which I do not like and when I add up pros and cons for Ada 
and C++ then Ada wins (again this is as seen with my eyes). That's
why I bother about Ada at all - I want Ada to become 'better'.

A side note: perhaps all these years in the shadow of C and C++
have resulted in that Ada proponents automatically takes a
defensive stand as soon as Ada and C/C++ are mentioned in the
same context. I don't believe Ada need to be defended - it can hold
its own ground. But no language is perfect - I don't believe anybody
would claim that Ada is the final and ultimate programming language.
I believe for e.g. that Ada would benefit by the 'access const'
construct. Perhaps Gnat could serve as a test environment for new
language concepts much as gcc does for C.

> 
> /Jon
> --
> Jon Anthony
> Organon Motives, Inc.
> 1 Williston Road, Suite 4
> Belmont, MA 02178
> 
> 617.484.3383
> jsa@organon.com

Re: Two ideas for the next Ada Standard

[Tucker Taft]

Jonas Nygren (ehsjony@ehs.ericsson.se) wrote:
: ...
: If we could have written:

: procedure P1 (Obj : access constant T);

: We could then call P1(Obj). Everything would then have been
: symmetrical and beautiful (again in my eyes).

: And I can't see that it would have been too difficult to implement
: in a compiler.

: ... I believe for e.g. that Ada would benefit by the 'access const'
: construct. ...

So do I.  This was just a boo-boo.  There were some subtle reasons
why we left this out, but in retrospect, they seem far too subtle
to have won the day.  There was enormous pressure to leave out
"marginal" changes, and sometimes, this pressure created some
strange incentives.  I think many people today would agree that
allowing "access constant" in a parameter would be a simplification
rather than an added complication in the language.

Luckily (and in my biased opinion), this is one of the few cases
where we really goofed.  I would agree that "access constant" parameters
should be one of the first minor updates to be considered.  

For what it is worth, my very first "minor update"
would still be some solution to the circular dependency problem.  
My current favorite solution, at least for experimentation purposes,
is to interpret a pragma Import on an incomplete type, or on an access type,
in a special way.  For example:

     package P is
         type QT;
         type QT_Ptr is access QT;
         pragma Import(Ada, QT, "Q.T");
         pragma Import(Ada, QT_Ptr, "Q.T_Ptr");

         type T is ...
         type T_Ptr is access T;

         procedure Use_Both1(X : QT_Ptr; Y : T_Ptr);
        ...
         
     end P;

     package Q is
         type PT;
         type PT_Ptr is access PT;
         pragma Import(Ada, PT, "P.T");
         pragma Import(Ada, PT_Ptr, "P.T_Ptr");

         type T is ...
         type T_Ptr is access T;

         procedure Use_Both2(X : T_Ptr; Y : PT_Ptr);
        ...
         
     end Q;

The semantics would be that the pragma Import effectively changes
the type declaration into a subtype declaration, using the
External_Name argument to the pragma to specify the subtype's
"true" name.  In both "Use_Both1" and "Use_Both2" one could
pass params of types (Q.T_Ptr, P.T_Ptr).  It's pretty bogus, but it 
could be used to experiment with what semantics works best when translating
into Ada, existing interfaces that have circular dependencies.

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Two ideas for the next Ada Standard

[Jon S Anthony]

In article <DxBMIy.EG.0.-s@inmet.camb.inmet.com> stt@henning.camb.inmet.com (Tucker Taft) writes:

> For what it is worth, my very first "minor update"
> would still be some solution to the circular dependency problem.  

I don't think I could over emphasize my strong agreement with this!
What is the story on actually getting this adopted?


> My current favorite solution, at least for experimentation purposes,
> is to interpret a pragma Import on an incomplete type, or on an access type,
> in a special way.  For example:

Hmmmm, while I see you say "experimentation purposes" here (in leu of the
original "with type ..." change) I suppose the pragma approach is easy to
get into standard conforming compilers...


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Two ideas for the next Ada Standard

[Robert Dewar]

iJon Anthony asks

"I don't think I could over emphasize my strong agreement with this!
What is the story on actually getting this adopted?
"

(talking about a solution to the circularity problem)

I don't see any chance of officially (i.e. at the ISO level) adopting a
modification to the  ISO standard any time soon (say any time in the next
few years).

So what we are looking at here is more like an informal agreement to 
provide a non-standard extension. This can be done either completely
informally, or perhaps the ACE can be stretched a little to encompass
the idea of semi-recognized non-standard extensions.

But first, we need to agre on a technical approach (I note that Tuck
has changed his mind on this since we last discussed it). Actually
I prefer Tuck's previous suggestion of "with type", because it makes
it more honestly clear that this is indeed an extension, than
trying to somehow fit it into the pragma semantics, but I think
we need to discuss that. Perhaps the next ARG meeting can find a little
time to discuss it.

Re: Two ideas for the next Ada Standard

[John G. Volan]

Robert Dewar wrote:
> 
> iJon Anthony asks
> 
> "I don't think I could over emphasize my strong agreement with this!
> What is the story on actually getting this adopted?
> "
> 
> (talking about a solution to the circularity problem)
> 
> I don't see any chance of officially (i.e. at the ISO level) adopting a
> modification to the  ISO standard any time soon (say any time in the next
> few years).
> 
> So what we are looking at here is more like an informal agreement to
> provide a non-standard extension. This can be done either completely
> informally, or perhaps the ACE can be stretched a little to encompass
> the idea of semi-recognized non-standard extensions.

Funny, I was just about to ask whatever became of the
circular-dependency issue. I'm glad to see that some of the bigwigs in
the Ada world are at least still thinking about it.

More broadly, I'm also glad to see that there's some thought about
allowing Ada95 to evolve even before ISO gets around to the next major
revision. Nobody's perfect, and nobody's perfectly clairvoyant either,
including the people who write language standards.  But the ability to
correct mistakes and adapt to new circumstances is a sign of good
health.  For this reason, I believe it's vital that there be some
mechanism for discussing, experimenting, implementing, and sanctioning
revisions and extensions to Ada95.  But I disagree that this mechanism
should be "informal" or "semi-recognized."  There should be some
formally-accepted way to perform corrective and adaptive maintenance on
the Ada95 standard.  Is there one? If there isn't, could somebody with
some clout step in to fill the vacuum, perhaps a coalition between ACT
and Intermetrics? Is this already the de facto situation?

> But first, we need to agre on a technical approach (I note that Tuck
> has changed his mind on this since we last discussed it). Actually
> I prefer Tuck's previous suggestion of "with type", 

I agree. For those of you that weren't around for the previous
discussion, at one point something like the following syntax was on the
table:

	with type <package_name>.<type_name>;

which would act as a forward incomplete declaration for a type coming
from another package spec, without actually "withing" the other package
spec. Eventually, the client must complete this incomplete type
declataion by actually "withing" the other package spec, but this could
be deferred until the client's body.

There was even a proposal for a variation on this that would allow a
client to forward declare not only an object type but also an
accompanying access type, all in the same breath:

    with type Q.T_Ptr is access all Q.T'Class;
    package P is
        type T is tagged limited private;
        type T_Ptr is access all T'Class;
        procedure Use_Both1 (PX : in out P.T; QY : in Q.T_Ptr);
        ...
    end P;

    with type P.T_Ptr is access all P.T'Class;
    package Q is
        type T is tagged limited private;
        type T_Ptr is access all T'Class;
        procedure Use_Both2 (QX : in out Q.T; PY : in P.T_Ptr);
        ...
    end Q;


> because it makes
> it more honestly clear that this is indeed an extension, than
> trying to somehow fit it into the pragma semantics, but I think
> we need to discuss that. Perhaps the next ARG meeting can find a little
> time to discuss it.

Here, here!

----------------------------------------------------------------------------
Internet.Usenet.Put_Signature 
  (Name => "John G. Volan",  Home_Email => "John_Volan@syspac.com",
   Employer => "S.A.I.C.",   Work_Email => "John_Volan@dayton.saic.com",
   Slogan => "Ada95: The World's *FIRST* Internationally-Standardized
OOPL",
   Disclaimer => "My employer never defined these opinions, so using
them"
     & "would be totally erroneous...or is that a bounded error now? :-)
");
----------------------------------------------------------------------------

Re: Two ideas for the next Ada Standard

[Jon S Anthony]

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

> iJon Anthony asks
> 
> "I don't think I could over emphasize my strong agreement with this!
> What is the story on actually getting this adopted?
> "
> 
> (talking about a solution to the circularity problem)
> 
> I don't see any chance of officially (i.e. at the ISO level) adopting a
> modification to the  ISO standard any time soon (say any time in the next
> few years).
> 
> So what we are looking at here is more like an informal agreement to 
> provide a non-standard extension. This can be done either completely
> informally, or perhaps the ACE can be stretched a little to encompass
> the idea of semi-recognized non-standard extensions.

Excellent!  That would be _reall_ good.  And that level of cooperation
would be really kewl.


> But first, we need to agre on a technical approach (I note that Tuck

Check.


> has changed his mind on this since we last discussed it). Actually
> I prefer Tuck's previous suggestion of "with type", because it makes
> it more honestly clear that this is indeed an extension, than
> trying to somehow fit it into the pragma semantics, but I think
> we need to discuss that. Perhaps the next ARG meeting can find a little
> time to discuss it.

I thought that this "pragma hack" was just for experimenting with the
semantics, but that the "with type" was the way it would end up.  Maybe
I misunderstood...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Two ideas for the next Ada Standard

[Jon S Anthony]

In article <Dx5zH4.2zo@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> Another choice is to declare a root integer type, and declare the
> function as primitive of that type, and inherit that function for all
> your integer types.  But this requires everything to be derived from a
> single root type, which inhibits code reuse.
                    ^^^^^^^^^^^^^^^^^^^^^^^^^

Interesting.  Care to elaborate (so to speak...)?

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Two ideas for the next Ada Standard

[Mark A Biggar]

In article <JSA.96Sep4172154@alexandria> jsa@alexandria (Jon S Anthony) writes:
>In article <Dx5zH4.2zo@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
>> Another choice is to declare a root integer type, and declare the
>> function as primitive of that type, and inherit that function for all
>> your integer types.  But this requires everything to be derived from a
>> single root type, which inhibits code reuse.
>Interesting.  Care to elaborate (so to speak...)?

The original Ada9x (before the trim down) had the idea of allowing the use
of 'CLASS on non-tagged types for just this purpose.  E.g.  you could declare
a procedure like:

procedure My_Op(P1: Integer'CLASS; P2: in out Float'CLASS);

Valid parameter for P1 and P2 could be anything of a type derived from
Integer and Float respectively.  This is very similar to the above 
method but the compiler implisitely does the required conversions.

This would make a reasonably simple GNAT experimential extension.

--
Mark Biggar
mab@wdl.lmco.com

Re: Two ideas for the next Ada Standard

[Robert A Duff]

In article <JSA.96Sep4172154@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
>In article <Dx5zH4.2zo@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
>...  But this requires everything to be derived from a
>> single root type, which inhibits code reuse.
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^
>
>Interesting.  Care to elaborate (so to speak...)?

I just meant that if I say, "I have a bunch of neat functionality you
can use, but only if you derive all your types from
Bob_Duffs_Package.Bob_Duffs_Root_Type", and you say you also have a
bunch of neat stuff, but you have to derive from
"Jon_Anthonys_Root_Type", and we've never heard of each other, then our
types won't be derived from each other, and somebody who wants to use
both sets of neat functionality will be stuck.

E.g. within a single project, you can declare a type Root_Integer, with
a primitive operation Image (like 'Image, but better), and derive all
your integer types from that.  (For efficiency, you might want more than
one such root in the project, but that's beside the point.)  Now, we
have an Image function that works for all integer types.  Except those
types that came from some outside place that never heard of our
convention.

Similarly, you can declare a root tagged type, and give it a primitive
Hash function, so anything in that hierarchy can be put in a hash table.
But it doesn't work if you import lots of tagged types from some third
party that doesn't know about that root type, and you want to put
*those* things in your hash table.

This isn't a criticism -- just a fact of life.

- Bob

Re: Two ideas for the next Ada Standard

[Robert I. Eachus]

In article <322C40B1.534A@ehs.ericsson.se> Jonas Nygren <ehsjony@ehs.ericsson.se> writes:

  > And dispatching on return values from functions. But I still like
  > X.P better than P(X) because I immediately can see what object I
  > am operating on. With P(X,Y) one would have to go back to the
  > definition of P to know if it dispatches on X or Y. But this is
  > something one have to adopt to - Ada will never change to X.P
  > notation.

   People have been missing one very important point here.  In Ada (83
and 95) the X.P notation exists and has a slightly different meaning
from P(X).  In particular, X can be a task or protected object, and P
an entry or procedure of that object.

   The paradigm shift from C++ to Ada that many people miss is that
Ada has a both active objects and objects with non-blocking behavior.
(Operations on non-blocking objects can use hidden active objects to
manage access, but that is a consequence of other rules.)

   So if you REALLY prefer that notation use it.  You may be paying an
implementation time price, but Ada had already defined the notational
split this way, and overriding it when adding tagged types would have
been confusing.


					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Two ideas for the next Ada Standard

[Jon S Anthony]

In article <322D6D79.7317@ehs.ericsson.se> Jonas Nygren <ehsjony@ehs.ericsson.se> writes:

> the following type of code is often found in Ada:
> 
> generic
>    type T is private;
>    type TA is access all T;   -- this is what I mean with carrying
> package P is....              -- with you
>                               
> Suppose that we after the instantiation of this package
> need to do some conversion to the access type passed to P,
> when e g extending an existing application, using:
> 
> (2)
>        generic
>            type Object(<>) is limited private;
>        package System.Address_To_Access_Conversions is
>           pragma Preelaborate(Address_To_Access_Conversions);
> (3)
>           type Object_Pointer is access all Object;
>           function To_Pointer(Value : Address) return Object_Pointer;
>           function To_Address(Value : Object_Pointer) return Address;
> (4)
>           pragma Convention(Intrinsic, To_Pointer);
>           pragma Convention(Intrinsic, To_Address);
>        end System.Address_To_Access_Conversions;
> 
> How do we use Object_Pointer together with our existing access type
> without conversion. Of course we could reorganise all our code

OK, that is true.  But this is a very strange example.  Are you saying
that you've got these sort of access<->system.address conversions
going on all over the place??  If so, that still sounds like a
basic/fundamental error.


> Further how do one end up with one and only one access type
> if one have to instantiate multiple packages that declare their
> own access types.

Why would you _want_ such an access type????  That just leads you down
the road to having weird reference problems.  Just like in C/C++...


> And no, renaming via subtypes don't help you.

In the example you give: correct.


> > If you are really this concerned about this why not just make the type
> > limited private?  Clients can't access the state (except through the
> > interface) and they can't assign the things.  For _clients_, it is
> > strictly _in_ mode.
> 
> This is too crude, an either-or approach. I want to be able to control 
> the accessability for each call.

I know you have some concerns here, I just can't make them out.  I
don't mean simple language mechanics, but rather issues about what you
are really trying to achieve.  There is no way in any language that is
readily available that you can gurantee the sort of thing you seem to
want in the _implementation_ of an interface.


> > object designated by the parameter, but you can't assign it.  This is
> > rather more secure than the analog C++ where you get a small piece of
> > this with const T* arguments.
> 
> Well, I suppose you have missed the 'const T* const'. 

No, this doesn't guarantee anything.  The function can change the argument
with very little effort.  Actually, basically no effort.


> What I want is similar to C++'s:
> 
> struct T {
> 	void p1() const; // the object cannot be modified inside P1
> 	void p2();       // the object can be modified inside P2
> ...
> };

This does not guarantee anything. p1 can change the object very
easily.  You can say, "hey no fair casting or whatnot".  I say, why
not?  It's part of the _implementation_ of T.  The sort of thing you
really want is to prevent a _client_ from doing this.  That is easy to
do in Ada.


> Yes, I guess so. The C++ example above but in Ada with access types:
> 
> type T is tagged....
> 
> procedure P1 (Obj : in T);     -- Obj cannot be modified inside P1
> procedure P2 (Obj : access T); -- Obj can be modified inside P2
> 
> calling:  P1(Obj.all);
>           P2(Obj);
> 
> Perhaps not a big deal, but the asymmetry of the solution is
> very ugly in my eyes. 

Well, yeah it is ugly and weird.  In fact it is really weird
especially as P1 can _easily_ change Obj if the implementor wants to,
as it is part of the implementation of T and knows all about its
structure and representation.  There is no guarantee here.  It is up
to the implementation to not screw you over.


> If we could have written:
> 
> procedure P1 (Obj : access constant T);

This really doesn't help at all.  Even with this you can in P1 change
Obj.all - no problem.


> We could then call P1(Obj). Everything would then have been
> symmetrical and beautiful (again in my eyes).

I suppose, but it wouldn't help you achieve what you seem to want to
achieve.


> And I can't see that it would have been too difficult to implement
> in a compiler.

I agree.  Especially since

    type T_Const_Ref is access constant T;

is already there and behaves in the way you want.  But note:

    procedure P1 (Obj : T_Const_Ref);

can't _guarantee_ what you want either.  Sure, it is a very strong
indication that Obj.all won't be changed, but since P1 has the
representation of T, it still might.  Note that I am also calling this
out as different from some client trying to pull this sort of thing as
they can't see the implementation.  Of course, they could still try
something nefarious behind your back, but then all bets are off and
they will get what they deserve.


> > That sounds correct as you never had what you really seem to want in
> > in C++ either.
> 
> In this case C++ have what I want. There are many other aspects 

Well it has "access const" parameters, but these don't look anywhere
near sufficient to do what you seem to want: Guarantee that the
_implementation_ of a type/class won't change a give instance in a
given operation.


> of C++ which I do not like and when I add up pros and cons for Ada 
> and C++ then Ada wins (again this is as seen with my eyes). That's
> why I bother about Ada at all - I want Ada to become 'better'.
> A side note: perhaps all these years in the shadow of C and C++
> have resulted in that Ada proponents automatically takes a
> defensive stand as soon as Ada and C/C++ are mentioned in the

If there's a problem of this sort it is due to the overwhelming
non-understanding of Ada in various circles conjoined with those same
circles being more than willing to make incorrect statements about it
as though they are fact.

You don't seem to be one of those.  In this case, I just don't
understand why you think you need to or even _can_ do what you seem
to want.  In C++ or Ada.  Or for that matter, Eiffel, Sather, Lisp, ...


> construct. Perhaps Gnat could serve as a test environment for new
> language concepts much as gcc does for C.

That's one of the reasons why it is there.  Go for it!

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Two ideas for the next Ada Standard

[Jonas Nygren]

Jon S Anthony wrote:
> 
> In article <322D6D79.7317@ehs.ericsson.se> Jonas Nygren <ehsjony@ehs.ericsson.se> writes:
> 
> > the following type of code is often found in Ada:
> >
> > generic
> >    type T is private;
> >    type TA is access all T;   -- this is what I mean with carrying
> > package P is....              -- with you
> >
> > Suppose that we after the instantiation of this package
> > need to do some conversion to the access type passed to P,
> > when e g extending an existing application, using:
> >
> > (2)
> >        generic
> >            type Object(<>) is limited private;
> >        package System.Address_To_Access_Conversions is
> >           pragma Preelaborate(Address_To_Access_Conversions);
> > (3)
> >           type Object_Pointer is access all Object;
> >           function To_Pointer(Value : Address) return Object_Pointer;
> >           function To_Address(Value : Object_Pointer) return Address;
> > (4)
> >           pragma Convention(Intrinsic, To_Pointer);
> >           pragma Convention(Intrinsic, To_Address);
> >        end System.Address_To_Access_Conversions;
> >
> > How do we use Object_Pointer together with our existing access type
> > without conversion. Of course we could reorganise all our code
> 
> OK, that is true.  But this is a very strange example.  Are you saying
> that you've got these sort of access<->system.address conversions
> going on all over the place??  If so, that still sounds like a
> basic/fundamental error.

It was an example I put together since I am not that well versed in 
lingua Ada. It apparently served its purpose - you understood what I
was trying to explain.

> 
> > Further how do one end up with one and only one access type
> > if one have to instantiate multiple packages that declare their
> > own access types.
> 
> Why would you _want_ such an access type????  That just leads you down
> the road to having weird reference problems.  Just like in C/C++...

What I am aiming at is that in Ada you have to plan your code very well in
advance to avoid a lot of conversions. This is all very well for 'release 1.0'!
But once you have to make changes or additions to your code your initial 
beautiful plan probably no longer holds. Then you end up with situations 
similar to what I described above. 

One solution to this could be to provide an 'anonymous general 
access-to-variable type', RM6.1(24), for variables to and not only for 
subprogram formals and discriminants. Perhaps one could use a syntax similar
to T'Class and have T'Access denoting this new subtype. With this syntax we could
have the example from above:

       generic
          type Object(<>) is limited private;
       package System.Address_To_Access_Conversions is
          pragma Preelaborate(Address_To_Access_Conversions);

	  subtype Object_Access is Object'Access;
          function To_Pointer(Value : Address) return Object_Access;
          function To_Address(Value : Object_Access) return Address;

          pragma Convention(Intrinsic, To_Pointer);
          pragma Convention(Intrinsic, To_Address);
       end System.Address_To_Access_Conversions;

Subtypes of type T'Access does not cause any dispatching for a tagged T when
used as formals to a subprogram.

Further, it causes the same implicit conversion to a derived access type for T, eg:

	type TP is new access all T;
	P : TP := My_T_Conversion.To_Pointer(Some_Address);

Assuming My_T_Conversion is an instantiation of the conversion package above.

To cover for the 'anonymous general access-to-constant type' case to we
should introduce an attribute T'Constant_Access with similar semantics as
T'Access.

I believe the add-on of the new anonymous subtypes given by the two attributes
T'Access and T'Constant_Access would really benefit the Ada language and 
improve the maintainability aspects of Ada code.

If these constructs have been up to discussion in the standardisation process
I would be interested in hearing the reasons for refuting them.

/jonas

<snipped out discussion on 'access constant'>

> /Jon
> --
> Jon Anthony
> Organon Motives, Inc.
> 1 Williston Road, Suite 4
> Belmont, MA 02178
> 
> 617.484.3383
> jsa@organon.com

Re: Two ideas for the next Ada Standard

[Jon S Anthony]

In article <323153E7.2CDA@joy.ericsson.se> Jonas Nygren <jonas@joy.ericsson.se> writes:

> It was an example I put together since I am not that well versed in 
> lingua Ada. It apparently served its purpose - you understood what I
> was trying to explain.

Yes, but it still doesn't get at what seems the very odd situation that
you are having to do this sort of thing a lot - even a little is odd.

But, as long as this particular case was used, I actually have a question
for Bob (if he is reading this...)  Why didn't the generic signature for
System.Address_To_Access_Conversions include the access type?  What subtle
or even obvious thing am I missing?


> > >        generic
> > >            type Object(<>) is limited private;
Why not this?:   type Object_Pointer is access all Object;
> > >        package System.Address_To_Access_Conversions is
> > >           pragma Preelaborate(Address_To_Access_Conversions);
> > > (3)
> > >           type Object_Pointer is access all Object;
> > >           function To_Pointer(Value : Address) return Object_Pointer;
> > >           function To_Address(Value : Object_Pointer) return Address;
> > > (4)
> > >           pragma Convention(Intrinsic, To_Pointer);
> > >           pragma Convention(Intrinsic, To_Address);
> > >        end System.Address_To_Access_Conversions;


> What I am aiming at is that in Ada you have to plan your code very
> well in advance to avoid a lot of conversions. This is all very well
> for 'release 1.0'!  But once you have to make changes or additions
> to your code your initial beautiful plan probably no longer
> holds. Then you end up with situations similar to what I described
> above.

Hmmm, I have never had this sort of problem.  So far, the Ada95 work
I've been doing does not seem to have this weakness either.  So, I
guess I just don't understand what you are doing...


> One solution to this could be to provide an 'anonymous general
> access-to-variable type', RM6.1(24), for variables to and not only
> for subprogram formals and discriminants. Perhaps one could use a
> syntax similar to T'Class and have T'Access denoting this new
> subtype. With this syntax we could have the example from above:

I _think_ Bob Duff would agree with you, but I still don't see this
as a problem so would not agree with it.  In fact, I see the current
situation of not having this as a _good_ thing not just a "shrug".


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Two ideas for the next Ada Standard

[Robert A Duff]

In article <JSA.96Sep7202332@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
>In article <323153E7.2CDA@joy.ericsson.se> Jonas Nygren <jonas@joy.ericsson.se> writes:
...
>But, as long as this particular case was used, I actually have a question
>for Bob (if he is reading this...)  Why didn't the generic signature for
>System.Address_To_Access_Conversions include the access type?

It probably should have been.  It was discussed, and I think the design
team basicall said, yeah, we know that it's usually best to pass in the
access type, to avoid unnecessary conversions, but in this case, you're
doing low-level hacking anyway, so a few extra conversions won't hurt.

>> One solution to this could be to provide an 'anonymous general
>> access-to-variable type', RM6.1(24), for variables to and not only
>> for subprogram formals and discriminants. Perhaps one could use a
>> syntax similar to T'Class and have T'Access denoting this new
>> subtype. With this syntax we could have the example from above:
>
>I _think_ Bob Duff would agree with you, ...

Yes.

>... but I still don't see this
>as a problem so would not agree with it.  In fact, I see the current
>situation of not having this as a _good_ thing not just a "shrug".

The examples we're discussing are not a real problem, because you can
avoid the conversions by simply using the same type, and pass it around
to generics.  But when you use a lot of access-to-class-wide types, it
*is* a problem, because you *have* to declare a bunch of different
access types.  Conversions in the upward direction are a real pain,
IMHO.

- Bob

Re: Two ideas for the next Ada Standard

[Jon S Anthony]

In article <JSA.96Sep7202332@alexandria> jsa@alexandria (Jon S Anthony) writes:

> > > >        generic
> > > >            type Object(<>) is limited private;
> Why not this?:   type Object_Pointer is access all Object;
> > > >        package System.Address_To_Access_Conversions is
> > > >           pragma Preelaborate(Address_To_Access_Conversions);
> > > > (3)
> > > >           type Object_Pointer is access all Object;

And, of course, get rid of this ^^^^^^^^^^^^^^^

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Two ideas for the next Ada Standard

[Robert Dewar]

Responding to Leonid Dulman's suggestions

     1. ALIASED is more common notion then RENAMES  and  (it seams to me)
        this key word needn't.

         Incomprehesible, not close enough to English to guess the intent!

     2. OUT parameters have such chances as IN OUT

         Incomprehesible, not close enough to English to guess the intent!

     3. Maybe  for calling entry in SELECT statement with  DELAY to write
        in the form :

        <entry_name>(...)   WITH DELAY [UNTIL] <time>;

        ACCEPT <entry_name>(...) WITH DELAY [UNTIL] <time> DO ...   END;

        This construction will  allow to expect rendezvous  up to a given
        time moment, or given time interval.

          This is redundant and unnecessary syntax, this functionality is
          already available in convenient form.

     4. To add the subroutine parameter type ALIASED, that will  allow to
        use inside it reference to the subroutines with  " 'ACCESS " or
        " 'UNCHECKED_ACCESS" parameters.

          Seems bogus, since if a parameter is passed by copy, what would
          it mean to take its acccess. Do you intend this to force call
          by reference

     5. Nongeneric form of packages  DIRECT_IO and SEQUENTIAL_IO.
        Parameter RECORD_SIZE to add for  parameter's  list in procedures
        CREATE and OPEN
        (for example in form RECORD_SIZE:=<type's name>'size;).

          Very confused, how could you pass data items to this without
          having a generic formal type parmeter. I suspect what you
          want can perfectly easily be provided using Stream_IO, but
          the suggestion is too confused to be sure.

     6. To specify use ACCESS and UNCHECKED_ACCESS attributes for aliased
        variable. Now (in basic) it is necessary to use  UNCHECKED_ACCESS
        attribute.

          Incomprehensible, another possible language problem?

Re: Two ideas for the next Ada Standard

[Jon S Anthony]

In article <Dx7M7F.8vF@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> >If you are really this concerned about this why not just make the type
> >limited private?  Clients can't access the state (except through the
> >interface) and they can't assign the things.  For _clients_, it is
> >strictly _in_ mode.
> 
> But limited is not the same thing as constant.  An 'in' parameter is
> constant -- it cannot be modified.  An 'in out' parameter of a limited
> type is NOT constant -- it can be changed.

Yes, that is true.  I was refering to having access type to a limited
type, since "constant" access parameters were the context.  But, I
agree that I was not too clear:

    type T is ...limited private;

    procedure P ( x : access T );

Clients can't change T things unless you (interface provider) give them
the ability to do so.  If you do, then you should not be too surprised
when they do.


> Saying clients can't change it (except blah blah blah) isn't much
> help -- the fact is it *can* be changed, and it's easy for the
> client to change it -- just call something in the package that owns
> the type.

Well, sure, if you supply accessors to change the thing then of course
you can change them.  What could possibly be the point of such a
comment?

The real issue being discussed though is whether the _"owner"_ of the
type should be allowed to change such instances in the _implementation_
of the interface when it does not explicitly say it will WITHIN THE
LANGUAGE.  That is, whether the client should be able to look at the
interface and say with _absolute certainty_ that the given operation
does _not_ change the parameter.  That is a little odd to say the
least, as that requires "real" (aka, mathematical) functions.  And I
don't know of any programming language that does that (not even
"functional" languages).  That doesn't mean they don't exist (actually
they do exist as I designed one with this once - but never
implemented), I just don't know of any you can go out and use.


> Also, what about the primitive operations of the type?  The whole
> point of parameter modes is so that you can tell by looking at the
> spec, whether or not a given parameter can be changed.
                                         ^^^ 

What about primitive operations?  As for the "whole point..." bit,
this will never be sufficient.  If I want to, I can change an in mode
parameter just fine.  Behind your back.  Sure, you can say that I have
violated the contract, but so?  The point is, the modes do _not_
_guarantee_ anything.

 
> So, I don't buy the advice "use limited instead of access constant".

Well, you don't even have "access constant" so certainly _can't_ use
limited _instead_ of this.  The idea was to provide an equivalent
level of functionality.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Two ideas for the next Ada Standard

[Jon S Anthony]

In article <Dx8IM1.GE2@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> In article <50jk0f$krh@goanna.cs.rmit.edu.au>,
> Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
> >bobduff@world.std.com (Robert A Duff) writes:
> >>Another example is: You can't write a function that takes a parameter of
> >>"any integer type".  This is a perfectly reasonable thing to do
> >
> >Wearing my Lisp hat:  only because Ada doesn't actually support integers,
> >but a machine-dependent set of machine-dependent small bounded integers.
> 
> That seems like an orthogonal issue.  One could imagine a language like
> Ada, where the potential range of integers was essentially infinite, but
> the type model would still be the same.

Hmmm, actually Ada does support that, just not for "regular" types.  I
mean universal_integer is pretty much just that, right?  Of course, that's
not particularly useful either...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Two ideas for the next Ada Standard

[Jon S Anthony]

In article <Dx8Kpo.GAH@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

> In article <JSA.96Sep4172154@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
> >In article <Dx5zH4.2zo@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
> >...  But this requires everything to be derived from a
> >> single root type, which inhibits code reuse.
> >                    ^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> >Interesting.  Care to elaborate (so to speak...)?
> 
> I just meant that if I say, "I have a bunch of neat functionality you
> can use, but only if you derive all your types from
> Bob_Duffs_Package.Bob_Duffs_Root_Type", and you say you also have a
> bunch of neat stuff, but you have to derive from
> "Jon_Anthonys_Root_Type", and we've never heard of each other, then our
> types won't be derived from each other, and somebody who wants to use
> both sets of neat functionality will be stuck.

Hmmmm. Good point (please, no one mention that dreaded confusion MI
here...)


> Similarly, you can declare a root tagged type, and give it a primitive
> Hash function, so anything in that hierarchy can be put in a hash table.
> But it doesn't work if you import lots of tagged types from some third
> party that doesn't know about that root type, and you want to put
> *those* things in your hash table.

Sounds like "generic" time to me.  Even with "all its verbiage"! :-}

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Two ideas for the next Ada Standard

[Samuel Tardieu]

>>>>> "Richard" == Richard A O'Keefe <ok@goanna.cs.rmit.edu.au> writes:

Richard> However, 'Image is one of the things that would merit
Richard> suppression: it would be nice to export an enumeration type
Richard> _as_ an enumeration type without having to provide all the
Richard> names as strings.

Doesn't the "pragma Discard_Names" do what you want ?

  Sam
-- 
"La cervelle des petits enfants, ca doit avoir comme un petit gout de noisette"
                                                       Charles Baudelaire

Re: Two ideas for the next Ada Standard

[Norman H. Cohen]

In article <5137hi$9oq@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au
(Richard A. O'Keefe) writes: 

|> So far the only way I've been able to figure out of exporting some
|> of the enumeration literals of an enumeration type is
|>
|>      package foo is
|>          type T is private;
|>          function X return T;
|>          function Z return T;
|>      private
|>          type T is (X, Y, Z, W);
|>      end foo;
|>
|> At least, I _thought_ it should work.  Enumeration literals are
|> parameterless functions returning values of the type, not so?
|> But gnat says that the declarations of X and Z in the private
|> part _conflict_ with the earlier declarations (instead of, as I
|> thought, matching them), and who am I to argue?
|>
|> My reaction to this was not to look through the standard for the fine
|> print explaining why I can't do it this way, but to stop trying.
|> Exporting half an enumeration type is probably too silly.

For the record, it's excluded by RM 6.1(20), which lists the allowable
completions for a subprogram declaration.  An enumeration-literal
specification is not among them.  (Also, RM 3.5.1(6) says that an
enumeration-literal specification DECLARES a parameterless function.
This makes it different from a function body, which serve as either a
declaration or a completion, depending on the context.  You cannot
declare the same function twice in the same package specification.)

However, a subprogram renaming declaration is allowed to serve as the
completion of a declaration, and can rename an enumeration literal, so
you can do the following: 

   package Foo is
       type T is private;
       function X return T;
       function Z return T;
   private
       type T is (X_Value, Y_Value, Z_Value, W_Value);
       function X return T renames X_Value;
       function Z return T renames Z_Value;
   end Foo;

(I gave the literals different names from the functions so that both
could be declared in the same package specification.)

I think that enumeration-literal specifications probably could have been
allowed as completions of function declarations without creating any
semantic difficulty.  I even think I recall someone mentioning the
possibility at the 9X review meeting where Tuck proposed allowing
renaming declarations as completions, but then again I may just be
imagining that (False Memory Syndrome ;-)).  In any event, if it was
thought of at the time, it wasn't considered important enough to add to
the burden of language implementors.

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

Re: Two ideas for the next Ada Standard

[Jon S Anthony]

In article <EACHUS.96Sep10165908@spectre.mitre.org> eachus@spectre.mitre.org (Robert I. Eachus) writes:

>   Why not:
> 
>       package Foo is
>           type T is private;
>   	  function X return T;
>   	  function Z return T;
>       private
>           package Bar is
> 	    type Hidden is (X, Y, Z, W);
>           end Bar;
> 
>           type T is new Bar.Hidden;
>   	  function X return T is begin return T(Bar.X); end X;
>   	  function Z return T is begin return T(Bar.Z); end Z;
>           pragma Inline(X,Z);
>       end Foo;

Getting just a bit too parsimonious with those key strokes, eh?  Or
have you been whacking some C++ lately? :-)

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Two ideas for the next Ada Standard

[Bob Mathis]

Bob Duff, in talking about Robert Dewar, said,

>I suspect he has two keyboards on his desk, and fixes bugs in GNAT with
>his right hand, while simultaneously posting to comp.lang.ada with his
>left hand.

A year ago Robert and I were in Frankfurt, Germany, and I was showing off my new
ThinkPad and how Compuserve connected to the Web. Robert asked if he could
Telnet to his home computer to read his mail. That was easy. Then he asked if he
might stay while the rest of us went back to a conference session. A couple of
hours later I went back to check on him and found him actually doing what Bob
Duff guessed about. Robert had my computer doing e-mail and his own ThinkPad
next to it doing a recompilation of some part of GNAT.

-- Bob Mathis

Re: Two ideas for the next Ada Standard

[Marin David Condic, 407.796.8997, M/S 731-93]

Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU> writes:
>I think the problem here is that instead of learning and understanding
>the Ada model, you are simply trying to write C++ in Ada.  A recipe
>for frustration and annoyance and error if there ever was one.
>
    Years ago when Ada83 first came out, I remember the Fortran
    programmers bitching up and down because you couldn't do with
    packages the things you could do with common blocks and worrying
    about if arrays were addressed in row-major order or not. They
    wanted to write "Adatran" code and found it difficult to "get with
    the game plan." (A good Fortran programmer can write Fortran no
    matter *what* language you give him!)

    Now it's the C++ programmers having a hard time trying to write
    "Ada++" Maybe someone needs to write a "Ada for C++ programmers"
    book that does some reeducation?

    I imagine this is a common problem when switching from *any*
    language to *any other*. It's hard to convince many people that
    they need to adjust the way they think about solving the problems
    to the (dare I use the word?) paradigm imposed by the new
    language.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        407.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "Thanks to the Interstate Highway System, it is now possible
    to travel across the country from coast to coast without seeing
    anything."

        --  Charles Kuralt
===============================================================================

Re: Two ideas for the next Ada Standard

[Jon S Anthony]

In article <96090416102641@psavax.pwfl.com> "Marin David Condic, 407.796.8997, M/S 731-93" <condicma@PWFL.COM> writes:

> Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU> writes:

Wow.  Something is _really_ screwy with my address.  I'm certainly
not at "americant.edu" - I'm at where my sig. sez.  I wonder what the
deal is with this - some others have pointed out some screwy things
with my address too.  <mutter mutter damn Unix mutter mutter damn UUNET
mutter mutter>


>     I imagine this is a common problem when switching from *any*
>     language to *any other*. It's hard to convince many people that
>     they need to adjust the way they think about solving the problems
>     to the (dare I use the word?) paradigm imposed by the new
>     language.

To me, the trick has always been to understand what it is that the
various constructs and their interrelationships are trying to solve or
what capability they are trying to provide.  I mean this at the level
of the language - not "just" the programmer's view trying to write a
hunk of code.  Once you have that, it is fairly easy to move around.
"Oh language X solves that problem with A, B, and C.  Interesting.
Language Y solves it with R and Q."  The only place where you may hit
a speed bump with this is when moving between procedural and
declarative languages.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Two ideas for the next Ada Standard

[Marin David Condic, 407.796.8997, M/S 731-93]

Jon S Anthony <jsa@organon.com> writes:
>Wow.  Something is _really_ screwy with my address.  I'm certainly
>not at "americant.edu" - I'm at where my sig. sez.  I wonder what the
>
    Sorry about that, but this is a direct cut from the INFO-ADA
    listserver that sends the stuff my way:
From:    Jon S Anthony <jsa@ALEXANDRIA.AMERICAN.EDU>


>what capability they are trying to provide.  I mean this at the level
>of the language - not "just" the programmer's view trying to write a
>hunk of code.  Once you have that, it is fairly easy to move around.
>"Oh language X solves that problem with A, B, and C.  Interesting.
>Language Y solves it with R and Q."  The only place where you may hit
>a speed bump with this is when moving between procedural and
>declarative languages.
>
    As you observe, you can get a couple of different views on the
    same problem (trying to shift from one language's "paradigm"
    (ugggh!) to another) C syntax/semantics tends to lead the
    programmer towards thinking of solutions involving pointers to
    everything, arrays/counters that start at zero, returned function
    codes for determining success/failure, etc. They get frustrated
    when they move to a language like Ada which may certainly allow
    you to do all of the same things, but doesn't really want you to.
    ("Yes you _can_ pass strings to subroutines by declaring an access
    type, etc., but why would you _want_ to???")

    Another class of problem is where the language itself is so
    dramatically different that it's damned near impossible to get
    your brain wrapped around the way it works. I started with Pascal,
    Fortran and other "normal" languages. The first time I encountered
    Lisp, it about choked me to death! (There are two kinds of
    programming languages in the world: Lisp and Everything-Else)
    Things like RPG-II were equally strange and difficult to find any
    "reference points" in. In some ways, this was better because you
    *knew* from the get-go that you were going to have to discard all
    of your pre-conceived notions about how to write a program and
    learn to work *with* the new language, rather than trying to
    bludgeon it into doing what you were used to.

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        407.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        407.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
   "The first guy that rats gets a bellyful of slugs in the head.
    Understand?"

        --  Joey Glimco, trade unionist
===============================================================================