user-defined assignment

user-defined assignment

[Robert Firth]

I don't want to become too embroiled in the current
debate about user-defined assignment, but one serious
misconception should, I feel, be corrected.

The ability to use ":=" as a subprogram designator
would in no way change the current strength or weakness
of Ada's typing model.  The process of overload resolution
would check actuals against formals, just as it does for,
say, "+" at present.  Naturally, a malicious implementor
could encode the body of ":=" so as to violate the typing
rules, just as an implementor of "+" can today.

Re: user-defined assignment

[David S. Rosenblum]

In article <7943@aw.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
|
|I don't want to become too embroiled in the current
|debate about user-defined assignment, but one serious
|misconception should, I feel, be corrected.
|
|The ability to use ":=" as a subprogram designator
|would in no way change the current strength or weakness
|of Ada's typing model.  The process of overload resolution
|would check actuals against formals, just as it does for,
|say, "+" at present.  Naturally, a malicious implementor
|could encode the body of ":=" so as to violate the typing
|rules, just as an implementor of "+" can today.

What "typing rules" of "+" can an implementor violate within his definition
of "+"?  I didn't know that the semantics of predefined "+" had any inherent
"typing rules" to violate.  As you say, the typing rules apply to parameters
of "+" and the return value of "+", as they do to all other subprogram
parameters and return values (e.g., in a user-defined ":=").  On the other
hand, as I understand ":=" it is restricted to copying a value of some type to
a variable of the SAME type, including a check that ALL subcomponents of the
target variable satisfy their respective constraints.  Aside from the rules
regarding implicit conversions of numeric values, I'm aware of no
rule (or AI) that sanctions a weakening of the behavior of ":=" as I've
(hastily) described it.  For example, I can "add", say, tasks to strings with
my own definition of "+".  This may violate some cherished notions about
addition, but I don't see that it "violates" any typing rules.  But with
overloaded ":=", I could assign tasks to strings; to me this violates typing
rules, as they currently apply to assignment.


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

User-defined assignment

[St ef Van Vlierberghe]

A personal opinion on the status of user-defined assignment and Ada9X.

In April ISO-WG9 decided that  user-defined  assignment is too costly,
without having a "reasonable" technical proposal.

To my knowledge, the most important technical proposal previously made
was the one by B.  Brosgol  and J-L  Gailly, 20  December  1989.  This
went as far as supporting  user-defined assignment on scalar types and
the use of this feature to get "automatic" type conversion whenever an
assignment  exists that can copy one type to another (as  requested by
the recent  post 'can I overload  ":="').  Needless  to point out that
this is not technically "reasonable".

In June I submitted a proposal for  user-defined  equality,  finalize,
assignment to the Mapping Revision Team (comment 92-1165.a).

Since then I have been adapting this proposal to the various  comments
I got, and most of the  technical  reactions  can be  summarized  to a
recent comment I got from the Mapping Revision Team (Bob Duff) :

: No, I didn't find any "serious"  problems  with your  proposal.  Maybe
: some minor  ones, but  that's  not  important.  What IS  important  is
: whether  we  spend  time  defining  a  user-defined   assignment   and
: finalization.  You think  it's very  important  that we do.  I think I
: agree.  But  most  others,  including  the  majority  of WG9  and  the
: majority of the DRs, think it's a waste of time.

In my humble opinion, WG9 is (too?)  biased towards the hard real time
market  needs.  The  majority  doesn't  care  about how  happy the C++
community is with their  user-defined  assignment, just as they didn't
care about OO programming some years ago.

A quote from a C++ user (Bob Martin) :

: If you ask my  opinion,  the  ability to  redefine  assignment  for an
: abstract  data type is critical to defining a usable  interface.  Copy
: semantics  are almost never trivial for complex  classes.  Some method
: needs to be specified  for  allowing  users to make copies of objects,
: and to assign objects.

With the variable sized data in mind, I find it hard to disagree.

Now the matter was recently re-raised by LSN-1046 (on Finalization) :

: All of this means that any finalization proposal must either prevent
: copies (i.e. limited type), or must allow the user to define the
: semantics of the copy (i.e. user-defined assignment).

