Future Ada language revisions?

Future Ada language revisions?

[bpr5549]

In a fairly recent c.l.a. discussion it was mentioned that there is no
plan for an Ada 0X project comparable to the 9X project. What is the process
by which incremental changes will be made to the language, and how does one
go about participating? Has anything changed with the demise of the AJPO?

-- Brian

PS: In case anyone is wondering, my main peeve is the restriction on out mode
function parameters, which I just don't understand, even when I'm trying to
open minded. I have yet to hear a good defense of this restriction, so if
anyone has one, I'm all ears, errr, eyes.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Future Ada language revisions?

[Larry Kilgallen]

In article <6um7on$db5$1@nnrp1.dejanews.com>, bpr5549@my-dejanews.com writes:

> PS: In case anyone is wondering, my main peeve is the restriction on out mode
> function parameters, which I just don't understand, even when I'm trying to
> open minded. I have yet to hear a good defense of this restriction, so if
> anyone has one, I'm all ears, errr, eyes.

On a more pragmatic note, what do you feel has changed about the
world since 1995 to make people change their minds on this issue?
There is no sense wasting resources to debate an issue when those
with a vote have chosen (twice) to let people use procedures rather
than functions to solve this need.

Larry Kilgallen

Re: Future Ada language revisions?

[Brian Rogoff]

On Sun, 27 Sep 1998, Larry Kilgallen wrote:
> In article <6um7on$db5$1@nnrp1.dejanews.com>, bpr5549@my-dejanews.com writes:
> 
> > PS: In case anyone is wondering, my main peeve is the restriction on out mode
> > function parameters, which I just don't understand, even when I'm trying to
> > open minded. I have yet to hear a good defense of this restriction, so if
> > anyone has one, I'm all ears, errr, eyes.
> 
> On a more pragmatic note, what do you feel has changed about the
> world since 1995 to make people change their minds on this issue?

I'm hoping, probably prematurely, that a large number of programmers who
hadn't used Ada before Ada 95 are using it now, and that in time perhaps 
the majority opinion will change. I'm one of those new Ada users, and as 
I've tried to "sell" Ada to colleagues I've been a bit embarassed at 
explaining this blemish.
 
> There is no sense wasting resources to debate an issue when those
> with a vote have chosen (twice) to let people use procedures rather
> than functions to solve this need.

Thats really not a solution to the problem. Robert's solution is better, 
but it involves stepping out of "pure" Ada. However, rather than waste 
resources on a problem that everyone considers a done deal right now,
maybe it would be best if I hadn't written that PS and just asked the
question about the process of change for the language. 

-- Brian

Re: Future Ada language revisions?

[Michael F Brenner]

>> On a more pragmatic note, what do you feel has changed about the
>> world since 1995 to make people change their minds on this issue?

> ... in time perhaps
> the majority opinion will change. I'm one of those new Ada users, and as
> I've tried to "sell" Ada to colleagues I've been a bit embarassed at
> explaining this blemish.

>> There is no sense wasting resources to debate an issue when those
>> with a vote have chosen (twice) to let people use procedures rather
>> than functions to solve this need.

> However, rather than waste
> resources on a problem that everyone considers a done deal right now,
> maybe it would be best if I hadn't written that PS and just asked the
> question about the process of change for the language.
                
I agree with the problems noted by both posters: 
   (a) the process should be opened up to additional opinions
       (there should be at least inputs, even if there is no hope
       of a vote)
   (b) the process should be published so we know who to talk to 
       about change

Re: Future Ada language revisions?

[dewarr]

In article <6unmol$vm@top.mitre.org>,
  mfb@mbunix.mitre.org (Michael F Brenner) wrote:
> I agree with the problems noted by both posters:
>    (a) the process should be opened up to additional opinions
>        (there should be at least inputs, even if there is no hope
>        of a vote)
>    (b) the process should be published so we know who to talk to
>        about change


Well of course you always have the phenomenon of people coming late into the
process and wanting to revisit things. That's fine if there are new viewpoints
to be added, but I don't think there are in this case, at least I have not
seen any.

Additional opinions are not really relevant unless they add new information.

As for the process being open, it was amazingly open, and there is indeed
quite a long record of discussion of this case. Go to the dejanews archives
as a first step!


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Future Ada language revisions?

[dewarr]

In article <Pine.BSF.4.02A.9809272141160.18704-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> I'm hoping, probably prematurely, that a large number of programmers who
> hadn't used Ada before Ada 95 are using it now, and that in time perhaps
> the majority opinion will change. I'm one of those new Ada users, and as
> I've tried to "sell" Ada to colleagues I've been a bit embarassed at
> explaining this blemish.


Remember that I completely agree on the technical issue here.

But this is by NO means a blemish, and if it causes you embarassment, it just
means you lack perspective.

There are good arguments on both sides of this issue.

Which side you come down on depends on your evaluation of the relative
merit of these good arguments. It is clear that the general viewpoint
is that the disadvantages of allowing this kind of specification outweigh
the advantages.

I find this perfectly reasonable, and not the least bit embarassing to
describe and defend!

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Future Ada language revisions?

[Brian Rogoff]

On Mon, 28 Sep 1998 dewarr@my-dejanews.com wrote:
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > I'm hoping, probably prematurely, that a large number of programmers who
> > hadn't used Ada before Ada 95 are using it now, and that in time perhaps
> > the majority opinion will change. I'm one of those new Ada users, and as
> > I've tried to "sell" Ada to colleagues I've been a bit embarassed at
> > explaining this blemish.
> 
> 
> Remember that I completely agree on the technical issue here.

OK.

> But this is by NO means a blemish, and if it causes you embarassment, it just
> means you lack perspective.

We all lack perspective, and I probably lack more than most. However, when
I find myself using access parameters (and then aliased variables :-) to
work around this restriction, I'm forced to ask myself if the cure isn't 
worse than the disease (side effecting functions). 

> There are good arguments on both sides of this issue.
> 
> Which side you come down on depends on your evaluation of the relative
> merit of these good arguments. It is clear that the general viewpoint
> is that the disadvantages of allowing this kind of specification outweigh
> the advantages.
> 
> I find this perfectly reasonable, and not the least bit embarassing to
> describe and defend!

You're better at playing devil's advocate than I am then. There are quite
a few design decisions in Ada that I am not completely happy with, for 
example the lack of downward funargs, but I understand the reasons for 
that choice and even if I would have decided differently I think I could 
argue against my preference honestly. Given that Ada is not referentially 
transparent, and that I can write side effecting functions now, and that
there is now a great temptation to (mis)use aliasing, etc., I don't see 
that the arguments against relaxing this restriction are very good at all. 

So, I stand by what I wrote, with the qualification to those who may
misunderstand my position, that I think Ada is exceptionally well
designed, and will keep using it even though I don't have to, and even if  
there are little blemishes (*) that vex me now and then.

-- Brian

(*) I suspect that you don't like my word choice here. Perhaps "poor
    design decision, IMO" would be less offensive ;-)
 

Re: Future Ada language revisions?

[Larry Kilgallen]

In article <Pine.BSF.4.02A.9809282138540.20653-100000@shell5.ba.best.com>, Brian Rogoff <bpr@shell5.ba.best.com> writes:

> We all lack perspective, and I probably lack more than most. However, when
> I find myself using access parameters (and then aliased variables :-) to
> work around this restriction, I'm forced to ask myself if the cure isn't 
> worse than the disease (side effecting functions). 

What is the circumstance in which access parameters and aliased variables
must be used, rather than switching to using a procedure ?  I started
with DEC Ada (actually, VAX Ada), and I applaud the ACT decision to adopt
IMPORT_VALUED_PROCEDURE for dealing with foreign language assumptions in
this regard.  But foreign languages seem to be the only circumstance
I can think of where using a procedure is a problem.

