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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8276b2994037cd71 X-Google-Attributes: gid103376,public From: Lao Xiao Hai Subject: Re: disjoint ranges ? Date: 2000/10/16 Message-ID: <39EBB984.F2F8905F@ix.netcom.com>#1/1 X-Deja-AN: 682307756 Content-Transfer-Encoding: 7bit References: <39E612C9.9BF98CD3@laas.fr> <8s59nu$ej4$1@news.huji.ac.il> <39E658A4.525AE881@acm.org> <39E6E890.3B13E7A9@laas.fr> <8s8iuk$q66$1@nnrp1.deja.com> X-Accept-Language: en X-Server-Date: 17 Oct 2000 02:34:55 GMT Content-Type: text/plain; charset=us-ascii Organization: MindSpring Enterprises Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-10-17T02:34:55+00:00 List-Id: Robert A Duff wrote: > Robert Dewar writes: > > > No, it could be over all damaging. Every new feature you add > > to a language damages it by adding to the understanding, > > programming, description, and implementation complexity. > > Quite true, but you don't necessarily have to add features in order to > add functionality. Sometimes, making a feature more powerful can add > functionality without increasing complexity. So, making a feature more powerful might be something such as being able to overload the "in" membership test. For some reason, this operator is not really a first class operator in Ada. I have often wondered about the rationale for that decision. If it were overloadable, one could simply declare a membership function that would enable disjoint membership tests. I do see some problems with this when considered in terms of the for loop since it would be a strange loop, indeed, that had disjoint values. On the other hand, that could also be an alternate solution to the absence of a step capability. Also, it does not have to be incompatible with the requirement that the value be discrete. Any thoughts on this? Richard Riehle