From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,73cb216d191f0fef X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.24.132 with SMTP id u4mr1242297wif.6.1364344360282; Tue, 26 Mar 2013 17:32:40 -0700 (PDT) MIME-Version: 1.0 Path: p18ni19770wiv.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.130.MISMATCH!xlned.com!feeder1.xlned.com!border2.nntp.ams.giganews.com!border2.nntp.dca.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsgate.cuhk.edu.hk!goblin3!goblin.stu.neva.ru!nntp-feed.chiark.greenend.org.uk!ewrotcd!reality.xs3.de!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Wed, 20 Mar 2013 18:57:58 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <51408e81$0$6577$9b4e6d93@newsspool3.arcor-online.net> <11rcs3gg4taww$.bylek8fsshyz$.dlg@40tude.net> <99929f93-b80f-47c3-8a37-c81002733754@googlegroups.com> <87ec4b1d-f7cd-49a4-8cff-d44aeb76a1ad@googlegroups.com> <78103a2f-5d19-4378-b211-1917175d5694@googlegroups.com> <3p6p8k0yfly7.ctazdw7fc5so$.dlg@40tude.net> <1jtvzi1v65aqm.1k5ejsveno59f.dlg@40tude.net> <1hvv2kd9smnfx.6spgz9thd1mh$.dlg@40tude.net> <1raubw1sk48ca$.69rdgczvnnf.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1363823881 6789 69.95.181.76 (20 Mar 2013 23:58:01 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 20 Mar 2013 23:58:01 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2013-03-20T18:57:58-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1raubw1sk48ca$.69rdgczvnnf.dlg@40tude.net... > On Tue, 19 Mar 2013 16:19:54 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:vo941i7imo8t$.1jjjox9r1hkqa.dlg@40tude.net... > >>> It is well possible. Consider tag a constraint as array bounds are. >>> Allow >>> constraints (=discriminants) passed independently as compilers already >>> do >>> for array bounds. This gives you array interfaces while keeping arrays >>> as >>> they are, plain arrays. >> >> No, it's not possible. In order to solve the string problem, we have to >> decouple the representation and the interface. But for slices, you have >> to >> know the representation in order to be able to pass it meaningfully. > > You pass dope and reference. You have to know the representation of what you reference in order to access it, even after the "dope and reference". The only way to handle differing representations is to pass accessor thunks along with the dope, but that only allows you to access individual elements. Turning every slice reference into a loop of thunk calls is just way to complicated for the usage (which is pretty rare, especially if packages like Unbounded_Strings are made class-wide). >> Moreover, the representation is not necessarily an array (UTF-8 encoding >> is >> not a normal array if you are using the character interface). > > In the dope you have type tag to handle class-wide instances. You will > dispatch to the body which implements indexing for UTF-8 encoded arrays of > characters. If any dispatching is involved, the syntax ought to be that of a function call. That allows indexing but not slicing. Even if you are willing to confuse users with implicit dispatching, you're also talking about turning every slice reference into a loop. The extra complication would be intolerable for most vendors. >>>> My rough proposed Root_String_Type would be an abstract tagged type, >>> >>> I definitely don't want strings tagged. >> >> Then forget it. All composite types ought to be tagged; the root of the >> existing problem is that arrays aren't tagged. > > If you use "tagged" in RM sense as a class of types which a tag embedded > into the representation, then no. That is not the problem and I don't want > arrays to have tag. I want array interfaces and an ability to have objects > of the type A'Class where A is an array type. The representation of > A'Class > will have tag. The representation of A will not. Why do you care? String objects are a lot bigger than a tag, so it can't be a memory usage concern. The only other place it could possibly matter is I/O. But for package like Text_IO, a tag and dispatching is exactly what you want, and for 98% of strings, that's what they ultimately get used for. For streaming and the like, the representation does not include the tag if you stream a specific type. So what's the problem?? Removing a tag from an object is an optimization; I believe every object should have a tag and it's up to the compiler how to implement it. It's really none of your (the programmer's) business (in the absence of representation clauses). ... >> I don't think we >> need 'Class for access types, > > You need them because access types shall implement "access interface." We > need access interface for user-defined referential types. Ada 2012 has user-defined referential types. You can do everything you need with plain-old tagged types. >> because the effect is essentially the same as >> what we already have for anonymous access types > > I don't see why. I want to be able to declare my own type as an access > type: > > type Handle is private access T; > private > type Handle is record > Connection : DB_Connection_Handle; > Table : Unbounded_String; > ... -- etc > end record; > > with the semantics of new, Free, dereferencing defined as I wish. You can do the latter two in Ada 2012 as it stands; the first can easily be simulated with a constructor function. (Oh, that's right, you can't stand constructor functions.) But in any case, this is a bad idea. You don't want to explicitly handle memory management in modern programs. Do it under the covers somewhere (like in the containers packages); do *not* expose access types. > And I > want to be able to write a class-wide subprogram which would take both > Handle and some plain access type as a parameter. As I said, no new code should be exposing raw access types. Something like the container Cursor type is a much better way to handle the need for referential semantics. ... >> For someone that hates generics, why would you have so many? > > I have: > > 1. I/O modes of input, output, duplex; Seems like a runtime parameter, not a compile-time one. (i.e. Mode in the I/O packages). > 2. Specific values of types: Integer_n, Unsigned_n, String, Wide_String, > IEEE_Float_n; Yes, of course, this is the problem that requires generics, mainly building things like the Ada containers. > 3. Devices responsible to handle "registers" holding values; I don't see how a generic would help here. It is illegal to have most representation clauses in a generic body, so I don't see how you could even have a generic in this case. (It certainly wouldn't work in Janus/Ada, can't talk about GNAT.) > 4. Handles to registers; Pretty much the same as the previous. The package involved would be so small and there would be so few of them (one for each kind of native register type) that I'd just copy the text and do a block substitution to make a new one. Generics would just get in the way (and add overhead on a compiler that does sharing, like Janus/Ada). > 5. Publishing value change events and monitors of; Maybe, if you need them to work on multiple types. Seems like a sort of container, to me. > 6. Much whished, but practically impossible to do, bounded values. Seems like that fits under #2 (it's not possible to do these without knowing the underlying representation, unless you're willing to make them very expensive with tons of barely necessary exception handlers). Here again, I'd make a package for each such type that I needed. (That's precisely how this issue is handled in the Janus/Ada compiler -- no generics in sight.) > Here you are. On top of that there exist immense problems with explicit > conversions which needed between, say, a handle to a duplex register, when > an output one is expected. It is not just N instances it is also 2**N > combinations of cross operations. Again, I don't see any good reason to try to separate these things. >> Maybe you're trying too hard to be Object-Oriented; > > I am trying to have it type-safe. It would be just impossible to do in Ada > 95. In Ada 2005, which has Java interfaces, it gives what I described. > Lack > of MI, which is worked around using generics. I guess that MI would slash > the amount of code by ten. MD would do another tenth. It's not worth it to be type-safe in this way. Especially as preconditions/postconditions combined with static analysis give the same effect (compile time checking) with 10% of the work. There definitely is such a thing as being too type-safe. Of course, YMMV. Randy.