Ada language revision

Ada language revision

[Stanley Roger Allen, AdaDude]

	Well, time is pressing on and the review has begun for
analyzing anew changes that should be made to the Ada language.
Through a variety of sources, a number of not-very-bright statements
have come to our attention concerning "improvements" to the Ada
language that should be "easily incorporated" into the the 1994
revision.

	A lot of these people are certainly driven by nothing more
sinister than the "feature junkie" complex (cf. Dijkstra's Turing
Award lecture, 1972).  What makes a lot of these suggestions dangerous
is more that just a lack of appreciation for the language design and
structure.  We are also seeing a deep misapprehension of what the
goals of the Ada program are to begin with.  We are not trying to
create a research engine, or a summation of the latest programming
language paradigms, or a fault-tolerant distributed operating system, 
etc.  Those who are to make decisions about the future of the Ada 
language need discover what exactly we *are* trying to create.

	To give a one-line answer to this question would be to defeat
the purpose of this missive.  I am proposing that anyone who wishes to
make suggestions for improving the language, adding new features,
deleting language elements, or change the organization of the language
(even in ways that may seem trivial) should first do their homework.
There is a specific body of knowledge that you should possess when
approaching this topic.  Have you read the Steelman document and/or
its predecessors?  (Do you even know what the Steelman document is?) 
Have you read the "Rationale for the Design of the Ada Language"?  Do
you understand the type system of the Ada language?  Have you been
looking through the megabytes of textual commentaries that have been
accumulating since the beginning of the Ada program?  Does the LRM
still confuse you? 

	Perhaps there should be a "required reading list" and
"qualifying exams" for Ada language maintainers.  Perhaps there is; I
don't know.  Jean Ichbiah says that many languages previous to Ada
followed a three-step process for their creation: "shoot, aim, think".
Ada is among the languages that reversed the process, which is one of
the reasons for the great success it has become.  In maintaining the 
language, thinking should also come first.  Part of that thinking is 
going back to previous thinking and absorbing it.  Any other path is 
pure hubris.

					Stanley Allen
					allen@star.stanford.edu

Re: Ada language revision

[Wilmer Rivers]

[Do not eat this line under penalty of law.]

   This is a somewhat edited version of a message I sent by E-MAIL
to SALLEN%LOCK.SPAN@STAR.STANFORD.EDU (Stanley Roger Allen) in response
to message <8811141420.AA01652@ajpo.sei.cmu.edu>.  I shall not re-post
any excerpts from his original article, but as I interpreted it he
wanted to make 2 major complaints : (1) many or most changes that are
being suggested to Ada are not adequately thought out before they are
proposed, and (2) any changes that would deviate from the original
intent of Ada's goals should be eschewed.  Although the first point
may well be correct, I should like to take mild exception to the
second one, and I am posting these remarks publicly in order to en-
courage further discussion of this issue via this newsgroup.

   The article seems to suggest that any changes to Ada should be re-
stricted to refining the grand design that was set into motion long
ago, rather than accommodating any changes that would involve a new
direction for the language.  You can certainly build a strong case for
that.  ("Here's what Ada is supposed to do, and if you want to do some-
thing else, then come up with a different language, just don't call it
Ada.")  However, proponents of more drastic changes also have a point.
Suggesting that all changes should be confined to moving from Steelman
to TitaniumMan (or ReinforcedConcreteMan, or whatever) may be too rigid.
(No pun intended, but actually the concept of rigidity is appropriate
here.)  This concept of minimal evolution reminds me of the member of
the board of directors of the Metro system here in D.C. who recently
dismissed commuters' pleas for more farecard machines in certain subway
stations by noting that introducing more machines would "interfere with
the aesthetic purity of the design" of the stations.  He's right, but
(1) commuting patterns change; (2) the farecard machines have turned out
to be less reliable than they were in the original "aesthetically pure"
design; and (3) assuming you don't want the subway stations to serve as
museums or cathedrals, what counts is not so much their architectural
splendor as how easy they make it to catch a train.  So it is with pro-
gramming languages.  (1) Programming has changed in recent years [and of
course Ada is partly responsible for that]; (2) some features of Ada
haven't *really* worked so well as the designers had intended; and (3)
whether or not the LRM is the best thought-out set of rules and specifi-
cations since the U.S. constitution is less important than whether pro-
grammers can use Ada to get their job done.  Apparently, some of them
think they can't, so they want some changes that aren't consistent with
what Steelman (and maybe even Strawman) thought Ada was supposed to do.
Is that so terrible?  The dogmatic attitude of "If it's inconsistent
with all the great effort that we've put into Ada, then it's heresy and
we musn't do it" may not be the best one for revising the language.
Sometimes it's necessary (or at least desirable) to make fundamental
changes ab initio, even if they are in conflict with what you originally
had in mind.  For example, if someone wants a language that does some of
the things that were cited in the original posting as contrary to the
goals of Ada, then is it so unthinkable for him to suggest that the new
language he needs should nevertheless still be Ada?  Saying "Nope, that
definitely isn't what Ada is all about," really just begs the issue.  An
appropriate response would be, "Maybe Ada wasn't about that originally,
but why shouldn't it be about that now?"  You shouldn't automatically
legislate against progress by saying that the goal of the language is
cast in stone (or straw, wood, tin, iron, steel, titanium, reinforced
concrete, ...).

   Well, that's my own mild flame.  In summary, I am arguing that langu-
age design purists shouldn't be allowed to use the obvious necessity for
considering very carefully any proposed changes to the LRM as justifi-
cation for outlawing a priori any changes in the *intent* of the langu-
age itself.  As I said above, a strong case can in fact be made for that
attitude, but personally I don't think making the language's goals sac-
rosanct is in the best interest of the programming community.

			    Wilmer Rivers (rivers@beno.CSS.GOV)
			    Teledyne Geotech


[I suppose I should add the standard disclaimer stating that my own
views and those of my employers may differ, but actually I doubt that
the company cares very much about this issue one way or the other, and
they would probably perfer that I didn't spend any time caring about
it either.]

Re: Ada language revision

[William Thomas Wolfe,2847,]

   In view of the recent discussions re: appropriateness of revisions, I'm 
   hereby submitting the revisions I think appropriate for Ada 9X for general
   discussion and/or flamage:

      1) The assignment operator should be available for overloading
         as part of an ADT specification (i.e., a limited private type 
         which is enclosed within a (usually generic) package).  Currently, the
         closest we can come is to define an ASSIGN procedure.  Unfortunately,
         this is not consistent with the use of := for other object types, and
         worse yet, the ASSIGN procedure is not invoked during the evaluation of
         in parameters, making it impossible to achieve anything other than a
         shallow copy of a user-defined ADT which is used as a value parameter,
         the disastrous implications of which should be readily apparent.

      2) Similarly, there is no provision for defining the DESTROY procedure
         over an abstract data type such that UNCHECKED_DEALLOCATION is required
         to invoke it.  Again, we have inconsistency with the predefined 
         objects, and there are unfortunate implications for space efficiency.

      3) The rule that a limited private type cannot be a direct component of 
         another limited private type should be repealed.  This makes it hard
         to use one ADT as a building block in the construction of higher-level
         ADTs.  The standard workaround is to use an intervening pointer, with
         negative implications for time and space efficiency upon each access.

      4) It should be possible to overload generic packages with differing 
         generic parameter structures.  For example, suppose I have two
         generic linked list requirements: sometimes I need the ability to
         INPUT and OUTPUT the list to a file, and sometimes I don't.  If I
         can't overload the package with differing generic parameter structures,
         I'll have to include the procedures INPUT (LINKED_OBJECT) and 
         OUTPUT (LINKED_OBJECT) in every instantiation of a linked list;
         even if I have no intention of ever calling the INPUT and OUTPUT 
         procedures for this particular type of linked list.  Result: more work
         on my part to define unnecessary INPUT and OUTPUT procedures which will
         never be called, and possibly an unnecessarily large body of 
         instantiated code which contains code to handle procedures that I will
         never call. 

      5) The rule that functions must have only in parameters should be 
         repealed.  Data structures which are history-sensitive, such as tree
         structures which secretly keep a "current item" pointer in order to
         speed up groups of requests which all involve the same item, will
         subtly change as a result of calls to the Boolean function ITEM_EXISTS;
         this forces us to use an intervening pointer in order to implement
         such a function with only in parameters, and suffer the resulting time 
         and space penalties upon each and every access to the structure. 
 
      6) Exceptions should be capable of being passed as parameters.  Currently,
         it is not possible to write a function ASSERT which takes a Boolean
         expression and an exception, and raises the exception if the expression
         turns out to be false.  The workaround is to enclose every call to 
         ASSERT in a local block, with an exception handler specifying that
         the desired exception should be raised in response to the exception
         Assertion_Failed.

      7) Arrays should be initializable via named association.  It is very 
         tedious to write out 37 Falses simply in order to initialize the
         38th element of a Boolean array to True before I can finally specify 
         that all other elements of the array are False. 

       8) Record types should have the attributes NUMBER_OF_FIELDS, 
          FIELD_NAME (Field Number), and FIELD_TYPE (Field Number).  Not having
          these attributes prevents the construction of a generic report
          generator which will accept a record type as a generic parameter,
          and provide a function GENERATE_REPORT which, given a file of those
          records, will automatically generate a report in which the column
          headers are labeled with the field names (with spaces substituted for
          underscores), and automatically laid out across the page with the
          appropriate spacing between columns.  Assuming the availability of an
          appropriate system call, the name of the source file could even be 
          used as the report title.   But without being able to read that record
          descriptor, the implementation of such a generic report generator is
          very hard to achieve in any reasonably clean way. 


   Well, there they are.   Now where was that fireproof outfit...?


                                                   Bill Wolfe

                                             wtwolfe@hubcap.clemson.edu

Re: Ada language revision

[Stephe Leake]

In reference to Stanley Allen's comments in message
<8811141420.AA01652@ajpo.sei.cmu.edu>, I agree completely.  However,
he did not give adequate references for me to go out and buy the
reading material he suggested, and I have the impression they are not
available in my corner bookstore. It seems to me that this forum is an
excelent place for us novices to propose changes, giving him and
others more knowledgeble a chance to spread some education. So, I am
responding to Wolfe's list of changes with my own opinions, and I hope
others do the same.

Note to future suggestors: please include the LRM section and
paragraph when suggesting a change to a specific rule.

In article <3563@hubcap.UUCP> billwolf@hubcap.clemson.edu (William
Thomas Wolfe,2847,) writes:

	 1) The assignment operator should be available for
	    overloading as part of an ADT specification...

Hear Hear! Right on! (and other assorted agreeable noises)

	 2) Similarly, there is no provision for defining the DESTROY
	    procedure over an abstract data type such that
	    UNCHECKED_DEALLOCATION is required to invoke it...

This needs clarification; what does a DESTROY procedure do that
UNCHECKED_DEALLOCATION doesn't?

	 3) The rule that a limited private type cannot be a direct
	    component of another limited private type should be
	    repealed...

What rule are you refering to? I have a Commented_IO package which
defines a limited private FILE_TYPE, which includes as a component
Text_IO.FILE_TYPE (also limited private). It compiles just fine.

	 4) It should be possible to overload generic packages with
	    differing generic parameter structures....

This sounds good. Currently, a better work-around is to have two
packages, both using a common lists sub-package.

	 5) The rule that functions must have only in parameters
	    should be repealed....

I have often wanted to do this myself, but I usually (not always) find
that a procedure ends up making more sense. In general, I find that
the restrictions Ada imposes usually lead to better code. (See my
personal gripes below for exceptions to this.)

	 6) Exceptions should be capable of being passed as
	    parameters....

What's wrong with a small if statement? Personally, I would like to
have an EXCEPTION_IO that would let me print the name of an exception.

	 7) Arrays should be initializable via named association...

According to LRM 4.3.2 (3), they are.

	 8) Record types should have the attributes NUMBER_OF_FIELDS,
	    FIELD_NAME (Field Number), and FIELD_TYPE (Field Number)....

This sounds good, but I suspect it would be difficult to handle
[limited] private types and variant records. Does NUMBER_OF_FIELDS
return the number for the current discriminant, or something else? You
can't expect the compiler to do _everything_ for you!

Here are a couple restrictions that I would like relaxed:

	9) LRM 10.2 (5) states that the simple names of all subunits
that have the same ancestor library unit must be distinct. This means
I can have tasks named ROBOT.PLANNER.MAIN_TASK and
ROBOT.TRAJECTORY.MAIN_TASK, but only if the task bodies are not
separately compiled; then the simple name MAIN_TASK must be changed.
This seems contrary to the intent of Ada naming. If the rule where
changed to "the simple names of all subunits that have the same
_parent_ unit must be distinct", things would be nicer.

	10) LRM 4.3.2 (6) says if I have an array aggregate with named
association and an others clause, it must be an actual parameter or
function result; ie, _not_ an object initalization. This prevents me
from declaring an object with an anonymous array type and initializing
it; which is exactly the correct thing to do for a state table in a
lexical analyzer. I do not want a named array type, since I do not
want any other state tables; I only need one.

	11) LRM 8.5 (2) lists the things that can be renamed. I would
like to add enumerals. I like to rename some things from a package
(usually with the same name) to make them visible, instead of "use"ing
the whole package; this makes it clear I am _not_ using the whole
package. Currently, to make an enumeral visible, I must declare a
derived type, which means I have to use explicit type conversions.

Well, that's probably enough for now.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

Re: Ada language revision

[Steve Tynor]

In article <733@marvin.cme-durer.ARPA> leake@cme-durer.ARPA (Stephe Leake) writes:
>What's wrong with a small if statement? Personally, I would like to
>have an EXCEPTION_IO that would let me print the name of an exception.

Here, here, etc.  I once worked with the Telesoft (?) compiler on an Eclipse
that had a package allowing you to find out what the current exception was.
It helped out immensely during debugging:

    ...
    exception
       when others =>
	   text_io.put_line ("Opps! exception " & CURRENT_EXCEPTION'IMAGE &
			      " in procedure XXX.");
	   raise;
    end XXX;

Unfortunately, I now use VAX Ada and Alsys, so I can't do this.  

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Progress means replacing something wrong with something more subtly wrong.
                     
    Steve Tynor
    Georgia Tech Research Institute
    tynor@gitpyr.gatech.edu

Re: Ada language revision

[Ron Guilmette]

In article <733@marvin.cme-durer.ARPA> leake@cme-durer.ARPA (Stephe Leake) writes:
>..Personally, I would like to
>have an EXCEPTION_IO that would let me print the name of an exception.

Howza 'bout allowing:

	MY_EXCEPTION'IMAGE

-- 
Ron Guilmette
National SemiConductor, 1135 Kern Ave. M/S 7C-266; Sunnyvale, CA 94086
Internet: rfg@nsc.nsc.com   or   amdahl!nsc!rfg@ames.arc.nasa.gov
Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg

Re: Ada language revision

[William Thomas Wolfe,2847,]

From article <733@marvin.cme-durer.ARPA>, by leake@cme-durer.ARPA (Stephe Leake):
> In article <3563@hubcap.UUCP> billwolf@hubcap.clemson.edu (William
> Thomas Wolfe,2847,) writes:
> 
> 	 2) Similarly, there is no provision for defining the DESTROY
> 	    procedure over an abstract data type such that
> 	    UNCHECKED_DEALLOCATION is required to invoke it...
> 
> This needs clarification; what does a DESTROY procedure do that
> UNCHECKED_DEALLOCATION doesn't?

      Consider an ADT which contains pointers to substructures.
      A user declares an access type pointing to an instance of your
      ADT, and uses UNCHECKED_DEALLOCATION to destroy that instance
      after finishing with it.  UNCHECKED_DEALLOCATION will not 
      recursively chase down and free up what might constitute 
      over 99% of the space occupied by the ADT.   Similarly, if your
      ADT uses another ADT in its implememtation, your DESTROY procedure
      will include a call to the DESTROY procedure of the sub-ADT,
      but UNCHECKED_DEALLOCATION will remain oblivious to the method
      which must be used to properly destroy the sub-ADT.

> 	 8) Record types should have the attributes NUMBER_OF_FIELDS,
> 	    FIELD_NAME (Field Number), and FIELD_TYPE (Field Number)....
> 
> This sounds good, but I suspect it would be difficult to handle
> [limited] private types and variant records. Does NUMBER_OF_FIELDS
> return the number for the current discriminant, or something else? 

      Generally, what I would like to do is be able to read everything
      about that record type that is contained in the type's description.
      We have attributes that allow us to know everything about an integer
      type, fixed type, float type, etc; we can tell what the bounds 
      of an array are, but we can't find out much of anything about records.
      ('FIRST_BIT, which tells us how far into the first storage unit 
      occupied by the record we have to go in order to find the first bit 
      of the record, and 'POSITION, which tells us how far past the first 
      storage unit occupied by the record we have to go in order to find 
      the specified component of the record, are the only attributes 
      pertaining specifically to the record)   Also, FIELD_TYPE was
      an error; I meant to say FIELD (Field Number), which would allow
      me to loop through the fields of a given record without knowing
      the names of the fields at compile time.
 
> Here are a couple restrictions that I would like relaxed:
> 
> 	10) LRM 4.3.2 (6) says if I have an array aggregate with named
> association and an others clause, it must be an actual parameter or
> function result; 

      This is what I meant about initializing arrays.  Thanks!

Re: Ada language revision

[Stephe Leake]

In article <3656@hubcap.UUCP> billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) writes:

	 Consider an ADT which contains pointers to substructures.
	 A user declares an access type pointing to an instance of your
	 ADT, and uses UNCHECKED_DEALLOCATION to destroy that instance
	 after finishing with it.  UNCHECKED_DEALLOCATION will not 
	 recursively chase down and free up what might constitute 
	 over 99% of the space occupied by the ADT.   Similarly, if your
	 ADT uses another ADT in its implememtation, your DESTROY procedure
	 will include a call to the DESTROY procedure of the sub-ADT,
	 but UNCHECKED_DEALLOCATION will remain oblivious to the method
	 which must be used to properly destroy the sub-ADT.

I see. Currently, the ADT author must provide a Destroy procedure, and
hope that users of the ADT call it as needed. So it would be nice if
the compiler would enforce this. This doesn't sound to bad; we just
need to add a generic parameter to UNCHECKED_DEALLOCATION (LRM 13.10.1):

generic
    type OBJECT is limited private;
    type NAME is access OBJECT;
    with procedure DESTROY (Y : in OBJECT) is <>;
procedure UNCHECKED_DEALLOCATION (X : in out NAME);

With a default definition of DESTROY declared in Standard, defining
UNCHECKED_DEALLOCATION this way would not break any current Ada
program that uses it. There is still a slight problem; if the
appropriate DESTROY procedure is not visible at the time of
instantiation, we lose.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

Re: Ada language revision

[Ron Guilmette]

In article <3563@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes:
>
>   In view of the recent discussions re: appropriateness of revisions, I'm 
>   hereby submitting the revisions I think appropriate for Ada 9X for general
>   discussion and/or flamage:

Well, since somebody else started this ball rolling, I guess it might be safe
to do a little Ada bashing and launch off into a jihad of my own.

>      3) The rule that a limited private type cannot be a direct component of 
>         another limited private type should be repealed...

I have some problems with limited private types too.  Specifically, if such
types are really only accessable through a "limited" functional interface,
then why shouldn't we be able to declare such types in the public part of
a package and then defer the full declaration until the package body?  Why?
Well, I'll tell you why.  It seems to me that it is because of Ada's silly
specification of parameter passing conventions, where the implementor gets
to decide if he/she wants to pass any given scalar type object using
value-result.  This should also be repealed.  All parameters should be passed
by reference.  Period.  Then programmers would never have to guess about
implementation semantics and the compiler would never have to know what the
real implementation of a given limited private type was until the package
body was being compiled.

>      6) Exceptions should be capable of being passed as parameters.

I agree completely, but I would go much further and say that any category of
run-time (not compile-time) entity which can be represented by an identifier
(including exceptions and record field names, but not generic units) should
be "passable" as parameters.  Further, I think that *all* entities which
can be designated by an identifier (including exceptions, record field names,
and generic units) should be "passable" as generic (instantiation) parameters.

>      7) Arrays should be initializable via named association.

If Ada only had "classes" (a la Simula & C++) we could trash a whole lot of
specialized convoluted syntax and semantics having to do with initialization
and constructors also.

>       8) Record types should have the attributes NUMBER_OF_FIELDS, 
>          FIELD_NAME (Field Number), and FIELD_TYPE (Field Number).  Not having
>          these attributes prevents the construction of a generic report
>          generator which will accept a record type as a generic parameter,
>          and provide a function GENERATE_REPORT which, given a file of those
>          records, will automatically generate a report in which the column
>          headers are labeled with the field names...

OK, but how do you number the fields in a variant record?

-- 
Ron Guilmette
National SemiConductor, 1135 Kern Ave. M/S 7C-266; Sunnyvale, CA 94086
Internet: rfg@nsc.nsc.com   or   amdahl!nsc!rfg@ames.arc.nasa.gov
Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfg

Re: Ada language revision

[Stephe Leake]

In article <7882@nsc.nsc.com> rfg@nsc.nsc.com (Ron Guilmette) writes
(among other things):

>   I have some problems with limited private types too.  Specifically, if such
>   types are really only accessable through a "limited" functional interface,
>   then why shouldn't we be able to declare such types in the public part of
>   a package and then defer the full declaration until the package body?

What would this gain? Do you have any specific examples where this
would have improved the readability or functionality of an
application? Let's not just suggest changes because they "sound good".
Let's put some thought into it, including concrete examples.

   ... I would go much further and say that any category of
   run-time (not compile-time) entity which can be represented by an identifier
   (including exceptions and record field names, but not generic units) should
   be "passable" as parameters.  Further, I think that *all* entities which
   can be designated by an identifier (including exceptions, record field names,
   and generic units) should be "passable" as generic (instantiation) parameters.

Again, why? What would we gain, what would we lose?

   >      7) Arrays should be initializable via named association.

According to LRM 4.3.2 (3), they are. (Doesn't anybody read the manual?)

   If Ada only had "classes" (a la Simula & C++) we could trash a whole lot of
   specialized convoluted syntax and semantics having to do with initialization
   and constructors also.

What convoluted syntax? There is _one_ construct; the aggregate. It is
a _very_ powerful construct, and I consider it one of the best
features of Ada. Perhaps you could give us an example of how Simula or
C++ would do something that an aggregate can't do.

Let's try to keep the discussion concrete, so we can come up with real
suggestions to the review commitee, not just a letter to Santa Claus.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

Re: Ada language revision

[Dennis Doubleday]

In article <739@marvin.cme-durer.ARPA> leake@cme-durer.ARPA (Stephe Leake) writes:
>In article <7882@nsc.nsc.com> rfg@nsc.nsc.com (Ron Guilmette) writes
>>   I have some problems with limited private types too.  Specifically, if such
>>   types are really only accessable through a "limited" functional interface,
>>   then why shouldn't we be able to declare such types in the public part of
>>   a package and then defer the full declaration until the package body?
>
>What would this gain? Do you have any specific examples where this
>would have improved the readability or functionality of an
>application? Let's not just suggest changes because they "sound good".
>Let's put some thought into it, including concrete examples.

There is a VERY good reason for it, if you're at all concerned about
portability.  The declaration of a limited private type is an
IMPLEMENTATION decision.  It doesn't belong in the specification, it
belongs in the body.  If I'm trying to export some abstract data type
from a package, I'd like to have a specification that could be moved,
intact, from one machine to another.  Only the body should need
changing.  However, since I must give the full declaration of the type
in the private part of the spec instead of in the body, it may be that
I will have to change that part of the spec if I want to port the
package to a machine which requires a different implementation of the
type. 

Why does your post sound so hostile?  How do you know that Ron hasn't
put any thought into his suggested changes?

Dennis Doubleday                       dd@sei.cmu.edu
Software Engineering Institute         (412)268-5873
Carnegie Mellon University
Pittsburgh, PA 15213

Re: Ada language revision

[Steve Tynor]

In article <7796@aw.sei.cmu.edu> dd@sei.cmu.edu (Dennis Doubleday) writes:
>
>In article <739@marvin.cme-durer.ARPA> leake@cme-durer.ARPA (Stephe Leake) writes:
>>In article <7882@nsc.nsc.com> rfg@nsc.nsc.com (Ron Guilmette) writes
>>>   then why shouldn't we be able to declare such types in the public part of
>>>   a package and then defer the full declaration until the package body?

>>What would this gain? Do you have any specific examples where this

>portability.  The declaration of a limited private type is an
>IMPLEMENTATION decision.  It doesn't belong in the specification, it
>belongs in the body.  If I'm trying to export some abstract data type

Here, here. I think the Modula 2 compromise of requiring 'opaque' types to be
pointers is adequate. This way there is enough information supplied in the
specification for code generation in client packages, but the implementation 
details are not broadcast.  Sure, the code may be slightly less efficient
(since you're forced to use a pointer), but I've rarely run into a situation
where I've wanted to create an ADT where a pointer (ok, ok, 'access
type') wasn't the natural representation anyway...

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Progress means replacing something wrong with something more subtly wrong.
                     
    Steve Tynor
    Georgia Tech Research Institute
    tynor@gitpyr.gatech.edu

Re: Ada language revision

[Richard Pattis]

In article <6843@pyr.gatech.EDU>, tynor@pyr.gatech.EDU (Steve Tynor) writes:
> Here, here. I think the Modula 2 compromise of requiring 'opaque' types to be
> pointers is adequate. This way there is enough information supplied in the
> specification for code generation in client packages, but the implementation 
> details are not broadcast.  Sure, the code may be slightly less efficient
> (since you're forced to use a pointer), but I've rarely run into a situation
> where I've wanted to create an ADT where a pointer (ok, ok, 'access
> type') wasn't the natural representation anyway...
> 
>     Steve Tynor
>     Georgia Tech Research Institute
>     tynor@gitpyr.gatech.edu

  As someone who has taught Modula-2 in introductory courses for 4 years (4
times a year) I've voted with my feet and switched to Ada.  Private types are
one reason.  While opaque types do allow for easier portability, and a link
time decision of which imlementation to use, there are some drawbacks.

  For teaching, the concept of a protected object is important and is easy to
motivate.  But by requiring students to learn about dynamic allocation and
deallocation to implement such a type, Modula-2 makes it very hard for me to
intoduce this concept early.  Also, the newest M-2 standard (at least that I
have seen) proposes to restrict opaque types to pointer only, disallowing me
to define an opaque cursor that in one instance must be implement by integer
that refers to some location in an array.

  Also, there are all sorts of problems with initialization/finalization in
Modula-2's opaque types.  Try writing a complex number type and functional
versions of the standard arithmetic operators, including garbage collection.

  Finally, if I recall my Ada correctly, one can use access types in Ada to
implement private types that are equivalent to Modula-2's opaque types, at
least with regard to portability problems residing in package bodies.  I
believe Cohen's book had a discussion of this use of access types in the
private parts of packages.

Re: Ada language revision

[Robert Firth]

In article <6843@pyr.gatech.EDU> tynor@pyr.UUCP (Steve Tynor) writes:
>In article <7796@aw.sei.cmu.edu> dd@sei.cmu.edu (Dennis Doubleday) writes:
>>  The declaration of a limited private type is an
>>IMPLEMENTATION decision.  It doesn't belong in the specification, it
>>belongs in the body.  If I'm trying to export some abstract data type
>
>Here, here. I think the Modula 2 compromise of requiring 'opaque' types to be
>pointers is adequate. This way there is enough information supplied in the
>specification for code generation in client packages, but the implementation 
>details are not broadcast.

And Ada provides exactly that facility, in almost exactly the same way.
See [RM 3.8.1(3)].

Sigh.

[On the other hand, whoever
invented that BLOODY STUPID
rule about appended material
having to be at least as long
as quoted material was A PEA
BRAINED FORNICATING MORON.
]

limited private types

[Stephe Leake]

In article <7796@aw.sei.cmu.edu> dd@sei.cmu.edu (Dennis Doubleday) writes:

   In article <739@marvin.cme-durer.ARPA> leake@cme-durer.ARPA (Stephe Leake) writes:
   >In article <7882@nsc.nsc.com> rfg@nsc.nsc.com (Ron Guilmette) writes
   >>   I have some problems with limited private types too.  Specifically, if such
   >>   types are really only accessable through a "limited" functional interface,
   >>   then why shouldn't we be able to declare such types in the public part of
   >>   a package and then defer the full declaration until the package body?
   >
   >What would this gain? Do you have any specific examples where this
   >would have improved the readability or functionality of an
   >application? Let's not just suggest changes because they "sound good".
   >Let's put some thought into it, including concrete examples.

   There is a VERY good reason for it, if you're at all concerned about
   portability.  The declaration of a limited private type is an
   IMPLEMENTATION decision.  It doesn't belong in the specification, it
   belongs in the body.  If I'm trying to export some abstract data type
   from a package, I'd like to have a specification that could be moved,
   intact, from one machine to another.  Only the body should need
   changing.  However, since I must give the full declaration of the type
   in the private part of the spec instead of in the body, it may be that
   I will have to change that part of the spec if I want to port the
   package to a machine which requires a different implementation of the
   type. 

This is true, but it doesn't allow separate compilation; you cannot
compile bodies that use the limited private type untill the size of
that type is known. One way around this is to declare the limited
private type to be a pointer to a type whose full declaration is
defered to the body of the package:

package My_Private_Type

type Hidden is limited private;
...
private

type Real_Hidden;
type Hidden is access Real_Hidden;

end My_Private_Type;

Admittedly, access types are not the best in all situations, but this
does enhance portability.

   >Why does your post sound so hostile?  How do you know that Ron hasn't
   >put any thought into his suggested changes?

I didn't mean to sound hostile, I was simply frustrated with the lack
of information. If Ron was concerned with the issue you raised, he
should have said so explicitly. Believing someone has good reasons,
and knowing what those reasons are, are two different things.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

Re: limited private types

[Ron Guilmette]

In article <748@marvin.cme-durer.ARPA> leake@cme-durer.ARPA (Stephe Leake) writes:
>
>In article <7796@aw.sei.cmu.edu> dd@sei.cmu.edu (Dennis Doubleday) writes:
>
>   In article <739@marvin.cme-durer.ARPA> leake@cme-durer.ARPA (Stephe Leake) writes:
>   >In article <7882@nsc.nsc.com> rfg@nsc.nsc.com (Ron Guilmette) writes
>   >>   I have some problems with limited private types too.  Specifically, if such
>   >>   types are really only accessable through a "limited" functional interface,
>   >>   then why shouldn't we be able to declare such types in the public part of
>   >>   a package and then defer the full declaration until the package body?

>This is true, but it doesn't allow separate compilation; you cannot
>compile bodies that use the limited private type untill the size of
>that type is known. One way around this is to declare the limited
>private type to be a pointer to a type whose full declaration is
>defered to the body of the package:

OK. Now there no >'s in from so this is me (Ron Guilmette) talking again.
Sorry for all the >>>>'s above, but I just couldn't pass up the chance to
totally confuse the issue by quoting quotes of comments on quotes of
comments of what I said way back when.  :-)

Anyway, I *do* know about the special tricky Ada rule which allows you
to defer a full type definition until the corresponding package body
(if that type is only used in the package spec to help define pointer
types).

>Admittedly, access types are not the best in all situations, but this
>does enhance portability.
>
>   >Why does your post sound so hostile?  How do you know that Ron hasn't
>   >put any thought into his suggested changes?
>
>I didn't mean to sound hostile, I was simply frustrated with the lack
>of information. If Ron was concerned with the issue you raised, he
>should have said so explicitly. Believing someone has good reasons,
>and knowing what those reasons are, are two different things.

Also, although I didn't explicitly say it, I did mean to make a point
about the "separation of concerns" between a spec and a body, which
Ada generally supports very well.  (I don't think that "portability"
per se is quite the issue that I'm concerned about).  Anyway, don't
worry about apparent hostility.  I'm generally pretty thick skinned
(and some would say thick-headed).

The point I wanted to make was this.  If you look at all the things that
you are allow to do with an object of a limited private type (as given
in LRM 7.4.2 and 7.4.4) in the scope where the given type is *actually*
limited (i.e. within the *whole* scope of the type name but *not* in the
same scope as the full type definition for the type) then you find out
that there isn't very much you can do with (or to) an object of a limited
private type.

Basically, about the only thing you can do with such objects is to pass
them as actual parameters to subprograms.  Obviously, if you do this, then
for each such subprogram, the actual *definition* of the given subprogram
must be compiled only *after* the full type declaration has already been
compiled.

"Why?" you ask.  Well it is because of the fact that Ada insists that
scalars must always be passed by value-result.  Non-scalars may be passed
any old way (e.g. by reference).

Since any given Ada compiler must generate code to copy scalar actual
parameters into their corresponding formals, and since the most efficient
way to do this is to know ahead of time the total size (e.g. 32 bits)
of the given parameter, and since the full type definition of a given
limited private type (object) may sometime be scalar, The Ada designers
made the only wise choice available to them, i.e. to insist that the
full type declaration for any arbitrary limited private type be given
in the same compilation (unit) as the (original) limited type declaration.

This rule insures that the compiler will always know the actual size
of all formal parameters at least before the end of the current compilation.
Thus, the "scalar-by-value-result" rule (see LRM 6.2{6}) may be obeyed
while parameter passing is kept efficient.

What I was proposing was the suspension of the "scalar-by-value-result"
rule, and a substitution (in LRM 6.2{6,7,8}) of language which would
instead insist that *all* parameters, regardless of type, be passed
by reference.

This would yield two benefits:

1)  We could put our (corresponding) full type declarations for our
    limited types into packages bodies where they seem to belong (and
    where they require fewer re-compilations when changed) and

2)  we could make the language simpler by having one single (standard?)
    type of parameter passing *semantics* for *all* types of objects.

Another (dubious?) benefit of my "pass-by-reference-only" rule would be
that it would make all the ex-FORTRAN people feel comfortable (and would
probably simplify mixed-language interfacing where Ada & FORTRAN were 
concerned).  Note that FORTRAN has *always* used the "pass-by-reference-only"
rule.

Note that the programmer himself can easily achieve the semantics of
"pass-by-value-result" if he/she is given the base semantics of "pass-
by-reference" but not vise versa!  To get value-result semantics given
a base of by-reference semantics, all one has to do is make one's own
temporary copies (of the variable(s) involved) within the subprogram in
question.

Re: limited private types

[Paul Stachour]

In article <8197@nsc.nsc.com> rfg@nsc.nsc.com.UUCP (Ron Guilmette) writes:
>
>What I was proposing was the suspension of the "scalar-by-value-result"
>rule, and a substitution (in LRM 6.2{6,7,8}) of language which would
>instead insist that *all* parameters, regardless of type, be passed
>by reference.
>
>This would yield two benefits:
>
>1)  We could put our (corresponding) full type declarations for our
>    limited types into packages bodies where they seem to belong (and
>    where they require fewer re-compilations when changed) and
>
>2)  we could make the language simpler by having one single (standard?)
>    type of parameter passing *semantics* for *all* types of objects.
>
>Another (dubious?) benefit of my "pass-by-reference-only" rule would be
>that it would make all the ex-FORTRAN people feel comfortable (and would
>probably simplify mixed-language interfacing where Ada & FORTRAN were 
>concerned).  Note that FORTRAN has *always* used the "pass-by-reference-only"
>rule.

  I have programmed in a variety of languages over the 25 years
(wow, it is hard to belive, but it is 25 years)
that I have been programming.  In that time, I've learned a LOT
about parameter-passing.
  I learned about Multics and good PL/I implementatations only
after I already had 15 years of work, like 10 years ago.  One of
the things I discovered was how efficent its parameter-passing was,
as well as being flexible.  PL/I likes to pass everything by
reference, and that's good (I'll say why in a moment).  Multics uses
2n+1 (or n+1) words for each parameter-list.  nwords for arg-pointers,
nwords for arg-desicriptors (iff needed), and 1-word for the arg-count,
discriptor-count, and whether args or discriptors exist at all.
Functions get an extra-arg (the result) created in the caller.
This means, in general, that one can often use an arg-list fully
prepared at compilation-time (sometime modified at execurion-time),
and just pass one-pointer to a calling routine. Long and well-thought
Ada-style paramater-lists (including defaults) can be done very
well using this mechanism.
  But the real advantage of reference semantics comes when you
have data-structures being accessed by multiple tasks, as we are
now starting to do in Ada, and Multics has done well for more
than the 10 years I've known it.  You pass an argument to a
subroutine, it changes it, and the change is immediately, instantly,
visable to all routines.  And without the messiness of passing
explicit pointers.  Now, languages that don't allow reference
semantics at all are really ugly.  C's sometimes-you-must (stucts)
and sometimes-you-mussent (arrays) are confusing.  Ada's consistancy
(at least for composites) is refreshing after the last two years
I've been fighting C to get jobs done.
  However, I don't believe that Ada REQUIRES reference semantics
for composites, it merely allows them.  And in these days of
distributed programs, it is questionable what kind of efficiency
one can get with reference semantics over many machines.
[The questions are similar to those of efficiency in virtual-machines
20 years ago; questions which were well-settled by the measurements
in Multics showing that IO actually got cut in half in virtual-memory
+ sharing paradym over thant of physical-memory + explicit IO.
Too bad most hardware/software groupings we call computer systems
still can't seem to do good virtual-memory management, but that's
another discussion.]
  I'm for reference semantics.  They are natural, efficient, and
don't force this explicit-pointer "junk".  But let's make sure
what we can do with them in today's environment before we ask
Ada 9X to mandate them.

Re: Reference Semantics

[William Thomas Wolfe,2847,]

From article <10322@umn-cs.CS.UMN.EDU>, by stachour@umn-cs.CS.UMN.EDU (Paul Stachour):
>   I'm for reference semantics.  They are natural, efficient, and
> don't force this explicit-pointer "junk".  But let's make sure
> what we can do with them in today's environment before we ask
> Ada 9X to mandate them.

    OK, we're sold on the benefits of reference semantics.  Let's assume
    that "in out" parameters are always passed by reference.  Now why
    should it be impossible for the programmer to choose pass-by-value,
    as in "in" and "out" modes?  

    (BTW, a good compiler could eliminate the copy in many cases by
    proving to itself that there is no attempt to modify the "in" parameter 
    and therefore just passing it by reference anyway.  Such compiler analysis 
    is necessary because programmers frequently want to use "in" mode 
    just to assure the procedure's users that the parameter will not 
    be modified.  But sometimes the local copy is modified, and the
    copy then becomes something that would have had to be done anyway.
    To force an explicit copy would then reduce program readability.) 

