S-expression I/O in Ada
in [ADA]
|
Prev: GPRbuild compatibility
Next: Irony?
From: Dmitry A. Kazakov on 10 Aug 2010 11:46 On Tue, 10 Aug 2010 05:06:29 -0700 (PDT), Natacha Kerensikova wrote: > On Aug 10, 12:36�pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> >> Which was the question: what was wrong with the first object so that you >> wanted another instead? > > The first object is the internal memory representation designed for > actual efficient use. For example, an integer will probably be > represented by its binary value with machine-defined endianness and > machine-defined size. > > The other object is a "serialized" representation, in the sense that > it's designed for communication and storage, for example the same > integer, in a context where it will be sent over a network, can be for > example represented as an ASCII-encoded decimal number, or in binary > but with a predefined size and endianness. Why don't you send it at once? > This is really the same > considerations as when storing or sending an object directly, except > that is has to reside in memory for a short time. There is no more > conversions or representations than when S-expression-lessly storing > or sending objects; the only difference is the memory buffering to > allow S-expression-specific information to be inserted around the > stream. This is impossible in general case, so the question why. As an example consider a stateful communication protocol (existing in real life) which is reacts only on changes. When you send your integer nothing happens because the device reacts only when the bit pattern changes. So if you wanted to really send it to another side you have to change something in the representation of integer, e.g. to toggle some extra bit. >> What was the problem then? > > The problem is to organize different objects inside a single file. S- > expression standardize the organization and relations between objects, > while something else has to be done beyond S-expression to turn > objects into representations suitable to live in a file. > > Or the same thing with, instead of a file, an IPC socket or a network > socket or whatever, I just don't know how to call it generically > without resorting to a word derived from "serialize", but I hope you > get the point anyway. Yes, I don't see how S-expression might help there. They do not add value, because the work of serialization or equivalent to serialization is already done while construction of the expression object. >> Because it cannot work without a conversion between >> S-sequence in the memory (object) and S-sequence in the file >> (representation). > > The S-expression standard describe what conversions are allowed and in > what they consist. I cannot follow the standard without such a > conversion anyway, so either I do it or I drop the idea of S- > expressions, but then I don't have anything to portably store or > transmit objects, so back to square one. There are two questions to discuss: 1. The external storage format: S-expressions vs. other 2. Construction of an intermediate S-expression object in the memory You justified #1 by an argument to legacy. You cannot [re-]use that argument for #2. (OK, since Ludovic had already done it, you could (:-)) >> Why do you need S-sequence in the memory, while dumping >> objects directly into files as S-sequences (if you insist on having them) >> is simpler, cleaner, thinner, faster. > > Because I need to examine the S-sequence before writing it to disk, in > order to have enough information to write S-expression metadata. At > the very lest, I need to know the total size of the atom before > allowing its first byte to be send into the file. That does not look like a stream! But this is again about abstraction layers. Why do you care? > That sounds like a very nice way of doing it. So in the most common > case, there will still be a stream, provided by the platform-specific > socket facilities, which will accept an array-of-octets, and said > array would have to be created from objects by custom code, right? Yes, if TCP sockets is what you use. There is a hell of other protocols even on the Ethernet, some of which are not stream-oriented. >> In other post Jeffrey Carter described this as low-level. Why not to tell >> the object: store yourself and all relations you need, I just don't care >> which and how? > > That's indeed a higher-level question. That's how it will happen at > some point in my code; however at some other point I will still have > to actually implement said object storage, and that's when I will > really care about which and how. I'm aware from the very beginning > that a S-expression library is low-level and is only used by mid-level > objects before reaching the application. This is what caused the questions. Because if the problem is serialization, then S-expression does not look good. >> You do not need S-expressions here either. You can >> store/restore templates as S-sequences. A template in the memory would be >> an object with some operations like Instantiate_With_Parameters etc. The >> result of instantiation will be again an object and no S-sequence. > > Well how would solve the problem described above without S- > expressions? (That's a real question, if something simpler and/or more > efficient than my way of doing it exists, I'm genuinely interested.) The PPN, a simple stack machine. Push arguments onto the stack, pop to execute an operation. Push the results back. Repeat. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Ludovic Brenta on 10 Aug 2010 11:48 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. I've corrected that and rewritten test.adb to use your example: (tcp-connection ((host foo.bar) (port 80))) My parser needs still the above syntax and will not accept the theoretically equivalent (tcp-connection (host foo.bar) (port 80)) yet. -- Ludovic Brenta.
From: Georg Bauhaus on 10 Aug 2010 11:59 On 10.08.10 17:48, Ludovic Brenta wrote: > I've corrected that and rewritten test.adb to use your example: > > (tcp-connection ((host foo.bar) (port 80))) > > My parser needs still the above syntax and will not accept the > theoretically equivalent > > (tcp-connection (host foo.bar) (port 80)) > > yet. How does it handle (tcp-connection ((host foo.bar) (port 80)) (tcp-connection ((host abc.xyz) (port 80))) Sorry, CNR ;-) Georg
From: Jeffrey Carter on 10 Aug 2010 14:13 On 08/09/2010 11:47 PM, Natacha Kerensikova wrote: > > So I was doing it the right way, right? (I still have almost no clue > about how to make the body, while the specification looks relatively > clear to me, even though I can't yet turn in into real Ada). Yes. > I have to admit I can't imagine how to do it in any higher level than > this. Or are you suggesting to replace my sequence of procedure calls > by something like: > > NewList(AtomFromString("tcp-connect", > NewList(AtomFromString("host", AtomFromString("foo,example", > Nil)), > NewList(AtomFromString("port", AtomFromPort(PortNb, Nil)), Nil)), > Nil); I was commenting on your ideas about writing an S-expression to a stream, which included operations to open and close a list, and put an atom. I thought this was how you expected a client to output an S-expression. I think the client should just do S : S_Expression := Some_Initialization; Put (File => F, Expression => S); > Or maybe we don't the same thing with "object"? Here I have five > objects to put into a S-expression as atoms, and they are indeed > fairly low-level objects. A higher-level object would be a record type > called e.g. TCP_Info, whose reading and writing primitives handle the > addition/matching of "host" and "port" and maybe "tcp-connect". So > there would be a single operation to read or write such a high-level > object by code using it. However the mid-level TCP_Whatever package > providing the high-level object and its operation would in turn use > the low-level Sexp_Stream (or anything else I might want to experiment > with, that's the whole point of modularity). Right. Here the program would call the single operation, and never look at an S-expression. Your TCP_Info-handling pkg would convert the record into an S-expression, and call a single operation from your S-expression pkg to output the S-expression. Your S-expression library would implement the writing of the expression as a series of steps. The TCP_Info-handling pkg is the client of the S-expression library; the program is the client of the TCP_Info-handling pkg. I was referring to the former. You were apparently talking about the internals of the S-expression library. -- Jeff Carter "Strange women lying in ponds distributing swords is no basis for a system of government." Monty Python & the Holy Grail 66 --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Simon Wright on 10 Aug 2010 17:22
"Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: > Yes, if TCP sockets is what you use. There is a hell of other > protocols even on the Ethernet, some of which are not stream-oriented. We leverage stream i/o via UDP (which on GNAT is seriously broken, because it tries to do an OS sendto() for each elementary component! http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9535) by using 'Write into a memory stream[1] on one side and then sendto() the constructed Stream_Element_Array; and on the other side recvfrom() to get the datagram contents, use this as input to a memory stream, then 'Read. (Of course we could use 'Output and 'Input, but the data types involved are all definite). [1] http://booch95.svn.sourceforge.net/viewvc/booch95/trunk/src/bc-support-memory_streams.ads?revision=1420&view=markup http://booch95.svn.sourceforge.net/viewvc/booch95/trunk/src/bc-support-memory_streams.adb?revision=1428&view=markup |