S-expression I/O in Ada
in [ADA]
|
Prev: GPRbuild compatibility
Next: Irony?
From: Randy Brukardt on 11 Aug 2010 19:18 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message news:iv3qwjogornz$.1s8kq0yfl2wxl.dlg(a)40tude.net... .... > Conversion mess is what we already have right now. The point is that "+" > is > well-defined and meaningful for octets, but it is not closed in there. Why > > function "**" (Left : T; Right : Natural) return T; > function S'Pos(Arg : S'Base) return universal_integer; > ... > > are OK and "+" is not? The first has the same operand and result type (the power operand is something else and not really part of the operator IMHO). The second is the long winded name for a conversion operator - it implies no semantic change. I'm arguing that operations like S'Pos would be better having a common name like "#" rather than a host of specialized names. >> Since we're inventing things, I would suggest: >> >> -- Conversion function (Not Ada): >> function "#" (Right : Octet) return Universal_Integer; >> >> Little_Endian_Value := #Octet_1 + #Octet_2 * 256; >> >> And now you don't need any Octet math. > > 1. What is this else? Huh? This doesn't parse. > 2. I see no advantage over > > Little_Endian_Value := Integer (Octet_1) + Integer (Octet_2) * 256; "#" can be overridden and/or user-defined. "Integer" cannot (and could never be in a version of Ada, as any such attempt would be way too incompatible). In addition, "#" is more readable in the 98% of the cases where you don't need to specify a type. I would probably consider using predefined versions of "#" to replace other forms of explicit type conversion as well (so "#" would always work if defined - no decision about whether to call a function, use a built-in type conversion, or use some attribute - and no need to look up the name of the type). >> BTW, the "#" operator was suggested by Jean Ichbiah and others back >> during >> the design of Ada 83, to be used for conversions between types. It's a >> pity >> that it or something like it never made it into Ada. (It comes up each >> time >> and still is rejected.) > > It would be nice to have more operators than now ("^", "|", "..", "in", > ":=", "<>", "()", "[]", "{}", "<=>", "@", "~" and so on. Ah, Ada is > Unicode > now, here is the list: http://www.unicode.org/charts/PDF/U2200.pdf ). > > But what is so special in type conversions, aren't they just functions? That's the point: in Ada, type conversions are *not* functions, they're a built-in gizmo [including some attributed]; by naming them "#" we would allow unifying them with functions. Of course, this could be abused (by having some semantic change encoded in the function as well), but that of course can happen just as well with "+" or "-" or "*". Randy.
From: Randy Brukardt on 11 Aug 2010 19:39 "Natacha Kerensikova" <lithiumcat(a)gmail.com> wrote in message news:d1c9014b-c78c-4cb5-ae34-506f8e5702c7(a)i13g2000yqd.googlegroups.com... .... >> ), then I assure you it can deal with Ada. > >But what's the point of knowing all this when one can't design a three- >digit LOC program properly? >It's just like knowing the dictionary contents by heart without >knowing anything about grammar. I think Bob's point is that most of this discussion is about software engineering and program decomposition. That's orthogonal to the implementation language: your programs would be better in any language, be it C, Ada, Fortran, Pascal, or anything else when you (or anyone) take those concepts into account. But there is no *requirement* to take those concepts into account in order to write Ada code. There is no requirement that you have to separate the creation and writing of atoms. Your code would be better in *any* language if you did, but it isn't always obvious how to accomplish that, and depending on the situation, it might not be worth the mental effort to do it. In any case, you are spending way too much effort trying to figure out how to fit your work into what Dmitry is suggesting. Bob and I have both tried to point out that there are lots of other ways to structure programs over what Dmitry is suggesting. Don't let one person's opinions push you away from Ada!! There are a lot of strong opinions here, and not all of them are the same. There is no one right way to use Ada! Randy Brukardt, Editor, Ada 2005 and Ada 2012 Standards.
From: Robert A Duff on 11 Aug 2010 21:31 "Randy Brukardt" <randy(a)rrsoftware.com> writes: > I think Bob's point is that most of this discussion is about software > engineering and program decomposition. Thank you, Randy. Yes, exactly. I don't think Natacha Kerensikova should be frightened away from Ada just because of this discussion. I don't know if S-expressions with untyped octet-sequence atoms are appropriate for some application or other, but if they are, Natacha's design seems reasonable to me. And that opinion is not specific to Ada. - Bob
From: Dmitry A. Kazakov on 12 Aug 2010 02:20 On Wed, 11 Aug 2010 18:18:48 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message > news:iv3qwjogornz$.1s8kq0yfl2wxl.dlg(a)40tude.net... > ... >> Conversion mess is what we already have right now. The point is that "+" >> is >> well-defined and meaningful for octets, but it is not closed in there. Why >> >> function "**" (Left : T; Right : Natural) return T; >> function S'Pos(Arg : S'Base) return universal_integer; >> ... >> >> are OK and "+" is not? > > The first has the same operand and result type (the power operand is > something else and not really part of the operator IMHO). What is the difference between "**" and "+"? It must be a language one, because semantically sum of octets is not an octet. > The second is the > long winded name for a conversion operator - it implies no semantic change. > I'm arguing that operations like S'Pos would be better having a common name > like "#" rather than a host of specialized names. Huh, and these must be a type conversions too: function S'Exponent (X : T) return universal_integer; S'Length A'Length (N) ... >>> Since we're inventing things, I would suggest: >>> >>> -- Conversion function (Not Ada): >>> function "#" (Right : Octet) return Universal_Integer; >>> >>> Little_Endian_Value := #Octet_1 + #Octet_2 * 256; >>> >>> And now you don't need any Octet math. >> >> 1. What is this else? > > Huh? This doesn't parse. The above looks like math to me. You take octet arguments and compute some results using arithmetic operations. >> 2. I see no advantage over >> >> Little_Endian_Value := Integer (Octet_1) + Integer (Octet_2) * 256; > > "#" can be overridden and/or user-defined. "Integer" cannot (and could never > be in a version of Ada, as any such attempt would be way too incompatible). > In addition, "#" is more readable in the 98% of the cases where you don't > need to specify a type. I would probably consider using predefined versions > of "#" to replace other forms of explicit type conversion as well (so "#" > would always work if defined - no decision about whether to call a function, > use a built-in type conversion, or use some attribute - and no need to look > up the name of the type). I see. No, that is a wrong way IMO. The right one is interfaces. If you want S be like T, derive S from T. If you don't like the implementation of T, inherit only the interface of. You should never have a need in explicit type conversions in a properly designed program. > That's the point: in Ada, type conversions are *not* functions, they're a > built-in gizmo [including some attributed]; by naming them "#" we would > allow unifying them with functions. I would prefer to eliminate them altogether. Conversions are always bad. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Ludovic Brenta on 12 Aug 2010 03:53
Georg Bauhaus wrote: > 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))) I made some fixes and I now consider my S-Expression parser[1] feature- complete as of revision b13ccabbaf227bad264bde323138910751aa2c2b. There may still be some bugs though, and the error reporting (to diagnose syntax errors in the input) is very primitive. Highlights: * the procedure S_Expression.Read is a quasi-recursive descent parser. "Quasi" because it only recurses when encountering an opening parenthesis, but processes atoms without recursion, in the same finite state machine. * the parser reads each character exactly once; there is no push_back or backtracking involved. This makes the parser suitable to process standard input on the fly. * to achive this, I had to resort to using exceptions instead of backtracking; this happens when the parser encounters a ')' immediately after an S-Expression (atom or list). * the parser also supports lists of the form (a b c) (more than 2 elements) and properly translates them to (a (b c)). The Append() procedure that does this is also public and available to clients. * the parser does not handle incomplete input well. If it gets Ada.IO_Exceptions.End_Error in the middle of an S-Expression, it will return an incomplete, possibly empty, S-Expression rather than report the error. I'll try to improve that. * the test.adb program demonstrates how to construct an S-Expression tree in memory (using cons()) and then sending it to a stream (using 'Write). * the test.adb program also demonstrates how to read an S-Expression from a stream (using 'Read) and then traverse the in-memory tree (using car(), cdr()). [1] http://green.ada-france.org:8081/branch/changes/org.ludovic-brenta.s_expressions I have not yet tested the parser on your proposed input (IIUC, consisting of two S-Expressions with a missing closing parenthesis). I think this will trigger the bug where End_Error in the middle of an S-Expression is not diagnosed. I also still need to add the proper GPLv3 license text on each file. I'll probably add support for Lisp-style comments (starting with ';' and ending at end of line) in the future. -- Ludovic Brenta. |