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!news2.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newspeer1.nwr.nac.net!newspeer.monmouth.com!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.arcor.de!newsspool2.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: <1q1kx2jlcvnuj.ck0711mj4few$.dlg@40tude.net> 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> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: # Message-ID: <1177097829.26685.36.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Date: Fri, 20 Apr 2007 21:37:09 +0200 NNTP-Posting-Date: 20 Apr 2007 20:35:30 CEST NNTP-Posting-Host: 71fdc789.newsspool4.arcor-online.net X-Trace: DXC=UCGNU]bf`eTV;Ef1`Jk54\4IUKCkJ3Qd4LS9bQN8QP X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:15163 Date: 2007-04-20T20:35:30+02:00 List-Id: On Fri, 2007-04-20 at 17:13 +0200, Dmitry A. Kazakov wrote: > You still can use > plain records as an abbreviation to: this implements a record interface and > surprisingly is also built-it record. Except for the surprise that's fine, then. (I'm curious what your ideas are regarding rules for accessing sister record components in .Mumble procedures, elaboration order, etc.. I'm assuming that the thing is more than a syntactical device?) > > This is where it becomes dangerous, I think. Suggesting that programmers > > can implement "linguistic interfaces" forces programmers to be language > > designers, profiting from decades of language research, compilation > > technology, etc. etc.. > > Honestly, I don't see what is so especially dangerous in X.A as compared to > A(X). I had understood that plain records were to be abandoned in favor of a set of record interface rules not only permitting programmers to implement record interfaces, but instead forcing them to do so because record mechanisms would no longer be part of the language. That is, X.A := whatever(expr); must in effect become whatever(X, expr); which does whatever it does. (Would we have whatever(X, expr(T'access)) in default initializers for limited types?) > >>> Not every programming team consists of real or even wannabe > >>> language designers. But who else has even got a chance of knowing > >>> what they are doing to a larger program when implementing the > >>> concept of record? > >> > >> Why they are allowed to implement a concept of task, > > > > Uh, what do you mean? > > I mean they are allowed to write > > task type X is > > but not > > record type X is > > (as opposed to type Y is record [X]) > > IMO, task is far more conceptually complex than a container of fixed number > of elements indexed by statically known strings. By analogy, and consistent with the desired record interfaces, I will be asking for task type interfaces (no, not really). This is a good illustration of what I meant to say. You can choose between two points of view: 1 this gives programmers the freedom to implement their ideas of a concurrent execution in a guided fashion. 2 this places the burden of implementing a tasking RTS on the shoulders of the programmers. > I cannot understand why a > record view should enforce anything on the implementation of, beyond that > view. Maybe for ease of recognition and simplicity of prediction in typical systems programming? When I see X.A := 16#FE#; and notice that X is of a simple record type, I expect only a small number of mishaps. > Also I fail to understand why polymorphic objects has to be records > and not arrays or access types. Why array or number cannot have > discriminants, but records can? "Uniformity. Discriminants make sense for any composite type. In Ada 9X, we allow them for any composite type except array types. The array-type restriction is for ease of implementation -- it does not simplify the language nor make it easier to use. Adding another restriction for task types would decrease uniformity further. Discriminants are allowed for protected types; disallowing them for tasks would make tasks a second-class citizen." -- http://archive.adaic.com/standards/95lsn/LSN1044.TaskDisc.txt You do not want subprogram interfaces, I presume? :-)