discontinuous subtype without aspect

discontinuous subtype without aspect

[Mehdi Saada]

I'm happy that non continuous index subtypes will be allowed,
but I wonder why 
subtype S is T with STATIC_PREDICATE S in Val1|Val5..Val7
has been favored instead of plain:
subtype S is T range Val1|Val5..Val7 ?
It's not an already used syntax though.
Same thing here:
If Index has some static predicate, Squares_Array : Array_Type := (for I in Index => I * I); will iterate on in a non continuous way,
but why not Squares_Array : Array_Type := (for I in Val1..Val3|Val5 => I * I);
It would be a lot nicer, and '|' as far as I understood has close to one meaning or semantic wherever it's used, be it exception handlers and or case selection choices.

Re: discontinuous subtype without aspect

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:b7590929-1b5f-4e14-b689-c86999142749@googlegroups.com...
> I'm happy that non continuous index subtypes will be allowed,
> but I wonder why
> subtype S is T with STATIC_PREDICATE S in Val1|Val5..Val7
> has been favored instead of plain:
> subtype S is T range Val1|Val5..Val7 ?

Because a range is contigious! That's a basic property of a range. Note that 
we don't allow declaring arrays with predicates because we don't want arrays 
with holes in them (and absolutely don't want slices with different holes in 
them).

I had proposed allowing a "set constraint" rather having static predicates, 
but most people felt it wasn't necessary. (Argubly, it's the range 
constraints that are redundant these days, but history [and arrays] prevent 
getting rid of them altogether.)

> but why not Squares_Array : Array_Type := (for I in Val1..Val3|Val5 => I * 
> I);

".." is a contiguous range.

...because people didn't want set constraints. I still fail to understand 
why, as you point out, a static predicate is not quite a replacement.

Re: discontinuous subtype without aspect

[Mehdi Saada]

> ...because people didn't want set constraints. I still fail to understand
why, as you point out, a static predicate is not quite a replacement. 
It is a replacement, but I thought it was a shame there existed now, two syntaxic constructs to express the same things.
subtype FOO is BAR range Val5..Val6;
subtype FOO is BAR with STATIC_PREDICATE => FOO in membership_choice;
The second can express much more, but they still overlap, which isn't nice and clean.
Beside, I get it that a range is continuous by definition, but I still think "range 1..5|8..9" could be read as "range 1..5 and range 8..9" or "in 1..5|8..9". Forbide that for arrays, and that would be it.
Or better, I can subtype FOO is BAR in Val5..Val6|Val10; No need for range at all anymore, even for arrays. "in" is all that's needed. Fewer keywords too. A tool could also easily, for matter of compatibility, parse existing code and change every and each "range X..Y" by "in X..Y", and qualify X and Y by the parent's subtype's name.
Is that what you mean by set constraints ?

Re: discontinuous subtype without aspect

[Dmitry A. Kazakov]

On 2018-01-30 18:31, Mehdi Saada wrote:
>> ...because people didn't want set constraints. I still fail to understand
> why, as you point out, a static predicate is not quite a replacement.

An arbitrary constraint does not preserve any properties of the type. 
The only meaning of a constraint is to create an algebraic structure of 
certain, provable or known properties. E.g. ranges keep the set of 
values convex etc. Without properties advertised to the clients it is 
just ad-hockery.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: discontinuous subtype without aspect

[Randy Brukardt]

"Mehdi Saada" <00120260a@gmail.com> wrote in message 
news:6972f8eb-6130-4c47-b27a-f8dd0afeb171@googlegroups.com...
>> ...because people didn't want set constraints. I still fail to understand
>>why, as you point out, a static predicate is not quite a replacement.
>It is a replacement, but I thought it was a shame there existed now, two 
>syntaxic
> constructs to express the same things.

They're not semantically the same thing, as the set of values for a type 
(determined by a constraint) is always contiguous. A predicate then excludes 
some values from the set for various purposes, but the formal value set of 
the type is always contiguous. I agree, though, that the difference is 
mainly semantic, but it does show in the values of 'First and 'Last for the 
subtype, and a few other places.

...
>Is that what you mean by set constraints ?

Something like that, I don't remember the proposed syntax. The main 
difference is that a set constraint did change the set of values - so 'First 
and 'Last would change. There's not much difference, so I suppose that some 
people thought that the predicate version was simpler. I never agreed, so 
I'm the wrong person to talk to about this topic!

                        Randy.