Re:Two ideas for the next Ada Standard

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]

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

[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

[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

[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

[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

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

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

[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

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

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

[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

[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

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

[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

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

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

[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

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

[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

[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

[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

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

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

[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

[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

[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

[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

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

[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

[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

[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

[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

[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

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

[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

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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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