As a non-mathematician, with no particular affection for the restriction,
I am somewhat put off by output parameters because there is no "natural"
path leading me to certainly make use of the output.  Function results
tend to lead me better in the direction of properly using the result.
But when there are multiple outputs (procedures in Ada), things are more
problematic, as I often find myself caring only about one of the results.

Larry Kilgallen

Re: Future Ada language revisions?

[Michael F Brenner]

On the topic of IN OUT parameters for Ada functions:
  > We all lack perspective, and I probably lack more than most. However, when
  > I find myself using access parameters (and then aliased variables :-) to
  > work around this restriction, I'm forced to ask myself if the cure isn't
  > worse than the disease (side effecting functions).

Using pointers and the Ada ALIASED keyword is only one way to alias variables.

However, IN OUT parameters have the same coupling effect (to alias
the variables through the parameter passing interface). The verb to alias
means to permit changes in one variable to effect the value of another.

Aliasing of any kind (including homonyms) encourages programmers to
insert bugs in their code and then provides a path in the variable 
name space through which those bugs can propogate to other parts of the
code.
 
We should therefore become more aware of what language features
cause aliasing to occur in address space or in name space, because
of the software maintenance implications of this aliasing (that is,
because aliasing provides bug propogation paths). To become more
aware, here is a list of the Ada constructs (other than ALIASED) which
provide a form of aliasing:
    overloaded variables such as RENAMES or equivalences or commons
    homonyms such as overloaded enumeration elements or array elements
    polymorphism or objects with changeable discriminants or tags
    external objects shared with other languages (e.g. pragma INTERFACE)
    parameters passed by reference (such as IN OUT)
    unchecked_conversion
    pointers or access type variables
    forcing the use of access variables to get things off the stack
    non-limited-private types
    re-use of variables for multiple assignments
    use of protocols like temporary variables or intermediate files
    non-limited-private-types

Mike Brenner   mikeb@mitre.org

Re: Future Ada language revisions?

[Fergus Henderson]

mfb@mbunix.mitre.org (Michael F Brenner) writes:

>Aliasing of any kind (including homonyms) encourages programmers to
>insert bugs in their code and then provides a path in the variable 
>name space through which those bugs can propogate to other parts of the
>code.  [...]
>here is a list of the Ada constructs (other than ALIASED) which
>provide a form of aliasing: [...]
>    homonyms such as overloaded enumeration elements [...]

Enumeration elements are constants, aren't they?
There's nothing wrong with aliasing constants, is there?

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

Re: Future Ada language revisions?

[Arthur Evans Jr]

In article <6um7on$db5$1@nnrp1.dejanews.com>, bpr5549@my-dejanews.com wrote:

> PS: In case anyone is wondering, my main peeve is the restriction on
> out mode function parameters, which I just don't understand, even when
> I'm trying to open minded. I have yet to hear a good defense of this
> restriction, so if anyone has one, I'm all ears, errr, eyes.

and in article <1998Sep27.181539.1@eisner>,
Kilgallen@eisner.decus.org.nospam wrote:

> On a more pragmatic note, what do you feel has changed about the world
> since 1995 to make people change their minds on this issue?  There is
> no sense wasting resources to debate an issue when those with a vote
> have chosen (twice) to let people use procedures rather than functions
> to solve this need.

When this issue was debated during the Ada-9X design process, several of
us came out strongly in favor of permitting out parameters in functions,
at least those with pragma interface C if not elsewhere; we lost.  It
seems to me that it's quite in order for contributors to cla to offer
reasoned objections to this -- or any -- Ada-9X design decision.  After
all, there will surely be an Ada-0X design some time.

Art Evans

Re: Future Ada language revisions?

[dewarr]

In article <eva_remove_this_ns-2809980910030001@ppp4.s9.pgh.net>,
  eva_remove_this_ns@evans.pgh.pa.us (Arthur Evans Jr) wrote:
> When this issue was debated during the Ada-9X design process, several of
> us came out strongly in favor of permitting out parameters in functions,
> at least those with pragma interface C if not elsewhere; we lost.  It
> seems to me that it's quite in order for contributors to cla to offer
> reasoned objections to this -- or any -- Ada-9X design decision.  After
> all, there will surely be an Ada-0X design some time.


Well sure, but before you offer reasoned objections, take the effort to
consult the archives. This is one issue that has been discussed to death
in the past, so there is no point in reopening the discussion unless someone
has something new to add!

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Future Ada language revisions?

[dewar]

In article <6um7on$db5$1@nnrp1.dejanews.com>,
  bpr5549@my-dejanews.com wrote:
> In a fairly recent c.l.a. discussion it was mentioned that there is no
> plan for an Ada 0X project comparable to the 9X project. What is the process
> by which incremental changes will be made to the language, and how does one
> go about participating? Has anything changed with the demise of the AJPO?
>
> -- Brian
>
> PS: In case anyone is wondering, my main peeve is the restriction on out mode
> function parameters, which I just don't understand, even when I'm trying to
> open minded. I have yet to hear a good defense of this restriction, so if
> anyone has one, I'm all ears, errr, eyes.


Brian, while I entirely share your view on this particular issue, you are
quite wrong if you think there is any likelihood of this being changed. I
was one of the authors of the requirements document, and we did not
specifically recommend this change in the language, but we did use it
as an example of an arbitrary restrction that should be reexamined.

We got very few comments on the requirements document, *except* for a
significant number of angry comments denouncing this horrible change :-)

During the Ada 9X process, there was a continued effort, by me and others,
but *particularly* by me, to get this addressed, and a last ditch effort
to get it allowed at least for interfaced procedures.

But it was quite clear that a significant and strong majority viewpoint is
that this would be a mistake, since it would allow *at the specification
level* the specification of functions that are clearly not functions in
the mathematical sense.

Yes, we all know that you can in Ada, still write non-mathematical functions,
but the idea is that specifically allowing out parameters encourages and
blesses this in a way that "illegitimate" use of side effects does not.

Language design is a cooperative consensus process. I considered my job here
to be to ensure that the majority exactly understood the issues in coming to
their decision, and fully understood the (powerful) arguments in favor of
dropping this distinction. I was convinced that both of these aims were
achieved, and yet the vote was still to retain this restriction, and that's
good enough for me. End of issue!

So don't suppose that any Ada0X process would make a change that you would
like here. It won't. No new arguments have been put forward, no new facts
are known, and there is no reason for anyone to change their opinion on this,
and having seen several separate communities come down in favor of retaining
this restriction, I think it is clear that it is there to stay.

And please don't start a thread discussing this without first doing extensive
research into both Ada 9X design documents, and into comp.lang.ada archives,
we have been there before :-)

Meanwhile, if you are using GNAT, we copied DEC's (complete) solution to this
in the form of the Import_Valued_Procedure pragma. If you are not using GNAT
then encourage your vendor to implement this very useful feature!

Robert Dewar
Ada Core Tecnologies

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Future Ada language revisions?

[Alfred Hilscher]

I have an other question to the Ada95 design: Why does Ada not support
simple PROCEDURE-Types (like C or Modula). When writing GUI
applications, one needs always to pass callback routines. They are in
fact passed as procedure variables. In Ada one have to pass adresses
instead. While Ada has task type, I did not found any procedure type. Is
there really none (and if, why not) or am I blind ?

Alfred

Re: Future Ada language revisions?

[Tucker Taft]

Alfred Hilscher (Alfred.Hilscher@oen.siemens.de) wrote:

: I have an other question to the Ada95 design: Why does Ada not support
: simple PROCEDURE-Types (like C or Modula). 

