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: Robert A Duff <bobduff@world.std.com>
Subject: Re: disjoint ranges ?
Date: 2000/10/16
Message-ID: <wcc66ms91t9.fsf@world.std.com>#1/1
X-Deja-AN: 682119453
Sender: bobduff@world.std.com (Robert A Duff)
References: <39E612C9.9BF98CD3@laas.fr> <DhpF5.178$AR3.40313@nnrp2.sbc.net>
 <8s59nu$ej4$1@news.huji.ac.il> <z6rF5.45$bz5.65618@nnrp3.sbc.net>
 <39E658A4.525AE881@acm.org> <39E6E890.3B13E7A9@laas.fr>
 <8s8iuk$q66$1@nnrp1.deja.com>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 2000-10-16T00:00:00+00:00
List-Id: <comp.lang.ada>

Robert Dewar <robert_dewar@my-deja.com> 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.

For example, the approach I would take in this case would be to add
arbitrary boolean conditions as invariant conditions (somewhat as in
Eiffel), and then *get rid of* all the various kinds of special-purpose
constraints (range, index, discrim, accuracy).  This would lead to
adding the requested functionality, at a net *decrease* in language
complexity.

Note that Eiffel doesn't quite solve this problem: it has arbitrary
invariant expressions on types, but they can't be applied to integers
(there's only one integer type, and it can't have invariants).

> A feature like this is actually *quite* complex, think for
> example, that we would have to allow dynamic bounds for the
> ranges, and then the checks for disjointness get tricky
> to describe (e.g. can several ranges be flat or superflat?
> if they are, can bounds overlap for the flat ranges? etc)
> 
> That's only the tip of the iceburg complexity wise.
> 
> But the point is that you have to make sure that the value
> of the feature more than undoes the damage done by its
> addition. The burden of proof is tricky in this case, and
> I doubt a convincing argument can be made for adding this
> feature to the language.

Agreed.  Simply *adding* this feature as a feature is not a good idea.

- Bob