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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,39579ad87542da0e X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 X-Received: by 10.180.109.111 with SMTP id hr15mr1641878wib.1.1368583240366; Tue, 14 May 2013 19:00:40 -0700 (PDT) Path: hg5ni110146wib.1!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.news.ucla.edu!nrc-news.nrc.ca!News.Dal.Ca!news.litech.org!news.stack.nl!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Seeking for papers about tagged types vs access to subprograms Date: Wed, 8 May 2013 17:29:33 +0200 Organization: cbb software GmbH Message-ID: References: <17ceq51ydy3s0.s94miqqzbg5w.dlg@40tude.net> <1vrhb7oc4qbob$.q02vuouyovp5$.dlg@40tude.net> <19lrzzbgm77v6.1dzpgqckptaj6.dlg@40tude.net> <1bfhq7jo34xpi.p8n2vq6yjsea.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 15waz9CoS+eMakbyhTPyFQ.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Date: 2013-05-08T17:29:33+02:00 List-Id: On Wed, 08 May 2013 13:08:48 +0200, Yannick Duchêne (Hibou57) wrote: > Le Wed, 08 May 2013 12:23:06 +0200, Dmitry A. Kazakov > a écrit: > >> On Wed, 08 May 2013 11:39:23 +0200, Yannick Duchêne (Hibou57) wrote: >> >>> But then, an example such as the above would present challenge with >>> derived types. >> >> That is the main question about parallel hierarchies: if you derive or >> constrain one type in the cloud, what happens with other types? Does this >> produce new types, related or unrelated, constrained or not. > > I would say there is no general answer without additional informations > about what the whole means, and no language or its compiler can tell it in > place of the author (or else, you decide in place of the author, and are > back to what it actually is). First you should be able to define such entities formally = at the language level. > A basic idea (more easy to say than to do): reuse things like > pre/post/pragma‑assert, but whose purpose is to be statically checked (if > it's too complicated to be checked, Checks if come in question, then only much later after you have formalized it. > Also to digress but still in some way related, more control on what can be > done of an instance of a type, toward restricting, permitting to deny the > use of some part of an interface, Each time you do something with a type you get another one. Otherwise it becomes untyped. So if you wanted to disallow operations that would make another interface. To put it differently, there shall be no preconditions on types and their operations which aren't trivially true. Another question is the relationship between the original type and the new one. That brings the issue of LSP with it, if you attempt to bring them into one hierarchy. Ad-hoc supertypes could possibly help. Parallel hierarchies could be an alternative. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de