Re: Reference Semantics

[Paul Stachour]

In article <3739@hubcap.UUCP> billwolf@hubcap.clemson.edu writes:
>From article <10322@umn-cs.CS.UMN.EDU>, by stachour@umn-cs.CS.UMN.EDU (Paul Stachour):
>>   I'm for reference semantics.  ...
>
>    OK, we're sold on the benefits of reference semantics.  Let's assume
>    that "in out" parameters are always passed by reference.  Now why
>    should it be impossible for the programmer to choose pass-by-value,
>    as in "in" and "out" modes?  
Guess I was not explicit enough.  Yes, if a programmer specifies
only "in" (no writing) or "out" (no reading), there is no need to force
reference (values are consistant throughout the "world") sematics.
But I don't equate "no writing" with "pass-by-copy-in" or "no reading"
with pass-by-copy-out (though, surely, that is one reasonable way to
implement it).  It's hard not to confuse the desired semantics
(always having the correct, current, value) with the mechansims
(pass-by-reference); I apologize if my meaning was not clear.
   ...Paul

Re: Reference Semantics, assignment overloading, etc.

[Ray Trent]

In the above article stachour@umn-cs.cs.umn.edu (Paul Stachour) writes:
>In article <3739@hubcap.UUCP> billwolf@hubcap.clemson.edu writes:
>>    OK, we're sold on the benefits of reference semantics.  Let's assume
>>    that "in out" parameters are always passed by reference.  Now why

Actually, :-), LRM 6.2(7, last sentence) states that such an assumption 
is either irrelevant or makes the program erroneous. :-)

>>    should it be impossible for the programmer to choose pass-by-value,
>>    as in "in" and "out" modes?  

Actually, I'd like the programmer to be always able to specify the method
used. (as s/he is likely to know better than the compiler which is
more efficient in some circumstances)

BTW, check the phrasing of LRM 6.2(especially 7&11). It implies to
me that pass by reference is only allowed for arrays, records and
task types (and only at the discretion of the compiler vender). Any
comments on this? I base my statement on LRM 6.2(7): (emphasis mine)
"[Arrays, records and tasks may be passed by copy], *as for scalar
types*. [...] Alternatively, an implementation may acheive these 
effects by reference...". This wording, combined with the qualification
"For parameters of array and record types" in LRM 6.2(11), leads me
to believe that pass-by-reference is verboten for scalar variables.
If this was not the intent, I would suggest a rewording.

But that aside, I wanted to mention something related to the 
assignment overloading discussion. To wit, many people have pointed
out that source level assignment semantics are not used in parameter
passing. I disagree. First, there are no source level assignment
semantics, as writing an ":=" is not allowed. :-) Assignment semantics
are defined only at the language level in Ada. Second, given this, 
I would argue that even if assignment semantics are not explicitly
called by parameter passing, the effects of Ada parameter passing
are indistinguishable from Ada assignment.

In an assignment, a value is copied to the variable and subtype
checked. In "in" or "in out" parameter passing, a value is 
copied and subtype checked. The effect is exactly as though 
the programmer had typed "<FormalParam> := <ActualParam>" (followed
at return by "<ActualParam> := <FormalParam>" for "in out"s). For
"out" parameters, an ":=" must have been called explicitly. Since
they are equivilent, and since ":=" is not overloadable, I'm not
surprised the LRM didn't state this explicitly...it would be
redundant.

The arguments that assignment should be overloadable seem to revolve 
around the complaint (the valid complaint) that Ada type semantics are 
inadequate. I.e. that the idea of type constraints needs expanding.
(to include user defined constraint checks, which *could* be implemented
as overloaded assignment) Overloading assignment *would* require
that the overloaded assignment be used in parameter passing, but
that is not a significant departure from the current parameter
passing scheme...only from the current assignment scheme.

Now, of course, the problem with this is that the programmer might
"override" type checking with hir assignment operation. I would claim
that writing an assignment operation is the same as providing an
expanded ADT for the type. If the programmer writes an assignment
operator, s/he is *defining* a new semantics for the type. Of course,
this makes proving correctness harder. *Of course*. So does tasking, 
so does unchecked programming, so do generics, so do many other
useful things. 

Now, admittedly, it might be better to allow user-defined constraint
checks for ADTs than to allow overloaded assignment. I suspect that
there would be even more complaints about this suggestion than about
assignment overloading. (one reason for this is that it would require
a whole new syntax) Of course, doing it this way would require that 
type checking be allowed to modify the result and not raise a constraint
error if it felt like it...get's pretty evil, huh? In many ways, 
asking for overloaded assignment is a kludge. It doesn't really solve
the problems with Ada type semantics, it just provides a workaround.

-- 
"Our little lives get complicated
 It's a simple thing
 Simple as a flower
 And that's a complicated thing"                     ../ray\..

Re: Reference Semantics, assignment

[ryer]

/* Written  8:07 pm  Dec  6, 1988 by trent@sri-unix.UUCP in inmet:comp.lang.ada */
/* ---------- "Re: Reference Semantics, assignment" ---------- */
In the above article stachour@umn-cs.cs.umn.edu (Paul Stachour) writes:
>In article <3739@hubcap.UUCP> billwolf@hubcap.clemson.edu writes:
>>    OK, we're sold on the benefits of reference semantics.  Let's assume
>>    that "in out" parameters are always passed by reference.  Now why

Actually, :-), LRM 6.2(7, last sentence) states that such an assumption 
is either irrelevant or makes the program erroneous. :-)

>>    should it be impossible for the programmer to choose pass-by-value,
>>    as in "in" and "out" modes?  

Actually, I'd like the programmer to be always able to specify the method
used. (as s/he is likely to know better than the compiler which is
more efficient in some circumstances)

BTW, check the phrasing of LRM 6.2(especially 7&11). It implies to
me that pass by reference is only allowed for arrays, records and
task types (and only at the discretion of the compiler vender). Any
comments on this? I base my statement on LRM 6.2(7): (emphasis mine)
"[Arrays, records and tasks may be passed by copy], *as for scalar
types*. [...] Alternatively, an implementation may acheive these 
effects by reference...". This wording, combined with the qualification
"For parameters of array and record types" in LRM 6.2(11), leads me
to believe that pass-by-reference is verboten for scalar variables.
If this was not the intent, I would suggest a rewording.

But that aside, I wanted to mention something related to the 
assignment overloading discussion. To wit, many people have pointed
out that source level assignment semantics are not used in parameter
passing. I disagree. First, there are no source level assignment
semantics, as writing an ":=" is not allowed. :-) Assignment semantics
are defined only at the language level in Ada. Second, given this, 
I would argue that even if assignment semantics are not explicitly
called by parameter passing, the effects of Ada parameter passing
are indistinguishable from Ada assignment.

In an assignment, a value is copied to the variable and subtype
checked. In "in" or "in out" parameter passing, a value is 
copied and subtype checked. The effect is exactly as though 
the programmer had typed "<FormalParam> := <ActualParam>" (followed
at return by "<ActualParam> := <FormalParam>" for "in out"s). For
"out" parameters, an ":=" must have been called explicitly. Since
they are equivilent, and since ":=" is not overloadable, I'm not
surprised the LRM didn't state this explicitly...it would be
redundant.

The arguments that assignment should be overloadable seem to revolve 
around the complaint (the valid complaint) that Ada type semantics are 
inadequate. I.e. that the idea of type constraints needs expanding.
(to include user defined constraint checks, which *could* be implemented
as overloaded assignment) Overloading assignment *would* require
that the overloaded assignment be used in parameter passing, but
that is not a significant departure from the current parameter
passing scheme...only from the current assignment scheme.

Now, of course, the problem with this is that the programmer might
"override" type checking with hir assignment operation. I would claim
that writing an assignment operation is the same as providing an
expanded ADT for the type. If the programmer writes an assignment
operator, s/he is *defining* a new semantics for the type. Of course,
this makes proving correctness harder. *Of course*. So does tasking, 
so does unchecked programming, so do generics, so do many other
useful things. 

Now, admittedly, it might be better to allow user-defined constraint
checks for ADTs than to allow overloaded assignment. I suspect that
there would be even more complaints about this suggestion than about
assignment overloading. (one reason for this is that it would require
a whole new syntax) Of course, doing it this way would require that 
type checking be allowed to modify the result and not raise a constraint
error if it felt like it...get's pretty evil, huh? In many ways, 
asking for overloaded assignment is a kludge. It doesn't really solve
the problems with Ada type semantics, it just provides a workaround.

-- 
"Our little lives get complicated
 It's a simple thing
 Simple as a flower
 And that's a complicated thing"                     ../ray\..
/* End of text from inmet:comp.lang.ada */

Re: limited private types

[ryer]

I agree it would be nice to be able to defer specifying the details
of the private type until the body is compiled.  Also, the reason for
the present restriction is so that the compiler can know the size of
the type.  Implicitly generated heap objects would work ok (forcing all
passage of private types by reference).  HOWEVER:

Ada now provides the pointer-based semantics when the user explicitly codes
an access type.  It ALSO provides the more efficient direct allocation/access
when the user does not code a access type.   The language changes proposed 
would eliminate one option.  It is possible to build an Ada compiler which 
NEVER uses the heap or any sort of pointer to access ordinary objects of 
static sizes, and at least one is very careful of this.  This is important
to those who use Ada for realtime systems.  

Many actual private types in real programs turn out to be integers.  Passing
these by value makes a big difference in the performance of the generated
code.  (Often a procedure parameter is already in a register at the call
site, and some optimizers contrive to make it the appropriate one so the cost
for passing it is zero as compared to a store at the call site followed by
a load in the caller).  Some Ada applications are built for small machines
with restricted memory and modest throughput and have to meet timing constraints
that are very tight (e.g. 100 hertz).  

As we used to say in the Ada language design days, "any good compiler will
resolve this", in this case by only introducing an implicit access type when
the private type's definition is missing from the spec and otherwise generating
the same code as now.  I hope we've learned that compiler writers sometimes
take the easiest path and defer the optimal approach to some future release.
We've gone through years of performance problems with Ada because of compilers
that weren't optimal.  Efficient approaches were proposed for every language
feature when the language was being designed, and features were dropped it
nobody could come up with an efficient implementation.  It turns out that 
compilers aren't as good as the language designers contemplated even now.

There had been no mention of the impact on the generated code in this note
stream and I had to post this flame.  In the 9X cycle, we need to ask
not only whether an efficient implementation is feasible, but whether
it is likely to appear in most compilers within a reasonable time.

I "vote" strongly against the proposal that ALL parameters should be
passed by reference  -- that clearly would make Ada less efficient on
most machines however good the compilers are.

The slow acceptance of Ada has been due to performance problems in the
generated code and speed and reliability problems in the compilers, not
due to a lack of flexibility in dealing with private types or other features.
Lets not add complexity and reduce performance this time around.

Mike Ryer
Intermetrics, Inc.

Re: limited private types

[stt]

All Ada compilers already deal with "stack" objects
of size unknown at compile time (e.g. x : string(1..f(y));).
Some compilers do this more efficiently than others,
but the big advantage is that the compiler takes care
of freeing the associated storage when the object goes away.
When access types are used, it is always a challenge to
figure out how to ensure that the storage gets efficiently
reclaimed.  (This is one of the big reasons why
I believe user-defined "finalization" should be added into the language.)

Nevertheless, access types with a deferred incomplete designated
type are still used in complex systems, because they break
recompilation dependencies.  It seems like allowing the
deferral of any private type to a package body would be little or no
additional burden on compiler writers, and would provide
the same nice break in recompilation dependency when used.  
For non-discriminated types,
the size would be an elaboration-time constant.  For discriminated types,
the size would be determined by a function call (many
compilers already create size functions to save code space
for complex variant record size calculations).
However, it would be appropriate to require that the full
definition of the private type be a record type, so that
pass-by-reference semantics would be allowed.  

The syntax for such a deferred private record type might be:
     . . .
  private
      type Priv is record;
     . . .

I fully agree with the importance of pass-by-value semantics
for all scalars/access-values.  It is easy enough to wrap a scalar
into a record if pass-by-reference semantics are preferred for some
particular application.  The improved speed possibilities for pass-by-value
scalars far outweigh any abstraction disadvantage.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138

Re: limited private types

[Stephe Leake]

In article <8197@nsc.nsc.com> rfg@nsc.nsc.com (Ron Guilmette) writes:

   What I was proposing was the suspension of the "scalar-by-value-result"
   rule, and a substitution (in LRM 6.2{6,7,8}) of language which would
   instead insist that *all* parameters, regardless of type, be passed
   by reference.

   This would yield two benefits:

   1)  We could put our (corresponding) full type declarations for our
       limited types into packages bodies where they seem to belong (and
       where they require fewer re-compilations when changed) and

   2)  we could make the language simpler by having one single (standard?)
       type of parameter passing *semantics* for *all* types of objects.

This sounds reasonable, but will obviously have a performance impact
where lots of scalar parameter passing is going on (something I don't
do much - records are much more expressive than scalars). But since
the problem is really only with (limited) private types, how about
insisting only those must be passed by reference?

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

Re: Ada language revision

[stt]

"Official" revision requests for Ada will ultimately have
to be sent to "ada9x@ajpo.sei.cmu.edu" following
a detailed format similar to language comments
as specified in the back of the Ada LRM, but with
many more standard paragraphs, including
"!keywords", "!summary", "!specific requirement/solution criteria", etc.
The primary emphasis is to state *requirements* which are currently
felt to be unanswered by Ada, rather than specific solutions.
The official revision request format will probably be announced soon.

It's pretty easy to indulge in Ada bashing, or Fortran bashing,
or Pascal bashing, etc.  However, the ada9x effort will probably
be most responsive to carefully argued points.  The following
2 points by <billwolf@hubcap.UUCP> would be easier to understand
if they identified the LRM paragraph of the mentioned "rule".
As far as I know, no such rules exist.

>>  3) The rule that a limited private type cannot be a direct component of 
>>     another limited private type should be repealed.  

Perhaps the issue is that non-limited types may not have components
of limited types?  (I agree this is annoying, though defensible.)

>>  7) Arrays should be initializable via named association.  It is very 
>>     tedious to write out 37 Falses simply in order to initialize the
>>     38th element of a Boolean array to True before I can finally specify 
>>     that all other elements of the array are False. 

Named aggregates are legal to initialize arrays.  Perhaps the issue
is the use of "named" notation in conjunction with "others =>".
This is never permitted in places where implicit array subtype
conversion (aka "sliding") is legal because there is no way of knowing what
is the first element of the aggregate (it may be one of the named
elements, or it may be one of the "others").
To avoid this problem, a qualified expression may be used,
specifying the subtype of the array aggregate explicitly,
which implies the low and high bounds.

Generally I agree with the spirit, if not the details, of these
requests.  But to be effective, they must be as formally
and carefully stated as possible.

Tucker Taft   stt@inmet.inmet.com; ...!uunet!inmet!stt
Intermetrics, Inc.
Cambridge, MA  02138

Collective response to := messages

[Geoff Mendal]

I will respond briefly to some of the replies made to my original
assignment overloading message.  Lines with ">>" are from my original
message, lines with ">" are responses to my original message.  I am a
bit shocked that some people apparantly agree with me... I'm not used
to that sort of thing.

>Date: 23 Nov 88 22:57:59 GMT
>From: hubcap!billwolf@gatech.edu  (William Thomas Wolfe,2847,)
>Subject: Ada Language Change: Assignment Overloading
>
>> 1. Why simply restrict it to assignment?  Why not include membership,
>>    short-circuit control forms, indexing, selection, attributes, etc.?
>>    These are all basic operations....
>
>   First, assignment is a "fundamental" operation; except for attributes,
>   the other things you've suggested apply only to specific classes of
>   ADTs.  As for attributes, I think we could live without them if 
>   appropriate procedures and functions were defined over the predefined
>   ADTs; having attributes for predefined ADTs and functions for user-defined
>   ADTs is another inconsistency.  Procedures and functions are definitely
>   necessary; the attribute mechanism is not.

Wrong.  Membership, qualification, attributes, and explicit type conversion
are all "fundamental" operations defined for EVERY type.  To argue that
assignment is special requires more justification than "we can live without
X and Y is necessary".  Who can live without X?  I can most certainly live
without assignment overloading.  Does this mean that overloading assignment
is a good/bad idea?  Nonsense.  Rethink your argument.

>   Another reason is that assignment procedures need to be invoked as part
>   of the evaluation of a user-defined ADT which is passed by value.  No
>   similarly vital function is performed by the other operations suggested.

I don't understand this at all.  You are assuming pass by value for an
ADT?  Rediculous.  The LRM only states that scalars and access values
are passed by copy.  In general, for an ADT, you cannot assume pass by
value and if your program depends on it, your program will execute
erroneously.  Justifying a language change based on a set of programs
which are known to execute erroneously it itself an erroneous argument.
If an "assignment procedure needs to be invoked as part of the evaluation
of a user-defined ADT" then one can explicitly write the Ada code
necessary for this.  Default components for records provide a simple
solution here.  There are other solutions as well.  None of the solutions
REQUIRE assignment to be overloaded.

>   The argument that the operations listed (except assignment and attributes)
>   should be user-programmable with respect to user-defined ADTs is reasonable,
>   but clearly assignment is in a higher class of importance than the others.

I strongly disagree.  Assignment is assignment.  A relational operator
is a relational operator.  Are we going to change the language by
taking a popular vote of which operations are "higher class" than
others?  Such justification for a language change is rediculous.  So
far, I have seen no justification why assignment should be overloaded
and not other basic operations.  Consider usability, readability,
understandibility, etc.  These should drive the justification, not
someone's arbitrary "higher class" argument.  My argument is that
while readability might be increased, understandability will be
diminished and therefore we should reject the notion that overloading
assignment is a good idea.  The designers of Ada went out of their way
to make typing Ada programs more difficult/time-consuming so that
understanding them would be easier.  Any language change should not
compromise understandability for the sole gain of making programs
easier to type.

>Date: 23 Nov 88 19:13:34 GMT
>From: trent@unix.sri.com  (Ray Trent)
>Subject: Ada Language Change: Assignment Overloading
[some verbage deleted]
>
>This standard argument against allowing the overloading of the ":="
>operator ignores the fact the programmers may want *semantics*
>in their type declarations instead of just syntax. Types are not 
>static objects that can be completely defined at compile time,
>however much the designers of Ada want to think they are.
[fraction example deleted]
>
>The Ada apolgists would have us write the semantics for ensuring
>LCD form for the type Fraction into *each and every operator*
>that acts upon 2 items of this type, instead of having that 
>functionality in the assignment operator, where it belongs. The point 
>is, readable or not, ":=" should validly ensure the *semantics* of
>every type it is defined for, as well as the pure syntactical elemants.
[more fraction examples deleted]

First, assignment is NOT an operator.  It is a basic operation.
Operators are completely different in that they follow different
scope/visbility rules and are afforded some luxeries (overloading)
not currently available to basic operations.  I tried to make this
point clear in my original message but it is obvious that still not
everyone understands the difference.  Read the LRM and be enlighted.

Now, of course programmers want semantics in their type declarations
and I believe that Ada provides some of these semantics through
predefined behavior of basic operations and operators.  But I disagree
that having the complete semantics for a type defined in an
"assignment operator" is appropriate or even desired.  Assignment
already has a very well defined semantics.  Read the LRM.  So what is
the problem?  You don't like those semantics and you would prefer to
alter them?  Fine, but I fail to see why ":=" has to be the syntagma which
carries your favorite semantics (which may not be my favorite
semantics).

One of the examples that I deleted above was "A := B / C;"
where A, B, and C were of some ADT (Fraction).  If I understand the
argument for placing the semantics in assignment instead of having the
programmer define the semantics in each user-defined operation, then
how would the semantics of passing the expression "B / C" to some
subprogram formal be handled?  There is no "assignment" here.  The
semantics have to be part of the division operation.  Perhaps you
are arguing that indeed "assignment semantics" should be a part of
EVERY operation.  This is a completely different language change,
far more involved than a "simple" overloading of "assignment".
Perhaps those who are involved with Ada formal definition projects
(DDC, etc.) can shed some light on what is involved here and if
such would be useful.

>The argument that pre-processors can be used to acheive this effect is
>bull. It ignores the absolute fact that *no one* maintains, reads, or
>is expected to understand the processed code. This is a null argument.

Quite the contrary.  The whole idea of a pre-processor or translation
tool is to remove the need to "read" the processed version.  How many
Ada programmers spend their time disassembling and reading the output
of their compilations?  A compiler is a translation tool.  The idea
being that Ada is more readable/understandable/etc. than assembly.  So
why is it that defining a mapping from some pre-processor to Ada is
met with such cynicism?  It simply provides an additional layer of
abstraction, which, the last time I looked, was thought to be a good
idea.

Those who are convinced that there is nothing above/beyond Ada should
continue to keep their blinders on so that they won't have to worry
about keeping up with computer science and software engineering.  If
others in our field had adopted this attitude, we'd still be
programming by wire wrapping and debugging with oscilloscopes.  (It is
a sad commentary that there are still Ada programmers out there who
still do not understand the need for and utility of an APSE.  You can
spot them right away... they're the ones who think that the only way
to improve/change things is by modifying the language.)

>Date: 24 Nov 88 01:55:31 GMT
>From: hp-sdd!ncr-sd!ncrcae!hubcap!billwolf@hplabs.hp.com  (William Thomas Wolfe,2847,)
>Subject: Ada Language Change: Assignment Overloading
>
>   Why can't an overloadable operation remain as a basic operation?
>
>   In order to preserve compatibility, the "old" interpretation of
>   assignment could be kept as the outermost interpretation (deepest
>   in the background), available as a default assignment procedure.

Yech!  The current language definition is clear and consistent.  A
basic operation (such as assignment) cannot be overloaded.
Overloading is defined only for subprograms, single entries,
operators, and enumeration literals.  My point was that if assignment
was to be overloaded, then it would most likely have to be
reclassified as an operator or a procedure.  Otherwise, this language
change would require much more work.  Having assignment as the only
basic operation which could be overloaded makes the semantics of
"assignment" more murky.  Overloading is complex enough without adding
a new special case to it.  And for what benefit?  I still haven't seen
a response that illustrates a useful case where overloading assignment
would do anything useful.  Does anyone have such a case?  Or is this
basically a theoretical argument whereby the impact of a language
change will not be understood until it has been made and programmers
start to experiment with it?

>>    Program provers might rely on the fact that if no exception is raised 
>>    during the "assignment", that the the value is assigned to the object.  
>
>   And what about the overloadable relational operators???
>
>   Program provers cannot now assume that "=" really means equality,
>   nor can they assume that some side effect will not occur during the
>   evaluation of an equality operator.  There is plenty of precedent here.
>   If we go ahead and overload assignment, the program prover will be able
>   to exercise one simple, consistent rule: "Assume nothing".  I think this
>   is an excellent mode of thought to force a program prover into.  

Well, not really.  Since "=" can only be overloaded by the user for
limited types, it is not a good example.  "*" is a better example.
But the point is that the current semantics of assignment do allow
program provers to make certain assumptions which make the job of
writing a program prover easier.  While it is certainly possible to
write a program prover which does not make use of the current
assignment semantics, it is far harder to do so.  The point being that
there exist applications of Ada out there which will suffer somewhat
from this proposed language change.  Whether this is a desired result
is debatable (do we really want to force the program proving folks to
go back and undertake a major redesign because a few programmers hate
to type ASSIGN?).

>> The proponents of overloading assignment have also overlooked other
>> less costly solutions such as pre-processors that would transform
>> "overloaded assignment" into Ada procedure calls, implementation-defined
>> pragmas, etc.
>
>    Wrong.  The ability to cleanly define abstract data types 
>    is very much a language issue.  Implementation-defined pragmas
>    would annihilate portability.  Preprocessors would have one hell
>    of a time implementing "If this procedure call involves passing
>    a user-defined ADT by value, then generate a temporary variable
>    of that type, invoke ASSIGN on that temporary (assuming we adhered
>    to the convention of using the name ASSIGN rather than, for example,
>    COPY or DUPLICATE), and pass the temporary instead, and remember 
>    to invoke DESTROY on the temporary afterward"...
>
>    There's no way around it.  Assignment needs to be overloadable.

I don't understand this argument at all.  Clearly one can write ASSIGN
procedures by hand to solve this sort of thing.  The only difference
is that ASSIGN (X, Y) has to be written instead of "infix" X := Y.
So why does assignment need to be overloaded?  And if one can write
the code with the intended semantics by hand, then why cannot an
advanced APSE tool do so?  Is your argument that the state of APSE
technology is not sufficient to solve the problem, and therefore we
have to solve it as a language problem?  This is again a silly argument
for making a language change and would prove my case that this is
indeed an APSE issue, not a language issue.

***********
Since overloading of assignment is not a very important issue, I'll
refrain from making any further comments about it.  I'll get back to
doing more important things... writing pre-processor tools for Ada.

gom

Re: Collective response to := messages

[Dennis Doubleday]

In article <8811282217.AA04896@ajpo.sei.cmu.edu> mendal@ANNA.STANFORD.EDU (Geoff Mendal) writes:
>But the point is that the current semantics of assignment do allow
>program provers to make certain assumptions which make the job of
>writing a program prover easier.  While it is certainly possible to
>write a program prover which does not make use of the current
>assignment semantics, it is far harder to do so.  The point being that
>there exist applications of Ada out there which will suffer somewhat
>from this proposed language change.  Whether this is a desired result
>is debatable (do we really want to force the program proving folks to
>go back and undertake a major redesign because a few programmers hate
>to type ASSIGN?).

I agree that overloading of ":=" is a bad idea, but your line of
reasoning here is not convincing (to me).  I would change your last
question to "are we really going to limit programmers to only those
language constructs which the program proving folks find easy to
handle?".  If the answer is "yes", then we're not going to get much
real work done for the next decade, at least.

Dennis Doubleday                       dd@sei.cmu.edu
Software Engineering Institute         (412)268-5873
Carnegie Mellon University
Pittsburgh, PA 15213

Re: Collective response to := messages

[Ray Trent]

In an article mendal@ANNA.STANFORD.EDU (Geoff Mendal) writes:
>>The Ada apolgists would have us write the semantics for ensuring
>>LCD form for the type Fraction into *each and every operator*
>>that acts upon 2 items of this type, instead of having that 
>
>First, assignment is NOT an operator.  It is a basic operation.

The argument is that it should be. (and is, in any sensible 
(i.e. non-Ada) definition of the word operator) That there is no
reason to have "basic" operators that are "special".

>One of the examples that I deleted above was "A := B / C;"
>where A, B, and C were of some ADT (Fraction).  If I understand the
>argument for placing the semantics in assignment instead of having the
>programmer define the semantics in each user-defined operation, then
>how would the semantics of passing the expression "B / C" to some
>subprogram formal be handled?  There is no "assignment" here.  The

Fine, perhaps a better example is assigning to an object that should 
be garbage-collected before assignment. (always, or the program 
will be erroneous (not in the Ada sense)) Which makes more sense, 
putting garbage collection in assignment, or assuming the programmer 
will always call a garbage collector while assigning? Even if
the programmer is a code maintainer, and not the designer?

If you are wondering why I chose my original example, consider
A := (B / C * D) + ... + (Q / (3/4)). (all variables are of type fraction,
and an appropriate "/"(A,B : INTEGER) is defined) Do you still want
LCD maintainance in the arithmetic operations? Of course, you could 
always force A := LCD(foo). What if someone wants to modify the program? 
Aren't they going to wonder/forget about this? If you are worried
about passing the expression B / C as a parameter, my answer is: 
if you have a procedure where LCDness is necessary for proving something,
you can *always* simply make "in" parameters "in out" parameters. This 
*ensures* that an input variable will be in LCD form. (if assignment is
overloadable and is overloaded as suggested) "Requiring" a A := LCD(B/C)
does not ensure the validity of something passed to a sub-program.

If assignment were overloadable, the writer of an Ada spec for
operations involving fractions could be *sure* of always having something
in LCD form when passed to a subprogram by overloading ":=" and passing
all variables as "in out" parameters. The only other way to do this
is force *all* subprograms to perform LCDing on their outputs (or inputs)
whether that condition is necessary or not. This would make the operation
A := <very complicated expression with *many* arithmetic operations>
extremely slow (potentially). The LRM explicitly says that intermediate
results need not follow the constraints of the ADT. 

>being that Ada is more readable/understandable/etc. than assembly.  So
>why is it that defining a mapping from some pre-processor to Ada is
>met with such cynicism?  It simply provides an additional layer of

Because it is used to justify inconsistent language constructs. If 
I had a nickel for every time someone said, "you don't need to 
change the language, just use a pre-processor" I'd drown in them.
Point one: any such preprocessor needs to be standardized to the
level that the language is, or it defeats the purpose of the language.
Point two: If such a preprocessor *is* in fact standarized to the level that 
the language is, there is no discernable difference between changing
the language and adding a preprocessor. Point three: the argument is that 
assignment should not be overloadable because it is not understandable
(though more readable). It makes no real difference whether you put
assignment overloading into a pre-processor or into the language. 
The pre-processing source is what will be maintained and used. 
It is identically as understandable if the language is changed as
it is if a processing step is added. Perhaps more so. If the language
is changed, no one will *assume* that assignment cannot be overloaded.
Tacking on a preprocessor is the coward's way out.

>a sad commentary that there are still Ada programmers out there who
>still do not understand the need for and utility of an APSE.  You can

It's needed because the language was designed in an inconsistant and 
inflexible manner in the first place. What would you say about a 
preprocessor that converts C into Ada. Is programming in C then
as good as programming in Ada? (don't laugh, it can be done, especially
if you use unchecked programming) I don't think so.

Another change I'd like to see. (upward compatible this time) Allow:

  if A in B | C | D | Q | Y | N then
    ...
  end if;

I.e. an extension of the membership idea. It's ridiculous to me that

  case A is 
    when B | C => ...
  end case;

is valid but the above (or some equivilent) is not. I argue that such
a construct is both more readable and more understandable than
 
  if A = B or A = C or else ... or else A = N then
    ...
  end if;

and also makes the Ada language more internally consistent. (and thus
easier to use) I also argue that compiler vendors are likely to 
implement the former more efficiently than the latter. This is especially
true when the comparands are of a large enumerated type. (hashing, and all)

Anyway, enough diatribe for today.
-- 
"Our little lives get complicated
 It's a simple thing
 Simple as a flower
 And that's a complicated thing"                     ../ray\..

Re: Collective response to := messages

[Stephe Leake]

There seems to be a point of confusion concerning overloading of ":=".
Some people assume that the (overloaded) semantics of ":=" apply to
parameter passing. This seems to be a reasonable assumption, and I
think the current Ada parameter passing semantics are equivalent to
the current Ada assignment semantics. However, other types of
overloading (such as for "*") only apply when the overloaded symbol
appears _explicitly_; thus an argument could be made that the
overloaded ":=" should only be used for explicit assignments, not the
implicit ones in parameter passing. Personally, I think parameter
passing should be the same as assignment, but I just wanted to point
out the confusion.

In Ray Trent's discussion of the Fraction Abstract Data Type, he
implies that "*" and "/" do not reduce fractions to LCD form, but ":="
does. It seems to me, therefore, that he is talking about 2 data
types; LCD_Fractions and Fractions. This removes the need to overload
":=". "*" and "/" take either type and return Fraction. Then, since
there are two types involved, the compiler will remind maintainers to
include the explicit LCD operation;

A : LCD_Fraction;
B, C : Fraction;

A := B /C ; 	-- illegal
A := To_LCD_Fraction (B / C);	-- legal

I don't think ":=" should be overloadable just so we can hide type
conversions; this is one of the main complaints about C - one can
never be _sure_ what type something is.

The example above brings up a suggestion; type names should be
overloadable by functions, so we can define type conversion functions
that look like the type conversions available to scalar types. Ie the
function "To_LCD_Fraction" above should be named "LCD_Fraction". I
don't know which section of the LRM to refer to here; overloading
rules seem very scattered.

Ray Trent says:
	> The LRM explicitly says that intermediate
	> results need not follow the constraints of the ADT.
Where does it say this?

I second the motion for allowing:

  if A in (B | C | D | Q | Y | N) then
    ...
  end if;

(note that I added parentheses). Currently, we can get the same effect
with a subtype, but _only_ if B | C | D | Q | Y | N can be _uniquely_
described by a range constraint, which is often not the case. This is
leaning further towards defining sets in Ada, something that PASCAL
has always had. There are certainly problems with fully implementing
sets, but I think this extension is a good one.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

Re: Collective response to := messages

[David S. Rosenblum]

In article <755@marvin.cme-durer.ARPA> leake@cme-durer.ARPA (Stephe Leake) writes:
>
>There seems to be a point of confusion concerning overloading of ":=".
>Some people assume that the (overloaded) semantics of ":=" apply to
>parameter passing. This seems to be a reasonable assumption, and I
>think the current Ada parameter passing semantics are equivalent to
>the current Ada assignment semantics.

They are not the least bit equivalent, for several reasons.  The most
obvious reason is that an implementation is free to pass composite
parameters by reference, although no implementation can "assign by
reference".  No source-level assignment operation is "invoked" to achieve
parameter passing.  Parameter passing is a language facility that is
implemented by the compiler, just as is, say, looping.

>However, other types of
>overloading (such as for "*") only apply when the overloaded symbol
>appears _explicitly_; thus an argument could be made that the
>overloaded ":=" should only be used for explicit assignments, not the
>implicit ones in parameter passing. Personally, I think parameter
>passing should be the same as assignment, but I just wanted to point
>out the confusion.

I personally believe such an interpretation of parameter passing creates
more confusion instead of less.  In essence, this interpretation adds yet
another special case to the scope and visibility rules--it allows a
subprogram call to "see past" a visible redefinition of assignment to
a predefined one that has been hidden.

>A : LCD_Fraction;
>B, C : Fraction;
>
>A := B /C ; 	-- illegal
>A := To_LCD_Fraction (B / C);	-- legal
>
>The example above brings up a suggestion; type names should be
>overloadable by functions, so we can define type conversion functions
>that look like the type conversions available to scalar types.

As I argued in the case of assignment, overloading of type conversion is
overloading of a basic operation, and such a facility would allow
one to circumvent type checking.  As you suggested above, we don't want
to turn Ada into C.


-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------

Re: Collective response to := messages

[William Thomas Wolfe,2847,]

From article <10917@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
> In article <755@marvin.cme-durer.ARPA> leake@cme-durer.ARPA (Stephe Leake) writes:
>>
>>There seems to be a point of confusion concerning overloading of ":=".
>>Some people assume that the (overloaded) semantics of ":=" apply to
>>parameter passing. This seems to be a reasonable assumption, and I
>>think the current Ada parameter passing semantics are equivalent to
>>the current Ada assignment semantics.
> 
> They are not the least bit equivalent, for several reasons.  The most
> obvious reason is that an implementation is free to pass composite
> parameters by reference, although no implementation can "assign by
> reference". 

    Sure, for "in out" mode.  But for modes "in" and "out", failure to
    use the ADT's assignment procedure causes major problems:

      "out" mode:  Programmer assigns the parameter a value, and the
                   value is copied back to the actual parameter.  
                   Unfortunately, the portions of the actual parameter
                   which were formerly accessible by pointers are now
                   uncollectable garbage.

       "in" mode:  Programmer assumes that this is a "pass by value"
                   and makes modifications.  Since ADT contains pointers,
                   modification echoes through to the actual parameter.
                   Programmer could also invoke DESTROY, blowing away
                   major portions of the actual parameter.

Re: Collective response to := messages

[David S. Rosenblum]

In article <3721@hubcap.UUCP> billwolf@hubcap.clemson.edu writes:
|From article <10917@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
|> In article <755@marvin.cme-durer.ARPA> leake@cme-durer.ARPA (Stephe Leake) writes:
|>>
|>>There seems to be a point of confusion concerning overloading of ":=".
|>>Some people assume that the (overloaded) semantics of ":=" apply to
|>>parameter passing. This seems to be a reasonable assumption, and I
|>>think the current Ada parameter passing semantics are equivalent to
|>>the current Ada assignment semantics.
|> 
|> They are not the least bit equivalent, for several reasons.  The most
|> obvious reason is that an implementation is free to pass composite
|> parameters by reference, although no implementation can "assign by
|> reference". 
|
|    Sure, for "in out" mode.  But for modes "in" and "out", failure to
|    use the ADT's assignment procedure causes major problems:
|
|      "out" mode:  Programmer assigns the parameter a value, and the
|                   value is copied back to the actual parameter.  
|                   Unfortunately, the portions of the actual parameter
|                   which were formerly accessible by pointers are now
|                   uncollectable garbage.
|
|       "in" mode:  Programmer assumes that this is a "pass by value"
|                   and makes modifications.  Since ADT contains pointers,
|                   modification echoes through to the actual parameter.
|                   Programmer could also invoke DESTROY, blowing away
|                   major portions of the actual parameter.

I'm terribly confused.  Are we still talking about Ada?  With this talk
about parameter passing invoking source-level assignment, I'm not so sure.
I'm not sure what your "out" mode comments refer to, but maybe you're
confusing what access values (pointers) can point to in Ada, or maybe you're
confusing how access values are passed as parameters in Ada--access values are
ALWAYS copied IN to their respective places in formal parameters, EVEN for
mode "out" formals.  Your "in" mode comments are also vague.  First of all,
"good" Ada programmers assume nothing about parameter passing behavior.
Second, an access value can be passed as a parameter, in which case the
language is concerned only with the access value during parameter passing,
NOT with the object designated by the access value.


-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------

Re: Collective response to := messages

[William Thomas Wolfe,2847,]