I am seriously  concerned  about Ada's future if it fails to appeal to
the  scientific  information  systems and soft real time market.  Some
people may believe this is a lost cause, but I am convinced that Ada's
security would become *very* attractive if it could compete with C++'s
programmer support.

Perhaps  things  might  improve if those of you that really care about
this issue would voice explicit support for user-defined assignment.  

Ideally you would submit a comment to ada9x-mrt@inmet.com, then it will
get filed in their database, and forwarded to DRs and ISO delegates. As
these comments are processed automatically, they have to start with the
following header :

!topic User defined assignment
!reference MS-5.2,7.4.1,7.4.5;4.0
!discussion
-- 
Stef VAN VLIERBERGHE            Eurocontrol - Central Flow Management Unit
stef@cfmu.eurocontrol.be        Avenue des Arts 19H
Tel: +32 2 729 33 42            B-1040 BRUSSELS
Fax: +32 2 729 32 16            Belgium

Re: User-defined assignment

[dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!qt.cs.utexas.edu!news.Brow]

In article <1992Oct16.115805.15575@cfmu.eurocontrol.be> 
stef@cfmu.eurocontrol.be (Stef Van Vlierberghe) writes:
> . . .
>Ideally you would submit a comment to ada9x-mrt@inmet.com, then it will
>get filed in their database, and forwarded to DRs and ISO delegates. As
>these comments are processed automatically, they have to start with the
>following header :
>
>!topic User defined assignment
>!reference MS-5.2,7.4.1,7.4.5;4.0

Please don't use this format.  It will be rejected by our automatic
mail processing tool.  Each reference should be on its own line:

  !reference MS-5.2;4.0
  !reference MS-7.4.1;4.0
  !reference MS-7.4.5;4.0

In case you are interested, these references refer to sections
of the Ada 9X Mapping Specification, version 4.0, which is on-line
on the ajpo machine, available via anonymous ftp.

>!discussion

We do encourage people to comment on this issue.

The fundamental difficulty we face is the fact that
Ada already supports exceptions and abort (something only
beginning to appear in C++), and having full support
for user-defined assignment and finalization without imposing
significant per-object space overhead requires an approach
based on some kind of program counter (PC) map of the program.
Currently Ada exception handlers are typically implemented using
PC maps, but they don't have to handle the granularity of
individual component initializations of a composite object, which
would be necessary to fully support finalization via a PC map.

Array initializations are problem the worst, since these generally
occur in a loop, and so the finalization would to be done
for only those elements for which initialiation succeeded, requiring
that the exception handler have a loop that depended on the state
of the initialization loop at the time of the exception.

It will be interesting to see how C++ implementations adapt to
accommodate the addition of exception handling, given that they
already support destructors and user-defined assignment without
per-object overhead (in general).  I have seen some descriptions
of PC-map based approaches, but they seemed both complex and incomplete.
Does anyone know the strategy/complexity/efficiency of HP's C++ 
(which supposedly supports exception handling, and of course destructors)?

>-- 
>Stef VAN VLIERBERGHE            Eurocontrol - Central Flow Management Unit
>stef@cfmu.eurocontrol.be        Avenue des Arts 19H
>Tel: +32 2 729 33 42            B-1040 BRUSSELS
>Fax: +32 2 729 32 16            Belgium

S. Tucker Taft   stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: User-defined assignment

[dog.ee.lbl.gov!hellgate.utah.edu!caen!malgudi.oar.net!zaphod.mps.ohio-sta]

In article <1992Oct16.231346.11881@inmet.camb.inmet.com> you write:
> We do encourage people to comment on this issue.
Thanks, I sent a comment.

May I give you a slightly emotional reaction based on
8 years of working with Ada.  Remember that a persons
emotional reaction to a language greatly influences his
perception of its technical merit (as is evident in the
Ada vs. C++ flame wars :)

> The fundamental difficulty we face is the fact that
> Ada already supports exceptions and abort (something only
> beginning to appear in C++), and having full support
> for user-defined assignment and finalization without imposing
> significant per-object space overhead requires an approach
> based on some kind of program counter (PC) map of the program.
> Currently Ada exception handlers are typically implemented using
> PC maps, but they don't have to handle the granularity of
> individual component initializations of a composite object, which
> would be necessary to fully support finalization via a PC map.

Then don't fully support it!  How many times in Ada did a
feature not get fully supported?  How many times did Ada say a
feature's behavior was undefined, erroneous, or implementation
defined?  But that didn't stop those features from getting
introduced!  In fact, now that we know so much more about
those features, they are being enhanced (and/or restrictions
lifted) in Ada9X.

> Array initializations are problem the worst, since these generally
> occur in a loop, and so the finalization would to be done
> for only those elements for which initialiation succeeded, requiring
> that the exception handler have a loop that depended on the state
> of the initialization loop at the time of the exception.

Or don't define what happens.  So its not a perfect solution.
It really doesn't seem that difficult.  The loop in the
declarative region has a state indicating where in the
loop it is (I know the order is undefined--but let's get
real), so the exception handler uses that state to determine
how far finalization should be applied.

Really, if this is the worst, I can live with it!  This is
not worth crippling the language over.  In fact, this sounds
like the baby (user-defined assignment) is being thrown out
with the bath-water (the few problems introduced).

These arguments appear valid, but they don't apply to any
of the situations that I have uncovered in practice.  Please
don't cripple Ada9X because of these difficulties.

I am currently working on the Ada Quality & Style guide.  It
is very common for these guidelines to explain how certain
features should best be used.  It also explains where certain
dangerous programming practices should be avoided.  If there
is an Ada9X Quality & Style guide, these concerns you point
out would be ideal warnings to the practicing programmer.

Unfortunately, if user-defined assignment is not available,
the guidelines explaining how to do memory management and
garbage collection will be pretty sparce (as in Ada).  There
is no need to explain the correct way to use a feature that
doesn't exist.

Doug Smith
smithd@software.org

Re: User-defined assignment

[Tucker Taft]

In article <1992Oct17.175730.17448@software.org> 
smithd@software.org (Doug Smith) writes:

> . . .
>Unfortunately, if user-defined assignment is not available,
>the guidelines explaining how to do memory management and
>garbage collection will be pretty sparce (as in Ada).  There
>is no need to explain the correct way to use a feature that
>doesn't exist.

I should probably clarify that Ada 9X *does* provide support
for user-defined initialization and finalization.  This is provided
for all limited types that are derivatives (direct or indirect)
of a predefined tagged type System.Controlled.  The operations
are called Initialize and Finalize, and are called at the 
"appropriate" time.  However, since this is restricted to "limited"
types, the user must define their own "Assign" procedure (or equivalent)
rather than rely on ":=".  

Therefore, this sort of user-defined assignment is 
supported, and Initialize and Finalize work correctly,
in the presence of exceptions and abort.  (What this means
is that Finalize is performed on an object if and only if Initialize
is performed on the object, and both Initialize and Finalize defer abort
until they complete, once they get started.)

However, a more complete kind of support for user-defined assignmet
would allow the user to simply use the ":=" operation, and have it invoke
user-defined code.  Unfortunately, this is only the tip of the iceberg.
Assignment is used implicitly in subprogram calls for by-copy parameters,
in creating aggregates, in explicit and implicit initialization, on
function return, in assignment for composite types,
etc.  By restricting user-defined finalization to
limited types, we avoid all of this hairy stuff, though the programmer
can still implement roughly equivalent operations using explicit 
subprograms.  E.g., Assign for assignment statements, Copy for
explicit copying, Make for constructing a value (like an aggregate),
and discriminants for controlling the Initialize procedure.

Of course, this is not as friendly or flexible as being able
to define ":=" for any type, and having it used automatically
everywhere it is appropriate.  However, it is significantly
easier to implement, while still giving the user the essential
capability of control over initialization and finalization, which
are sufficient to implement memory management and garbage collection.

So the question is how much Ada implementor expense and
effort is justified relative to the benefits of
the additional friendliness and flexibility.  Will this
have the tendency to make Ada compilers even more complex
and expensive, or is there some straightforward approach
that can be implemented at reasonable cost that will provide
sufficient benefit.

>Doug Smith
>smithd@software.org

S. Tucker Taft    stt@inmet.com
Ada 9X Mapping/Revision Team  ada9x-mrt@inmet.com (don't forget !topic)
Intermetrics, Inc.
Cambridge, MA  02138

Re: User-defined assignment

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!uvaarpa!soft]

