S-expression I/O in Ada
in [ADA]
|
Prev: GPRbuild compatibility
Next: Irony?
From: Robert A Duff on 9 Aug 2010 13:00 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: > On Mon, 09 Aug 2010 09:48:02 -0400, Robert A Duff wrote: > >> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: >> >>> The implementation or the idea? Would you agree that objects with some >>> properties of modular integers have place in Ada programs which do not >>> interface C? >> >> No. I do not like implicit "mod". But that's the essence of >> modular types. >> >> If I ran the circus, then this: >> >> M : constant := 2**64; >> type My_Unsigned is range 0..M-1; >> pragma Assert(My_Unsigned'Size = 64); >> >> X : My_Unsigned := ...; >> Y : My_Unsigned := (X + 1) mod M; >> >> would be legal, and would not raise any exceptions, even when >> X = M-1. (And I'd want "(X + 1) mod M" to be implemented >> as a single "add" instruction on a typical 64-bit machine.) > > What does "+" above return? A value of type My_Unsigned. The values of this type are the infinite set of all integers -- that's already the case in Ada, except that the RM allows (not requires) certain calculations to overflow and raise C_E. >...Is "mod M" a required part of the notation or > not? No, not required -- my idea is that if you want to perform some operation ("mod" or "+" or "*" or anything), you write that explicitly in the code. No change there from the way signed integers already work. >>>> Perhaps they _should_ be unordered, but I won't agree or disagree, >>>> since I think in an ideal world they should be banished. >>> >>> I think they could be fixed. >> >> How? And having fixed them, when would you use them? >> That is, when would you prefer them over signed integers? > > Ring buffer indexing, I prefer an explicit "mod" there. >...flags (by-value sets actually), I prefer array-of-Boolean over modular. Even better would be a proper user-defined abstraction, with notations like "in". >...cryptography, Explicit "mod". > interfacing, communication. 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;" > I think that all these usages require different types of modular types with > different sets of operations. So I would prefer a language extension which > would allow me construction of such types rather than built-in ones, which > satisfy no one. I certainly agree with that. But it sounds like you are agreeing with my point -- that modular types should not be in the language. > I agree. But it rather means that C is wrong defining size_t modular. On > Ada side it must be Natural_32. Why Ada does not support that? Why is it > impossible to declare 32-bit range 0..2**32-1 without wrapping (=with > overflow check)? Good question. - Bob
From: Robert A Duff on 9 Aug 2010 13:05 Georg Bauhaus <rm.dash-bauhaus(a)futureapps.de> writes: >> 7. No array index of > > These refer to arrays in general, not Boolean arrays as sets and, > I guess, the item numbered 7 follows a general rule: > Where the array type is visible, its index type is > visible. (Or else, you have been too lazy and used > an anonymous index type; still, you have 'first etc.) > Therefore, the index type can be named without > indirection, that is, via some array attribute function. > (Or else, index values can be made from 'first etc.) > Array access will be type checked either way. I think Dmitry was complaining in 7 that you can't do this: type Bit_Map is array(...) of Boolean; type T is array (Bit_Map) of Something; -- Illegal index type. whereas if Bit_Map is modular then you CAN do that. You can, but only if the number of bits is small. - Bob
From: Natacha Kerensikova on 9 Aug 2010 14:00 On Aug 8, 5:24 pm, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > So Ada's overloading rules might be as complicated as the C++ > rules, but Ada _seems_ simpler, because you can safely ignore > all the details. Unless you're writing an Ada compiler, of > course. I remember I wasn't that happy with C++ overloading, especially operator overloading. I wrote a 3D vector library only to find out operator overloading was more obscuring than improving readability, because too much was happening behind the scenes. So I came back to a math-assembly-looking sequence of function calls, uglier but easier to follow and maintain. > >...learning both Ada and AWS at the same time will > > probably be way too much. > > Well, I'm not sure. To learn a programming language, you need to > write programs, and also read programs. Jeff's point was that > reading AWS will help you learn Ada, and that's probably true. For some strange reason it didn't even occurred to be that the advice included reading AWS source and not only use it as a library. Still, AWS looks like an overkill for my web needs. > By the way, I don't see anything fundamentally wrong with > your s-expression plans, with s-expressions containing > raw arrays-of-octets Thanks for the support, that's what I'm about to do, except I'm still unsure about what array type to use: range octet, modular octet, Storage_Element, Stream_Element, something else > -- especially since you say you > already have a lot of stuff using s-exprs. You can layer on > top of that less-general but more-typed abstractions, probably > using generics. Actually I wasn't aware until very recently that the code I usually put on top of my S-expression parser is indeed called a parser too. So yeah, basically my S-expression library will be the common core of all my specialized configuration/template/etc file parsers. Natacha
From: Robert A Duff on 9 Aug 2010 14:09 Natacha Kerensikova <lithiumcat(a)gmail.com> writes: > Thanks for the support, that's what I'm about to do, except I'm still > unsure about what array type to use: range octet, modular octet, > Storage_Element, Stream_Element, something else The truth (after all this discussion) is that it doesn't matter a whole lot. - Bob
From: Natacha Kerensikova on 9 Aug 2010 14:10
On Aug 8, 10:34 pm, Jeffrey Carter <spam.jrcarter....(a)spam.not.acm.org> wrote: > On 08/08/2010 06:11 AM, Natacha Kerensikova wrote: > Most of what you presented seem more like implementation decisions > (S-expressions for the configuration information, S-expressions for the page > templates) than requirements. Even discussion of files and directories might be > premature, depending on the higher level requirements. A web server that can be > used in an embedded system as the external interface as well as as a stand-alone > system would need a more abstract view of permanent storage, for example. > > Of course, sometimes implementation decisions are made by others and become part > of one's requirements, but I wouldn't expect that in a personal project. And the > existence of an existing library can be an important factor when masking such > decisions. Technically, these are implementation decisions made by an earlier me: the web server project is intended to be a replacement for an existing web server, so either I use the same input files, or I write as a part of the project a converter from the existing format into the new server data. In both cases, I do have these S-expressions based files, and I do want to serve HTTP responses based (directly or indirectly) on them. > I wasn't saying that implementing an S-expression library, or deciding to use it > at a low level in your project, was a bad thing. I was viewing this project as a > separate thing from your S-expression library. I'm actually viewing it that way too: whatever project I will do next, it will almost surely rely on some existing S-expression files, so it make sense to start with general code dealing with S-expressions before making the final choice about what to do next. > > Unless I'm very misunderstanding and/or vary naive, I've got the > > feeling our approaches are not that different, and differ mostly in > > the order of implementation, which indeed doesn't change that much in > > the final result. > > You may well be right, in which case you'll likely find Ada to be a good fit for > your way of approaching things. That's what I think after reading most posts from this threads, exceptions being mostly Dmitry's posts which often make me feeling Ada's world is a strange place (to my mind) where I don't belong. I guess I'll have to dive deeper into Ada before knowing who's right. Thanks for your advice, Natacha |