From article <10960@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
> |> They are not the least bit equivalent, for several reasons.  The most
> |> obvious reason is that an implementation is free to pass composite
> |> parameters by reference, although no implementation can "assign by
> |> reference". 
> |
> |    Sure, for "in out" mode.  But for modes "in" and "out", failure to
> |    use the ADT's assignment procedure causes major problems:
> |
> |      "out" mode:  Programmer assigns the parameter a value, and the
> |                   value is copied back to the actual parameter.  
> |                   Unfortunately, the portions of the actual parameter
> |                   which were formerly accessible by pointers are now
> |                   uncollectable garbage.
> |
> |       "in" mode:  Programmer assumes that this is a "pass by value"
> |                   and makes modifications.  Since ADT contains pointers,
> |                   modification echoes through to the actual parameter.
> |                   Programmer could also invoke DESTROY, blowing away
> |                   major portions of the actual parameter.
> 
> I'm terribly confused.  Are we still talking about Ada?  With this talk
> about parameter passing invoking source-level assignment, I'm not so sure.
> I'm not sure what your "out" mode comments refer to, but maybe you're
> confusing what access values (pointers) can point to in Ada, or maybe you're
> confusing how access values are passed as parameters in Ada--access values are
> ALWAYS copied IN to their respective places in formal parameters, EVEN for
> mode "out" formals.  

     OK.  Envision an ADT which just happens to be implemented as a pointer
     to a descriptor, which probably has more pointers to the "value".  Now
     our ADT user wishes to transfer an ADT "out".  The ADT user has no idea
     how the ADT is implemented.  Now when the procedure was invoked, let's 
     assume that the ADT supplied as an actual parameter had some value;
     hence, the pointer which represents the "ADT type" is not null, and 
     in fact constitutes the only known method for accessing a substantial
     amount of utilized memory.  Our ADT user sends the value "out", and
     Ada implements this by copying the value of a single pointer.  The old
     pointer value associated with the actual parameter is lost forever,
     and all the stuff it pointed to is now garbage.
 
> Your "in" mode comments are also vague.  First of all,
> "good" Ada programmers assume nothing about parameter passing behavior.

     Anything which is passed as an "in" parameter should be treatable as
     something which was passed in by value.  Anything which is passed as
     an "in out" parameter should be treatable as something which was passed
     by reference.  Anything which is passed as an "out" parameter should
     be treated as the target of a pass by value in the "outward" direction.

     If nothing can be assumed about parameter passing behavior, then 
     parameter passing is just too vaguely defined, and needs to be clarified.

> Second, an access value can be passed as a parameter, in which case the
> language is concerned only with the access value during parameter passing,
> NOT with the object designated by the access value.

     When what is being passed is known to the user as an access value,
     this is precisely what the programmer expects.  When what is being
     passed is known to the user as an ADT, this sort of behavior is
     totally counterintuitive.  It violates the abstraction.


                                          Bill Wolfe

                                  wtwolfe@hubcap.clemson.edu

Re: Collective response to := messages

[David S. Rosenblum]

In article <3734@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes:
|     OK.  Envision an ADT which just happens to be implemented as a pointer
|     to a descriptor, which probably has more pointers to the "value".  Now
|     our ADT user wishes to transfer an ADT "out".  The ADT user has no idea
|     how the ADT is implemented.  Now when the procedure was invoked, let's 
|     assume that the ADT supplied as an actual parameter had some value;
|     hence, the pointer which represents the "ADT type" is not null, and 
|     in fact constitutes the only known method for accessing a substantial
|     amount of utilized memory.  Our ADT user sends the value "out", and
|     Ada implements this by copying the value of a single pointer.  The old
|     pointer value associated with the actual parameter is lost forever,
|     and all the stuff it pointed to is now garbage.

The language already has a very nice feature to handle such situations.
It's called the "limited type".  By implementing your ADT as a limited
type, you deny the user of the ADT the ability to assign to variables and
in-out and out mode parameters of the type.  The only way to assign
to such a parameter or variable is to pass it to a subprogram that is
part of the implementation of the ADT.  That subprogram can then reclaim
the storage refernced by the access value if it decides to give the parameter
a new value.  Geoff Mendal did a nice paper on the encapsulation of storage
reclamation mechanisms inside user-defined ADTs in a paper he gave at a
recent SIGAda (you can get a copy from him).

|     Anything which is passed as an "in" parameter should be treatable as
|     something which was passed in by value.  Anything which is passed as
|     an "in out" parameter should be treatable as something which was passed
|     by reference.  Anything which is passed as an "out" parameter should
|     be treated as the target of a pass by value in the "outward" direction.
|
|     If nothing can be assumed about parameter passing behavior, then 
|     parameter passing is just too vaguely defined, and needs to be clarified.

You'll have to take this up with the Ada Language Maintenance Committee.
The language designers, and many Ada programmers, believe it to be as
clearly defined as it needs to be so that portable programs may be written.

|     When what is being passed is known to the user as an access value,
|     this is precisely what the programmer expects.  When what is being
|     passed is known to the user as an ADT, this sort of behavior is
|     totally counterintuitive.  It violates the abstraction.

Right.  So as I said above, define the ADT as limited private, so that
you (as the implementor of the ADT) can have complete control over the
use of the ADT.  That way the user of the ADT won't be able to violate the
abstraction.

Back to work.


-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------

Re: Collective response to := messages

[William Thomas Wolfe,2847,]

From article <10963@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
@ By implementing your ADT as a limited
@ type, you deny the user of the ADT the ability to assign to variables and
@ in-out and out mode parameters of the type.  The only way to assign
# to such a parameter or variable is to pass it to a subprogram that is
# part of the implementation of the ADT.  That subprogram can then reclaim
# the storage refernced by the access value if it decides to give the parameter
# a new value.  

   Sure, except for the circumvention of the provided ASSIGN routine which
   occurs every time the ADT is passed as an "in" or "out" parameter.

   There is no way to deny the user this particular method of circumventing
   your assignment routine, or even to have the compiler warn the user
   that a limited private ADT cannot be relied upon as a value parameter.
   
> |     When what is being passed is known to the user as an access value,
> |     this is precisely what the programmer expects.  When what is being
$ |     passed is known to the user as an ADT, this sort of behavior is
$ |     totally counterintuitive.  It violates the abstraction.
$ 
$ Right.  So as I said above, define the ADT as limited private, so that
% you (as the implementor of the ADT) can have complete control over the
% use of the ADT.  That way the user of the ADT won't be able to violate the
% abstraction.

    Except by way of the parameter passing mechanism.

Re: Collective response to := messages

[Stephe Leake]

In article <3757@hubcap.UUCP> billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) writes:

      Sure, except for the circumvention of the provided ASSIGN routine which
      occurs every time the ADT is passed as an "in" or "out" parameter.

A limited type CANNOT be passed as an out parameter!!!!
A limited type CANNOT be passed as an out parameter!!!!
(in a user routine) LRM 7.4.4 (4). Have you got the message now? And
for an in parameter, the only access to the object is thru the ADT
functions, which work as desired.

Do you have an explicit example where a limited type violates the
abstraction in the way you are discussing? If so, maybe you have found
a compiler bug.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

Definition of pass by reference

[Robert Eachus]

In article <10963@ulysses.homer.nj.att.com> dsr@hector.UUCP (David S. Rosenblum) writes:
>In article <3734@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes:
>|     If nothing can be assumed about parameter passing behavior, then 
>|     parameter passing is just too vaguely defined, and needs to be clarified.
>
>You'll have to take this up with the Ada Language Maintenance Committee.
>The language designers, and many Ada programmers, believe it to be as
>clearly defined as it needs to be so that portable programs may be written.

     The Ada Rapporteur Group (the current instantiation of the Ada
LMC), does NOT feel that it is as clearly defined as it needs to be.
AI-178 Passing parameters by reference, was discussed again at the
meeting in October, and although we are close to a consensus, the AI
is being rewritten for the February meeting.

     Basically, the AI defines when it is legal to pass parameters by
reference, and what it means to do so.  In spite of some of the
comments here, there are many cases where non-scalar parameters must
be passed by copy to conform to Ada semantics.  However, there are
some questionable cases which this AI attempts to resolve.  For
example, if A and B are arrays stored in adjacent locations in memory,
is it legal to pass A&B by reference?  The AI says no, but currently
allows A(1..10) to be passed by reference, and is being reworded to
require (A) to be passed by copy.

     If this issue is important to you, get the current version from
ajpo.sei.cmu.edu, and send any comments to ada-comment@ajpo.sei.cmu.edu.
Please, read the entire AI and any current comments before commenting
on it yourself.  This is an issue where programming style and what
users think are important, but there are some real gotchas that have
to be taken into account.

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

Re: Collective response to := messages

[Stephe Leake]

In article <3734@hubcap.UUCP> billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) writes:

	OK.  Envision an ADT which just happens to be implemented as a pointer
	to a descriptor, which probably has more pointers to the "value".  Now
	our ADT user wishes to transfer an ADT "out".  The ADT user has no idea
	how the ADT is implemented.  Now when the procedure was invoked, let's 
	assume that the ADT supplied as an actual parameter had some value;
	hence, the pointer which represents the "ADT type" is not null, and 
	in fact constitutes the only known method for accessing a substantial
	amount of utilized memory.  Our ADT user sends the value "out", and
	Ada implements this by copying the value of a single pointer.  The old
	pointer value associated with the actual parameter is lost forever,
	and all the stuff it pointed to is now garbage.

This is precisely the reason for limited private types; only functions
provide by the ADT package may have out parameters of the limited
type, so the ADT programmer can ensure correct behaviour, including
garbage collection and copying. This is a much simpler solution than
forcing parameter passing to use the ADT assignment operator.

	Anything which is passed as an "in" parameter should be treatable as
	something which was passed in by value.  Anything which is passed as
	an "in out" parameter should be treatable as something which was passed
	by reference.  Anything which is passed as an "out" parameter should
	be treated as the target of a pass by value in the "outward" direction.


	If nothing can be assumed about parameter passing behavior, then 
	parameter passing is just too vaguely defined, and needs to be clarified.

The program should be independent of the choice of parameter passing
implementation. (LRM 6.2 (7) says so).  What can be assumed about
parameter passing behaviour is precisely what the LRM says (mostly in
6.2,3,4); no more, and no less. If you want different semantics, use a
limited type (and document the semantics in the package spec).

   > Second, an access value can be passed as a parameter, in which case the
   > language is concerned only with the access value during parameter passing,
   > NOT with the object designated by the access value.

	When what is being passed is known to the user as an access value,
	this is precisely what the programmer expects.  When what is being
	passed is known to the user as an ADT, this sort of behavior is
	totally counterintuitive.  It violates the abstraction.

Once again, this is why limited types are available. It is up to the
ADT implementor to insure that abstraction violations are not
possible. This is not always easy.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

Re: Collective response to := messages

[Stephe Leake]

In article <10917@ulysses.homer.nj.att.com> dsr@hector.UUCP (David S. Rosenblum) writes:

   As I argued in the case of assignment, overloading of type conversion is
   overloading of a basic operation, and such a facility would allow
   one to circumvent type checking.  As you suggested above, we don't want
   to turn Ada into C.

Type checking _cannot_ be circumvented by overloading of type
conversion! Consider:

type DEGREES is digits 6 range 0.0 .. 360.0;
type RADIANS is digits 6;

function DEGREES (Item : in RADIANS) return DEGREES
is
begin
	return Item * 180.0 / PI;	-- range constraint is checked!
end;

Since the underlying Ada type checking is done on the function result,
no circumvention of type checking is possible.

On the other hand, the fact that type conversion is a basic operation
is significant; allowing overloading would mean changing it to a
normal operation (is "normal" the complement of "basic"?), with
corresponding changes in visibility. As I see it, there are two gains;
first, I get to name my type conversion functions the same as the
implicit type conversions (ie DEGREES instead of TO_DEGREES).  Second,
I get to hide the implicit conversion, which is appropriate in the
case of DEGREES and RADIANS. However, Ada provides limited types for
hiding purposes, so this second point is not really valid (although a
limited type seems like a lot of effort for such a simple thing,
remember that Ada was intended for maintainers, not programmers :-).
So it probably isn't worth persuing. (Sigh - one of these days I'll
have a really good idea :-).

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

Re: Collective response to := messages

[David S. Rosenblum]

In article <772@marvin.cme.nbs.gov> leake@cme.nbs.gov (Stephe Leake) writes:
>In article <10917@ulysses.homer.nj.att.com> dsr@hector.UUCP (David S. Rosenblum) writes:
>
>   As I argued in the case of assignment, overloading of type conversion is
>   overloading of a basic operation, and such a facility would allow
>   one to circumvent type checking.  As you suggested above, we don't want
>   to turn Ada into C.
>
>Type checking _cannot_ be circumvented by overloading of type
>conversion! Consider:
>
>type DEGREES is digits 6 range 0.0 .. 360.0;
>type RADIANS is digits 6;
>
>function DEGREES (Item : in RADIANS) return DEGREES
>is
>begin
>	return Item * 180.0 / PI;	-- range constraint is checked!
>end;
>
>Since the underlying Ada type checking is done on the function result,
>no circumvention of type checking is possible.

My comment did NOT have to do with checking the constraints of the
target type.  I hope anybody with a minimal familiarity with Ada knows
that type constraints are checked on function return values.  My point
was that overloading of type conversion will allow you to "covert" pointers
to integers, arrays to files, tasks to widgets, etc.  This is called "casting"
in C, better known as "anything goes".  To me such conversions are a
circumvention of Ada's strong typing model.

I'll try this just one more time.  By allowing the overloading of
basic operations, you may gain some flexibility in defining your
abstractions, but this gain will be achieved only at the (to me, unjustifiable)
cost of severely weakening Ada's strong typing strictures.  Any
proposal to increase flexibility in defining abstractions in Ada
MUST ("read my lips"--MUST) conform to the fundamental language philosophies
of Ada.

I would suggest two promising areas for making such improvements
in an "Ada-like" way.  (1) Allow user-specifiable initialization and
destruction routines for types.  Ray Trent and Bill Wolfe have been arguing
for a parameter passing semantics based on assignment.  Stroustrup, in his
C++ book, argues that you need initialization mechanisms, not assignment, for
parameter passing, and that initialization and assignment are
fundamentally different operations.  Initialization routines would
be appropriate for initializing parameters that are passed by copy, which
(at least for scalars) is the mandated parameter passing mechanism.
(2) Define a mechanism for allowing richer user-specified constraints
on types, e.g. "all objects of type EVEN must have even values", or "for
all objects of record type FOO, component BAR must always be greater than
component BAZ".  Then let Ada's inherent type checking mechanisms check
these constraints automatically.

In short, Ada has a very nice type checking framework.  We should try to
come up with proposals that improve that framework in ways that increases
its flexibility without decreasing its robustness; don't just propose tacking
on new language rules and band-aids that will cheaply rid you of your
frustrations with the current framework.


-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------

Re: Collective response to := messages

[Ray Trent]

In the above article leake@cme-durer.ARPA (Stephe Leake) writes:
>does. It seems to me, therefore, that he is talking about 2 data
>types; LCD_Fractions and Fractions. This removes the need to overload

Indeed, this is the case. I explained that type Fraction was not a 
particularly good example, and why I used it anyway. I mostly object
to the internal inconsistancies of Ada...exceptions to the rules
for "special" operators, the non-object status of certain types
of procedural objects and not others, disallowing user definition
of attributes, the wierdnesses inherent in the "use" clause that
make it almost useless, the fact that Ada is supposed to 
be strongly typed, but that uninitialized variables of a type
are not required to contain a valid value in the range of that type,
and are also not required to contain an *invalid* value, etc., etc.

>Ray Trent says:
>	> The LRM explicitly says that intermediate
>	> results need not follow the constraints of the ADT.
>Where does it say this?

LRM 11.6 [6] states: Similarly, additional freedom is left to an 
implementation for the evaluation of numeric simple expressions. For
the evaluation of a predefined operation, an implementation is 
allowed to use the operation of a type that has a range wider than that of
the base type of the operands, provided that this delivers the exact result,
even if some intermediate results lie outside the range of the base type.

