Re: Should weak counted reference be able to be strengthened?

[brbarkstrom@gmail.com]

On Wednesday, November 26, 2014 4:28:07 AM UTC-5, Dmitry A. Kazakov wrote:
> On Tue, 25 Nov 2014 15:49:49 -0600, Randy Brukardt wrote:
> 
> > "Dmitry A. Kazakov" wrote in message 
> 
> > ...
> >> Instead of introducing "crazy beautiful" implicit dereference, Ada 2012
> >> should have delegation support for the patterns like this.
> > 
> > Depending heavily on interfaces is a sure way to madness. :-)
> > 
> > But the real problem here is I don't see any way to add "delegation support" 
> > that actually saves much over the explicit version that you showed. We 
> > certainly don't want *everything* to delegate (it has to be declared somehow 
> > for the particular operations in question),
> 
> Everything of course, unless explicitly overridden.
> 
> > and because of overloading we 
> > have to at least have the complete profile. That means an awful lot of 
> > typing (and source text to read), and lots of chance for errors.
> 
> Yes, which is why delegation and other means to compose overridden
> operations are needed.
> 
> The programmer should be able to define things which happen implicitly when
> for example:
> 
>    type X is new Integer;
> 
> This implicitly defines a lot of operations composed like:
> 
>    function "abs" (Value : X) return X
>       = X (abs (Integer (Value));
> 
> It is not much different from how "sane" implicit dereference would work
> 
>    type Y is access Integer;
> 
>    function "abs" (Value : Y) return Integer
>       = abs (Value.all);
> 
> I don't know how to describe such things syntactically. That is a
> challenge.
> 
> > In a sense, Ada 2012 has delegation support as one can use expression 
> > functions that way.
> 
> Yes, they could be viewed this way, but in my view they are too powerful.
> What I want is a more limited mechanism of composition which could be
> easily checked. The limitation is that the old body is used with an
> epilogue and/or a prologue and conversions are applied to the arguments
> and/or the result. If the body has to be changed, it must be overridden.
> 
> -- 
> Regards,
> Dmitry A. Kazakov

This dialogue reminds me of a substantial conversation currently going on
in the library community with respect to long-term (200 years) information
preservation with transformational migration.  The problem gets even more
interesting in federated archives (think DSA across the Internet).

The life of digital files (or databases) is more or less limited by the
lifecycle of hardware or software obsolescence.  So, if your favorite
documentation formatting vendor decides to deprecate the previous format,
what's an archive to do - transform the original or throw it out?  If the
archive throws the document out, it might still want a reference to it to
maintain a provenance track that can aid in proving authenticity of the
transformed original.  

Furthermore, that community has tendencies to want some centralized authority 
to provide references to the "unique" "authentic original."  [Never mind the
fact that such an authority - raking in money even - is a single point of
failue.]  So, if the archive throws out that original file (or it becomes 
unreadable) and the community seems to think that a backup copy is "not 
authentic" because only the one "original" copy was the "authentic" one
there may need to be some mechanism to notify users of the history of the
changes.

The weak references in the previous posts appear to be like the 
"centralized" site's reference to the archive copy that they think is
the "authentic original" (but now unreadable or deleted).  The latter
is presumably the strong reference.

I'm still inclined to think Ada has a significant potential market in
the long-term information preservation business.  The requirements for
loss per year are into the number of nines we think about for life-critical
software systems.  After looking at the posts here, I am pretty sure that
the arguments about weak and strong references in Ada are similar (and
perhaps mathematically identical) to the issues the library community
is arguing about.  There may even be some light their discussion 
could shed on the one in the Ada community.  [Besides, if this small
discussion could help solve a "big" problem, that would be even more fun.]

Bruce B.