* Re: Overloading of ":="
@ 1988-12-26 13:07 Erland Sommarskog
1988-12-28 5:46 ` Overloading of ":=", ADT survivability William Thomas Wolfe,2847,
0 siblings, 1 reply; 2+ messages in thread
From: Erland Sommarskog @ 1988-12-26 13:07 UTC (permalink / raw)
Bill Wolfe (billwolf@hubcap.clemson.edu) writes:
>From article <4189@enea.se>, by sommar@enea.se (Erland Sommarskog):
>> [Mats Weber and Erland Sommarskog rehash the argument about
>> assignment procedures having an "in out" parameter for the destination]
>>
>> Now, WHY, is A of mode "in out" in the Assign procedure? If we had
>> "out" only, nothing "erroneous" could occur.
>
> Because the ASSIGN procedure needs to be able to DESTROY the old
> value; DESTROY procedures must read objects during the process
> of destroying them. Please review the recent discussion rather
> than recreating it, unless there are new issues to be considered.
Talk about rehash. We all know, except Bill of course, that the memory-
management problem is best handled with garbage collection.
As for the answer to the question above, the answer is simply that
Generic
Data_type is limited private;
With procedure Assign(A : out Data_type; B : in Data_type);
Package...
is illegal. Parameters of a limited type may not be in "out" mode.
This means, as Mats pointed out, that to use this package for
type without a default value, like standard.integer, the user have to
do something erroneous. I, in my turn, pointed out that this was not
a problem in practice except for constrained types, and that this
case also easily was handled with a "supress" pragma.
Please read more carefully before you flame. We didn't talk about
memory management. We didn't even talk about access types.--
Erland Sommarskog
ENEA Data, Stockholm This signature is not to be quoted.
sommar@enea.se
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Overloading of ":=", ADT survivability
1988-12-26 13:07 Overloading of ":=" Erland Sommarskog
@ 1988-12-28 5:46 ` William Thomas Wolfe,2847,
0 siblings, 0 replies; 2+ messages in thread
From: William Thomas Wolfe,2847, @ 1988-12-28 5:46 UTC (permalink / raw)
From article <4193@enea.se>, by sommar@enea.se (Erland Sommarskog):
>>> Now, WHY, is A of mode "in out" in the Assign procedure? If we had
>>> "out" only, nothing "erroneous" could occur.
>>
>> Because the ASSIGN procedure needs to be able to DESTROY the old
>> value; DESTROY procedures must read objects during the process
>> of destroying them. Please review the recent discussion rather
>> than recreating it, unless there are new issues to be considered.
>
> Talk about rehash. We all know, except Bill of course, that the memory-
> management problem is best handled with garbage collection.
And in article <4195@enea.se>, Erland also writes:
> I think Ada should require garbage collection
> that could be disabled with a pragma for critical applications.
But consider what happens when the programmer of a critical
application must write his/her assignment procedures. Use
of the "out" mode results in the production of garbage. Since
the GC crutch is not available, the more survivable "in out"
mode is then preferred.
Now since we know that "out" mode is worthless under certain
circumstances, and since ADT designers must design for the widest
possible audience, "in out" is the mode of choice.
Similarly, when performing deletions and such, ADT designers must
again design for the widest possible audience. This directly implies
an ADT which manages its own deallocations.
Certain aspects of the language tend to interfere with the need
of critical applications to exercise total control over memory
management; among these are the inability to integrate DESTROY
procedures into the automatic destruction of local environments.
Sure, it requires more mental discipline to be space-conscious.
But with experience, it becomes automatic. Forgive me if I've
been a bit harsh at times, but once a person has become accustomed
to managing space and time simultaneously, complaints regarding
pointer errors sound very much like complaints that it's too
difficult to have to walk and chew gum at the same time.
I like to program my ADTs to be *survivable*, in the hardest possible
sense. An ADT should be capable of surviving multitasking, invalid
parameters, memory exhaustion, whatever. Only then will the part
achieve widespread acceptance.
Bill Wolfe
wtwolfe@hubcap.clemson.edu
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1988-12-28 5:46 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1988-12-26 13:07 Overloading of ":=" Erland Sommarskog
1988-12-28 5:46 ` Overloading of ":=", ADT survivability William Thomas Wolfe,2847,
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox