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: 103376,1a52c822fc0dbb23 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!storethat.news.telefonica.de!telefonica.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Rational for not making cursor tagged in Containers From: Georg Bauhaus In-Reply-To: References: <1176998738.656903.141250@q75g2000hsh.googlegroups.com> <1177010938.200523.325290@p77g2000hsh.googlegroups.com> <1a8y2vakorfhx.225uqh4hifpd$.dlg@40tude.net> <1xmzi7newnilp.23m3zze8h9yi.dlg@40tude.net> <1177066583.5876.30.camel@localhost.localdomain> <1177080147.5876.87.camel@localhost.localdomain> <1q1kx2jlcvnuj.ck0711mj4few$.dlg@40tude.net> <1177097829.26685.36.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: # Message-ID: <1177235674.13243.48.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Date: Sun, 22 Apr 2007 11:54:34 +0200 NNTP-Posting-Date: 22 Apr 2007 11:54:35 CEST NNTP-Posting-Host: cb7bf1cc.newsspool1.arcor-online.net X-Trace: DXC=:;a`UNQ2ZdmJ00P1S40fZgic==]BZ:afn4Fo<]lROoRaFl8W>\BH3YbPhITQ6bA`3fA:ho7QcPOVcTY?37b[bL[ccYWLXJ1:?Xe X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:15218 Date: 2007-04-22T11:54:35+02:00 List-Id: On Fri, 2007-04-20 at 14:55 -0500, Randy Brukardt wrote: > "Georg Bauhaus" wrote in message > news:1177097829.26685.36.camel@localhost.localdomain... > ... > > By analogy, and consistent with the desired record interfaces, > > I will be asking for task type interfaces (no, not really). > > Ada already has task interfaces, so you don't need to ask. ;-) I meant something different (i.e. not synchronized interfaces), based on my initial understanding that the concept of record was to be changed, not that there be some publicly visible syntactic sugar for read/write access to private components. If the suggested "record interface" allows programmers to write a subprogram that defines what R.A means, then the analog *change* for task types will be "type T is interface task ...". It will allow programmers to specify what "accessing" The_T.A means, i.e. they not only write an acceptor A, but they will also be writing what "accept" means. Only be default will "accept" fall back to the LRM thing. :-) Now the argument was that in a sense I can write "callable components" of packages, of protected objects, of tasks, but not of simple composite types. If this distinction seems unwarranted, it is perhaps interesting to compare with Eiffel counterparts. ECMA Eiffel defines Dmitry's suggestion AFAICS. (I'll leave out the complication introduced by expanded objects.) Access to a record component in Eiffel is either a function or looks like a function, depending on how it is defined. A client writing a record component in Eiffel will always call a procedure of the record class, even when it is written like assignment (":="), because the only way to modify an object from the outside is to call a procedure. The function will have an assigner command associated with it, class FOO inherit FLOAT feature get: INTEGER assign put is ... put (Value: INTEGER) is ... Suppose Ada was to give up simple record component read/write in favor of programmer defined subprograms implementing record interfaces. There are cases when the translated code will have to move memory words from here to their (as per LRM and reps.) When this is to be done for an Eiffel record, then reportedly, it always is tricky. Either the Eiffel literature suggest that the compiler has built in magic, or you revert to the programmer's knowledge of how the Eiffel code is translated to C and have him use this C knowledge to achieve the desired effect (assignment) at the C level. > Shouldn't it be possible > to create a complete abstraction that works like the built-in ones? Yes and No. I had (mis)understood that the built-in "abstractions" like "record" should only default to built-in mechanics. The more basic new "record interface" mechanism would in fact be less basic, because programmers can write a subprogram for what .Integer_Component := 5; will mean. If this were the only mechanism, wouldn't we soon be entering an infinite loop of a missing basic assignment? For what is the reason that I cannot make Integer assignment be an interface ;-) ;-) > After all, it's not about the syntax: > > X := Y; > > looks simple, but I've had to debug as much as 1K of machine code that > actually implements it. There can be a lot of complexity hidden behind the > two characters ":=". There is no reason to think that it would be a problem > if '.' or '(' or '"' had similar complexity. (Indeed, there are cases where > they do, you just can't write such cases yourself.) Exactly, and I was trying to suggest that it might or might not be a good idea to have the programmers write such cases, as they will have to manage the complexity of assignment in a way that is likely more complex than understanding ":=". But then, I think Dmitry is basically suggesting different syntax, not a new record mechanism; after all, with tagged records and Controlled components, the call side syntax is almost part of Ada.