From: Natacha Kerensikova on
On Aug 12, 8:51 pm, Jeffrey Carter
<spam.jrcarter....(a)spam.not.acm.org> wrote:
> On 08/12/2010 02:26 AM, Natacha Kerensikova wrote:
> > There are situations when a memory representation of S-expressions is
> > not needed, and the tcp-connect example here seems to be such a case.
> > That's why I imagined TCP_Info as a client of Sexp_Stream instead of a
> > client of the second package.
>
> Not needed, perhaps, but it makes things clearer and more reusable if it is used
> anyway.

Well indeed, I do consider readability and simplicity (they often come
together) as one of the most important criteria when choosing an
interface. I think I didn't explained the whole thought process above,
my bad.

When I wrote this I couldn't think of any way to write clearer or
simpler code with any of the two proposed packages (stream or memory
based), because of the basic argument that 8 nodes have to be somehow
created anyway and couldn't think of any way of doing that except by
creating them one by one (be it with a sequence of procedure calls or
a bunch of nested function calls). So when complexity and readability
are equal, I go for the least amount of dependencies.

Of course finding a way to make S-expression building much clearer
with a given interface would be a huge argument in favor of the
interface, no matter its level.

> > To achieve such an interface, the client has to build an in-memory S-
> > expression object. In the tcp-connect example, there are eight nodes
> > (five atoms and three lists). They have to be somehow built, and it
> > doesn't look like a simple initialization.
>
> Perhaps not. But for each kind of thing you want to store using this
> representation, it need be done only once, and then reused:
>
> S : S_Expression := To_S_Expression (TCP_Info);

Unless I missed something important, it looks like it only moves the
problem around. While a To_S_Expression function does make a
TCP_Info'Write simple and one-operation and all, complexity is only
transferred to To_S_Expression which will still have to do the dirty
job of creating 8 nodes.

> > The second interface I proposed, with a lot of nested calls, builds
> > the S-expression object with functions looking like:
> > function NewList(Contents, Next: S_node_access) return S_node_access;
> > function AtomFromWhatever(Contents: whatever, Next: S_node_access)
> > return S_node_access;
>
> An aside on Ada style: Ada is not case sensitive, and many of us reformat code
> to make it easier for us to read. The resulting identifiers such as Newlist and
> Atomfromwidget are not very readable. This is why the convention is to use
> underlines between words.

Yes, I have not managed yet to get that habit. I try to use a
Underscore_And_Capitalization style (not sure whether it's the usual
Ada idiom or not), but sometimes in the heat of action I forgot to do
it (funny thing that identifier that slip end up to be camel cased,
while my C habit is underscore and lower case).

> >> 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.
>
> > That's the tricky part. At least so tricky that I can't imagine how to
> > do it properly.
>
> I'm not sure what you think is tricky about it. Clearly you see how to output an
> S-expression:

You're not the only one having trouble understanding that part. I'm
not good at expressing myself :-(

What I found tricky is the "single operation" part. Building 8 nodes
in a single operation does look very difficult, and while Ludovic's
trick of building them from an encoded string is nice, it makes we
wonder (again) about the point of building a S-expression object
before writing it while it's simpler and clearer to write strings
containing hand-encoded S-expressions.



Thanks for your remarks,
Natacha
From: Natacha Kerensikova on
On Aug 12, 11:22 am, Georg Bauhaus <rm-
host.bauh...(a)maps.futureapps.de> wrote:
> On 8/12/10 10:53 AM, Natacha Porté wrote:
>
> > I have to admit I was quite surprised to find my old way of using S-
> > expressions to be so extremely more difficult in Ada compared to C
> > (whaddoyoumean I can't just feed to strcmp() raw data I've just read
> > from a file!?).
>
> You can "=" just those bytes: you'll just have to drop type
> checking by using an instance of Unchecked_Conversion of
> the-bytes-you-read to String.

Isn't that more-than-a-bit un-Ada-ish?

But then again there might be simple
command_string = String(array_of_read_octets);
if command_string = "my-command" them

which would solve the problem.

And if said string converter/constructor doesn't exist, I guess the
same thing can be done with an ad-hoc String_From_Atom function. But
it would be nice if there was a way to make that operation a no-op in
machine code (at least on platforms where array-of-octets and String
share the same representation, which should be quite often considering
the definition of Character).

> > But on other hand it might be a good thing to be
> > shaken into realizing the deep implication from the difference in
> > typing strength.
>
> The 12K SLOC Python programs on my screen surely would
> be a little easier to rewrite if Python had explicit typing.
> assert isinstance(this, that) seems a helpful workaround,
> but tedious in comparison to strong typing during translation...

Explicit typing is what made me drop python. I remember very well the
last straw, when I spend a long time chasing around a bug which was
cased by a 1 given as a function argument, which was then passed to
another function and then another where it divided by 2. However the
context was completely floating point, so the 0 obtained was quite a
surprise compared to the expected 0.5. And even today I still think 1
and 2 are completely valid floating-point constants.


Natacha
From: Dmitry A. Kazakov on
On Fri, 13 Aug 2010 02:10:23 -0700 (PDT), Natacha Kerensikova wrote:

> On Aug 13, 12:25�am, "Jeffrey R. Carter"

>> provided a more detailed grammar (using the
>> trailing '*' from regexps rather than {}) with some additional options.
>
> Is one of them more standard than the other?

{} is from EBNF

http://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_Form

used in the meaning "repeat or nothing". However earlier, at least I
remember it so, {} was rather used as mere grouping brackets of required
alternatives, and the number of repetitions where written as a superscript
number on the closing bracket. So the newish {P} were denoted as [P]*. And
[P] itself was an abbreviation of {P|} etc.

> I can assure you what I'm doing is completely conform with Rivest's
> standard proposition. I don't know how come it has not reached the
> status of full-fledged RFC (while real RFCs like SPKI do depend on
> it),

Probably because there already was a standard, the Abstract Syntax
Notation:

http://en.wikipedia.org/wiki/ASN.1

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Georg Bauhaus on
On 13.08.10 10:56, Natacha Kerensikova wrote:

> Ada arrays are statically sized,

Not quite, but I think you mean that once an array is allocated, you
can't add more components than are declared by the index constraint?
Example:

procedure Uses_Array (N : Positive; ...) is

X : array (1 .. N) of Character; -- now fixed to N compoments

begin...

But Ada's Container packages can provide for the desired flexibility.
There are containers of homogeneous components and containers of
heterogeneous components. The latter have _Indefinite in their
package's names. Example:

package Vecs is new Ada.Containers.Indefinite_Vectors
(Element_Type => Types.Heterogenous'Class,
Index_Type => Positive,
"=" => Types.Eq);

(Vecs.Vector objects will grow as needed.)

Another option is to instantiate a "definite" container generic with
a pointer type, which is definite. Its access values will point
to any object in some hierarchy. (This can mean pointers to
any objects that share the same interface (Ada 2005 keyword),
so types need not even be rooted at the same one parent type,
I think). For example

package S_Lists is new Ada.Containers.Doubly_Linked_Lists
(Element_Type => Some_Hier_Ptr,
"=" => ...);


Georg
From: Ludovic Brenta on
Natacha Kerensikova <lithiumcat(a)gmail.com> writes on comp.lang.ada:
> What I found tricky is the "single operation" part. Building 8 nodes
> in a single operation does look very difficult, and while Ludovic's
> trick of building them from an encoded string is nice, it makes we
> wonder (again) about the point of building a S-expression object
> before writing it while it's simpler and clearer to write strings
> containing hand-encoded S-expressions.

The only use case for constructing an S-Expression tree in memory and
then writing it out is when the S-Expression is very dynamic. For
example, when you want to save the state of your application, e.g. the
cache of a web browser, in a structured way. Or when you want to save a
tree, the contents and structure of which are unknown in advance.

If the S-Expression is static or mostly so, then by all means write it
by hand.

--
Ludovic Brenta.
First  |  Prev  |  Next  |  Last
Pages: 21 22 23 24 25 26 27 28 29 30 31 32 33
Prev: GPRbuild compatibility
Next: Irony?