It does support such things.  They are called "access-to-subprogram" types.

: ... When writing GUI
: applications, one needs always to pass callback routines. They are in
: fact passed as procedure variables. In Ada one have to pass adresses
: instead. While Ada has task type, I did not found any procedure type. Is
: there really none (and if, why not) or am I blind ?

Check your glasses ;-).  And then look in RM95 3.10 for the discussion
of "access-to-subprogram" types.

: Alfred

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company

Re: Future Ada language revisions?

[Brian Rogoff]

Actually Alfred, Ada 95 *does* support the equivalent of C function
pointers, although you'll have to use the Ada terminology "access to 
subprogram" to find them. 

If you really want to be a trouble-maker, you'll complain that the
limitations on them make them only as powerful as C's function pointers, 
and less powerful than Pascal's function arguments (terminology?), and in 
that case I can point you directly to the long arguments on why they are 
so restricted :-)

-- Brian

On Mon, 5 Oct 1998, Alfred Hilscher wrote:

> I have an other question to the Ada95 design: Why does Ada not support
> simple PROCEDURE-Types (like C or Modula). When writing GUI
> applications, one needs always to pass callback routines. They are in
> fact passed as procedure variables. In Ada one have to pass adresses
> instead. While Ada has task type, I did not found any procedure type. Is
> there really none (and if, why not) or am I blind ?
> 
> Alfred
> 
> 

Re: Future Ada language revisions?

[dewarr]

In article <Pine.BSF.4.02A.9810050914220.9326-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> Actually Alfred, Ada 95 *does* support the equivalent of C function
> pointers, although you'll have to use the Ada terminology "access to
> subprogram" to find them.
>
> If you really want to be a trouble-maker, you'll complain that the
> limitations on them make them only as powerful as C's function pointers,
> and less powerful than Pascal's function arguments (terminology?), and in
> that case I can point you directly to the long arguments on why they are
> so restricted :-)


Well Brian has a (well known to us here) axe to grind here, but the above is
a bit misleading. In fact in most respects the access-to-procedure values of
Ada are far more powerful than the procedure parameters of Pascal, in that
they are non-limited types that can be freely assigned. Yes it is true that
there are some limitations on the use of procedure parameters referring to
nested procedures, but on the other hand, many of the purposes for which
procedure parameters are used in Pascal are preferably implemented using
generics in the case of Ada, which are far more powerful than anything
Pascal has to offer.

For a good idea of how the use of generics and access-to-procedure approaches
compare, look at the g-hesorg.ads/adb and g-hesora.ads/adb files in the GNAT
distribution, these are respectively a generic and access-to-procedure
implementation of an optimized heapsort that does N log N comparisons (instead
of the usual 2 N log N).

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Future Ada language revisions?

[dewarr]

In article <3618DAE7.326A@oen.siemens.de>,
  Alfred.Hilscher@oen.siemens.de wrote:
> I have an other question to the Ada95 design: Why does Ada not support
> simple PROCEDURE-Types (like C or Modula). When writing GUI
> applications, one needs always to pass callback routines. They are in
> fact passed as procedure variables. In Ada one have to pass adresses
> instead. While Ada has task type, I did not found any procedure type. Is
> there really none (and if, why not) or am I blind ?


This is a bit peculiar, perhaps you have been looking at an obsolete language
(Ada 83). In Ada 95, there is an access procedure type which does exactly what
you want. Very similar to, but safer than, the use of procedure pointers in C.
This feature was primarily motivated by the need to support callbacks and has
been widely and successfully used for this purpose.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Future Ada language revisions?

[Alfred Hilscher]

Thanks to all. I think I must read the LRM once again.

Alfred

Re: Future Ada language revisions?

[Robert I. Eachus]

In article <6um7on$db5$1@nnrp1.dejanews.com> bpr5549@my-dejanews.com writes:

  > PS: In case anyone is wondering, my main peeve is the restriction
  > on out mode function parameters, which I just don't understand,
  > even when I'm trying to open minded. I have yet to hear a good
  > defense of this restriction, so if anyone has one, I'm all ears,
  > errr, eyes.

   I don't have strong feelings either way here, with a slight bias
toward allowing it in interfaces to make interfacing to C easier.
(Flame retardant:  Of course in C you can't have a function that
changes a function parameter, but the workaround it to require the
user to pass a pointer to an appropriate sized area.  You can, of
course, do exactly the same in Ada, but it means that the caller has
to be responsible for managing the memory.)

   But let me give the reasoning from the winning side:  There are
four cases where functions with side-effects are needed. 

   1) Memoizing functions, like random number generators.  This can be
done neatly enough in Ada, but in fact the twin requirements of Annex
A semantics and good performance make this a little tricky.  However,
users are unlikely to have to deal with any case as tough as the A.5.2
generators.  (The tough part is A.5.2(46): "Any storage associated with
an object of type Generator should be reclaimed on exit from the scope
of the object.")

   2) Functions which return more than one unconstrained value.  Again
Ada offers a disciplined way to do this since you can always declare a
record type and return that.  The known special cases in Ada 83 were
dealt with elsewhere, such as with Ada.Task_Identification.Task_ID.

   3) Functions which are operations of an object, with side effects
on that object.  The solution here is to make the complete object type
an access type, and hide that fact completely from outside users.  The
introduction of finalization in Ada 95 vastly simplifies the amount of
work to do this right in Ada 95.

   4) Interfacing to languages which permit functions to modify
parameters directly.  The prime case is PL/I.  (I like PL/I, I've
written a lot of code in PL/I, including parts of three Ada
compilers.)  Of course, PL/I is relatively much less popular than it
was when Ada 83 was standardized.

   So in every case where it is needed, the drawbacks are much less in
Ada 83.  On the other hand, if you do pull a fast one in Ada and write
a function with a side effect, READERS of the code will be very
surprised, and may miss the intent of the function, and certainly the
fact that such a call could have side effects or change its
parameters.  So allowing such functions has a distributed cost in
shops where no functions with side effects are ever written.
--

					Robert I. Eachus

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

Re: Future Ada language revisions?

[Brian Rogoff]

On 2 Oct 1998, Robert I. Eachus wrote:
> In article <6um7on$db5$1@nnrp1.dejanews.com> bpr5549@my-dejanews.com writes:
> 
>   > PS: In case anyone is wondering, my main peeve is the restriction
>   > on out mode function parameters, which I just don't understand,
>   > even when I'm trying to open minded. I have yet to hear a good
>   > defense of this restriction, so if anyone has one, I'm all ears,
>   > errr, eyes.
> 
>    I don't have strong feelings either way here, with a slight bias
> toward allowing it in interfaces to make interfacing to C easier.

Thanks Robert! I was starting to regret my PS, since it was generating
more heat than light, and distracting people from the main question in the 
subject line, but this reply saved me (and others) from having to dredge
up the discussions. I take it that you use "interfaces" above to mean 
foreign function interfaces, so that Robert Dewar's suggestion of
encouraging the adoption of GNAT's pragma Export_Valued_Procedure would be 
a satisfactory solution. 

> (Flame retardant:  Of course in C you can't have a function that
> changes a function parameter, but the workaround it to require the

This is true with the exception of the increment/decrement operators ++,
and --. I don't frequently use these for their value in my own C code, so 
I don't miss them much in Ada. I do miss the ?: ternary operator, and the 
"op=" forms though, and I wish Ada had something similar (op:= perhaps?), 
but I digress.

>    But let me give the reasoning from the winning side:  There are
> four cases where functions with side-effects are needed. 
> 
>    1) Memoizing functions, like random number generators.  This can be
> done neatly enough in Ada, but in fact the twin requirements of Annex
> A semantics and good performance make this a little tricky.  However,
> users are unlikely to have to deal with any case as tough as the A.5.2
> generators.  (The tough part is A.5.2(46): "Any storage associated with
> an object of type Generator should be reclaimed on exit from the scope
> of the object.")

I agree that its unlikely, but that seems to me to be a weak argument
in favor of a language restriction rather than a style guideline. 

>    3) Functions which are operations of an object, with side effects
> on that object.  The solution here is to make the complete object type
> an access type, and hide that fact completely from outside users.  The
> introduction of finalization in Ada 95 vastly simplifies the amount of
> work to do this right in Ada 95.

Yes, this is nice, though I (perhaps wrongly) feel that this solution is
kind of heavy in terms of performance costs, especially if I want to have 
side-effecting functions on objects with value semantics.

>    4) Interfacing to languages which permit functions to modify
> parameters directly.  The prime case is PL/I.  (I like PL/I, I've
> written a lot of code in PL/I, including parts of three Ada
> compilers.)  Of course, PL/I is relatively much less popular than it
> was when Ada 83 was standardized.

The pragma solution is fine here in any case.

>    So in every case where it is needed, the drawbacks are much less in
> Ada 83.  On the other hand, if you do pull a fast one in Ada and write
> a function with a side effect, READERS of the code will be very
> surprised, and may miss the intent of the function, and certainly the

Eh? READERS will look at the interface to the function and see an out mode 
parameter, so they'll only be surprised if they don't read the spec.
"Against stupidity the gods themselves contend in vain", right?

> fact that such a call could have side effects or change its
> parameters.  So allowing such functions has a distributed cost in
> shops where no functions with side effects are ever written.

I see "distributed cost" has become overloaded now ;-). I think if a shop 
had a rule of "no access mode" or no "_Type" in type names or whatever
there is also a similar cost, but I don't think that means that should be 
language rules enforcing restrictions here.

-- Brian

Re: Future Ada language revisions?

[dewarr]

In article <Pine.BSF.4.02A.9810031123180.20730-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
<< text of message regarding out params for functions deleted>>

I delete this text because it says nothing new (on either side). I strongly
suggest that everyone who wants to contribute to this thread first go to the
DN archives and look up the old threads on this subject, which has been argued
to death more than once. I see no reason to simply rerun old threads unless
there is something new to say!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Future Ada language revisions?

[Brian Rogoff]

On Mon, 5 Oct 1998 dewarr@my-dejanews.com wrote:
> In article <Pine.BSF.4.02A.9810031123180.20730-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> << text of message regarding out params for functions deleted>>
> 
> I delete this text because it says nothing new (on either side). I strongly
> suggest that everyone who wants to contribute to this thread first go to the
> DN archives and look up the old threads on this subject, which has been argued
> to death more than once. I see no reason to simply rerun old threads unless
> there is something new to say!

I'd be happy to oblige. If you remember the names and dates of the threads
under which this topic has been argued (obviously *not* to death) I'll spend
some time there looking. 

Since some of us don't have superfast connections, a suggestion to look on
the Deja News archives without some more info is rather unhelpful. A naive 
search on obvious keywords turns up too much to scan.

-- Brian

Re: Future Ada language revisions?

[Martin Dowie]

In article <Pine.BSF.4.02A.9810042210470.18465-100000@shell5.ba.best.com
>, Brian Rogoff <bpr@shell5.ba.best.com> writes
>Since some of us don't have superfast connections, a suggestion to look on
>the Deja News archives without some more info is rather unhelpful. A naive 
>search on obvious keywords turns up too much to scan.

i've had a look through DN to see if this one has been done to death
before but i can't find anything on it - if you know different please e-
mail me!

my suggestion concerns subprogram specs. as defined in Ada83 (i'm still
reading up on Ada95, but i haven't seen anything to suggest this
extension has been made) the contract made between the provider and user
is clearly defined when things are going well, but when exceptions are
raised, its up to the mercy of the provider to add appropriate
documentation (be it user manual, code comment, whatever) to allow the
user to see what to expect.

