From: Georg Bauhaus on
_FrnchFrgg_ wrote:

> I don't know enough ada to even imagine how you would implement such a
> thing in Ada, if possible, or whether it already exists (but I gather no
> from what you say).

For the basic types like discrete types, value matching
is fully supported and re1quired.

type Color is (Red, Green, Blue);
C : Color;

case C is
when Red => Add_Green;
when Green => Add_Blue;
end case;


7. case C is
|
>>> missing case value: "BLUE"


Some of the structure matching can, I think, be handled
by choosing meaningful type hierarchies (Tree, Leaf and
the like) and use O-O overridings (for Tree and Leaf,
respectively).


Georg
From: Ludovic Brenta on
Natacha Kerensikova <lithiumcat(a)gmail.com> writes:
> On Aug 9, 8:49 pm, Ludovic Brenta <ludo...(a)ludovic-brenta.org> wrote:
>> I pursued that idea a little further and actually wrote an embryonic
>> S-Expression library.  I'm not entirely satisfied with it because it
>> uses copy semantics instead of reference semantics and so is probably
>> inefficient.  But it does demonstrate how to read and write
>> S-Expressions on a stream (e.g. a file).  Also, it shows how to
>> hex-encode and hex-decode blobs, which I've modelled as Storage_Arrays.
>>
>> You can browse the sources here:
>>
>> http://green.ada-france.org:8081/branch/changes/org.ludovic-brenta.s_...
>>
>> Enjoy.  (the license is the GPLv3 or later).
>
> Interesting, though it seems your code won't like strings containing a
> double-quote.

Right; that's a minor detail and easy to correct by e.g. preceding
embedded double-quotes with a backslash.

> However, the principal conclusion I draw from reading this is that I'm
> still far from having the Ada level required to write anything like
> that (since I can't even understand everything while reading it).

I think I could simplify the library with some additional thought. What
you see is but a first iteration :)

> Still, from what I understood, I'm not fond of the idea of having to
> write type-to-atom conversion procedure while they already exist.
>
> It occurred to me that most types already know how to serialize
> themselves, through the Stream subsystem. Strings, Unbounded_strings,
> Integers, Float, etc, can all be read from and written into a stream.
> So the code to convert them into file-suitable Stream_Element_Array
> exist. Won't be a pity not to reuse it?
>
> Pursuing this idea leads to a library quite different from what I had
> in mind when I started this thread. Let's call it Sexp_Stream, which
> would be derived from Root_Stream_Type. Then Read and Write procedure
> are called (from what I understand) by type'Read and type'Write after
> said type has turned itself into a Stream_Element_Array. That would
> cover atom I/O, and some procedures must be added to cover the list I/
> O part.
>
> I think I can imagine how the writing part would happen:
> after having initialized a Sexp_Stream object with various
> information, including an underlying stream where the S-expression
> would be actually written, the application would use the Write
> procedure to append an object as an atom to the current node, and the
> newly appended atom would become the current node. List procedure
> would be called something like List_Open, to open a new list and
> append following nodes into it, and List_Close, to close the current
> list and come back to the previous list.
>
> Using my tcp-connect example, it would look like this (please excuse
> Ada syntax error and focus on the idea):
>
> Sexp_Stream.Open(SxStream, underlying_stream, ...);
> Sexp_Stream.Open_List(SxStream);
> String'Write(SxStream, "tcp-connect");
> Sexp_Stream.Open_List(SxStream);
> String'Write(SxStream, "host");
> String'Write(SxStream, Hostname);
> Sexp_Stream.Close_List(SxStream);
> Sexp_Strean.Open_List(SxStream);
> String'Write(SxStream, "port");
> Integer'Write(SxStream, PortNumber);
> Sexp_Stream.Close_List(SxStream);
> Sexp_Stream.Close_List(SxStream);
>
> Now I have to admit I don't know how to specify the reading part of
> such a Sexp_Stream. I guess I would need the notion of a current node,
> with a function telling the application whether the current node is a
> list or an atom, type'Read converting the current atom into said type
> (and raising an exception when the current atom is a list), and some
> procedures to get to the next node, to the frist node following the
> current list (i.e. up one level), and when the current node is a list
> to go the first node of the list (i.e. one level deeper).
>
> However such a library wouldn't cover all my S-expression needs,
> because I sometimes need to keep S-expressions into memory, so there
> would be another package for in-memory S-expressions, which would have
> to interact nicely with Sexp_Stream.

