Re: S-expression I/O in Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 1 Aug 2010 10:35:17 -0700 (PDT), Natacha Kerensikova wrote:

> On Aug 1, 2:53�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:

>> How can it make sense if the type is unknown? If the type is known, why not
>> to state it?
> 
> Actually the type is deduced from the context, e.g.
> (tcp-connect (host foo.example) (port 80))

Hmm, why do you consider brackets as separate elements? I mean, more
natural would be "procedural":

   tcp-connect (host (foo.example), port (80))

or

   tcp-connect (foo.example, 80)

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

The above is mere syntax, it is not clear why internal/external
representation must be as you described. (Actually, the structures as above
are widely used in compiler construction e.g. syntax tree, Reverse Polish
notation etc.)

There is no such thing as untyped data. The information about the type must
be somewhere. In your example it could be:

   type Connect is new Abstract_Node with record
       Host : IP_Address;
       Port : Port_Type;
   end record;

So I would derive leaves from some abstract base type and link them into an
acyclic graph. It is relatively simple to do using either standard Ada
containers or other libraries containing trees and/or graphs.

>>> Though it looks like a fine Ada API (at least to my eyes), I have
>>> absolutely no idea about how to implement the library. How to define
>>> the application-opaque Sexp_Atom type?
>>
>> It is not clear why do you need such a type. What are the properties of,
>> and what is it for, given the application need to convert it anyway?
> 
> 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.

But you know the type if you are going to interpret raw data. It must be
somewhere, hard-coded or dynamically stored/restored.

BTW, Ada supports I/O of types (i.e type tags) implicitly in the form of
already mentioned stream attributes, but also explicitly by external type
tag representations (RM 3.9(7/2)) and generic dispatching constructors (RM
3.9(18/1)).

> I thought this was the strong type safety to prevent (de)serialization
> procedure from trying to interpret just any chunk of memory.

No, actually it eases serialization because you can define
Serialize/Unserialize operations on the type.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de