Would it be feasible to extend the specification for subprograms to
include a list of exceptions that can also be 'returned' from a
subprogram? here's an example using of what i'm driving at (hopefully
it's self explanatory) -

  function Blah return Boolean
    or exception Some_Exception;

and for multiple exceptions, something like -

  function Blah return Boolean
    or exception Some_Exception, Another_Exception;

the syntax i have used here also reuses existing reserved keywords, so
no language extension necessary there.

This would not only help the user of the subprogram but perhaps could be
used by compilers/linkers to generate warnings (errors?) for unhandled
exceptions or even when the body is provided if it can't/doesn't
actually raise the error declared.

Are there compiler problems with this, or fundamental language problems?
over to the language lawyers!
-- 
Martin Dowie

Re: Future Ada language revisions?

[dewarr]

In article <KxPqMDAonPG2EwCX@dowie-cs.demon.co.uk>,
  Martin Dowie <martin@dowie-cs.demon.co.uk> wrote:


> my suggestion concerns subprogram specs. as defined in Ada83 (i'm still
> reading up on Ada95, but i haven't seen anything to suggest this
> extension has been made) the contract made between the provider and user
> is clearly defined when things are going well, but when exceptions are
> raised, its up to the mercy of the provider to add appropriate
> documentation (be it user manual, code comment, whatever) to allow the
> user to see what to expect.
>
> Would it be feasible to extend the specification for subprograms to
> include a list of exceptions that can also be 'returned' from a
> subprogram? here's an example using of what i'm driving at (hopefully
> it's self explanatory) -

This is of course a very old idea, one that has been introduced in some
languages, and was of course discussed in detail during the Ada 83 and
Ada 95 designs. Again, it is clear what the arguments are on both sides
of this issue, and I don't see anything new coming up. There was some
sentiment for revisiting this during the Ada 95 design, but not much.

I don't know how many of the language study notes for Ada 83 still exist.
Many of these issues are probably discussed there!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Future Ada language revisions?

[Niklas Holsti]

Martin Dowie wrote:
  [ snip ]
> Would it be feasible to extend the specification for subprograms to
> include a list of exceptions that can also be 'returned' from a
> subprogram? here's an example using of what i'm driving at (hopefully
> it's self explanatory) -
> 
>   function Blah return Boolean
>     or exception Some_Exception;
> 
> and for multiple exceptions, something like -
> 
>   function Blah return Boolean
>     or exception Some_Exception, Another_Exception;

I'd prefer to leave the analysis of exception flow to a static analysis
tool, and not require a list of possible exceptions in the spec, at
least
not a complete list.

Consider the case where you have a deeply layered program, with MAIN
calling module A calling module B calling ... calling some library L.
If an exception raising is added to L, intended to signal a fatal
error to MAIN, you would have to modify the specs of all intermediate
levels. Then, what if some intermediate level modules are also used
in some other project, with a different library L, which does not raise
this particular exception? Requiring a list of all possible exceptions
on all levels would make code sharing harder.

I could accept having the list optional. Perhaps it would be good
to allow "others" as the last element in the list, to mean that the
list is possibly incomplete:

     function Blah return Boolean
        or Some_Exception or others;

(I'd prefer a syntax that places "or" between all exception names,
instead of separating them with commas. Also, the "exception" is
unnecessary and it doesn't add a whole lot of readability, since
most exception names already hint at exceptions, for example
"Constraint_Error".)

One trouble spot could be exceptions raised by run-time checks that
may or may not be elided, depending on the compiler. For example,
a smart compiler given a strongly typed subprogram might
elide all constraint checks, and therefore the subprogram should
not be specified as possibly raising Constraint_Error -- or should it?
Another, dumber compiler perhaps could not prove to its own
satisfaction that Constraint_Error is impossible, and so would
complain about the missing "or Constraint_Error" in the spec.

> Martin Dowie

Niklas Holsti
Space Systems Finland Ltd.

Re: Future Ada language revisions?

[Martin Dowie]

In article <3619254C.C82A4A71@icon.fi>, Niklas Holsti <nholsti@icon.fi>
writes
[snip]
>I'd prefer to leave the analysis of exception flow to a static analysis
>tool, and not require a list of possible exceptions in the spec, at
>least
>not a complete list.

do you know of any tool that currently does this? i haven't come across
one yet (the nearest similar listing would be unused data
objects/subprograms that a linker has removed).

>Consider the case where you have a deeply layered program, with MAIN
>calling module A calling module B calling ... calling some library L.
>If an exception raising is added to L, intended to signal a fatal
>error to MAIN, you would have to modify the specs of all intermediate
>levels. Then, what if some intermediate level modules are also used
>in some other project, with a different library L, which does not raise
>this particular exception? Requiring a list of all possible exceptions
>on all levels would make code sharing harder.

fair point - but even without this extension, the behaviour of a
different library unit would (should) be concidered for differences
which might also require changes to the mid-level units.

also hasn't the behaviour of the mid level units changed if using this
lower level unit (it no longer raises the exception)? shouldn't this
change in 'exported' behaviour be explicit in its specification? this
would force the user of the mid-level package to reconcider his
decisions.

>I could accept having the list optional. Perhaps it would be good
>to allow "others" as the last element in the list, to mean that the
>list is possibly incomplete:
>
>     function Blah return Boolean
>        or Some_Exception or others;
>
>(I'd prefer a syntax that places "or" between all exception names,
>instead of separating them with commas. Also, the "exception" is
>unnecessary and it doesn't add a whole lot of readability, since
>most exception names already hint at exceptions, for example
>"Constraint_Error".)
>One trouble spot could be exceptions raised by run-time checks that
>may or may not be elided, depending on the compiler. For example,
>a smart compiler given a strongly typed subprogram might
>elide all constraint checks, and therefore the subprogram should
>not be specified as possibly raising Constraint_Error -- or should it?
>Another, dumber compiler perhaps could not prove to its own
>satisfaction that Constraint_Error is impossible, and so would
>complain about the missing "or Constraint_Error" in the spec.

a case for having these as compilation warning rather than errors?

'others' could also still cater for anonymous exceptions.

all i'm really trying to point out is that subprogram specifications
appear to be "incomplete". ada seems to go out its way to allow as many
compile time checks as possible with specifications allowing 'contracts'
to be made between provider and user - except in this one area.
-- 
Martin Dowie

Re: Future Ada language revisions?

[dennison]

In article <KxPqMDAonPG2EwCX@dowie-cs.demon.co.uk>,
  Martin Dowie <martin@dowie-cs.demon.co.uk> wrote:
> Would it be feasible to extend the specification for subprograms to
> include a list of exceptions that can also be 'returned' from a
> subprogram? here's an example using of what i'm driving at (hopefully
> it's self explanatory) -
>
>   function Blah return Boolean
>     or exception Some_Exception;

What about exceptions raised by a called subprogram *called by* this
function? How about those that are raised within a rendezvous? What if said
exception isn't visible in the package specification where this declaration
has to be placed? How is the compiler to know that I even *want* an exception
handled? Do you want every unit that calls Put_Line to spit out warnings
about missing explicit handlers for use_error and mode_error?

No thank you!

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Future Ada language revisions?

[dewarr]

In article <6vdbcg$p9c$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> In article <KxPqMDAonPG2EwCX@dowie-cs.demon.co.uk>,
>   Martin Dowie <martin@dowie-cs.demon.co.uk> wrote:
> > Would it be feasible to extend the specification for subprograms to
> > include a list of exceptions that can also be 'returned' from a
> > subprogram? here's an example using of what i'm driving at (hopefully
> > it's self explanatory) -
> >
> >   function Blah return Boolean
> >     or exception Some_Exception;
>
> What about exceptions raised by a called subprogram *called by* this
> function? How about those that are raised within a rendezvous? What if said
> exception isn't visible in the package specification where this declaration
> has to be placed? How is the compiler to know that I even *want* an exception
> handled? Do you want every unit that calls Put_Line to spit out warnings
> about missing explicit handlers for use_error and mode_error?


Right exactly. So that observation is the *starting* point for trying to
design a reasonable facility. Obviously the first thought that all exceptions
should be mentioned is quite wrong. So now the question becomes, can we find
some other form of expression that is still useful, without being a useless
pain in the neck.

Various partial solutions have been suggested, but none proved satisfactory.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Future Ada language revisions?

[Martin Dowie]

In article <6vdg8g$16g$1@nnrp1.dejanews.com>, dewarr@my-dejanews.com
writes
>> What about exceptions raised by a called subprogram *called by* this
>> function? How about those that are raised within a rendezvous? What if said
>> exception isn't visible in the package specification where this declaration
>> has to be placed? How is the compiler to know that I even *want* an exception
>> handled? Do you want every unit that calls Put_Line to spit out warnings
>> about missing explicit handlers for use_error and mode_error?
>
>
>Right exactly. So that observation is the *starting* point for trying to
>design a reasonable facility. Obviously the first thought that all exceptions
>should be mentioned is quite wrong. So now the question becomes, can we find
>some other form of expression that is still useful, without being a useless
>pain in the neck.
>
>Various partial solutions have been suggested, but none proved satisfactory.

sorry, i didn't mean to imply that every exception had to be named in
the spec! the compile time check when compiling the subprogram body
could be limited to ensuring that those explicitly mentioned, are
explicitly raised (or something more sensible than i can come up with!).
for those that aren't named (e.g. out of scope) the extension could
include an 'or others' declaration to specify that other exceptions can
be raised.

> This is of course a very old idea, one that has been introduced in
> some languages, and was of course discussed in detail during the Ada
> 83 and Ada 95 designs. Again, it is clear what the arguments are on
> both sides of this issue, and I don't see anything new coming up.
> There was some sentiment for revisiting this during the Ada 95 design,
> but not much.

i tried hunting down anything about this topic in DN (excruciating!) and
managed to download a few 100Ks of the "preliminary findings of the Ada
9X Requirements Team " (all i could find) but there didn't seem to be
anything about this type of proposal.
-- 
Martin Dowie

Re: Future Ada language revisions?

[Martin Dowie]

In article <6vdbcg$p9c$1@nnrp1.dejanews.com>, dennison@telepath.com
writes
>What about exceptions raised by a called subprogram *called by* this
>function?

what indeed! if handled internal, no problem. if out of scope perhaps
the 'new spec' could be extended with something like an 'or others'
statement to indicate that an anonymous exception is possible.

> How about those that are raised within a rendezvous?

a case for expanding the 'entry' specification too?

> What if said
>exception isn't visible in the package specification where this declaration
>has to be placed?

see point 1

> How is the compiler to know that I even *want* an exception
>handled?

perhaps 'pragma surpress' or a compiler option could indicate that this
warning should not be given?

> Do you want every unit that calls Put_Line to spit out warnings
>about missing explicit handlers for use_error and mode_error?

if the 'or others' extension is provided then it wouldn't. if this
option was missing then your spec or body wouldn't be concidered
complete as either a) the spec does cater for the those errors; or b)
the subprogram body didn't handle them in some way. eithe way the
exceptions you can currently get would still occur at exactly the same
time as they do now, but the compiler would be able to provide a
stronger check.


so the general feeling seems to be that when deciding to handle
exceptional cases and to search out which subprograms raise which
exceptions, perhaps after the body has changed, or, if any are raised at
all, is best left to the programmer to do by hand (or buying another
tool to do this) rather than getting the compiler to do it as part of
the language. could someone please point me in the direction of a tool
that actually does this?!?! i certainly don't have the time to sit an
write one myself!

the other down side to me is in legacy code, which unless this sort of
thing were optional (rather defeating the purpose) would have to be
revisited and updated. still who knows what you might find then...
-- 
Martin Dowie

Re: Future Ada language revisions?

[dennison]

In article <KxPqMDAonPG2EwCX@dowie-cs.demon.co.uk>,
  Martin Dowie <martin@dowie-cs.demon.co.uk> wrote:
> In article <Pine.BSF.4.02A.9810042210470.18465-100000@shell5.ba.best.com
> >, Brian Rogoff <bpr@shell5.ba.best.com> writes
> >Since some of us don't have superfast connections, a suggestion to look on
> >the Deja News archives without some more info is rather unhelpful. A naive
> >search on obvious keywords turns up too much to scan.
>
> i've had a look through DN to see if this one has been done to death
> before but i can't find anything on it - if you know different please e-
> mail me!

Since this may become a FAQ, I'll post it instead.  There was a thread named
"functions with out parameters" in comp.lang.ada around the October 1995 era
with a horde of postings in it. I'm not good enough with dejanews to tell you
how to find it directly, but I found it with about 5 minutes of effort.

Happy reading!

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Future Ada language revisions?

[r_barton1]

In article <KxPqMDAonPG2EwCX@dowie-cs.demon.co.uk>,
  Martin Dowie <martin@dowie-cs.demon.co.uk> wrote:
>
> Would it be feasible to extend the specification for subprograms to
> include a list of exceptions that can also be 'returned' from a
> subprogram? here's an example using of what i'm driving at (hopefully
> it's self explanatory) -
>
>   function Blah return Boolean
>     or exception Some_Exception;

  Modula-3 does something pretty close to this. It's written as:
PROCEDURE P (param: ParamType) : ReturnType RAISES {Except1, Except2};

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Future Ada language revisions?

[Matthew Heaney]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> I'd be happy to oblige. If you remember the names and dates of the threads
> under which this topic has been argued (obviously *not* to death) I'll spend
> some time there looking. 

The thread was called "functions with out parameters", and took place
and Sep/Oct of 1995.  I just looked it up in DejaNews.

Re: Future Ada language revisions?

[Robert I. Eachus]

In article <Pine.BSF.4.02A.9810031123180.20730-100000@shell5.ba.best.com> Brian Rogoff <bpr@shell5.ba.best.com> writes:

  > Yes, this is nice, though I (perhaps wrongly) feel that this solution is
  > kind of heavy in terms of performance costs, especially if I want to have 
  > side-effecting functions on objects with value semantics.

  1) You can do that!  The compiler may warn you that you are being
naughty, but you knew that.  The idiom is to use an attribute
definition clause to overlay an internal object:

with Text_IO;
procedure Cheat_Test is
   Test_String: String := "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
   Junk: Character;

   function Cheat(X: in String) return Character is
     Temp: Character := X(X'First);
     Overlay: String(X'Range);
     for Overlay'Address use X'Address;
   begin
     Overlay(X'First) := 'Z';
     return Temp;
   end Cheat;

begin

   Text_IO.Put_Line(Test_String);
   Junk := Cheat(Test_String);
   Text_IO.Put_Line(Test_String);

end Cheat_Test;

   Using GNAT on a Sun this program produces no warnings and:

spectre% cheat_test
ABCDEFGHIJKLMNOPQRSTUVWXYZ
ZBCDEFGHIJKLMNOPQRSTUVWXYZ
spectre% 

   If you look at RM 13.3(13), we went to a great deal of effort to
write it to leave erroneousness to the programmer.  If you know what
you are doing, there is no problem:

   "If an Address is specified, it is the programmer's responsibility
to ensure that the address is valid; otherwise, program execution is
erroneous."

  > Eh? READERS will look at the interface to the function and see an out mode 
  > parameter, so they'll only be surprised if they don't read the spec.
  > "Against stupidity the gods themselves contend in vain", right?

  Correct, but irrelevant.  If the style in Ada is that functional
notation means that--in spite of the realities above--the effect of a
function on its parameters is benign, then a function which does
violence to its parameters will always be unexpected.

  > I see "distributed cost" has become overloaded now ;-). I think if a shop 
  > had a rule of "no access mode" or no "_Type" in type names or whatever
  > there is also a similar cost, but I don't think that means that should be 
  > language rules enforcing restrictions here.

  No, in Ada design it has always been used to mean a "feature" which
makes things more difficult even if it is not used.  If you use the
above approach, there is no distributed cost--you take the
responsibility for what happens if the argument is a constant, and any
compiler optimizer will know that an address clause is bad juju--the
hardware may even play with the value.

--

					Robert I. Eachus

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

Re: Future Ada language revisions?

[Brian Rogoff]

On 6 Oct 1998, Robert I. Eachus wrote:
> In article <Pine.BSF.4.02A.9810031123180.20730-100000@shell5.ba.best.com> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> 
>   > Yes, this is nice, though I (perhaps wrongly) feel that this solution is
>   > kind of heavy in terms of performance costs, especially if I want to have 
>   > side-effecting functions on objects with value semantics.
> 
>   1) You can do that!  The compiler may warn you that you are being
> naughty, but you knew that.  The idiom is to use an attribute
> definition clause to overlay an internal object:
> 
> with Text_IO;
> procedure Cheat_Test is
>    Test_String: String := "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
>    Junk: Character;
> 
>    function Cheat(X: in String) return Character is
>      Temp: Character := X(X'First);
>      Overlay: String(X'Range);
>      for Overlay'Address use X'Address;
>    begin
>      Overlay(X'First) := 'Z';
>      return Temp;
>    end Cheat;
> 
> begin
> 
>    Text_IO.Put_Line(Test_String);
>    Junk := Cheat(Test_String);
>    Text_IO.Put_Line(Test_String);
> 
> end Cheat_Test;

Very nice! Kind of naughty IMO, but still very nice. I never thought about
this approach, thanks for bringing it to my attention. 

>   > Eh? READERS will look at the interface to the function and see an out mode 
>   > parameter, so they'll only be surprised if they don't read the spec.
>   > "Against stupidity the gods themselves contend in vain", right?
> 
>   Correct, but irrelevant.  If the style in Ada is that functional
> notation means that--in spite of the realities above--the effect of a
> function on its parameters is benign, then a function which does
> violence to its parameters will always be unexpected.

Sure, but I was assuming an Ada with out-mode functions, in which that
assumption would no longer be true. I think we're talking about slightly
different things. 

> ... snip some stuff about "distributed costs" ...
> 
>   No, in Ada design it has always been used to mean a "feature" which
> makes things more difficult even if it is not used. 

I defer to your definition, for obvious reasons :-). I took it as meaning
an actual speed or space penalty imposed for a feature which isn't used in
a program; I see its meaning was actually much broader.

-- Brian

Re: Future Ada language revisions?

[dewarr]

In article <EACHUS.98Oct6183832@spectre.mitre.org>,
  eachus@spectre.mitre.org (Robert I. Eachus) wrote:
> In article <Pine.BSF.4.02A.9810031123180.20730-100000@shell5.ba.best.com>
Brian Rogoff <bpr@shell5.ba.best.com> writes:
>
>   > Yes, this is nice, though I (perhaps wrongly) feel that this solution is
>   > kind of heavy in terms of performance costs, especially if I want to have
>   > side-effecting functions on objects with value semantics.
>
>   1) You can do that!  The compiler may warn you that you are being
> naughty, but you knew that.  The idiom is to use an attribute
> definition clause to overlay an internal object:

In GNAT, we prefer to use 'Unrestricted_Access for this trick, because (a) it
retains the strong typing of the pointers, without going through addresses
and (b) it points up a possible implementation dependence more clearly than
using 'Address!










>
> with Text_IO;
> procedure Cheat_Test is
>    Test_String: String := "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
>    Junk: Character;
>
>    function Cheat(X: in String) return Character is
>      Temp: Character := X(X'First);
>      Overlay: String(X'Range);
>      for Overlay'Address use X'Address;
>    begin
>      Overlay(X'First) := 'Z';
>      return Temp;
>    end Cheat;
>
> begin
>
>    Text_IO.Put_Line(Test_String);
>    Junk := Cheat(Test_String);
>    Text_IO.Put_Line(Test_String);
>
> end Cheat_Test;
>
>    Using GNAT on a Sun this program produces no warnings and:
>
> spectre% cheat_test
> ABCDEFGHIJKLMNOPQRSTUVWXYZ
> ZBCDEFGHIJKLMNOPQRSTUVWXYZ
> spectre%
>
>    If you look at RM 13.3(13), we went to a great deal of effort to
> write it to leave erroneousness to the programmer.  If you know what
> you are doing, there is no problem:
>
>    "If an Address is specified, it is the programmer's responsibility
> to ensure that the address is valid; otherwise, program execution is
> erroneous."
>
>   > Eh? READERS will look at the interface to the function and see an out
mode
>   > parameter, so they'll only be surprised if they don't read the spec.
>   > "Against stupidity the gods themselves contend in vain", right?
>
>   Correct, but irrelevant.  If the style in Ada is that functional
> notation means that--in spite of the realities above--the effect of a
> function on its parameters is benign, then a function which does
> violence to its parameters will always be unexpected.
>
>   > I see "distributed cost" has become overloaded now ;-). I think if a shop
>   > had a rule of "no access mode" or no "_Type" in type names or whatever
>   > there is also a similar cost, but I don't think that means that should be
>   > language rules enforcing restrictions here.
>
>   No, in Ada design it has always been used to mean a "feature" which
> makes things more difficult even if it is not used.  If you use the
> above approach, there is no distributed cost--you take the
> responsibility for what happens if the argument is a constant, and any
> compiler optimizer will know that an address clause is bad juju--the
> hardware may even play with the value.
>
> --
>
> 					Robert I. Eachus
>
> with Standard_Disclaimer;
> use  Standard_Disclaimer;
> function Message (Text: in Clever_Ideas) return Better_Ideas is...
>

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Future Ada language revisions?

[Matthew Heaney]

"Thomas G. McWilliams" <tgm@netcom.com> writes:

> bpr5549@my-dejanews.com wrote:
> : PS: In case anyone is wondering, my main peeve is the restriction on out mode
> : function parameters, which I just don't understand, even when I'm trying to
> : open minded. I have yet to hear a good defense of this restriction, so if
> : anyone has one, I'm all ears, errr, eyes.
> 
> For an enlightening discussion of this issue, see Bertrand Meyer's 
> Object Oriented Software Construction, 2nd ed. (ISBN 0-13-629155-4),
> chapter 23.1.

There's also a discussion of this issue in Section 7.7, Routines, in
Meyer's other book Introduction to the Theory of Programming Languages.

Re: Future Ada language revisions?

[dennison]

Ok, here's a couple of omissions I'm curious about. How come task and
controlled types can't be tagged? It would sure be nice to be able to extend
them.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Future Ada language revisions?

[Pat Rogers]

dennison@telepath.com wrote in message
<6vj4sb$m3o$1@nnrp1.dejanews.com>...
>Ok, here's a couple of omissions I'm curious about. How come task
and
>controlled types can't be tagged? It would sure be nice to be able
to extend
>them.


A nasty little problem.  Have a look at Burns' and Wellings' book
"Concurrency In Ada".

-- pat

Patrick Rogers
progers@acm.org

Re: Future Ada language revisions?

[Brian Rogoff]

On Thu, 8 Oct 1998 dennison@telepath.com wrote:

> Ok, here's a couple of omissions I'm curious about. How come task and
> controlled types can't be tagged? It would sure be nice to be able to extend
> them.
> 
> --
> T.E.D.

Look up "inheritance anomaly" (on Alta Vista +"inheritance anomaly"
+"object oriented") for more info than you want. Synchronization is not so 
easily inherited.  

-- Brian

Re: Future Ada language revisions?

[dennison]

In article <Pine.BSF.4.02A.9810081500220.3133-100000@shell5.ba.best.com>,
  Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> On Thu, 8 Oct 1998 dennison@telepath.com wrote:
>
> > Ok, here's a couple of omissions I'm curious about. How come task and
> > controlled types can't be tagged? It would sure be nice to be able to extend
> > them.
> Look up "inheritance anomaly" (on Alta Vista +"inheritance anomaly"
> +"object oriented") for more info than you want. Synchronization is not so
> easily inherited.

Wow. You're absolutely right. Thanks.

I'm kinda suprised I haven't stumbled across this before in my graduate
studies.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Future Ada language revisions?

[Robert A Duff]

dennison@telepath.com writes:

> Ok, here's a couple of omissions I'm curious about. How come task and
> controlled types can't be tagged? It would sure be nice to be able to extend
> them.

Good question.  We considered that during the 9X design, but eventually
gave up.  Too many details to worry about getting right.  For example,
if you override an entry, what does that mean?  Can it change the
barrier condition, and if so, what happens when somebody dispatchingly
calls the parent entry?

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Future Ada language revisions?

[Van Snyder]

The reason that internal procedures can't be used for actual arguments seems
to revolve around the possibility that their "addresses" might be copied,
because when they appear as formal arguments they're "access to procedure"
with no additional restrictions.  Right?

Could we have another annotation for access formal arguments that prohibits
using them for anything other than actual arguments, and dereferencing them?
Say, "limited"?  This would loosen up the restrictions on actual arguments
that are procedures substantially.

-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

Re: Future Ada language revisions?

[Robert A Duff]

vsnyder@vanpcjpl.nasa.gov (Van Snyder) writes:

> The reason that internal procedures can't be used for actual arguments seems
> to revolve around the possibility that their "addresses" might be copied,
> because when they appear as formal arguments they're "access to procedure"
> with no additional restrictions.  Right?

Right.

> Could we have another annotation for access formal arguments that prohibits
> using them for anything other than actual arguments, and dereferencing them?
> Say, "limited"?

The Ada 9X team proposed exactly that.  As an alternative, we also
proposed a set of rules that would allow copying, but not to a
more-global place.  Both of these proposals were rejected, primarily on
the grounds that they are hard to implement if the compiler uses a
"display" to implement a procedure's environment, rather than a "static
link".

I think it was a mistake.  I liked the "limited" idea best.  It matches
Pascal's semantics for passing procedures as parameters.  This is the
only case I can think of where Ada is less powerful than Pascal.

>...This would loosen up the restrictions on actual arguments
> that are procedures substantially.

Well, you would normally use one or the other.  There are really two
separate features here:

1. Call-backs.  The caller passes in a procedure that lives pretty-much
forever, and the callee can save it away in some global data structure.
This is supported by Ada 95.  It is often used in interfacing to things
like windowing systems.

2. Downward closures.  The caller passes in a possibly-local procedure,
and the caller is *not* allowed to save it in a global data structure.
This is not directly supported by Ada 95, although there are two
workarounds: (1) pass the procedure to a generic, and (2) pass a pointer
to a tagged type, where you have overridden the "do it" operation, and
the tagged type contains the procedure's environment.

Note that C supports 1, but not 2 (since C doesn't support nesting at
all, much less passing nested procedures as parameters).  Note also that
gcc supports both 1 and 2.  Interestingly, gcc uses neither of the
approaches I mentioned (displays or static links).  Instead, it uses a
"trampoline" mechanism, which involves writing machine code into the
stack, and passing around pointers to that machine code.  Self-modifying
code!  Also the gcc extension is unsafe, in that it allows dangling
pointers-to-functions.  The two Ada 9X proposals I mentioned above were
safe -- the "limited" proposal prevented copying of
pointers-to-procedures at compile time, and the other one checked at run
time that any copying could not create dangling pointers.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Future Ada language revisions?

[Brian Rogoff]

On Thu, 22 Oct 1998, Robert A Duff wrote:
> vsnyder@vanpcjpl.nasa.gov (Van Snyder) writes:
> 
> > The reason that internal procedures can't be used for actual arguments seems
> > to revolve around the possibility that their "addresses" might be copied,
> > because when they appear as formal arguments they're "access to procedure"
> > with no additional restrictions.  Right?
> 
> Right.
> 
> > Could we have another annotation for access formal arguments that prohibits
> > using them for anything other than actual arguments, and dereferencing them?
> > Say, "limited"?
> 
> The Ada 9X team proposed exactly that.  As an alternative, we also
> proposed a set of rules that would allow copying, but not to a
> more-global place.  Both of these proposals were rejected, primarily on
> the grounds that they are hard to implement if the compiler uses a
> "display" to implement a procedure's environment, rather than a "static
> link".
> 
> I think it was a mistake.  I liked the "limited" idea best.  It matches
> Pascal's semantics for passing procedures as parameters.  This is the
> only case I can think of where Ada is less powerful than Pascal.

I take it that you've changed your mind then, since you were the author
of the "limited access to subprogram" proposal, and at the end of that 
proposal you had recommended that it not be adopted. What changed your
mind?

I have mixed feelings; on one hand I *really* wish that Ada had this
feature, on the other I think that penalizing implementors who used
displays wouldn't have been such a good idea. If there is a future
enhanced Ada, this is one of those things that I hope makes it in there,
so I hope all implementors are at least looking at it now so the argument
of "too much change in too little time" no longer applies.

-- Brian

Re: Future Ada language revisions?

[Robert I. Eachus]

In Bob Duff wrote:

   > The Ada 9X team proposed exactly that.  As an alternative, we also
   > proposed a set of rules that would allow copying, but not to a
   > more-global place.  Both of these proposals were rejected, primarily on
   > the grounds that they are hard to implement if the compiler uses a
   > "display" to implement a procedure's environment, rather than a "static
   > link".

   > I think it was a mistake.  I liked the "limited" idea best.  It matches
   > Pascal's semantics for passing procedures as parameters.  This is the
   > only case I can think of where Ada is less powerful than Pascal.

   I think it should have been added too, but I didn't fight it at the
time because, as Jean-Pierre Rosen demonstrated, the generic
"workaround" is exactly equivalent.  Incidently, once I understood
this, I talked to someone from R&R Software who confirmed that their
compiler (which used displays) had the necessary code "in there"
becuase there was one ACVC test that broke if they didn't save and
restore displays.

   However, I think it is now time to consider providing a better
syntax, in particular the limited keyword.  Using generic
instantiation to provide downward closures may just require a few
extra lines of code, but the mental effort required to use it is much
too high.  In fact, it has always amazed me how difficult it is for
most Ada programmers to understand WHY generic instantiation occurs at
run-time.  Generic instantiatiation is really a process for saving a
snapshot of a (dynamic) context.  In a language like Algol 68 it would
be obvious which generic formal parameters were snapshotting the
current value, and which parts were really imaging the reference to
the parameter.  In Ada you can go either way for just about anything,
but the syntax doesn't make it obvious that this is occuring:

   "In an instance, a formal_object_declaration of mode in declares a
new stand-alone constant object whose initialization expression is the
actual, whereas a formal_object_declaration of mode in out declares a
view whose properties are identical to those of the actual." RM 12.3(10)

   So in:

with Text_IO; use Text_IO;
procedure Gen_Test is
  type String_Pointer is access String;
  generic
    Foo: in String;
    Bar: in out String;
    Foobar: in out String_Pointer;
  function Test return String;
  function Test return String is
  begin return Foo & Bar & Foobar.all; end Test;
  X: String_Pointer := new String'("ABCD");
  function Test1 is new Test(X.all,X.all,X);
begin 
  X.all := "EFGH";
  X := new String'("IJKL");
  Put_Line(Test1);
end Gen_Test;

   Foo is a snapshot of the current value of X.  Bar is a reference to whatever
object X currently points to, and Foobar is a view of X.  So the
program prints:

spectre% gen_test
ABCDEFGHIJKL

   (You don't access types to get this effect, I just used them to
make it clear that the in out parameter is keeping a view of the old
X.all in Foo not a copy of the value of X, and this is different from
the view of X that is passed to Foobar.)

--

					Robert I. Eachus

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

Re: Future Ada language revisions?

[Robert A Duff]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> I take it that you've changed your mind then, since you were the author
> of the "limited access to subprogram" proposal, and at the end of that 
> proposal you had recommended that it not be adopted. What changed your
> mind?

I dunno.  I guess at the time I was mainly worried about gaining the
concensus needed to standardize Ada 9X, and that required that we not
place too much burden on those implementations that had already chosen
the display approach for Ada 83.  From a purely technical point of view,
I have always thought that Ada 9X should allow passing nested procedures
as parameters to unnested procedures.  The two workarounds I know of
(using generics, and making an explicit closure using tagged types)
are somewhat ugly, IMHO.

I suppose I won't be truly satisfied until I can pass an unnamed block
(written in line) as a parameter, like I can in Smalltalk.  Sigh.

GNAT supports the 'Unrestricted_Access attribute, which can be used to
pass nested procedures.  Unfortunately, this attribute allows dangling
pointers.  I would much prefer one of the two proposals I mentioned
before, since they gave the same power, but with no dangling pointers
(compile-time-checked for the limited access-to-subp idea, and run-time
checked for the other one).

> I have mixed feelings; on one hand I *really* wish that Ada had this
> feature, on the other I think that penalizing implementors who used
> displays wouldn't have been such a good idea. If there is a future
> enhanced Ada, this is one of those things that I hope makes it in there,
> so I hope all implementors are at least looking at it now so the argument
> of "too much change in too little time" no longer applies.

GNAT uses the "trampoline" mechanism, and I think most other Ada 95
compilers use the static link mechanism, both of which easily support
downward closures.  Of course, even compilers that choose to use
displays can support downward closures; it's just a bit more
complicated.  I've used Pascal compilers that used closures, and fully
supported Pascal's procedures-as-parameters feature.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Future Ada language revisions?

[Brian Rogoff]

On Thu, 29 Oct 1998, Robert A Duff wrote:
> ... snip ...
> 
> I suppose I won't be truly satisfied until I can pass an unnamed block
> (written in line) as a parameter, like I can in Smalltalk.  Sigh.

Well, I have similar tastes, if we substitute ML for Smalltalk above.
However, since Ada syntax is a bit heavy, in that you'd need to type
arguments to your anonymous subprogram, use "begin...end;", etc., I don't
think there would be that much advantage to unnamed blocks in Ada; you
might as well just declare local named functions. 

I think there would be a real win in having some restricted type-inference
or automatic instantiation of generic subprograms, as in C++, but I doubt
*that* will ever happen either. 

So, now I'm wondering, as I did in my original post, if there are
mechanisms in place to get some of the smaller changes (downward closures, 
access constant parameters, and such) into Ada.

-- Brian