They only explicitly allow this for predefined operations, though it's
ambiguous enough that vendors are likely to allow it for user-defined
operations as well. (and it's kind of hard to test) I object to "special"
properties of language constructs that I am not "allowed" as a programmer
to use or duplicate in my own types, subprograms, etc., in any event.

-- 
"Our little lives get complicated
 It's a simple thing
 Simple as a flower
 And that's a complicated thing"                     ../ray\..

Re: Collective response to := messages

[Stephe Leake]

In article <24934@sri-unix.SRI.COM> trent@unix.SRI.COM (Ray Trent) writes:

   ... I mostly object
   to the internal inconsistancies of Ada...exceptions to the rules
   for "special" operators, the non-object status of certain types
   of procedural objects and not others, disallowing user definition
   of attributes, the wierdnesses inherent in the "use" clause that
   make it almost useless, the fact that Ada is supposed to 
   be strongly typed, but that uninitialized variables of a type
   are not required to contain a valid value in the range of that type,
   and are also not required to contain an *invalid* value, etc., etc.

That is the purpose of this discussion; to find the "inconsistencies"
in Ada, and propose solutions. So far, I don't think any of the
proposed solutions are better than what we already have. Certainly Ada
is more consistent than C! Also remember that Ada is very powerful,
and is _not_ simple; things that may appear inconsistent are actually
logical consequences of this power.

   LRM 11.6 [6] states: Similarly, additional freedom is left to an 
   implementation for the evaluation of numeric simple expressions. For
   the evaluation of a predefined operation, an implementation is 
   allowed to use the operation of a type that has a range wider than that of
   the base type of the operands, provided that this delivers the exact result,
   even if some intermediate results lie outside the range of the base type.

   They only explicitly allow this for predefined operations, though it's
   ambiguous enough that vendors are likely to allow it for user-defined
   operations as well. (and it's kind of hard to test) I object to "special"
   properties of language constructs that I am not "allowed" as a programmer
   to use or duplicate in my own types, subprograms, etc., in any event.

I don't see any ambiguity: "numeric simple expressions" and
"predefined operations" are very well defined, and user ADT's do not
fit the definitions!

On the other hand, I agree that this is a "special" exception to the
general rule. It has a very good justification, however; any hardware
must have only a few types (32 and 16 integers, 64 and 32 bit float,
for example) to be efficient (although I sometimes daydream about the
connection machine, where I could implement a 25 bit float if I wanted
to :-). Ada was intended to be a practical language, as well as an
abstract one.  Thus compromises are sometimes necessary.

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

Re: Collective response to := messages

[David S. Rosenblum]

In article <24856@sri-unix.SRI.COM> trent@unix.sri.com (Ray Trent) writes:
>In an article mendal@ANNA.STANFORD.EDU (Geoff Mendal) writes:
>>
>>First, assignment is NOT an operator.  It is a basic operation.
>
>The argument is that it should be. (and is, in any sensible 
>(i.e. non-Ada) definition of the word operator) That there is no
>reason to have "basic" operators that are "special".

Most of the non-Ada definitions of "operator" that I am familiar with
describe operators in a purely mathematical sense, i.e. in terms of
domains and algebras.  However, assignment is a concept that is peculiar to
programming languages, so in a sense you're comparing apples and oranges.
And most "sensible" definitions of assignment that I know of describe
assignment simply in terms of placing a value in a variable or memory location.

Basic operations in Ada ARE special, for very good reasons.  Unlike operators,
they are intimately connected with Ada's model of type constraints in some
way and cannot be hidden.  One of the nice features of Ada type constraints is
that they are (or at least were intended to be) implemented consistently
throughout the language, in part via the basic operations.  This consistent
enforcement would be lost if overloading of basic operations were allowed.  In
particular, by allowing overloading of assignment, it would be possible to
override one of the fundamental steps of the assignment operation, which is to
guarantee that the target variable in an assignment statement is assigned a
legal value of its type.  When you overload operators such as "=" and "+",
you may give perverse semantics to operators that have a "traditional"
meaning, but you are not able to override Ada's type checking.  Thus,
allowing overloading of assignment (or any basic operation) would seriously
weaken Ada's strong typing features.

>[lots of discussion about LCD deleted]

As I understand your LCD example, you seem to see assignment overloading
as a vehicle for implementing type constraints that can't be expressed in
Ada's constraint language (such as LCD-ness).  So why stop with assignment?
Wouldn't you need overloading of all the basic operations?  Suppose
I'm given a language change which allows overloading of basic operations,
and suppose I have a type EVEN, e.g.,

	type EVEN is new INTEGER;

which I want to constrain in a way that would require all variables of
the type to have even values.  In order to enforce this constraint
consistently in the manner of Ada, I would want to do the following:

(1) Overload := so that it raises CONSTRAINT_ERROR when given an odd
    right-hand-side.
(2) Overload the attributes 'SUCC and 'PRED so that they skip odd values.
(3) Overload the attributes 'POS and 'VAL so that count only even values.
(4) Overload the attribute 'FIRST so that it returns the smallest even
    value of EVEN's base type.
(5) Overload the attribute 'LAST so that it returns the largest even
    value of EVEN's base type.
(6) Overload the membership tests and the ".." token so that only
    even ranges are considered.
(7) Overload the indexing operation for all array types I define that are
    indexed by EVEN values, so that even-numbered components are stored and
    accessed contiguously.
(8) Overload the aggregate operation for such array types so that
    the index values for the aggregate are computed "the right way".

Yet after all these exertions, my evenness constraint would STILL not
be enforced consistently, unless I was given several more language changes.
For example, type conversions, qualifications, attribute evaluations and
membership tests never propagate exceptions.  Yet what would be the effect
of the type conversion "EVEN(3)"?  What would be the effect of the attribute
evaluation "EVEN'POS(3)"?  What would be the effect of the tests
"2 in 0 .. 3" or "3 in 0 .. 10" ?  Should they raise CONSTRAINT_ERROR, or
should they round 3 to some even value?  Suppose I instantiate INTEGER_IO to
perform I/O on EVEN values.  How do I get the instantiation to enforce my
evenness constraint?  First I would need another language change that requires
source-level assignment "operators" to be used to implement parameter
passing.  But I'm still in trouble because my overloaded := cannot be made
visible to my INTEGER_IO instantiation.  So I would ALSO need INTEGER_IO to be
redefined to accept a generic formal := parameter.  Oy!

I agree with Geoff.  The proponents of assignment overloading have not
addressed the ramifications of their proposal thoroughly enough to come
up with a fully consistent change to the language.  Until they do, I'm
happy to write ASSIGN instead of := whenever I need a "special" assignement
operation.


-- David

-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------

Re: Collective response to := messages

[William Thomas Wolfe,2847,]

From article <10906@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
> One of the nice features of Ada type constraints is
> that they are (or at least were intended to be) implemented consistently
> throughout the language, in part via the basic operations.  This consistent
> enforcement would be lost if overloading of basic operations were allowed.  In
> particular, by allowing overloading of assignment, it would be possible to
> override one of the fundamental steps of the assignment operation, which is to
> guarantee that the target variable in an assignment statement is assigned a
> legal value of its type.  

     Since the overloaded assignment would be implemented in terms of
     the existing low-level assignment operations, I don't see where any 
     potential problem exists here.  Please clarify.
 
> As I understand your LCD example, you seem to see assignment overloading
> as a vehicle for implementing type constraints that can't be expressed in
> Ada's constraint language (such as LCD-ness).  
> [...] 
> Yet after all these exertions, my evenness constraint would STILL not
> be enforced consistently, unless I was given several more language changes.
> For example, type conversions, qualifications, attribute evaluations and
> membership tests never propagate exceptions.  Yet what would be the effect
> of the type conversion "EVEN(3)"?  What would be the effect of the attribute
> evaluation "EVEN'POS(3)"?  What would be the effect of the tests
> "2 in 0 .. 3" or "3 in 0 .. 10" ?  Should they raise CONSTRAINT_ERROR, or
> should they round 3 to some even value?  

    The problems mentioned pertain specifically to this implementation
    only; if EVEN were implemented as a limited private type within an
    appropriate package, all the operations mentioned would be available 
    only through the procedures/functions provided.  Type conversions
    would not be legally expressible in the usual notation, most attributes
    would not be defined, etc.  Ada 83 allows us to do all of these things,
    but not in the "conventional" notation.  

    Since Ada does not allow implicit type conversions, the fact that we
    cannot overload type conversion does not cause us any grief in the
    parameter-passing process.  Nor do any of the other operations mentioned.

    Only assignment and destruction play vital roles in the evaluation of
    parameters and in the creation and destruction of variables (particularly
    with regard to block entry and exit).  It is the fact that the language
    does not consider the impact of these mechanisms upon the ADT paradigm,
    mechanisms which can play havoc with our abstractions, that compels us 
    to call for changes in the language with regard to the ability to
    define specific procedures for assignment and destruction which are 
    taken into consideration by these mechanisms. 

> I agree with Geoff.  The proponents of assignment overloading have not
> addressed the ramifications of their proposal thoroughly enough to come
> up with a fully consistent change to the language.  

    It is entirely possible that given the desire of AJPO to minimize the
    extent of changes in the language, it will not be possible to get Ada
    to provide complete support for the abstract data type paradigm.  Ada
    was explicitly intended as an interim solution, covering the range
    1983..20xx, and not as "the perfect language".  Perhaps for Ada it is
    already too late.  But the issue needs to be thoroughly discussed,
    because it is a major area in which Ada has "missed the boat". 

    Perhaps there is a solution which AJPO will find acceptable.  We must
    know whether or not this is the case.  If there is no hope for Ada,
    then we must focus on the construction of Ada's successor.


                                           Bill Wolfe

                                    wtwolfe@hubcap.clemson.edu

Re: Collective response to := messages

[David S. Rosenblum]

In article <3698@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes:
>From article <10906@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
>> In
>> particular, by allowing overloading of assignment, it would be possible to
>> override one of the fundamental steps of the assignment operation, which is to
>> guarantee that the target variable in an assignment statement is assigned a
>> legal value of its type.  
>
>     Since the overloaded assignment would be implemented in terms of
>     the existing low-level assignment operations, I don't see where any 
>     potential problem exists here.  Please clarify.

Essentially, the problems arise from the characteristics of Ada's parameter passing semantics.
(Or we could change those too while we're at it. :-) )  Suppose ":=" overloadings are required
to have an out-mode parameter to represent the target variable.  Then an overloaded ":="
on a composite type can selectively assign to some components of the target and
leave other components undefined (if they were undefined prior to execution of the assignment).
This cannot happen with predefined assignment to objects of a composite type (i.e., when a full
composite object, not just a component of one, is given as the left-hand side).  Alternatively,
suppose ":=" overloadings are required to have an in out-mode parameter to represent the target
variable.  Then it would be impossible to assign to an undefined variable, because the
variable would first be constraint-checked when it is passed in to the assignment procedure.

For example,

procedure CIRCUMVENT is

    type LCD_FORM is
	record
	    NUMERATOR, DENOMINATOR : INTEGER;
	end record;

    X, Y : LCD_FORM;	-- X and Y undefined.

    procedure ":=" (L : out LCD_FORM; R : in FLOAT) is
    begin
	if R = 0.0 then
	    L.NUMERATOR := 0;
	else
	    -- calculate LCD form.
	end if;
    end ":=";

begin
    X := 1.5;
    -- X.NUMERATOR is presumably 3, X.DENOMINATOR is presumably 2.

    -- Y.DENOMINATOR is undefined.
    Y := 0.0;
    -- Y.DENOMINATOR is STILL undefined.
end CIRCUMVENT;

You can object that I didn't define ":=" "correctly" and that I stupidly failed to assign to
DENOMINATOR when R is zero, but that's the whole point--I've circumvented the type checking
that is inherent in predefined assignment.

> 
>> As I understand your LCD example, you seem to see assignment overloading
>> as a vehicle for implementing type constraints that can't be expressed in
>> Ada's constraint language (such as LCD-ness).  
>> [...] 
>> Yet after all these exertions, my evenness constraint would STILL not
>> be enforced consistently, unless I was given several more language changes.
>> For example, type conversions, qualifications, attribute evaluations and
>> membership tests never propagate exceptions.  Yet what would be the effect
>> of the type conversion "EVEN(3)"?  What would be the effect of the attribute
>> evaluation "EVEN'POS(3)"?  What would be the effect of the tests
>> "2 in 0 .. 3" or "3 in 0 .. 10" ?  Should they raise CONSTRAINT_ERROR, or
>> should they round 3 to some even value?  
>
>    The problems mentioned pertain specifically to this implementation
>    only; if EVEN were implemented as a limited private type within an
>    appropriate package, all the operations mentioned would be available 
>    only through the procedures/functions provided.  Type conversions
>    would not be legally expressible in the usual notation, most attributes
>    would not be defined, etc.  Ada 83 allows us to do all of these things,
>    but not in the "conventional" notation.  

That's the whole point of why you don't need assignment overloading!!!  You can also do assignment
with limited private types, but not in the "conventional" notation.  All you need to do is provide
an "appropriate subprogram".

>
>    Since Ada does not allow implicit type conversions, the fact that we
>    cannot overload type conversion does not cause us any grief in the
>    parameter-passing process.  Nor do any of the other operations mentioned.

You seem to be missing my point.  You are trying to use an overloaded assignment operator
to implement a constraint on your LCD type that can't be expressed in Ada's constraint language.
I've argued that I would want the ability to overload the other basic operations so that
I could implement in a consistent manner the constraints that I may dream up.  You've ignored that
argument and instead still seem to be harboring the belief that assignment is "different" from
the other basic operations.  What is so unique about assignment that it alone of all the basic
operations requires special treatment?

>
>    Only assignment and destruction play vital roles in the evaluation of
>    parameters and in the creation and destruction of variables (particularly
>    with regard to block entry and exit).  It is the fact that the language
>    does not consider the impact of these mechanisms upon the ADT paradigm,
>    mechanisms which can play havoc with our abstractions, that compels us 
>    to call for changes in the language with regard to the ability to
>    define specific procedures for assignment and destruction which are 
>    taken into consideration by these mechanisms. 

We can argue about implicitly invoked destruction mechanisms some other time, since Ada provides no
such animal.  And Ada's parameter passing mechanisms are defined implicitly, beyond the reach
of the programmer, as they should be (again to enforce type checking)--they have nothing
to do with assignment at the source level.  Regarding your assignment "abstraction", all
I can offer is the suggestion that reduction to LCD form is an over-specification of what I
consider to be the normal semantics of an assignment operation, and it is better left to
another procedure whose sole purpose is to perform the reduction.  If you define your
LCD type as a limited type in a package, you can provide a NORMALIZE procedure which
will achieve the desired effect.  If you need to add new code later, your only
recourse will be to use the NORMALIZE procedure, as there is no predefined assignment operation
available to confuse you.

>    It is entirely possible that given the desire of AJPO to minimize the
>    extent of changes in the language, it will not be possible to get Ada
>    to provide complete support for the abstract data type paradigm.  Ada
>    was explicitly intended as an interim solution, covering the range
>    1983..20xx, and not as "the perfect language".  Perhaps for Ada it is
>    already too late.  But the issue needs to be thoroughly discussed,
>    because it is a major area in which Ada has "missed the boat". 

I tend to agree with your last comment.  But Ada's abstraction mechanisms will never
be improved in the next revision without a proposal that is carefully thought out and
is fully consistent with the goals of the language.  As I've tried to illustrate, none
of the proposals I've seen for assignment overloading come close to meeting these criteria.

-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------

Re: Collective response to := messages

[William Thomas Wolfe,2847,]

From article <10913@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
> Alternatively, suppose ":=" overloadings are required to have an in out-mode 
> parameter to represent the target variable.  Then it would be impossible 
> to assign to an undefined variable, because the variable would first be 
> constraint-checked when it is passed in to the assignment procedure.

    This is a question which applies to any assignment procedure,
    whether ":=" or "ASSIGN".  The way I do it is to use in-out mode
    and implement the ADT as a pointer to a descriptor.  That way,
    I take advantage of the fact that all pointers are automatically
    initialized to null, and I use the null-pointer state as the 
    "empty" or "undefined" state of my ADT.  I'd prefer that all
    data types were automatically initialized to "undefined", so I
    could save the space and time associated with the pointer, but
    the workaround does get the job done.
 
>>    The problems mentioned pertain specifically to this implementation
>>    only; if EVEN were implemented as a limited private type within an
>>    appropriate package, all the operations mentioned would be available 
>>    only through the procedures/functions provided.  Type conversions
>>    would not be legally expressible in the usual notation, most attributes
>>    would not be defined, etc.  Ada 83 allows us to do all of these things,
>>    but not in the "conventional" notation.  
> 
> That's the whole point of why you don't need assignment overloading!!!  
> You can also do assignment with limited private types, but not in the 
> "conventional" notation.  All you need to do is provide an "appropriate 
> subprogram".

    Yes, I've been doing exactly that for a long time now.

>>    Only assignment and destruction play vital roles in the evaluation of
>>    parameters and in the creation and destruction of variables (particularly
>>    with regard to block entry and exit).  It is the fact that the language
>>    does not consider the impact of these mechanisms upon the ADT paradigm,
>>    mechanisms which can play havoc with our abstractions, that compels us 
>>    to call for changes in the language with regard to the ability to
>>    define specific procedures for assignment and destruction which are 
>>    taken into consideration by these mechanisms. 
> 
> We can argue about implicitly invoked destruction mechanisms some other time, 
> since Ada provides no such animal.  And Ada's parameter passing mechanisms 
> are defined implicitly, beyond the reach of the programmer, as they should 
> be (again to enforce type checking)--they have nothing to do with assignment 
> at the source level.  Regarding your assignment "abstraction", all I can 
> offer is the suggestion that reduction to LCD form is an over-specification 
> of what I consider to be the normal semantics of an assignment operation, 
> and it is better left to another procedure [...]

   The LCD example is not mine, and I'll leave it to the author of the
   example to make whatever counterpoints are appropriate.  But with regard
   to the point concerning enforcement of type checking, I'd like to point
   out that the example you gave was one in which you did NOT define an ADT;
   all you did was define a local record type.  I made the suggestion earlier
   that the definition of assignment, comparison, and other operators be
   restricted to the package specification in which the (limited) private 
   ADT type was defined.  The intent was to prohibit the implementation of
   an assignment operator over some limited private type declared somewhere
   else (e.g., TEXT_IO.FILE_TYPE).  Another point: the ADT-handling package
   could leave the denominator as an undefined integer if it jolly well
   felt like it, as long as it met the requirements imposed by the package
   specification.  I don't see how that would constitute any violation of
   type checking.  
   
>>    It is entirely possible that given the desire of AJPO to minimize the
>>    extent of changes in the language, it will not be possible to get Ada
>>    to provide complete support for the abstract data type paradigm.  Ada
>>    was explicitly intended as an interim solution, covering the range
>>    1983..20xx, and not as "the perfect language".  Perhaps for Ada it is
>>    already too late.  But the issue needs to be thoroughly discussed,
>>    because it is a major area in which Ada has "missed the boat". 
> 
> I tend to agree with your last comment.  But Ada's abstraction mechanisms 
> will never be improved in the next revision without a proposal that is 
> carefully thought out and is fully consistent with the goals of the 
> language.  As I've tried to illustrate, none of the proposals I've seen 
> for assignment overloading come close to meeting these criteria.

    I think providing complete support for the abstract data type paradigm
    is fully consistent with the goals of the language; as for carefully
    thought out proposals, a major purpose of this discussion is to uncover
    bugs in the details of the proposal prior to filing the 9X revision
    forms (which were made available by AJPO at Tri-Ada '88).  The points
    that have been made by you and others have done that.  Whether the 
    finalized request will be within AJPO's tolerance for change is,
    of course, still very much an open question.  But in this language
    or the next, the abstraction mechanisms available to programmers
    will be significantly stronger as a result. 


                                       Bill Wolfe

                                wtwolfe@hubcap.clemson.edu

Re: Collective response to := messages

[David S. Rosenblum]

In article <3702@hubcap.UUCP> wtwolfe@hubcap.clemson.edu writes:
>From article <10913@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
>
>   The LCD example is not mine, and I'll leave it to the author of the
>   example to make whatever counterpoints are appropriate.  But with regard
>   to the point concerning enforcement of type checking, I'd like to point
>   out that the example you gave was one in which you did NOT define an ADT;
>   all you did was define a local record type.

I constructed the example that way for clarity.  The arguments are just
as valid if I make the type private in some package.  The declared
objects would still be undefined, and the assignment of 0.0 would still
leave a component undefined.

Your suggestion of implementing ADTs as access types gets around the
problems I mentioned with parameter passing, but allowing overloading of
assignment then requires a great deal of faith (misguided in my view) in
the programmer to implement his or her ADTs in such a safe manner.  I
guess you could argue that many other language features have a similarly
implicit faith in the sanity of the programmer.

>   Another point: the ADT-handling package
>   could leave the denominator as an undefined integer if it jolly well
>   felt like it, as long as it met the requirements imposed by the package
>   specification.  I don't see how that would constitute any violation of
>   type checking.  

The ADT-handling package may feel like leaving a component undefined, but
Ada doesn't feel like leaving variables undefined after an assignment.
That's why such a user-defined assignment violates Ada's strong typing.


-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------

Re: Collective response to := messages

[William Thomas Wolfe,2847,]

From article <10918@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
> 
> The ADT-handling package may feel like leaving a component undefined, but
> Ada doesn't feel like leaving variables undefined after an assignment.
> That's why such a user-defined assignment violates Ada's strong typing.

      Really?  Consider the following:

         procedure FUN_WITH_UNDEFINED_VARIABLES is

            A : INTEGER;    -- A is undefined...
            B : INTEGER;    -- B is undefined...
         
         begin
            A := B;   -- Quick, what value does A have? 
         end FUN_WITH_UNDEFINED_VARIABLES;

      This compiles and executes under Alsys Ada.

Re: Collective response to := messages

[David S. Rosenblum]

In article <3720@hubcap.UUCP> billwolf@hubcap.clemson.edu writes:
|From article <10918@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
|> 
|> The ADT-handling package may feel like leaving a component undefined, but
|> Ada doesn't feel like leaving variables undefined after an assignment.
|> That's why such a user-defined assignment violates Ada's strong typing.
|
|      Really?  Consider the following:
|
|         procedure FUN_WITH_UNDEFINED_VARIABLES is
|
|            A : INTEGER;    -- A is undefined...
|            B : INTEGER;    -- B is undefined...
|         
|         begin
|            A := B;   -- Quick, what value does A have? 
|         end FUN_WITH_UNDEFINED_VARIABLES;

Easy.  A has a value that satisfies the constraints on INTEGER, which
implies that B does also.  We splitting hairs here, but I'll give it
to you--A is still undefined.

Note that you're relying on INTEGER being implicitly initialized with a valid
value; this is probably considered erroneous (I don't have an LRM
on hand).

|
|      This compiles and executes under Alsys Ada.

I don't doubt it.  Do you seriously regard this as "proof" that assignment
doesn't incorporate type checking?


-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------

Re: Collective response to := messages

[William Thomas Wolfe,2847,]

From article <10959@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
> In article <3720@hubcap.UUCP> billwolf@hubcap.clemson.edu writes:
> |From article <10918@ulysses.homer.nj.att.com>, by dsr@hector.UUCP (David S. Rosenblum):
> |> 
> |> The ADT-handling package may feel like leaving a component undefined, but
> |> Ada doesn't feel like leaving variables undefined after an assignment.
# |> That's why such a user-defined assignment violates Ada's strong typing.
# |
# |         [FUN_WITH_UNDEFINED_VARIABLES]
# 
# Easy.  A has a value that satisfies the constraints on INTEGER, which
% implies that B does also.  We splitting hairs here, but I'll give it
% to you--A is still undefined.
% 
% Note that you're relying on INTEGER being implicitly initialized with a valid
% value; this is probably considered erroneous (I don't have an LRM
@ on hand).
@ 
@ |
@ |      This compiles and executes under Alsys Ada.
@ 
@ I don't doubt it.  Do you seriously regard this as "proof" that assignment
@ doesn't incorporate type checking?

     Well, you are quoted above as saying (correct me if I'm wrong...) that
     Ada somehow required that a variable be defined after assignment, and
     that a user-defined assignment such as the one you described could leave
     a component undefined and therefore violate strong typing.  

     As far as I'm concerned, if we implemented your example as a user-defined
     ADT, the only problem that could occur would be failure of the implementor
     to properly respond to a request for the value of the denominator.  If the
     implementor handles the request properly, it wouldn't matter if there were
     undefined components; the user can never access them anyway, and in general
     will never know the difference.  In other words, the implementor may well
     view the state in which the denominator is undefined as a valid state of
     the ADT.  I see nothing wrong with that. 
  

Re: Collective response to := messages

[David S. Rosenblum]

In article <3736@hubcap.UUCP> billwolf@hubcap.clemson.edu writes:
|
|     Well, you are quoted above as saying (correct me if I'm wrong...) that
|     Ada somehow required that a variable be defined after assignment, and
|     that a user-defined assignment such as the one you described could leave
|     a component undefined and therefore violate strong typing.  

Yes, that was an exaggeration that I am more than happy to retract.  Replace
that statement with "Ada doesn't feel like allowing a variable to have
a value outside of its type after an assignment to the variable.  Your
example certainly didn't demonstrate any weaknesses in Ada's type checking
semantics, which has been the real crux of the whole discussion.

|
|     As far as I'm concerned, if we implemented your example as a user-defined
|     ADT, the only problem that could occur would be failure of the implementor
|     to properly respond to a request for the value of the denominator.  If the
|     implementor handles the request properly, it wouldn't matter if there were
|     undefined components; the user can never access them anyway, and in general
|     will never know the difference.  In other words, the implementor may well
|     view the state in which the denominator is undefined as a valid state of
|     the ADT.  I see nothing wrong with that. 
|  

For the umpteenth time, the point of my example was to show that user-definable
assignment is a means of circumventing type checking.  I was not concerned
with the mindset of the implementor or the user of the abstraction--we can
talk all day about what an ideal safe programmer would do.  If you
find such a weak semantics for := acceptable, then you are certainly entitled
to your opinion.  I'm just suggesting that you'll probably never see
such a semantics in Ada.

I'm afraid I've exhausted whatever supply of insight I may have been able
to offer on assignment overloading.  I feel I've spent more space quoting
the reference manual on language fundamentals than I have on arguing any
substantive points.  In short, Ada is not a language to consider using if you
desire (1) condoned mechanisms for circumventing type checking, (2) parameter
passing mechanisms defined in terms of assignment, as assignment is defined
at the source level.


-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------

Re: Collective response to := messages

[Stephe Leake]

In article <10962@ulysses.homer.nj.att.com> dsr@hector.UUCP (David S. Rosenblum) writes:

   ... I feel I've spent more space quoting
   the reference manual on language fundamentals than I have on arguing any
   substantive points.  ...

I, for one, appreciate the time and the pointers. The LRM is complex
enough that it takes discussions like this to fully educate the user.

Thanks!

Stephe Leake 	(301) 975-3431 		leake@cme.nbs.gov
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Rm. B-124, Bldg. 220
Gaithersburg, MD  20899

Re: Collective response to := messa

[stt]

Here is another example of assignment leaving
uninitialized components:
    type Rec is record
        F : Positive;
        G : Positive := 5;
    end record;

    X : Rec;
    Y : Rec;
begin
    Y := X;

In this example predefined assignment, the compiler is NOT required to
perform any constraint checks, and it is quite possible
that Y.F is < 0 after the indicated assignment.
It would be erroneous to use the value of Y.F, and it would
be erroneous to use Y as a whole as an operand to "=" or "/=",
but the assignment itself is not erroneous.  (See LRM 3.2.1:18 for
discussion of erroneous use of uninitialized scalar subcomponents).

S. Tucker Taft
Intermetrics, Inc
Cambridge, MA  02138

Re: Collective response to := messa

[David S. Rosenblum]

In article <124000022@inmet> stt@inmet writes:
|Here is another example of assignment leaving
|uninitialized components:
|    type Rec is record
|        F : Positive;
|        G : Positive := 5;
|    end record;
|
|    X : Rec;
|    Y : Rec;
|begin
|    Y := X;
|
|In this example predefined assignment, the compiler is NOT required to
|perform any constraint checks, and it is quite possible
|that Y.F is < 0 after the indicated assignment.
|It would be erroneous to use the value of Y.F, and it would
|be erroneous to use Y as a whole as an operand to "=" or "/=",
|but the assignment itself is not erroneous.  (See LRM 3.2.1:18 for
|discussion of erroneous use of uninitialized scalar subcomponents).

I don't have an LRM handy, but I believe that the compiler IS required
to implement the constraint checks.  But the constraint check performed by
the generated code may fail, if it is unable to distinguish an undefined
value from a correct value, or if undefined objects happen to be elaborated
in a valid state.  Thus, what is erroneous then is the reliance on a such a
quirk of the implementation.

Nevertheless, this example is hardly a justification for a further
weakening of Ada's strong typing model.  I don't feel any better knowing
that I can avoid writing an un-erroneous program in this case if I never
subsequently use the erroneously assigned object.  Yes, Ada allows unchecked
programming, Ada defines certain program constructions to be erroneous, Ada
defines representation clauses, etc.  These are red herrings in a discussion
of proposals to improve Ada's abstraction mechanisms.  Maybe I'm incredibly
naive, but I would like to see language improvements discussed based on the
assumption that we will adhere as best as possible to the spirit of Ada's
fundamental language philosophies.


-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------

CORRECTION Re: Collective response to := messages

[David S. Rosenblum]

In article <10906@ulysses.homer.nj.att.com> dsr@hector.UUCP (David S. Rosenblum) BLEW it!:
|
|In order to enforce this [evenness] constraint
|consistently in the manner of Ada, I would want to do the following:
|
|(1) Overload := so that it raises CONSTRAINT_ERROR when given an odd
|    right-hand-side.
|(2) Overload the attributes 'SUCC and 'PRED so that they skip odd values.
|(3) Overload the attributes 'POS and 'VAL so that count only even values.
|(4) Overload the attribute 'FIRST so that it returns the smallest even
|    value of EVEN's base type.
|(5) Overload the attribute 'LAST so that it returns the largest even
|    value of EVEN's base type.
|(6) Overload the membership tests and the ".." token so that only
|    even ranges are considered.
|(7) Overload the indexing operation for all array types I define that are
|    indexed by EVEN values, so that even-numbered components are stored and
|    accessed contiguously.
|(8) Overload the aggregate operation for such array types so that
|    the index values for the aggregate are computed "the right way".
|
|Yet after all these exertions, my evenness constraint would STILL not
|be enforced consistently, unless I was given several more language changes.
|For example, type conversions, qualifications, attribute evaluations and
|membership tests never propagate exceptions.

Oops, type conversions and qualifications CAN propagate exceptions,
so add the following to the above list:

(9)  Overload type conversion on EVEN so that CONSTRAINT_ERROR will be
     raised by an attempt to convert an odd value.
(10) Overload qualification on EVEN so that CONSTRAINT_ERROR will be
     raised by an attempt to qualify an odd value.

The rest of my message stands as written.


-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------

Re: Collective response to := messages

[Ray Trent]

In an article dsr@hector.UUCP (David S. Rosenblum) writes:
>domains and algebras.  However, assignment is a concept that is peculiar to
>programming languages, so in a sense you're comparing apples and oranges.

Untrue. "Let S = foo" is an idea from mathematics. But this is an aside.

>And most "sensible" definitions of assignment that I know of describe
>assignment simply in terms of placing a value in a variable or memory 

Except C's definition, of course, which is that = is an operator that
returns a value and has a domain and range.

>meaning, but you are not able to override Ada's type checking.  Thus,
>allowing overloading of assignment (or any basic operation) would seriously
>weaken Ada's strong typing features.

I'm afraid unchecked programming already does that. If the language 
designers were sooooo concerned about strong typing, why was unchecked
programming included at all? Was it perhaps because programmers know
that strong typing is a crock? I'd rather have nastiness like non-strong
typing out in the open, rather than hidden away in places where it
can't necessarily be found. (like package bodies, for example)

>Ada's constraint language (such as LCD-ness).  So why stop with assignment?
>Wouldn't you need overloading of all the basic operations?  Suppose

Of course you would. (and do)

>	type EVEN is new INTEGER;
>which I want to constrain in a way that would require all variables of
>the type to have even values.  In order to enforce this constraint
[several other basic operations overloaded]

>For example, type conversions, qualifications, attribute evaluations and
>membership tests never propagate exceptions.  Yet what would be the effect

And why not? They often should.

>perform I/O on EVEN values.  How do I get the instantiation to enforce my
>evenness constraint?  First I would need another language change that requires

You shouldn't have to in a language that purports to have strong typing.
Simply using a value outside of the constraints of the ADT should raise
a constraint error.

I don't actually propose we change the language to allow assignment
overloading. It would cause too many problems at this late date.

I'm just saying it wasn't designed right the first time. I would
argue that if assignment cannot be overloaded in any situation then
"=" should not be overloadable in any situation. In fact, I think
it's inconsistant to allow overloading of any kind if you don't allow
overloading of all kinds. After all, it's just as easy to type
"FooReal(X)" and "FooInt(X)" as it is to type just "Foo(X)", right? hurm.
And more understandable, right? Might even be more readable, neh?
Not allowing ":=" to be overloaded because it's "special" is a kludge.



-- 
"Our little lives get complicated
 It's a simple thing
 Simple as a flower
 And that's a complicated thing"                     ../ray\..

Re: Collective response to := messages

[David S. Rosenblum]

In article <24922@sri-unix.SRI.COM> trent@unix.sri.com (Ray Trent) writes:
>In an article dsr@hector.UUCP (David S. Rosenblum) writes:
>>domains and algebras.  However, assignment is a concept that is peculiar to
>>programming languages, so in a sense you're comparing apples and oranges.
>
>Untrue. "Let S = foo" is an idea from mathematics. But this is an aside.

This is NOT assignment as we know it in programming languages.  You don't
later assign new values to S, there is no "storage" of foo in S, etc.  Your
expression is simply a use of the equality relation to state an assumption
or axiom.  You are guaranteed from the substitutivity of equality that ALL
subsequent occurrences of S may be replaced by "foo".  Substitutivity of
this kind is not a property of assignment.

>>And most "sensible" definitions of assignment that I know of describe
>>assignment simply in terms of placing a value in a variable or memory 
>
>Except C's definition, of course, which is that = is an operator that
>returns a value and has a domain and range.

Yes, assignment in C is an operator.  And you've just justified further the
argument that Ada's assignment is NOT an operator, since it returns no
value.  It's seems silly to use such high-falutin' terms as "domain" and
"range" to describe assignment in C though, because due to C's weak enforcement
of type constraints, assignment can operate on arbitrary unions of domains.

>>meaning, but you are not able to override Ada's type checking.  Thus,
>>allowing overloading of assignment (or any basic operation) would seriously
>>weaken Ada's strong typing features.
>
>I'm afraid unchecked programming already does that. If the language 
>designers were sooooo concerned about strong typing, why was unchecked
>programming included at all? Was it perhaps because programmers know
>that strong typing is a crock? I'd rather have nastiness like non-strong
>typing out in the open, rather than hidden away in places where it
>can't necessarily be found. (like package bodies, for example)

Yes, unchecked programming is provided in the language, but its use is heavily
discouraged.  The semantics of unchecked programming are largely left to the
discretion of the implementor, therefore making unchecked programming
a highly non-portable feature of the language.  And note the following
(admittedly difficult-to-enforce) admonition in the LRM:  "Whenever unchecked
conversions are used, it is the programmer's responsibility to ensure
that these conversions maintain the properties that are guaranteed by the
language for objects of the target type.  Programs that violate these
properties by means of unchecked conversions are erroneous."
(Book 13, Chapter 10.2, Verse 3).

"Correct use" of Ada demands a good faith effort to construct portable
programs.  (Pardon the weasel wording.)  If you believe strong typing to
be a crock (and I'm one programmer that DOESN'T "know" that it's a
crock), then why are you lamenting the unsatisfactory character of
Ada's abstraction mechanisms?  (Maybe you never said this; I'm getting confused
as to who has argued what.)  C gives you all the "abstraction" mechanisms
you seem to desire--a wide open window to the implementation details of
your data types.

We seem to be getting away from the subject.  Somebody has suggested
allowing overloading of assignment in Ada.  I have been arguing against
this proposal from the hypothetical viewpoint of a person in charge of
updating the language.  Arguments about some of Ada's fundamental language
philosophies seem out of place in this context.

>I'm just saying it [assignment] wasn't designed right the first time. I would
>argue that if assignment cannot be overloaded in any situation then
>"=" should not be overloadable in any situation. In fact, I think
>it's inconsistant to allow overloading of any kind if you don't allow
>overloading of all kinds.

This seems like an arbitrary argument.  Overloading of operators
(in the Ada sense) seems justifiable, since the operators aren't
directly concerned with the semantics of strong typing.  You can
give kooky semantics to your favorite mathematical operator, but those
semantics may be characteristic of an abstraction.  However, overloading
of Ada's basic operations does not seem justifiable, because they are
intimately concerned with the implementation of strong typing.


-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------

Re: Collective response to := messa

[stt]

>  However, overloading
> of Ada's basic operations does not seem justifiable, because they are
> intimately concerned with the implementation of strong typing.

I don't agree with the validity of this argument.  Replacing user-defined
assignment with builtin assignment could never create a violation
of strong typing, in the sense that an inappropriate value would be placed
in a variable.  If assigning one type to another is considered
a "violation" then this could be disallowed by rules similar to those
that applied to "=", namely that the base types of the parameters
to user-defined assignment must be the same.

In fact, given the rules associated with parameter passing, there is
no way that the substitution of a user-defined operation for
a builtin operation could violate "strong typing."  If anything,
the user-defined operation would be limited to more strict
rules, because the intermediate results would not be allowed
to violate range restrictions.

I think the only "valid" argument against user-defined assignment is an
aesthetic/philosophic one, namely that it will have different visibility
rules from user-defined operators.  In particular, a := b will NOT be
strictly equivalent to ":="(a,b), but rather will be interpreted
in a local scope including an implicit "use" of the package
in which the operand type is defined.

However, the very great advantage of providing user-defined assignment
outweighs this aesthetic one in my opinion.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138

Re: Collective response to := messages

[Robert Eachus]

     There has been a lot of frothing at the mouth on both sides of
this issue about what is or is not the Ada model of assignment.  First
of all a lot has been said about what a change to the language it
would be to make assignment or other basic operations overloadable.
However, if you look in 8.7 Context of Overload Resolution, the first
paragraph states:

     "Overloading is defined for subprograms, enumeration literals,
operators, and single entries, and also for the operations that are
inherent in several basic operations such as assignment, membership
tests, allocators, the literal null, aggregates, and string literals."

      Overloading, and overload resolution involving basic operations
is a fact of Ada life.  If you think otherwise try:

      package Overload_Test is
        type A is access Boolean;
        B: constant Boolean := null = null;
        type C is access Character;
        D: constant Boolean := null = null;
      end Overload_Test;

      The compiler should accept the decalartion of B, but reject the
declaration of D.  A lot of work went on during the language
definition process to make similar (but useful) cases work for numeric
types. If you object that this example involves equality which is not
a basic operation instead try:

       package Overload_Two is
	 A: Boolean := 'b' in 'a'..'c';
         type New_Char is ('b', 'a', 'c');
	 C: Boolean := 'b' in 'a'..'c';
       end Overload_Two;

Re: Collective response to := messages

[David S. Rosenblum]

In article <42334@linus.UUCP> eachus@mbunix.mitre.org (Robert I. Eachus) writes:
|
|     "Overloading is defined for subprograms, enumeration literals,
|operators, and single entries, and also for the operations that are
|inherent in several basic operations such as assignment, membership
|tests, allocators, the literal null, aggregates, and string literals."
|
|      Overloading, and overload resolution involving basic operations
|is a fact of Ada life.

Yes, but there is an important difference between overloading of operators,
subprograms, etc., and overloading of basic operations.  Overloaded basic
operations are ALWAYS implicitly defined--they can NEVER be user-defined.
It is the proposal to allow user-defined overloadings of basic operations
that is prompting all the "frothing".


-------------------------------------------------------------------
David Rosenblum			UUCP: {ucbvax, decvax}!ulysses!dsr
AT&T Bell Laboratories		ARPA: dsr@ulysses.att.com
600 Mountain Ave.		      dsr%ulysses@att.arpa
Murray Hill, NJ 07974-2070
(201) 582-2906
-------------------------------------------------------------------

Re: Collective response to := messages

[Mark C. Adolph]

In article <24856@sri-unix.SRI.COM>, trent@unix.SRI.COM (Ray Trent) writes:
> The LRM explicitly says that intermediate
> results need not follow the constraints of the ADT. 

Could you cite this in the LRM?  This could be a very important point for
we who are trying to model physical quantities (length, temperature,
density, etc.) as derived types and trying to do operations on these
types.

-- 

					-- Mark A.
					...uw-beaver!ssc-vax!adolph

Re: Collective response to := messa

[stt]

In LRM paragraph 11.6:6 --
  ... For the evaluation of a predefined oepration, an implementation
is allowed to use the operation of a type that has a range wider than
that of the base type of the operands, provided this delivers the exact
result (or a result within the declared accuracy, in the case of a
real type), even if some intermediate results lie outside the range
of the base type.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138

Re: Collective response to := messages

[William Thomas Wolfe,2847,]

From article <8811282217.AA04896@ajpo.sei.cmu.edu>, by mendal@ANNA.STANFORD.EDU (Geoff Mendal):
>>   Another reason is that assignment procedures need to be invoked as part
>>   of the evaluation of a user-defined ADT which is passed by value.  No
>>   similarly vital function is performed by the other operations suggested.
> 
> I don't understand this at all.  You are assuming pass by value for an
> ADT?  Rediculous.  The LRM only states that scalars and access values
> are passed by copy.  In general, for an ADT, you cannot assume pass by
> value and if your program depends on it, your program will execute
> erroneously.  

    This is precisely the problem.  This is what must be fixed.

> [Argues that the proposal would mean more work for language designers]
>
> [Argues that the proposal would mean more work for program provers]
>
> [Argues that the proposal would mean less work for him, since he
>  is employed as a writer of preprocessor tools for Ada]

     Much more money is spent using a programming language such as Ada
     than is spent designing it.  Hence, if we can save the time of
     30 million programmers at the expense of the time of 300 language
     designers, I submit that this is an appropriate tradeoff.  

     What is needed is a completion of the ADT paradigm, support for
     which is the fundamental reason for the "limited private" feature.
     Given that one must remember to destroy all non-predefined ADTs 
     upon block exit, it is clear that the implications of this paradigm 
     were not appropriately considered in the Ada 83 design. 

Re: limited private types

[Erland Sommarskog]

Ron Guilmette (rfg@nsc.nsc.com.UUCP) wants to be able to defer the 
implementation of a (limited) private type to the body of his package.
He writes:
>Anyway, I *do* know about the special tricky Ada rule which allows you
>to defer a full type definition until the corresponding package body
>...
>Basically, about the only thing you can do with such objects is to pass
>them as actual parameters to subprograms.  Obviously, if you do this, then
>for each such subprogram, the actual *definition* of the given subprogram
>must be compiled only *after* the full type declaration has already been
>compiled.
>...
>Since any given Ada compiler must generate code to copy scalar actual
>parameters into their corresponding formals, and since the most efficient
>...

Since you have thought so much on the not-so-obvious problem of parameter 
passing, you must have found the answer to the more obvious problem of
heap and stack allocation as trivial. I am probably stupid, because I
fail to see any attractive solutions to that. If in my block I declare:
   A : A_limited_type;
   B : Another_limited;
   C : ARRAY(1..20) OF Yet_another_limited;
If the implementation of the types in available in the specification 
of the types originating package, there is no problem. But if you defer
them to the body, and do not allow cheating with pointers? Enlighten
me, how to you allocate them on the stack? Implicit pointers? Some
implicit size-telling function called at run-time? Not very attractive,
since the place on the stack for other local variables is dependent 
of the size of the types.

To be straight I think that the pointer "trick" serves our needs 
perfectly here, and that your proposal is just YAUAC. (Yet Another 
Unnecessary Ada Change.)
-- 
Erland Sommarskog
ENEA Data, Stockholm
sommar@enea.se
"Frequently, unexpected errors are entirely unpredictable" - Digital Equipment

Memory Access Question

[tony]

Does anyone have a code fragment that demonstrates how to access memory?
I am looking for a program that tests memory.  Instruction and data space
are seperate on my machine and I am trying to test RAM from 0 to n.  I have
looked at the "access" data type and can't figure out how to initialize it
to 0 let alone increment the pointer by 1.  The representation
specification doesn't seem to provide the answer either.  Any and all help
is greatly appreciated.

Tony Becker			Phone: 407-356-9334
University of Central Florida	csnet: tony@ucf-cs.ucf.edu
Orlando, FL  32816		uucp:  {ihnp4!decvax,peora}!ucf-cs!tony

Re: Memory Access Question

[richard a hammond]

In article <18800002@ucf-cs.ucf.edu> tony@ucf-cs.ucf.edu writes:
>
>Does anyone have a code fragment that demonstrates how to access memory?
>I am looking for a program that tests memory.  Instruction and data space
>are seperate on my machine and I am trying to test RAM from 0 to n.  I have
>looked at the "access" data type and can't figure out how to initialize it
>to 0 let alone increment the pointer by 1.  The representation
>specification doesn't seem to provide the answer either.  Any and all help
>is greatly appreciated.
>Tony Becker			Phone: 407-356-9334
>University of Central Florida	csnet: tony@ucf-cs.ucf.edu
>Orlando, FL  32816		uucp:  {ihnp4!decvax,peora}!ucf-cs!tony

Argh!!! No matter what you come up with in Ada, I can't believe that it
would be portable across all machines - so why try to write it in Ada?

Why not make it explicit to the next person porting the code that this
code is going to break all the access controls and possibly muck up
all memory (or do you just want to see if you can read it?) and write
it in assembler?

Besides, the several lines of assembly required to do this are as readable
for most competent programmers as the dozens of lines of Ada.

If you're doing a lot of other work, just write a trivial assembly
language routine that takes two unsigned integers and stuffs the
second argument's lower n (n = 8, 16, 32, 64, ...) bits into the
physical/logical address implied by treating the first argument as
an address.  And another assembly routine to read the contents.

Ada was designed to write portable, safe software.  Reading/writing
all locations in memory is possibly portable, but certainly not safe.
Use the tool suited to the job, assembly language.

Rich Hammond

Re: Memory Access Question

[Ray Trent]

In the above article, hammondr@sunroof.crd.ge.com (richard a hammond) writes:
>In article <18800002@ucf-cs.ucf.edu> tony@ucf-cs.ucf.edu writes:
>>I am looking for a program that tests memory.  Instruction and data space
>>are seperate on my machine and I am trying to test RAM from 0 to n.  I have
>[various other grumbling]
>Ada was designed to write portable, safe software.  Reading/writing
>all locations in memory is possibly portable, but certainly not safe.
>Use the tool suited to the job, assembly language.

Why not just say: No, you can't do it in Ada (easily), nor should you
want to. This is not convincing if a client wants *all* of the code
delivered to be written in Ada (many of them are absolutely stupid
about this). Or perhaps you could just say: check if your
implementation uses integers as pointers and use unchecked conversion
to do pointer arithmetic. 

The answer to the question is: it's implementation dependent whether
you can even do what you want in Ada...if access types are implemented
as integers, you have a pretty good chance of being able to do what
you want via unchecked conversion. If that's unacceptable, then you're
out of luck, use another language.
-- 
"When you're down, it's a long way up
 When you're up, it's a long way down
 It's all the same thing
 And it's no new tale to tell"                      ../ray\..

Re: Memory Access Question

[Mike Murphy]

Others have commented that you should write in assembler to 
do low-level memory accesses, but keep in mind that you don't
really need to leave Ada to use assembly language:  just use
machine-code insertions!   It's for this kind of application
that Ada provides machine_code.  Now if your compiler does not 
support machine code then you're out of luck, but a number of 
good Ada compilers do.
-- 
-- Mike Murphy
-- UUCP: sun!decwrl!mips!murphy
-- AT&T: (408) 991-0438

Re: Memory Access Question

[Mike Walsh]

>>Others have commented that you should write in assembler to 
>>do low-level memory accesses, but keep in mind that you don't
>>really need to leave Ada to use assembly language:  just use
>>machine-code insertions!   It's for this kind of application
>>that Ada provides machine_code.  Now if your compiler does not 
>>support machine code then you're out of luck, but a number of 
>>good Ada compilers do.
>>-- 
>>-- Mike Murphy
>>-- UUCP: sun!decwrl!mips!murphy
>>-- AT&T: (408) 991-0438

 In my experience, writing machine code insertions is not as trivial as
 this posting makes it out to be.  The project I worked on was and ARMY
 contract and they wanted everything done in Ada.  We were using the
 Softech Ada86 Compiler and an Intel 80186.  Softech provided the Machine
 Code Package, but it was incomplete or erroneous.  Plus anyone writing
 machine code insertions had better be better than just average assembly
 language programmer.  IMHO it is better to write the routine in Assembly,
 and pass an Address to the routine from the Ada caller, or just invoke
 an Assembly Language routine from Ada, since if the code needs to be 
 protable, it is likely that the architecture of the machine that the
 porting is being done on is different from the original machine.  Since
 the architecture is most likely different, the memory scheme is probably
 different.  I also feel that a good Assembly Language Routine that is
 well documented is much more maintainable than a peice of code written
 in machine code insertions.  BTW, machine code insertions are machine
 dependent anyway.


...Mike

Mike Walsh, Electrical Engineer
Star Technologies 
Graphicon Products Division
P.O. Box 13951
Reserach Triangle Park, NC 27709
(919) 361-3800

walsh@stdc01.UUCP   {...!uunet!mcnc!rti!stdc01!walsh}

Re: Memory Access Question

[Mike Murphy]

In article <513@stdc01.UUCP> walsh@stdc01.UUCP (Mike Walsh) writes:
> In my experience, writing machine code insertions is not as trivial as
> this posting makes it out to be.  The project I worked on was and ARMY
> contract and they wanted everything done in Ada.  We were using the
> Softech Ada86 Compiler and an Intel 80186.  Softech provided the Machine
> Code Package, but it was incomplete or erroneous.  Plus anyone writing
> machine code insertions had better be better than just average assembly
> language programmer.  IMHO it is better to write the routine in Assembly,
> and pass an Address to the routine from the Ada caller, or just invoke
> an Assembly Language routine from Ada....

It sounds to me like your problem was not with machine code but that your 
compiler provided a weak implementation of machine code.  Machine code
lets you access the full range of assembly language, plus (at least in 
Verdix-based implementations) allows you to access Ada objects from 
within machine code.  So anything you can do in pure assembly language 
you can also do in machine code, plus you have added functionality.
The ability to access Ada objects (parameters and global variables)
is a definite advantage of machine code (admittedly this functionality 
does not have to be supported and is not in all implementations of 
machine code).  Plus you can enhance performance by inlining machine code 
procedures, unlike assembly language routines that are linked in.

> ....  I also feel that a good Assembly Language Routine that is
> well documented is much more maintainable than a peice of code written
> in machine code insertions. 

Why?  What's the difference between the two?

-- 
-- Mike Murphy
-- UUCP: sun!decwrl!mips!murphy
-- AT&T: (408) 991-0438

Re: Memory Access Question

[Brian Sullivan]

  It is possible to use UNCHECKED_CONVERSION to provide access
memory locations.  The following Ada package will allows you
to read and write to memory locations.

  The file depends on the existence of a predefined integer type
that is the same size as SYSTEM.ADDRESS, and the SYSTEM.ADDRESS
is of the same size as a pointer or access object.

------------------------------------------------------------------------
with SYSTEM;
package MEMORY is

   --
   -- The predefined integer type used for the type ADDR_INT
   -- must be the same size in bits as the type SYSTEM.ADDRESS
   -- because unchecked conversion is used to convert ADDR_INT
   -- into SYSTEM.ADDRESS
   --
   -- Also the size of an access type must be the same as the
   -- size of SYSTEM.ADDRESS
   --
   -- These two requirements are automatically check in the
   -- elaboration code for the body of this package.
   --

   type ADDR_INT is new INTEGER;      

   type DATUM is range 0 .. (2**SYSTEM.STORAGE_UNIT)-1;

   function  READ ( FROM : ADDR_INT ) return DATUM;
   
   procedure WRITE( TO : ADDR_INT; VALUE : DATUM);
   
   function  CONVERT_TO_ADDR_INT( LOC : SYSTEM.ADDRESS) return ADDR_INT; 
   
private

   pragma INLINE(READ);
   pragma INLINE(WRITE);
   pragma INLINE(CONVERT_TO_ADDR_INT);

   for DATUM'SIZE use SYSTEM.STORAGE_UNIT;
   
end MEMORY;   

with UNCHECKED_CONVERSION;
package body MEMORY is

   type DATUM_PTR is access DATUM;
   
   function CONVERT_TO_DATUM_PTR is 
      new UNCHECKED_CONVERSION( SOURCE => ADDR_INT,
                                TARGET => DATUM_PTR);
   pragma INLINE(CONVERT_TO_DATUM_PTR);

   function LOCAL_CONVERT_TO_ADDR_INT is 
      new UNCHECKED_CONVERSION( SOURCE => SYSTEM.ADDRESS,
                                TARGET => ADDR_INT);
   pragma INLINE(LOCAL_CONVERT_TO_ADDR_INT);

   function  READ ( FROM : ADDR_INT ) return DATUM is
   begin
      return CONVERT_TO_DATUM_PTR(FROM).all;
   end;
   
   procedure WRITE( TO : ADDR_INT; VALUE : DATUM) is
   begin
      CONVERT_TO_DATUM_PTR(TO).all := VALUE;
   end;
   
   function  CONVERT_TO_ADDR_INT( LOC : SYSTEM.ADDRESS) return ADDR_INT is
   begin
      return LOCAL_CONVERT_TO_ADDR_INT(LOC);
   end;
   
begin
   if ADDR_INT'SIZE /= SYSTEM.ADDRESS'SIZE then
      raise PROGRAM_ERROR;
   end if;    
   if DATUM_PTR'SIZE /= SYSTEM.ADDRESS'SIZE then
      raise PROGRAM_ERROR;
   end if;    
end MEMORY;   
   
   
 

limited private types

[r_srinivasan]

folks,

I hope someone has a reasonable suggestion for the following problem :

I am developing a file processing application that requires opening and
closing of an unspecified number of files. Ideally i would like to
build a "stack" of "files".

Currently I am using text_io package. Unfortunately the type
text_io.file_type is a "limited private" type and this means no
assignments. I have been able to get around this somewhat by using
File_access type but there is no "close" procedure that will take a
file_access.

Any and all ideas would be appreciated.

regards

srini


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: limited private types

[Marin D. Condic]

r_srinivasan@my-deja.com wrote:
> I am developing a file processing application that requires opening and
> closing of an unspecified number of files. Ideally i would like to
> build a "stack" of "files".

Well, one possible alternative is to store the information necessary to
open and close the file rather than the file itself. (The string for the
name, etc.) Of course this depends on if you have to have them open all
at once or not.

There's probably other ways, but I have not given it enough thought just
yet. In general, I'd consider it a bad idea to have lots of files open
all at once if it can be avoided. Better to open and close them as
needed. If you do need them open all at once, maybe you could collect up
the names and once the number is known, allocate an array of File_Type
that matches the number you need.

What exactly are the requirements? There may be a better alternative.

MDC
-- 
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

"I'd trade it all for just a little more"
    --  Charles Montgomery Burns, [4F10]
======================================================================

Re: limited private types

[r_srinivasan]

An array of File_Type might well do the trick even though I might have
to think up some arbitrary limits to this array. while not too elegent,
will do the trick. Thank you.

In case it matters the application is a "C" preprocessor (like) that
supports inclusion of other files . I would rather not have to close
and reopen/seek etc.

regards

srini

In article <3907DF77.5BD05EBE@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> r_srinivasan@my-deja.com wrote:
> > I am developing a file processing application that requires opening
and
> > closing of an unspecified number of files. Ideally i would like to
> > build a "stack" of "files".
>
> Well, one possible alternative is to store the information necessary
to
> open and close the file rather than the file itself. (The string for
the
> name, etc.) Of course this depends on if you have to have them open
all
> at once or not.
>
> There's probably other ways, but I have not given it enough thought
just
> yet. In general, I'd consider it a bad idea to have lots of files open
> all at once if it can be avoided. Better to open and close them as
> needed. If you do need them open all at once, maybe you could collect
up
> the names and once the number is known, allocate an array of File_Type
> that matches the number you need.
>
> What exactly are the requirements? There may be a better alternative.
>
> MDC
> --
> ======================================================================
> Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
> Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
> Visit my web site at:  http://www.mcondic.com/
>
> "I'd trade it all for just a little more"
>     --  Charles Montgomery Burns, [4F10]
> ======================================================================
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: limited private types

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]


<r_srinivasan@my-deja.com> a �crit dans le message :
8eaaa2$rkl$1@nnrp1.deja.com...
> An array of File_Type might well do the trick even though I might have
> to think up some arbitrary limits to this array. while not too elegent,
> will do the trick. Thank you.
>
> In case it matters the application is a "C" preprocessor (like) that
> supports inclusion of other files . I would rather not have to close
> and reopen/seek etc.
>
In this case, why don't you use a local variable for the file ?
Stacking will occur automatically...

There's only one trick: don't forget to close the file when you leave the
procedure that holds the variable. Otherwise, you'll leave a file open with
no way of closing it. If you declare a local file variable, it is advisable
to end the subprogram with:
exception
   when others =>
      if Is_Open (F) then
         close (F);
      end if;
end;

--
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://pro.wanadoo.fr/adalog

Re: limited private types

[Ray Blaak]

r_srinivasan@my-deja.com writes:
> Currently I am using text_io package. Unfortunately the type
> text_io.file_type is a "limited private" type and this means no
> assignments. I have been able to get around this somewhat by using
> File_access type but there is no "close" procedure that will take a
> file_access.

Assuming:

  type File_Access is access Text_IO.File_Type;
  f_ptr : File_Access;

then why can't you do Text_IO.Close(f_ptr.all)?

-- 
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
blaak@infomatch.com                            The Rhythm has my soul.

Re: limited private types

[r_srinivasan]

The "access" technique does not work because text_io.close takes an "in
out" parameter and gnat complains that the "access".all is not
a "variable".

In article <un1mfl8cp.fsf@infomatch.com>,
  Ray Blaak <blaak@infomatch.com> wrote:
> r_srinivasan@my-deja.com writes:
> > Currently I am using text_io package. Unfortunately the type
> > text_io.file_type is a "limited private" type and this means no
> > assignments. I have been able to get around this somewhat by using
> > File_access type but there is no "close" procedure that will take a
> > file_access.
>
> Assuming:
>
>   type File_Access is access Text_IO.File_Type;
>   f_ptr : File_Access;
>
> then why can't you do Text_IO.Close(f_ptr.all)?
>
> --
> Cheers,                                        The Rhythm is around
me,
>                                                The Rhythm has control.
> Ray Blaak                                      The Rhythm is inside
me,
> blaak@infomatch.com                            The Rhythm has my soul.
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: limited private types

[tmoran]

>The "access" technique does not work because text_io.close takes an "in
>out" parameter and gnat complains that the "access".all is not
>a "variable".
       This runs just fine with Gnat 3.12p NT:
with ada.text_io;
 use ada.text_io;
procedure Test is
  type ptrs is access file_type;
  p : ptrs;
begin
  p := new file_type;
  create(p.all, out_file, "pall");
  put_line(p.all, "hello world");
  close(p.all);
end Test;

Re: limited private types

[Marc A. Criley]

You can use an "access File_Type" type, allocate instances
of it, stack them, and Close them--Close(F.all).

Marc

r_srinivasan@my-deja.com wrote:
> 
> folks,
> 
> I hope someone has a reasonable suggestion for the following problem :
> 
> I am developing a file processing application that requires opening and
> closing of an unspecified number of files. Ideally i would like to
> build a "stack" of "files".
> 
> Currently I am using text_io package. Unfortunately the type
> text_io.file_type is a "limited private" type and this means no
> assignments. I have been able to get around this somewhat by using
> File_access type but there is no "close" procedure that will take a
> file_access.
> 
> Any and all ideas would be appreciated.
> 
> regards
> 
> srini
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.