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=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,24d7acf9b853aac8
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: S-expression I/O in Ada
Date: Sun, 01 Aug 2010 23:03:32 +0100
Organization: A noiseless patient Spider
Message-ID: <m2aap6at3f.fsf@pushface.org>
References: <547afa6b-731e-475f-a7f2-eaefefb25861@k8g2000prh.googlegroups.com>
	<1qk2k63kzh7yv$.3jgc403xcqdw$.dlg@40tude.net>
	<8ae8e899-9eef-4c8c-982e-bfdfc10072f1@h17g2000pri.googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sun, 1 Aug 2010 22:03:33 +0000 (UTC)
Injection-Info: mx03.eternal-september.org;
 posting-host="KCXegvZb5vh43D+f3BR6Ew";
	logging-data="13578"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19Ryc/Y+ZG6p1WzhYqCh9aNVLnSp9H3pPA="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (darwin)
Cancel-Lock: sha1:aKvG+FbMVwgZ5pWl52tPsmUikfA=
	sha1:S2wBhzb9moyXG5ih0jdRpE0lSFo=
Xref: g2news1.google.com comp.lang.ada:12793
Date: 2010-08-01T23:03:32+01:00
List-Id: <comp.lang.ada>

Natacha Kerensikova <lithiumcat@gmail.com> writes:

> This means that as far as the S-expression library is concerned, the
> byte sequence read from the file is not typed. Its typing actually has
> to be delayed until the application has enough context to interpret
> it.  Hence the need of a typeless chunk of data.
[...]
> Well, I imagined making such a new type to distinguish 'raw data
> coming from a S-expression to be interpreted' from other raw data
> types.  I thought this was the strong type safety to prevent
> (de)serialization procedure from trying to interpret just any chunk of
> memory.

This sounds really like an alternative implementation of Ada Stream
attributes - ARM 13.13,
http://www.adaic.com/standards/05rm/html/RM-13-13.html .

The idea of a stream is that the data is written (perhaps to a file,
perhaps over a network, perhaps to memory) in suce a way that it can be
retrieved later by the same or another program.

   type R is record
      I : Integer;
      F : Float;
   end record;
   procedure Read
     (Stream : not null access Ada.Streams.Root_Stream_Type'Class;
      Item : out R);
   procedure Write
     (Stream : not null access Ada.Streams.Root_Stream_Type'Class;
      Item : R);
   for R'Read use Read;
   for T'Write use Write;

then implement Read and Write as you wish.

But as you will see the medium - the Stream above - is just a bunch of
bytes in a file or a network packet. If you send a Foo and I read it
hoping it'll be a Bar, we're going to have a problem.

I guess, given the above, we could start the Sexp with "(R ...", then
the recipient would raise Constraint_Error if the type expected didn't
match the data being read.

This is like the mechanism standard Streams (in GNAT, at any rate) use
for transferring tagged and classwide types; the introductory segment
names the provided type and compiler magic creates the proper result.

[Team, I seem to remember an '05 feature that would support this? or was
that my imagination?]