Re: S-expression I/O in Ada

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

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

> On Aug 1, 8:49�pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> 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?
> 
> Because that's the definition of S-expressions :-)

OK, why S-expressions, then? (:-))

> I'm referring to this almost-RFC: http://people.csail.mit.edu/rivest/Sexp.txt

I see, yet another poor data format.

> I use S-expression as a sort of universal text-based container, just
> like most people use XML these days,

These wonder me too. I see no need in text-based containers for binary
data. Binary data aren't supposed to be read by people, they read texts.
And conversely the machine shall not read texts, it has no idea of good
literature...

>>> 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;
> 
> It is indeed somewhere, but beyond the reach of a S-expression
> library: its belongs to the application using the library.

Yes

> The record
> you show here can't be part of a generic S-expression handling
> library.

It need not to be. Abstract_Node should declare Serialize and Unserialize
operations, which Connect does implement. The library makes dispatching
calls. Of course you can declare something like:

 � type List_Of_Anything is new Abstract_Node with
       -- Container of class-wide objects

and implement its Serialize and Unserialize through walking the items of an
calling its Serialize and Unserialize. BTW, this is how attributes 'Input
and 'Output work with arrays.

> In my example, as far as the S-expression library is concerned, it
> looks like:
> "(<some_stuff_1> (<some_stuff_2> <some_stuff_3>) (<some_stuff_4>
> <some_stuff_5>))"

That is no matter. Serialize/Unserialize will use this format if they have
to.

> The library is not supposed to care about what those some_stuff_ are.
> Actually, the library is suppose to get binary data from the
> application along with the tree structure described above, store it
> into a sequence of bytes (on a disk or over a network or whatever),
> and to retrieve from the byte sequence the original tree structure
> along with the binary data provided.

Serialize can yield a binary chunk, but if you have to write it anyway, why
not to write text? You insisted on having text, why do mess with binary
stuff?

> But now that I think about it, I'm wondering whether I'm stuck in my C
> way of thinking and trying to apply it to Ada. Am I missing an Ada way
> of storing structured data in a text-based way?

I think yes. Though it is not Ada-specific, rather commonly used OOP design
patterns.

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