In article <1992Oct17.233209.16059@inmet.camb.inmet.com> stt@spock.camb.inmet.c
om (Tucker Taft) writes:
> I should probably clarify that Ada 9X *does* provide support
> for user-defined initialization and finalization.  This is provided
> for all limited types that are derivatives (direct or indirect)
> of a predefined tagged type System.Controlled.  The operations
> are called Initialize and Finalize, and are called at the 
> "appropriate" time.  However, since this is restricted to "limited"
> types, the user must define their own "Assign" procedure (or equivalent)
> rather than rely on ":=".  

Yes, I know.  And have in the past provided an Assign or
Copy procedure.  Guess how overjoyed the other
programmers were to not have the ":=" work, and instead,
have to call the Assign procedure (which couldn't be
invoked in the declarative region.)  My arguments about
memory management and the inability to redefine ":=" did not
gain me a lot of sympathy.  So pardon me if I'm not too
excited about having to continue this practice!

At least now they don't have to explicitly call a Finalize
procedure (and I hope will be able to use function calls.)

> Therefore, this sort of user-defined assignment is 
> supported, and Initialize and Finalize work correctly,
> in the presence of exceptions and abort.  (What this means
> is that Finalize is performed on an object if and only if Initialize
> is performed on the object, and both Initialize and Finalize defer abort
> until they complete, once they get started.)

Therefore, Ada provides user-defined assignment and is only
missing the Initialize and Finalize operations :-)  I don't
think anyone that is requesting a form of user-defined
assignment means this.

I'm glad Initialize and Finalize will work correctly.  (By the
way, when is Finalize to be invoked on values returned from
a function call?)

> 
> However, a more complete kind of support for user-defined assignmet
> would allow the user to simply use the ":=" operation, and have it invoke
> user-defined code.  Unfortunately, this is only the tip of the iceberg.
> Assignment is used implicitly in subprogram calls for by-copy parameters,
> in creating aggregates, in explicit and implicit initialization, on
> function return, in assignment for composite types,
> etc.  By restricting user-defined finalization to
> limited types, we avoid all of this hairy stuff, though the programmer
> can still implement roughly equivalent operations using explicit 
> subprograms.  E.g., Assign for assignment statements, Copy for
> explicit copying, Make for constructing a value (like an aggregate),
> and discriminants for controlling the Initialize procedure.

I've read this paragraph carefully, and to me, this is a
strawman argument.  Being able to define the way parameters
are passed was not in the scope of my argument.  The statement
that assignment is `implicit' in many constructs is no doubt
true--But I was talking about `explicit' assignment, which in
Ada appears as an operator `:='.  So to keep from complicating
the argument, delete this paragraph and the previous paragraph
and deal with just the ability to redefine the `:=' operator.

> 
> Of course, this is not as friendly or flexible as being able
> to define ":=" for any type, and having it used automatically
> everywhere it is appropriate.  However, it is significantly
> easier to implement, while still giving the user the essential
> capability of control over initialization and finalization, which
> are sufficient to implement memory management and garbage collection.

This paragraph is confusing also.  The phrase, `having it used
automatically everywhere it is appropriate' means what?  If you
mean everywhere the ":=" operation appears, GOOD!  You are
right, it would be friendly and flexible; and I'm glad it would
be easier to implement.  I WANT IT!  How about a survey?

> 
> So the question is how much Ada implementor expense and
> effort is justified relative to the benefits of
> the additional friendliness and flexibility.  Will this
> have the tendency to make Ada compilers even more complex
> and expensive, or is there some straightforward approach
> that can be implemented at reasonable cost that will provide
> sufficient benefit.

Well, I interpreted the previous paragraph to say
the redefinition of explicit assignment would be significantly
easier to implement.  Tell me how easy.  Because it would be
a big improvement.

However, I am one voice-- Are there any experienced programmers
that actually want to redefine implicit assignment as described
in the paragraphs above (silence means no)?

> 
> S. Tucker Taft    stt@inmet.com
> Ada 9X Mapping/Revision Team  ada9x-mrt@inmet.com (don't forget !topic)
> Intermetrics, Inc.
> Cambridge, MA  02138

Doug Smith
smithd@software.org

Re: User-defined assignment

[Dag Bruck]

In <comp.lang.ada> stt@spock.camb.inmet.com (Tucker Taft) writes:
>
>Array initializations are problem the worst, since these generally
>occur in a loop, and so the finalization would to be done
>for only those elements for which initialiation succeeded, requiring
>that the exception handler have a loop that depended on the state
>of the initialization loop at the time of the exception.

Arrays are built-in types in C++, so the initialization routine for
and array of Foo is part of the runtime library (typically).  Any
special handling to cope with partial construction is thus restricted
to this single vendor-supplied library routine.

An array library in C++, for example a library that provides index
range checking, would have to be carefully written to preserve the
desired behaviour in presence of exceptions.


		-- Dag

Re: User-defined assignment

[Dag Bruck]

In <comp.lang.ada> stt@spock.camb.inmet.com (Tucker Taft) writes:
>
>Assignment is used implicitly in subprogram calls for by-copy parameters,
>in creating aggregates, in explicit and implicit initialization, on
>function return, in assignment for composite types,
>etc.

C++ makes a very clear distinction between creation and assignment:

	- constructors create an object in a piece of storage
	  with no existing content (except random bits)

	- assignment changes the content of existing well-defined
	  object

This distinction seems to be missing from the current discussion in
comp.lang.ada.  In my view it is a fundamental distinction that also
has practical ramifications for the programmer.  For example, an ADT
which uses shared representation in its implementation may have to
create a copy of the underlying data when a new value is assigned.  To
create a new object with same value, the underlying data may be shared.

Argument passing in C++ is not done by the assignment operator; it is
done by the "copy constructor" which creates a copy of an existing
object.


>Of course, this is not as friendly or flexible as being able
>to define ":=" for any type, and having it used automatically
>everywhere it is appropriate.  However, it is significantly
>easier to implement, .....

Hmmm.  I see this as a syntactic issue.  Why would user-defined ":="
be harder to implement that user-defined "Assign(....)"?  Would it be
hard for the compiler to know what ":" to use?  Or do you mean that it
would be hard for the user to write a ":=" that meets the semantic
demands of all compiler-generated uses of ":="?

In any case, in my view bit-wise ":=" is almost always wrong for
non-trivial data types. 

				-- Dag

Re: User-defined assignment

[Douglas N. Surber]

In <1992Oct17.175730.17448@software.org> smithd@software.org (Doug Smith) write
s:

>In article <1992Oct16.231346.11881@inmet.camb.inmet.com> you write:

>Really, if this is the worst, I can live with it!  This is
>not worth crippling the language over.  In fact, this sounds
>like the baby (user-defined assignment) is being thrown out
>with the bath-water (the few problems introduced).

>These arguments appear valid, but they don't apply to any
>of the situations that I have uncovered in practice.  Please
>don't cripple Ada9X because of these difficulties.

>I am currently working on the Ada Quality & Style guide.  It
>is very common for these guidelines to explain how certain
>features should best be used.  It also explains where certain
>dangerous programming practices should be avoided.  If there
>is an Ada9X Quality & Style guide, these concerns you point
>out would be ideal warnings to the practicing programmer.

>Unfortunately, if user-defined assignment is not available,
>the guidelines explaining how to do memory management and
>garbage collection will be pretty sparce (as in Ada).  There
>is no need to explain the correct way to use a feature that
>doesn't exist.

>Doug Smith
>smithd@software.org

Hear! Hear!

Douglas Surber
Lockheed 
Houston, TX

Re: User-defined assignment

[Rick Hudson]

>>>>> On Sat, 17 Oct 1992 23:32:09 GMT, stt@spock.camb.inmet.com (Tucker Taft) 
said:

Tucker> Therefore, this sort of user-defined assignment is 
Tucker> supported, and Initialize and Finalize work correctly,
Tucker> in the presence of exceptions and abort.  (What this means
Tucker> is that Finalize is performed on an object if and only if Initialize
Tucker> is performed on the object, and both Initialize and Finalize defer abor
t
Tucker> until they complete, once they get started.)

It is probable wrong to formally specify that Finalize will *defer* abort
until it completes. Such a specification pretty much limits Ada to gc
strategies that utilize reference counts which are not as efficient
generational copying collectors. While such forms of memory management may be
the only strategies that are currently envisioned for Ada, similar languages
such as Modula-3 have shown that other solution are possible. If the Ada 9X
folks simply say that Finalization will eventually happen (possible
concurrently) then it doesn't cut off roads that might lead to interesting
places.
--

       Richard L. Hudson  -  Hudson@cs.umass.edu; (413) 545-1220; 
       Advanced Languages Project - University Computing Services
       Lederle Graduate Research Center
       University of Massachusetts             Amherst, MA  01003
       

Re: User-defined assignment

[dog.ee.lbl.gov!hellgate.utah.edu!caen!zaphod.mps.ohio-state.edu!rpi!bu.ed]

In article <HUDSON.92Oct20101211@yough.cs.umass.edu> 
  hudson@cs.umass.edu writes:

>>>>>> On Sat, 17 Oct 1992 23:32:09 GMT, 
  stt@spock.camb.inmet.com (Tucker Taft) said:

>Tucker> Therefore, this sort of user-defined assignment is 
>Tucker> supported, and Initialize and Finalize work correctly,
>Tucker> in the presence of exceptions and abort.  (What this means
>Tucker> is that Finalize is performed on an object if and only if Initialize
>Tucker> is performed on the object, and both Initialize and Finalize defer abo
rt
>Tucker> until they complete, once they get started.)
>
>It is probable wrong to formally specify that Finalize will *defer* abort
>until it completes. Such a specification pretty much limits Ada to gc
>strategies that utilize reference counts which are not as efficient
>generational copying collectors. While such forms of memory management may be
>the only strategies that are currently envisioned for Ada, similar languages
>such as Modula-3 have shown that other solution are possible. If the Ada 9X
>folks simply say that Finalization will eventually happen (possible
>concurrently) then it doesn't cut off roads that might lead to interesting
>places.

If you reread what it says above, it says that "Finalize" defers
abort until it completes, *once it gets started.*
For stack-allocated variables, Finalize is required to happen prior
to exiting the frame.  For heap-allocated variables, Finalize
may be performed automatically as soon as the object is no longer
accessible, or anytime thereafter, up until the access type itself
goes away.  Alternatively, if the user explicitly deallocates a 
heap-allocated object (via UNCHECKED_DEALLOCATION), Finalize is performed
immediately prior to reclaiming the storage.

In other words, garbage collection is permitted in Ada 9X, and
even acknowledged in the proposed language rules (as it was in Ada 83).
Now all we are waiting for is enough bucks to get some Ada compiler
vendor to implement it.  The ones who tried in the past (AT&T and Symbolics)
never became major players in the Ada market.  Maybe this will
change, but we did not feel it was appropriate to mandate garbage
collection without some proof of commercial viability.  Perhaps
by 200X we will be ready to require GC for Ada.  Until then, you
will have to use your wallet rather than the "club" of the ANSI standard
to get GC into your favorite Ada compiler...

>       Richard L. Hudson  -  Hudson@cs.umass.edu; (413) 545-1220; 
>       Advanced Languages Project - University Computing Services
>       Lederle Graduate Research Center
>       University of Massachusetts             Amherst, MA  01003

S. Tucker Taft    stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138

Re: User-defined assignment

[dog.ee.lbl.gov!hellgate.utah.edu!caen!zaphod.mps.ohio-state.edu!darwin.su]

> So the  question  is how much Ada  implementor  expense  and effort is
> justified relative to the benefits of the additional  friendliness and
> flexibility.

I believe  that the real cost is the danger of people  falling for the
cheap-but-unsafe  solution of non-limited  non-finalized types, rather
than going for the elaborate-but-sound approach (it happens!).

The  second-best  problem is the one with  generics.  Of the thousands
(or  more ?)  generic  Abstract  Data  Type  packages  (lists,  rings,
queues,  stacks,  maps, etc...  ) Very few have limited  formal types,
perhaps inspired by Booch's approach in Software  Components with Ada.
In Ada9X we expect to get an automatically finalized type X, but if we
also want a list of X's, ring of X's,  etc...  we need to convert  the
generics to use procedure a limited  private  generic  formal type and
generic  formal  function  "=" and  procedure  ASSIGN,  or  build  the
composite abstraction ad-hoc.

Then there is a lot of minor  problems, that still affect  programmers
emotionally.  They are bound to get "restless"  when they are expected
to write tons of code such as :

procedure ASSIGN ( TO : in out T; VALUE : in T ) is
begin
  COMP1.ASSIGN ( TO.COMP1, VALUE.COMP1 );
  COMP2.ASSIGN ( TO.COMP2, VALUE.COMP2 );
end;

function "=" ( LEFT, RIGHT : T ) return BOOLEAN is
begin
  return COMP1."=" ( LEFT.COMP1, RIGHT.COMP1 ) and then
         COMP2."=" ( LEFT.COMP2, RIGHT.COMP2 );
end;

Some  constructs are not so easy to replace, e.g.  an array  aggregate
can't be replaced by a construction function.

And finally, in the process of going to limited-ness  some might still
be surprised by the "Midas touch" of limitedness (if a type is derived
from it, contains it, or is completed by it, it becomes  limited too).
They could get desperate when they see the effect disturb much more of
an application than they initially thought.

I can't imagine that all this would cost less than  implementing  some
modest form of user-defined assignment, and this for several reasons :

I believe that the feature is implementable at a fairly early stage in
a compiler, with an appropriate intermediate  representation, it could
stay  entirely  in the  compiler's  front-end.  After all, most of the
code to be generated  can be  represented  in straight Ada, some of it
relies on frames in  expression  contexts and local  frames that don't
interfere  with  the  visibility  rules.  Expecting  no more  than  50
compiler front-ends for 9X, that justifies the cost.

There are many  restrictions one could put on user-defined  assignment
that  are  simplifying  the  implementation  and  are  much  less of a
nuisance to the  programmer  than the absence of the  feature.  One of
the more obvious ones is supporting  only record types.  This protects
the predefined  language  environment  (there are no predefined record
types), prevents the problems with discriminants (that can't be record
types),  except  for  function  return,  they can  always be passed by
reference,  etc...  The nuisance for the  programmer  is that  private
types that were  completed  with  non-records  have to be put inside a
record type, as one would do when needing a default value in Ada83.

Finally there are cases where user-defined  assignment  actually makes
compiler implementation  simpler.  A recently published Language Study
Note    (LSN-1043)    discusses   the   function   return   of   local
self-referential objects (e.g.  objects with access discriminants that
point  to   themselves,   the  Ada9X   solution  to   "mix-in").  With
user-defined  assignment,  it  becomes  the  application  programmer's
responsibility   to   implement   a   proper   copy,   resetting   the
self-reference  of the copy to itself.  Then the  compiler can call it
to implement a "normal"  function return.  Without it, compilers would
need to do fancy tricks with the stack, delaying the normal  stack-pop
at function return until the time the enclosing  context has done with
the  function  result.  Alternatively,  you can't  return  such  local
objects, and we add one more case of "if you use  language-feature  X,
then  you (and  your  clients)  lose  language  feature  Y".  As these
"unmovable"  types currently have no specific language  category, this
restriction may well affect any (inherently)  limited types, including
"movable" inherently limited types, such as (again) finalized types.

-- 
Stef VAN VLIERBERGHE            Eurocontrol - Central Flow Management Unit
stef@cfmu.eurocontrol.be        Avenue des Arts 19H
Tel: +32 2 729 33 42            B-1040 BRUSSELS
Fax: +32 2 729 32 16            Belgium

Re: User-defined assignment

[Jack Beidler]

In article <1992Oct22.221917.15169@cfmu.eurocontrol.be>, stef@cfmu.eurocontrol.
be (Stef Van Vlierberghe) writes:
|>   ...
|> I believe  that the real cost is the danger of people  falling for the
|> cheap-but-unsafe  solution of non-limited  non-finalized types, rather
|> than going for the elaborate-but-sound approach (it happens!).
|> 
|> The  second-best  problem is the one with  generics.  Of the thousands
|> (or  more ?)  generic  Abstract  Data  Type  packages  (lists,  rings,
|> queues,  stacks,  maps, etc...  ) Very few have limited  formal types,
|> perhaps inspired by Booch's approach in Software  Components with Ada.
|> In Ada9X we expect to get an automatically finalized type X, but if we
|> also want a list of X's, ring of X's,  etc...  we need to convert  the
|> generics to use procedure a limited  private  generic  formal type and
|> generic  formal  function  "=" and  procedure  ASSIGN,  or  build  the
|> composite abstraction ad-hoc.
|> 

I wonder if Booch had to do it all over again if he would have used
limited private types.  I have a full set of components that I use in my
courses.  We have adopted the following naming convention 

             component_inst_vis

where "component" is the type of component, "inst" is the type of instantiation
parameter (Pt or Lpt for private or limited private), and "vis" is the
method of visibility (Pt or Lpt).  Three packages are made available for
each component.  For example, the stack packages are:

    Stack_Pt_Pt, Stack_Pt_Lpt, and Stack_Lpt_Lpt.

Note Stack_Lpt_Pt makes no sense.  Pt assumes bound and Lpt assumes managed
storage.

Whenever a package makes a limited private type available, it also supplies
three procedures and one function,

   Zap (nulls the component), Copy (Source, Target), 
   Move_And_Reset (Source, Target) and the function "="

We also require that when a package is instantiated with a limited private
type, the client must also supply Zap, Copy, Move_And_Reset, and "="
for that object, as in,

   generic
      type Object_Type is limited private;
      with procedure Copy ( Source : in     Object_Type ;
                            Target : in out Object_Type ) ;
      with procedure Move_And_Reset ( Source : in out Object_Type ;
                                      Target : in out Object_Type ) ;
      with procedure Zap ( Source : in out Object_Type ) ;
      with function "=" ( Left, Right : Object_Type ) return boolean ;
   package Stack_Lpt_Lpt is

     type Stack_Type is limited private ;

        . . .

By requiring that limited private types be supplied with the correct resources
the client is not longer hindered by a lack of ":=" .

Besides Copy, Zap, and Move_And_Reset, components may also have a 
sharing mechanism if the software developer feels it may be accomplished
in a safe and appropriate manner.  When we supply sharing in our
component packages, we supply them with typical support procedures, like
Share, Unshare, Is_Shared.  Usually when a representation is shared, we
do not allow items to be removed from the structure.  This eliminates a 
lot of coding.

Our experience has been that the support above is sufficient.  I'd appreciate
hearing about other approaches.  I am also looking for an example where the
Zap-Copy-Move_And_Reset-Share support is not sufficient for providing access
to a limited private type.

-- 
+------------------------------------------------------------------+
|  John (Jack) Beidler				                   |
|  Prof. of Computer Science Internet: BEIDLER@JAGUAR.UOFS.ED      |
|  University of Scranton              beidler@guinness.cs.uofs.edu|
|  Scranton, PA 18510	      Bitnet : BEIDLER@SCRANTON            |
|                                                                  |
|          Phone: (717) 941-7446	 FAX:   (717) 941-4250     |
+------------------------------------------------------------------+

Re: User-defined assignment

[Alex Blakemore]

In article <11237@platypus.uofs.uofs.edu> beidler@guinness.cs.uofs.edu (Jack Be
idler) writes:
> I wonder if Booch had to do it all over again if he would have used
> limited private types. [for generic formal types ?]

  I sure hope so, exporting limited but importing non limited types makes
composing abstractions close to impossible. if anything, that strategy is
completely backwards.

> By requiring that limited private types be supplied with the correct resource
s
> the client is not longer hindered by a lack of ":=" .

absolutely.  whenever you see

  generic
    type xxx is private;

instead of 

  generic
    type xxx is limited private;
    function "=" (left, right : xxx) return boolean is <>; -- only if needed
    procedure assign (left in out xxx; right : xxx);       -- ditto

little warning signs should go off. The first form makes predefined equality
and assignnment visible & its impossible to tell from the generic spec
whether they are used (i.e. the assumptions remain unstated).
It is also impossible to instantiate the generic using any other
form of equality and assignment.  This means you cant instantiate it
with a limited private type - and an access type wont work (as Booch suggests)
because you end up testing whether the pointers are the same instead
of the objects.

In spite of any irritation you may have had with limited private
types, it really helps to make generic formal types limited instead of
private.  This causes the generic writer to type a little more but
makes the generic package more general.

This is entirely different from the decision as to whether to make
exported types limited - in that case judgement is required.
I cant think of a single good reason to ever
import a private type instead of a limited private type.
-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted