From: Brian Rogoff <bpr@shell5.ba.best.com>
Subject: Re: Idea for Ada 200x: Arguments that are procedures
Date: 1998/07/03
Date: 1998-07-03T00:00:00+00:00 [thread overview]
Message-ID: <Pine.BSF.3.96.980703105626.24708B-100000@shell5.ba.best.com> (raw)
In-Reply-To: swhalenEvI788.43x@netcom.com
On Fri, 3 Jul 1998, Steve Whalen wrote:
> Van,
>
> I'd vote for "fixing" this deficiency in the Ada200x version of the
> language. The way you suggested using "limited" for procedures as
> parameters seems like a reasonable syntax to me.
>
> Compared to GNAT's Unrestricted_Access attribute I would MUCH prefer
> your approach because (to me) such attributes are way too powerful
> (and implementation dependant).
I think you would agree with Robert Duff, who floated the limited access
type for procedure parameters a while ago, in
http://sw-eng.falls-church.va.us/AdaIC/standards/95lsn/LSN1083.GeneralAccess
as I pointed out in my reply to Van Snyder. If you really want to go
digging, I've appended a post from Norman Cohen on this topic; you can use
the thread title to trace the entire thread under DejaNews.
> This is about the only language issue I've seen raised on
> comp.lang.ada that actually causes me problems in *my* "real world".
> It seems silly to keep requiring workarounds for a deceased
> implementation.
I think more than one implementation uses displays, and there is also the
issue of problems caused in implementations with shared generics.
FWIW, I started out with your view (omission of downward closures was an
egregious mistake) and ended up agreeing that it was the only right thing
to do for Ada *95*. However, I have wanted this in code I write and I
think the workarounds are really clumsy and impair readability. I'd rather
that generics were never shared, if the interaction of the two features
is problematic!
I guess the thing to do is to ask your Ada compiler vendor to provide this
feature in some form, so that even if we have N variants for N vendors at
least the economic argument will be weakened.
-- Brian
From ncohen@watson.ibm.com Thu Jul 11 10:13:24 1996
From: ncohen@watson.ibm.com (Norman H. Cohen)
Newsgroups: comp.lang.ada
Subject: Re: Q: access to subprogram
Date: 11 Jul 1996 00:49:51 GMT
Organization: IBM T.J. Watson Research Center
Distribution: world
Reply-To: ncohen@watson.ibm.com
NNTP-Posting-Host: rios8.watson.ibm.com
In article <ROGOFF.96Jul8155205@sccm.Stanford.EDU>,
rogoff@sccm.Stanford.EDU
(Brian Rogoff) writes:
|> ncohen@watson.ibm.com (Norman H. Cohen) writes:
...
|> Bill Taylor had made what I considered an
|> irrefutable case for downward closures, showing how much easier it
would
|> be to write iterators if downward closures were allowed. It came
down to
|> a conflict between the interests of Ada programmers and the
interests of
|> a minority of Ada implementors, and in this case the interests of
the few
|> implementors using displays prevailed.)
|>
|> Could you summarize or provide a reference to Bill Taylor's work? Does
it
|> answer the objection that downward closures impose an inefficiency on
programs
|> that don't use them?
Bill Taylor's contribution was part of an ongoing discussion in the form
of comments sent to the Mapping/Revision Team during the design of Ada 9X.
All of these comments from June 1992 on are publicly available in the
following directory:
ftp://sw-eng.falls-church.va.us/public/AdaIC/standards/95com/mrtcomments/
All the comments through April 1994 are in files with names of the form
YYMMmrt.zip, where YY and MM are the year and month the comment was
received. (Thus all comments from May 1993 are in 9305mrt.zip.) Starting
with May 1994, there are individual daily files, such as 94.0501 for all
comments received on May 1, 1994.
The discussion on downward closures and their impact on display
implementations included the following comments:
Date Comment ID Author My summary
April 29, 1993 93.2622.b Bill Taylor The initial message about
iterators mentioned above.
May 1, 1993 93-2628.b Robert Duff Says he likes the feature,
but Robert Dewar has
frightened WG9 members
about the cost, and the MRT
won't add downward closures
until someone convinces WG9
otherwise. Claims the size
of a display is not known
at compile time.
May 3, 1993 93-2634.a Norman Cohen Reply to Duff, asserting
that the size of a display
IS known at compile time.
Foreshadows an identical
exchange that will take
place on comp.lang.ada in
July 1996. :-)
May 3, 1993 93-2635.a Robert Duff Reply to Cohen. Size of a
display is not known at the
site of a call through a
pointer. Says he hates
arguing against a feature
he likes.
May 3, 1993 93-2637.a Randy Brukardt Reports that Janus/Ada uses
(RR Software) displays. Proposes a
workaround involving
unchecked conversion.
May 3, 1993 93-2638.a Robert Duff Reply to Brukardt, asking
him to explain workaround.
May 4, 1993 93-2644.a Antoine Bertier Reports that Alsys uses
(Alsys) displays for most of its
compilers.
May 4, 1993 93-2645.a Ted Baker Calls displays an
"anachronism", except on
register-poor machines.
May 4, 1993 93-2646.a Randy Brukardt Reply to Duff, explaining
his workaround and
conceding that it is not
portable to compilers that
do NOT use displays.
May 5, 1993 93-2647.a Brian Dobbing Also reports that Alsys
(Alsys) uses displays, states that
Alsys cannot afford any
more language changes with
such great impact on their
compilers, and states that
neither the display
approach nor the static
link approach is always
the right choice.
May 5, 1993 93-2651.a Bill Taylor Points out that Brukhardt's
proposed workaround does
not work when the pointed-
to procedures reference
data in surrounding scopes,
as they do in his iterators
example.
May 5, 1993 93-2655.a Robert Dewar Reply to Baker, defending
displays and asserting
that they can be quite
efficient.
May 5, 1993 93-2656.a Robert Eachus Experiments (with a
compiler that was altered
to send Eachus e-mail every
time code was generated for
a call on a nested
subprogram!) show that
calls on nested procedure
are rare, so the expense of
supporting this feature is
not justified.
May 6, 1993 93-2661.a Ted Baker Reply to Dewar, claiming
that downward closures were
important for the kind of
applications that justified
ANY inclusion of 'Access
for nested subprograms in
Ada 9X, and worth the cost;
but admitting that Brian
Dobbing's economic argument
might be the deciding
consideration.
May 11, 1993 93-2676.a Randy Brukardt Reply to Baker.
May 11, 1993 93-2676.b Randy Brukardt States that downward
closures impose a
distributed overhead on all
uses of generics when
generics are implemented by
shared code for all
instances, as in Janus/Ada.
January 14, 1994 94-3669.a Bjorn Kallberg An eloquent case for the
importance of downward
closures, pointing out that
their omission would create
the only case in which Ada
is not a functional
superset of Pascal.
February 15, 1994 LSN 1083 Robert Duff A dispassionate analysis
of all sides of the issue,
explaining why the MRT
decided not to include
downward closures in Ada 9X.
March 4, 1994 94-3985.a David Tombs An empassioned plea to
reconsider this decision.
--
Norman H. Cohen ncohen@watson.ibm.com
next prev parent reply other threads:[~1998-07-03 0:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-07-03 0:00 Idea for Ada 200x: Arguments that are procedures Van Snyder
1998-07-02 0:00 ` Brian Rogoff
1998-07-02 0:00 ` Robert Dewar
1998-07-03 0:00 ` Charles Hixson
1998-07-04 0:00 ` Larry Kilgallen
1998-07-06 0:00 ` Dr Richard A. O'Keefe
1998-07-03 0:00 ` Steve Whalen
1998-07-03 0:00 ` Brian Rogoff [this message]
1998-07-03 0:00 ` Steve Whalen
1998-07-04 0:00 ` Larry Kilgallen
1998-07-07 0:00 ` Robert I. Eachus
1998-07-07 0:00 ` Brian Rogoff
1998-07-03 0:00 ` Robert Dewar
1998-07-03 0:00 ` Brian Rogoff
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox