From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: article on acces types and dynamic serialization in Ada (2003)
Date: Thu, 22 Feb 2018 17:49:01 -0600
Organization: JSA Research & Innovation
Message-ID: <p6nkte$tbk$1@franka.jacob-sparre.dk>
References: <503e3322-ee8e-4d6f-9aa5-e7b98f87e8f8@googlegroups.com>
 <5d8580c2-b43d-4b2c-8a46-3a6ed33967aa@googlegroups.com>
Injection-Date: Thu, 22 Feb 2018 23:49:02 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="30068"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: reader02.eternal-september.org comp.lang.ada:50577
Date: 2018-02-22T17:49:01-06:00
List-Id: <comp.lang.ada>

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:5d8580c2-b43d-4b2c-8a46-3a6ed33967aa@googlegroups.com...
...
>There might be numerous ways around this linked data issue but having a
>sane default implementation, as we already have defaults everywhere
>you can still override.

What default (read relatively cheap to read/write) implementation could 
possibly be sane?

As Dmitry points out, full serialization doesn't make sense for Ada -- for 
that matter, it doesn't make sense (as a default) for any language, since 
one has to deal with recursive data structures. Having P'Write go into an 
infinite loop is hardly sane!

To see this, imagine writing a doubly-linked list node with a serializing 
access definition:

                    type Node;
                    type Node_Ptr is access all Node;
                    type Node is record
                          Data : Natural;
                          Prev, Next : Node_Ptr;
                    end record;

For the Node_Ptrs to be written as anything useful, you'd have to dump the 
entire list -- but that then would be duplicative. One really has to write a 
custom solution for each such data structure --- there is no 
one-size-fits-most solution.

As to why it doesn't just raise Program_Error to 'Read/'Write an access 
value, I would say that it is because one can reliably test a read access 
value for null/not null. One then can use that information to determine 
whether or not do do more serialization. Doing that is a lot easier (for 
both the author and the compiler) than separating the record into separate 
components and having to deal with each individually.

OTOH, I once had an argument with Robert Dewar about this, he made the claim 
that one can't rely on that as "implementation-defined" doesn't necessarily 
mean "something trivially cheap". It's hard for me to imagine an 
implementation doing anything other than just dumping the access value 
binary, but argubly he was right. (In practice, I was right so far as I can 
tell.) But in that case, Ptr'Write should raise Program_Error because it can 
never have any useful portable meaning. (Too late now, though, there are 
lots of uses like mine out there.)

                                         Randy.