That's exactly what my library is for: it lets you build S-Expressions
in memory and serialize them to a stream (adding any parentheses or
quoting necessary along the way) and, conversely, read from a stream and
build in-memory S-Expressions. At this level, the value of any atom is
an unbounded_string; the semantics are left to the application.

The To_Atom and From_Atom functions are there to help you build a
high-level layer on top of the S-Expression layer. The "test.adb"
program contains such a higher layer: it defines a (simple) record type
containing an integer and a boolean (enumerated type) and encodes it
into an S-Expression containing strings, and back.

I'll add a generic to encode arbitrary hashed_maps into S-Expressions of
the form ((key value) (key value) ...) later on, if you're interested.

> So, how does it sound? Is it totally crazy? Is it totally not-Ada? Is
> there something right in there?

I don't think "Ada" or "not Ada" should be the question; the proper
question should be "is it reusable and maintainable?"

> For Jeffry Carter (and anybody interested in helping me understand the
> Ada way): here is how it looks like when I haven't thought much about
> it. Notice that all this is completely from the point of view of the
> application using the package, with very few implementation choices.
> If I knew Ada, wouldn't these explanations be pretty much the contents
> of the specification file, with about everything from the body being
> still to invent? How Ada-ish is that thought process?
>
>
> Thanks in advance for your reviews of my ideas,
> Natacha

--
Ludovic Brenta.
From: Randy Brukardt on
"Robert A Duff" <bobduff(a)shell01.TheWorld.com> wrote in message
news:wccbp9bspzy.fsf(a)shell01.TheWorld.com...
> Simon Wright <simon(a)pushface.org> writes:
>
>> Natacha Kerensikova <lithiumcat(a)gmail.com> writes:
>>
>>> and I don't know either how to deal with cases where Stream_Element is
>>> not an octet.
>>
>> By ignoring them, I think!
>
> Are there any such cases in the real world? There are machines
> in the embedded world where Storage_Element is not 8 bits.

Not sure if it still exists in the real world, but the compiler we did for
the Unisys mainframes used Stream_Element'Size = 9. (The Unisys mainframes
are 36-bit machines.) Stream_Element'Size = 8 would have made the code for
handling arrays awful.

Similarly, Character'Size = 9 on that machine. While the upper bit was not
used in the representation, this is surely not an Octet.

> But any machine that's hooked up to any sort of network
> is going to be talking Octets, I think. Does anybody know of
> counterexamples?

The network interfaces on the Unisys machines required binary or text mode
settings: in text mode, the extra bit was just dropped; in binary mode all
of the bits were sent (not sure precisely how that was done, it was in the
OS).

> Perhaps Stream_Element should have been defined as exactly
> 8 bits. Perhaps it should have been called "Octet".

That would have made a compiler for the Unisys machines impossible; it would
have made streaming impossible. There is no sane way to put 36-bit values
into Octets - the only way that would have worked would have been to use
16-bits for every 9-bit byte.

Whether this is a significant consideration today (in 2010) is debatable,
but it surely was a real consideration back in 1993-4. So Ada 95 could not
have made this choice.

Randy.



From: Jeffrey Carter on
> Natacha Kerensikova<lithiumcat(a)gmail.com> writes:
>
> For Jeffry Carter (and anybody interested in helping me understand the
> Ada way): here is how it looks like when I haven't thought much about
> it. Notice that all this is completely from the point of view of the
> application using the package, with very few implementation choices.
> If I knew Ada, wouldn't these explanations be pretty much the contents
> of the specification file, with about everything from the body being
> still to invent? How Ada-ish is that thought process?

In general, describing it from the point of view of "the application using the
package" (often referred to as "the client") is the purpose of the
specification. The body is for the implementation, usually best left until the
specification is finished.

On the other hand, your proposed operations seem unnecessarily low level for the
client. You have an internal representation, which is probably hidden from the
client, and an external representation, and operations to write an object of the
internal representation to that external representation and read the external
representation to create an object of the internal representation. Thus, your
client should probably invoke a single operation to write an object, and another
single operation to read.

--
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Jeffrey Carter on
On 08/09/2010 05:51 PM, Randy Brukardt wrote:
>
> Not sure if it still exists in the real world, but the compiler we did for
> the Unisys mainframes used Stream_Element'Size = 9. (The Unisys mainframes
> are 36-bit machines.) Stream_Element'Size = 8 would have made the code for
> handling arrays awful.

What was Storage_Unit? 36?

--
Jeff Carter
"Run away! Run away!"
Monty Python and the Holy Grail
58

--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
First  |  Prev  |  Next  |  Last
Pages: 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
Prev: GPRbuild compatibility
Next: Irony?