S-expression I/O in Ada
in [ADA]
|
Prev: GPRbuild compatibility
Next: Irony?
From: Randy Brukardt on 9 Aug 2010 21:06 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message news:tg5qbr47zjz4$.2ywa2b17s656.dlg(a)40tude.net... .... >>> Most of modular types should have no + at all. There should be a >>> readable >>> notation for X+1 instead of infernal T'Succ(X) There was a proposal to support X'Succ (effectively as a procedure), X being an object name. That eliminates most of the noise, but isn't perfect as it can't be easily used in a larger expression. I was in favor of that (along with X'Image, which is something that GNAT has supported for years). Randy.
From: Randy Brukardt on 9 Aug 2010 21:17 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message news:1y1c8zzqmcer5.po56hkesa968.dlg(a)40tude.net... .... >> For these, you don't want modular semantics -- you just want >> a data type whose representation matches what you're >> interfacing/communicating with, such as "type Octet is >> range 0..2**8-1;" > > The problem is that these things require both array-of-Boolean view and > arithmetic. I agree that when arithmetic is used, then it has to be wide. > E.g. when interpreting sequences of octets as little/big endian numbers, > we > never use modular arithmetic. But integer arithmetic is incompatible with > array/set view. What have you done with Dmitry?? You can't be the *real* Dmitry! :-) Array-of-bytes views and arithmetic views are of clearly different types, with different sets of operations. These shouldn't be mixed, logically or any other way. If you need to go between these views, you need some sort of type conversion (or Unchecked_Conversion or Stream'Read or...). Thus, it is *never* necessary to do operations on both views at once, and it is irrelevant what the "math" operations for octets is. If Ada gets anything wrong about this, it is that it has math operations at all for stream_elements. The Dmitry I now certainly understands this, so I wonder what you've done with him... :-) Randy.
From: Natacha Kerensikova on 10 Aug 2010 02:47 On Aug 10, 2:57 am, Jeffrey Carter <spam.jrcarter....(a)spam.not.acm.org> wrote: > > Natacha Kerensikova<lithium...(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. 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). > 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. 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); 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). Would you mind hinting me about to do specify my library in a better way? Thanks for your help, Natacha
From: Dmitry A. Kazakov on 10 Aug 2010 02:48 On Mon, 9 Aug 2010 20:17:40 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message > news:1y1c8zzqmcer5.po56hkesa968.dlg(a)40tude.net... > ... >>> For these, you don't want modular semantics -- you just want >>> a data type whose representation matches what you're >>> interfacing/communicating with, such as "type Octet is >>> range 0..2**8-1;" >> >> The problem is that these things require both array-of-Boolean view and >> arithmetic. I agree that when arithmetic is used, then it has to be wide. >> E.g. when interpreting sequences of octets as little/big endian numbers, >> we >> never use modular arithmetic. But integer arithmetic is incompatible with >> array/set view. > > What have you done with Dmitry?? You can't be the *real* Dmitry! :-) Brainwashed me? (:-)) > Array-of-bytes views and arithmetic views are of clearly different types, > with different sets of operations. These shouldn't be mixed, logically or > any other way. If you need to go between these views, you need some sort of > type conversion (or Unchecked_Conversion or Stream'Read or...). Thus, it is > *never* necessary to do operations on both views at once, and it is > irrelevant what the "math" operations for octets is. If Ada gets anything > wrong about this, it is that it has math operations at all for > stream_elements. Right, but there is no contradiction because it is more than one type involved. What I meant is: type Octet is ...; -- Array interface to access bits of the octet (not Ada) type Bit_Index is range 1..8; function "()" (Unit : Octet; Bit : Bit_Index) return Boolean; procedure "()" (Unit : in out Octet; Bit : Bit_Index; Value : Boolean); -- Arithmetic interface, immediately leads out of octets (not Ada) function "+" (Left, Right : Octet) return Universal_Integer; function "-" (Left, Right : Octet) return Universal_Integer; ... So when you write: Little_Endian_Value := Octet_1 + Octet_2 * 256; There result is not an octet, as it would be with a modular type. Presently it is just broken. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 10 Aug 2010 03:07
On Tue, 10 Aug 2010 00:21:46 +0200, Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: >> there is only one right way. > > (There is one right way per person. Some agree on the right way. > Even those who believe(!) in the one right way don't know(!) > for sure ... ;-) It is the purpose of science to find the right way. No, it wondered so many, why is there only one mathematics, a product of pure imagination? But it is out of comp.lang.ada scope. >> ["+"] is broken in C because it contradicts to the >> mathematical meaning of. > > The mathematical meaning of "+" is ambiguous or context dependent. It is exact in each context. C's authors didn't mean matrix addition when they designed +. > It depends on the definitions of "+" etc. Meaning depends on definitions? There must be something wrong in this sentence... > > So what do you propose? To keep it broken? Because >> people better understand broken stuff? They don't. > > Use operator symbols that clearly separate: > > - traditional mathematical addition > - computer addition I don't know what computer addition is. Computer does not count. Computer *models* counting. Function "+" is a model of what? > int f() {} > int (*g)() = f + 4; > int main() > { > return g(); > } I have no problem with this. They don't model integers here. They do software faults. As such + perfectly serves the purpose. (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |