Making sense of predicates

Making sense of predicates

[Dmitry A. Kazakov]

Considering this:

   type T is tagged null record;
   procedure P (X : T);

   type S is new T with null record;
   procedure Q (X : T);

   subtype Subclass is T'Class with
      Dynamic_Predicate => Subclass in S'Class;
      -- Should have been Static_Predicate, but illegal

Now:

   X : Subclass := S'(null record);
begin
   X.P;
   X.Q; -- Illegal

Well, predicates were not supposed to work in an intelligent way, so why
not to add a kind that will?

There are number of cases where this would be very useful. E.g. smart
pointers:

   type T1 is tagged ...;
   type T1_Ptr is access all T1'Class;
   type H1 is new Ada.Finalization.Controlled with record -- Handle type
       Ptr : T1_Ptr;
   end record;

   type T2 is new T1 with ...;

Presently it is impossible to derive H2 from H1 constrained to point to
T2'Class. (Neither it were possible with implicit dereferencing)

With the above, one would create a subtype of H1 constrained to T2'Class
and then derive from it (better in one step, of course).

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

Re: Making sense of predicates

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:myuy19txq4vq.6xym4vrt6irl.dlg@40tude.net...
> Considering this:
>
>   type T is tagged null record;
>   procedure P (X : T);
>
>   type S is new T with null record;
>   procedure Q (X : T);
>
>   subtype Subclass is T'Class with
>      Dynamic_Predicate => Subclass in S'Class;
>      -- Should have been Static_Predicate, but illegal
>
> Now:
>
>   X : Subclass := S'(null record);
> begin
>   X.P;
>   X.Q; -- Illegal
>
> Well, predicates were not supposed to work in an intelligent way, so why
> not to add a kind that will?

They're plenty intellegent: they're purely a runtime check, just like a 
constraint. If you don't want a runtime check, don't use 'em. You want a new 
kind of type, which is something very different.

> There are number of cases where this would be very useful. E.g. smart
> pointers:
>
>   type T1 is tagged ...;
>   type T1_Ptr is access all T1'Class;
>   type H1 is new Ada.Finalization.Controlled with record -- Handle type
>       Ptr : T1_Ptr;
>   end record;
>
>   type T2 is new T1 with ...;
>
> Presently it is impossible to derive H2 from H1 constrained to point to
> T2'Class. (Neither it were possible with implicit dereferencing)
>
> With the above, one would create a subtype of H1 constrained to T2'Class
> and then derive from it (better in one step, of course).

It should be one step (only). We'd need something like co-derivation for 
that, which might make sense to pursue someday (the main reason would be to 
get rid of access types altogether, but to do that you need some sort of 
handle, like the container cursor -- and clearly you need to be able to 
derive the container and its handle together). But that would be a big job 
to define properly, it would take the existing inheritance rules and make 
them much more complex. (There are already 3 pages of rules associated with 
inheritance for derived types.)

                                     Randy.

Re: Making sense of predicates

[Dmitry A. Kazakov]

On Mon, 21 Oct 2013 23:35:59 -0500, Randy Brukardt wrote:

> It should be one step (only). We'd need something like co-derivation for 
> that, which might make sense to pursue someday (the main reason would be to 
> get rid of access types altogether, but to do that you need some sort of 
> handle, like the container cursor -- and clearly you need to be able to 
> derive the container and its handle together). But that would be a big job 
> to define properly, it would take the existing inheritance rules and make 
> them much more complex. (There are already 3 pages of rules associated with 
> inheritance for derived types.)

It is not only access types. It is relationships between types: Pointer -
Target, Array - Index - Element, etc.

If you try, as Ada designers keep on doing, to handle that at the language
level for each built-in type individually, you indeed end up with something
as horrific as accessibility rules are. That does not work.

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

Re: Making sense of predicates

[Georg Bauhaus]

On 22.10.13 10:19, Dmitry A. Kazakov wrote:
> That does not work.

From a vendors' point of view, adding fancy stuff works,
immediately. If industry does not complain, why would we?

Re: Making sense of predicates

[Dmitry A. Kazakov]

On Tue, 22 Oct 2013 14:53:04 +0200, Georg Bauhaus wrote:

> On 22.10.13 10:19, Dmitry A. Kazakov wrote:
>> That does not work.
> 
> From a vendors' point of view, adding fancy stuff works,
> immediately. If industry does not complain, why would we?

Don't really understand your point. BTW, I am not sure about you, but I
regard myself as a part of the industry.

P.S. I would also object the very idea of design by industry requests.
Industry by necessity is conservative and unimaginative.

P.P.S. My educated guess would be that accessibility checks score about one
third of faults in Ada programs, while preventing no more than 1%.

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

Re: Making sense of predicates

[Georg Bauhaus]

On 22.10.13 15:38, Dmitry A. Kazakov wrote:
> On Tue, 22 Oct 2013 14:53:04 +0200, Georg Bauhaus wrote:
>
>> On 22.10.13 10:19, Dmitry A. Kazakov wrote:
>>> If you try, as Ada designers keep on doing, to handle that at
>>>  the language level for each built-in type individually, you indeed
>>>  end up with something as horrific as accessibility rules are.
>>>  That does not work.

>>  From a vendors' point of view, adding fancy stuff works,
>> immediately. If industry does not complain, why would we?
>
> Don't really understand your point. BTW,

I meant that Ada 2012 has got new things by "adding fancy stuff"
here and there as opposed to by "redesigning the language".

The first approach, "adding fancy stuff", is an excellent
source of arguments and illusions, as it serves make-believe
on several accounts:

- you can state that it is substantially easier to handle source
  text written in "compatible" dialects than it is to handle source
  text written in two related, though slightly different languages.

- or, that a patched language protects your investments better than
  a cleaned-up language.

- or, you lift that backwards compatibility steam hammer and
   most project managers think all is well.

But that's all just a fake, see below.

Try finding consistency in Ada business regarding the languages.
This is from Ada videos:

(1) "Many customers happily continue using Ada 95 only."
(2) "Backwards compatibility is a hugely important thing."

If "many" customers means "most" customers, then what is the
fraction of Ada customers actually affected by a redesigned
Ada 202Z, more than by another collection of patches and
additions, if (1) is true?

If (2) is real, is there a technical reason that prevents
translating to Ada 95 source text?  I don't see how there
could be a reason if at the same time compilers handle both
old and new dialects of Ada. I mean, no technical reason.

(3) "They perform object code verification."

Then, to start with, why are they using a different compiler
at all? How does backwards compatibility at the source level
matter so much if what really matters is (3)? Is backwards
compatibility not just irrational FUD that's so perfect a tool
in the hands of every salesperson? If is more than irrational
FUD, to what extent is it rational?  Does this extent warrant
an ever growing complexity of a backwards compatible language?

At least GNAT showcases the inconsistency in this regard:
it does support Ada 95 and Ada 20XY nicely, yet we can read
that it will be catastrophic if Ada ever deviates from Ada 95
more than what had to be allowed. GNAT handles both languages.
But see, both _languages_!  If the Ada language were redesigned,
we'd still have just two languages, and closely related!

IINM, they are merging Ada and SPARK at AdaCore. This reminds me
of Windows NT 3.51 -> 4.0, merging the core OS and its GUI.
For technical reasons? No.

> P.S. I would also object the very idea of design by industry requests.
> Industry by necessity is conservative and unimaginative.

The craftspeople, the engineers do not seem that unimaginative
to me; they frequently want to handle the new (to them)
interesting stuff, and even build it. Some are really into
engineering new thing, wanting to do it right, technically.

Minimalist project management is a different story. But its
conservative and unimaginative traits will be gone as
soon as there is 1 industry acting as one to get the tools
they all want, for their money. Not N non-cooperative companies
that are so easily handled by the oligopoly...

> I am not sure about you, but I regard myself as a part of
>the industry.

So did the Daimler Group manager who said, publicly, that
their software department was not going buy that new offering by
software maker MS!
I am almost certain MS's salespoeple rolled every honeypot they
could find towards Stuttgart to silence the man! That was just
one man in industry.

Re: Making sense of predicates

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:9vlzla1igu9w$.1ifys2xkaugrn$.dlg@40tude.net...
> On Mon, 21 Oct 2013 23:35:59 -0500, Randy Brukardt wrote:
>
>> It should be one step (only). We'd need something like co-derivation for
>> that, which might make sense to pursue someday (the main reason would be 
>> to
>> get rid of access types altogether, but to do that you need some sort of
>> handle, like the container cursor -- and clearly you need to be able to
>> derive the container and its handle together). But that would be a big 
>> job
>> to define properly, it would take the existing inheritance rules and make
>> them much more complex. (There are already 3 pages of rules associated 
>> with
>> inheritance for derived types.)
>
> It is not only access types. It is relationships between types: Pointer -
> Target, Array - Index - Element, etc.

Yes, of course. The idea is that you'd be able to declare any set of types 
as "co-tagged" or something like that. (I'm thinking on the fly here, so 
don't read anything much into the names.) Then they'd have to be derived 
(extended) together as a group.

> If you try, as Ada designers keep on doing, to handle that at the language
> level for each built-in type individually, you indeed end up with 
> something
> as horrific as accessibility rules are. That does not work.

That's doesn't remotely resemble what I was thinking of; I was only thinking 
about a new kind of derivation and possibly a new kind of tagged type. Basic 
building blocks, nothing "built-in".

                                  Randy.

Re: Making sense of predicates

[Dmitry A. Kazakov]

On Wed, 23 Oct 2013 23:03:05 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:9vlzla1igu9w$.1ifys2xkaugrn$.dlg@40tude.net...
>> On Mon, 21 Oct 2013 23:35:59 -0500, Randy Brukardt wrote:
>>
>>> It should be one step (only). We'd need something like co-derivation for
>>> that, which might make sense to pursue someday (the main reason would be 
>>> to
>>> get rid of access types altogether, but to do that you need some sort of
>>> handle, like the container cursor -- and clearly you need to be able to
>>> derive the container and its handle together). But that would be a big job
>>> to define properly, it would take the existing inheritance rules and make
>>> them much more complex. (There are already 3 pages of rules associated 
>>> with inheritance for derived types.)
>>
>> It is not only access types. It is relationships between types: Pointer -
>> Target, Array - Index - Element, etc.
> 
> Yes, of course. The idea is that you'd be able to declare any set of types 
> as "co-tagged" or something like that. (I'm thinking on the fly here, so 
> don't read anything much into the names.) Then they'd have to be derived 
> (extended) together as a group.

The problem going this path is that when you derive from a "co-tagged" type
you most likely have to drop its implementation. E.g. a more specific
handle must replace a wider access type in it with a narrower one. This is
why I always suggested interface inheritance from concrete types. That is,
not a type extension, you inherit primitive operations abstract and drop
the representation.

A way to do it through null extension (though more limited in its
capabilities) is what I did in the original post. That requires a mechanism
of propagation constraints from the type down to its components and a
mechanism of static constraining T'Class to a subclass.

Of course constraints propagation could be a benefit elsewhere. E.g.
consider not null access components. They are mostly useless because the
constraint is on the component's type and thus is enforced too early.
Instead of that if we could attach the constraint to its container and let
it propagate to the component, we could postpone first check until
initialization of the container, e.g. until return from Initialize. Which
will make it possible to initialize such components from Initialize and
cleanup in Finalize.

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

Re: Making sense of predicates

[Shark8]

On Monday, October 21, 2013 1:51:58 PM UTC-6, Dmitry A. Kazakov wrote:
> Considering this:
>    type T is tagged null record;
>    procedure P (X : T);
> 
>    type S is new T with null record;
>    procedure Q (X : T);
> 
>    subtype Subclass is T'Class with
>       Dynamic_Predicate => Subclass in S'Class;
> 
>       -- Should have been Static_Predicate, but illegal

Er, why not have:
  Function Is_S( Input : in T'class ) return boolean is
  ( Input in S'Class );
or just use S'class variables?


> 
> Well, predicates were not supposed to work in an intelligent way, so why
> not to add a kind that will?

I think they are supposed to work in an intelligent way, though perhaps they're not as nice as compile-time/static checks.

> There are number of cases where this would be very useful.

Agreed; I was disappointed the following doesn't work:

 Subtype Digit_Character is Character range '0'..'9';

 Subtype Part_Number is String
   with Static_Predicate => (for all C in Part_Number => C in Digit_Character);

As it would be nice to basically subtype out [further-constrain] the element-type just as we can do to the index (e.g. "Subtype Phone_Digits is String(1..7);", which is equivalent to "subtype phone_range is Positive range 1..7; Subtype Phone_Digits is String(Phone_Range);", where 'phone_range' is an anonymous subtype.)

Re: Making sense of predicates

[Jacob Sparre Andersen]

Shark8 <onewingedshark@gmail.com> writes:

> Agreed; I was disappointed the following doesn't work:
>
>  Subtype Digit_Character is Character range '0'..'9';
>
>  Subtype Part_Number is String
>    with Static_Predicate => (for all C in Part_Number => C in Digit_Character);
>
> As it would be nice to basically subtype out [further-constrain] the
> element-type just as we can do to the index (e.g. "Subtype
> Phone_Digits is String(1..7);", which is equivalent to "subtype
> phone_range is Positive range 1..7; Subtype Phone_Digits is
> String(Phone_Range);", where 'phone_range' is an anonymous subtype.)

If you did it right, it would work:

package Parts is
   subtype Digit_Character is Character range '0' .. '9';

   subtype Part_Number is String
     with Dynamic_Predicate => (for all C of Part_Number
                                  => C in Digit_Character);
end Parts;

with Parts;

procedure Use_Parts is
   Work : Parts.Part_Number := "1234";
   Fail : Parts.Part_Number := "fail";
begin
   null;
end Use_Parts;

% ./use_parts

raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : Dynamic_Predicate failed at use_parts.adb:6
%

Greetings,

Jacob
-- 
Photos from the Faroe Islands:
       http://billeder.sparre-andersen.dk/The_Faroe_Islands/

Re: Making sense of predicates

[Shark8]

On Tuesday, October 22, 2013 1:35:02 AM UTC-6, Jacob Sparre Andersen wrote:
> Shark8 writes:
> 
> > Agreed; I was disappointed the following doesn't work:
> >
> >  Subtype Digit_Character is Character range '0'..'9';
> >  Subtype Part_Number is String
> >    with Static_Predicate => (for all C in Part_Number => C in Digit_Character);
> >
> > As it would be nice to basically subtype out [further-constrain] the
> > element-type just as we can do to the index (e.g. "Subtype
> > Phone_Digits is String(1..7);", which is equivalent to "subtype
> > phone_range is Positive range 1..7; Subtype Phone_Digits is
> > String(Phone_Range);", where 'phone_range' is an anonymous subtype.)
> 
> If you did it right, it would work:
> 
> package Parts is
>    subtype Digit_Character is Character range '0' .. '9';
>    subtype Part_Number is String
>      with Dynamic_Predicate => (for all C of Part_Number
>                                   => C in Digit_Character);
> end Parts;

I think you misunderstand my point: there's no real reason [at least that I can tell (apart from syntax, possibly)] that an array-type cannot be subtyped in order to place additional [static] constraint upon the base-type.

IOW, why is the predicate required to be dynamic when, for example, "subtype Number_String is Array(Positive range <>) of Digit_Character" or "subtype short_String is String(1..255)" is not a dynamic-predicate?

Re: Making sense of predicates

[Jacob Sparre Andersen]

Shark8 wrote:

> On Tuesday, October 22, 2013 1:35:02 AM UTC-6, Jacob Sparre Andersen wrote:

>> package Parts is
>>    subtype Digit_Character is Character range '0' .. '9';
>>    subtype Part_Number is String
>>      with Dynamic_Predicate => (for all C of Part_Number
>>                                   => C in Digit_Character);
>> end Parts;
>
> I think you misunderstand my point: there's no real reason [at least
> that I can tell (apart from syntax, possibly)] that an array-type
> cannot be subtyped in order to place additional [static] constraint
> upon the base-type.

I've not tried to work out what differences there must be between how a
compiler implements dynamic and static predicates, but I assume that
there is a reason that the ARG decided to distinguish between the two
cases.

> IOW, why is the predicate required to be dynamic when, for example,
> "subtype Number_String is Array(Positive range <>) of Digit_Character"

That one isn't a subtype, which may hint at the reason.

> or "subtype short_String is String(1..255)" is not a
> dynamic-predicate?

A better example.  I'm not sure why, but I suspect that the
differentiation is due to how a compiler implements the checks.

If we can work out how to make the checks for some classes of
(currently) dynamic predicates as simple as those for static predicates,
we can probably get the ARG to reclassify those classes of predicates.

Greetings,

Jacob
-- 
"It ain't rocket science!"

Re: Making sense of predicates

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:b4d93d01-c200-404f-a414-71258ef8318c@googlegroups.com...
...
> IOW, why is the predicate required to be dynamic when, for example, 
> "subtype Number_String is Array(Positive range <>) of Digit_Character" or 
> "subtype short_String is String(1..255)" is not a dynamic-predicate?

Because the idea of a "static predicate" was a hack to allow certain 
(scalar) predicates in for loops and case statements. All predicates were 
originally supposed to be dynamic; there was a set constraint proposed to 
handle the static set cases. Most people (not me) preferred having 
predicates handle sets, that required two kinds of predicate to avoid 
maintenance hazards.

Maybe we'll extend them someday, but I think we'd have to have a compelling 
use case. And adding new kinds of constraints (such as an array element 
constraint) would have a much higher bar than extending existing kinds of 
constraints (such as a way to have a static one-ended unconstrained array).

                                Randy.

Re: Making sense of predicates

[Dmitry A. Kazakov]

On Tue, 22 Oct 2013 00:14:27 -0700 (PDT), Shark8 wrote:

>> Well, predicates were not supposed to work in an intelligent way, so why
>> not to add a kind that will?
> 
> I think they are supposed to work in an intelligent way, though perhaps
> they're not as nice as compile-time/static checks.

It is not about checks. Mathematically there might be no difference, but
for the language there is a great difference between inferred and
manifested properties of types. The power of the former is very limited.

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

Re: Making sense of predicates

[Jacob Sparre Andersen]

Dmitry A. Kazakov wrote:

> Considering this:
>
>    type T is tagged null record;
>    procedure P (X : T);
>
>    type S is new T with null record;
>    procedure Q (X : T);
>
>    subtype Subclass is T'Class with
>       Dynamic_Predicate => Subclass in S'Class;
>       -- Should have been Static_Predicate, but illegal
>
> Now:
>
>    X : Subclass := S'(null record);
> begin
>    X.P;
>    X.Q; -- Illegal
>
> Well, predicates were not supposed to work in an intelligent way, so
> why not to add a kind that will?

But they do.

* Predicates limit the set of possible values of a type.
* Extensions expand the set of possible values of a type.

You just have to use the right tool for the job.

> There are number of cases where this would be very useful. E.g. smart
> pointers:
>
>    type T1 is tagged ...;
>    type T1_Ptr is access all T1'Class;
>    type H1 is new Ada.Finalization.Controlled with record -- Handle type
>        Ptr : T1_Ptr;
>    end record;
>
>    type T2 is new T1 with ...;
>
> Presently it is impossible to derive H2 from H1 constrained to point
> to T2'Class. (Neither it were possible with implicit dereferencing)
>
> With the above, one would create a subtype of H1 constrained to
> T2'Class and then derive from it (better in one step, of course).

I think I understand what you want.  I suspect that it would be rather
hard to implement in a compiler.  Do you have an idea for how it could
be done?  (Just asking for fancy stuff without thinking if it is
possible is something we should leave to architects.)

Greetings,

Jacob
-- 
"War does not determine who is right - only who is left."
                                         -- Bertrand Russell

Re: Making sense of predicates

[Dmitry A. Kazakov]

On Tue, 22 Oct 2013 09:20:50 +0200, Jacob Sparre Andersen wrote:

> Dmitry A. Kazakov wrote:
> 
>> Considering this:
>>
>>    type T is tagged null record;
>>    procedure P (X : T);
>>
>>    type S is new T with null record;
>>    procedure Q (X : T);
>>
>>    subtype Subclass is T'Class with
>>       Dynamic_Predicate => Subclass in S'Class;
>>       -- Should have been Static_Predicate, but illegal
>>
>> Now:
>>
>>    X : Subclass := S'(null record);
>> begin
>>    X.P;
>>    X.Q; -- Illegal
>>
>> Well, predicates were not supposed to work in an intelligent way, so
>> why not to add a kind that will?
> 
> But they do.
> 
> * Predicates limit the set of possible values of a type.

Which definitely applies to Subclass. The set of values of Subclass is
narrowed from T'Class to its proper subset S'Class.

BTW, intelligence when limiting values set is a big issue by itself. It is
enough to mention the Circle-Ellipse controversy.

>> There are number of cases where this would be very useful. E.g. smart
>> pointers:
>>
>>    type T1 is tagged ...;
>>    type T1_Ptr is access all T1'Class;
>>    type H1 is new Ada.Finalization.Controlled with record -- Handle type
>>        Ptr : T1_Ptr;
>>    end record;
>>
>>    type T2 is new T1 with ...;
>>
>> Presently it is impossible to derive H2 from H1 constrained to point
>> to T2'Class. (Neither it were possible with implicit dereferencing)
>>
>> With the above, one would create a subtype of H1 constrained to
>> T2'Class and then derive from it (better in one step, of course).
> 
> I think I understand what you want.  I suspect that it would be rather
> hard to implement in a compiler.  Do you have an idea for how it could
> be done?

By reworking Ada type system, which never will happen. I thought that maybe
a more subtle way could be to bend some recently added patches in a useful
way.

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

Re: Making sense of predicates

[Dan'l Miller]

On Tuesday, October 22, 2013 2:57:21 AM UTC-5, Dmitry A. Kazakov wrote:
> On Tue, 22 Oct 2013 09:20:50 +0200, Jacob Sparre Andersen wrote:
> [...snip...]
> By reworking Ada type system, which never will happen. I thought that maybe
> a more subtle way could be to bend some recently added patches in a useful
> way.

Dmitry,
Please present to comp.lang.ada a minimal* itemized list of
A) the extant portions of the Ada2012 typing-system whose presence obstructs what you are seeking along with why these presences obstruct your vision
B) the lacks within the Ada2012 typing-system whose absence obstructs what you are seeking along with why these absences obstruct your vision.

* minimal = not everything plus the kitchen-sink that world+dog thinks is trendy & cool.  Rather, please focus on only those few portions that could be applied to great advantage in Ada without wholesale replacement of Ada's entire typing-system (or worse, Ada's entire runtime semantic system) with, say, OCaml's entire typing-system, warts & all.

Re: Making sense of predicates

[Dmitry A. Kazakov]

On Tue, 22 Oct 2013 07:52:03 -0700 (PDT), Dan'l Miller wrote:

> On Tuesday, October 22, 2013 2:57:21 AM UTC-5, Dmitry A. Kazakov wrote:
>> On Tue, 22 Oct 2013 09:20:50 +0200, Jacob Sparre Andersen wrote:
>> [...snip...]
>> By reworking Ada type system, which never will happen. I thought that maybe
>> a more subtle way could be to bend some recently added patches in a useful
>> way.
> 
> Dmitry,
> Please present to comp.lang.ada a minimal* itemized list of
> A) the extant portions of the Ada2012 typing-system whose presence
> obstructs what you are seeking along with why these presences obstruct
> your vision

You mean type system things which better be removed from the language?

1. Accessibility checks
2. Anonymous access types
3. Dynamic predicates
4. Limited types "return"
5. Interfaces (superfluous, abstract types, plus MI do the job)

> B) the lacks within the Ada2012 typing-system whose absence obstructs what
> you are seeking along with why these absences obstruct your vision.

1. Enforced [de/con]structors and for all types, with arguments
2. Class-wide [de/con]structors (a way to dispatch upon construction and
finalization)
3. Discriminants of any type for any type
4. Assignment as a proper primitive operation (MD)
5. Attributes as proper primitive operations (e.g. Image)
6. MD (difficult)
7. MI (easy)
8. Delegation (instead of manually written wrappers)
9. Interface inheritance from concrete types (dropping representation)
10. Tagged classes of non-tagged types (classes for all types)
11. Abstract array, record, access types with interfaces and classes of
12. Proper abstract index types with interfaces and classes of
13. Proper range and slice types with interfaces and classes of
14. Tagged task and protected types
15. Proper procedural types (instead of access types in downward closures)
16. In general, return back to named typing (from creeping types inference
and structural equivalence)

> Rather, please focus on only those few portions that could be applied to
> great advantage in Ada without wholesale replacement of Ada's entire
> typing-system (or worse, Ada's entire runtime semantic system) with, say,
> OCaml's entire typing-system, warts & all.

The goal should be a leaner and more powerful type system with the present
type system implemented on top of it at the library level, 100% backward
compatible.

P.S. Putting up such lists is a completely wasted time, as nothing will
ever happen, until somebody with the influence of Ichbiah or Taft will nuke
the swamp again.

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

Re: Making sense of predicates

[Dan'l Miller]

On Tuesday, October 22, 2013 11:30:30 AM UTC-5, Dmitry A. Kazakov wrote:
> The goal should be a leaner and more powerful type system with the present
> type system implemented on top of it at the library level, 100% backward
> compatible.

Ahhhh, you seek effectively the C++ vision, but done differently somehow (or else why not simply leave Ada and program in C++2011).  Then, your primary task is not to convince people in Ada of matters related to the typing-system per se.  Rather your goal is to convince people in Ada how delegating language/compiler functionality upward to the "library level" would not suffer the disastrous defects plaguing C++'s metatemplate programming (MTP).  What you seek is not a better typing-system per se.  What you seek is a better way of layering the compiler and extending the compiler, such as multistage programming (of which C++-style MTP is a poor-man's misguided inferior-quality knock-off of a half-baked flight of fancy).  [Hint:  don't replicate the C++ MTP mess; do something *entirely* different than the C++ direction.]  You should advocate for what that multistage(-or-whatever) programming feature-set would look like in Ada-refounded, act like in Ada-refounded, enforce safety like in Ada-refounded, and so forth, preferably revealing both the new utopia as well as the impeccability of the Ada2012 backward-compatibility.  Then a feature-rich rethought typing-system is merely the first impressive tour-de-force demonstration of such compiler extensibility.

Btw, Seed7 has done some limited work in this direction, but is best thought of as a one-off tangential demonstration of some categories of partial-solutions toward this compiler-extensibility goal, instead of as the only path leading toward the promised land of multistage programming and compiler extensibility.  Of course, the set {OCaml, Camlp4, MetaOCaml} deserve a peek as well, borrowing here & there, leaving behind their bizarreness.

> P.S. Putting up such lists is a completely wasted time, as nothing will
> ever happen, until somebody with the influence of Ichbiah or Taft will nuke
> the swamp again.

Your pessimism here presumes that neither Tucker Taft nor anyone else of visionary influence reads comp.lang.ada, which I suspect is entirely false.  Hence, when good ideas are well-formed, they might inspire those on the ISO standardization committee (or at AdaCore & the like) to work on such goals.

Re: Making sense of predicates

[Dmitry A. Kazakov]

On Tue, 22 Oct 2013 10:15:13 -0700 (PDT), Dan'l Miller wrote:

> On Tuesday, October 22, 2013 11:30:30 AM UTC-5, Dmitry A. Kazakov wrote:
>> The goal should be a leaner and more powerful type system with the present
>> type system implemented on top of it at the library level, 100% backward
>> compatible.
> 
> Ahhhh, you seek effectively the C++ vision,

No idea what makes you think so. Anyway C++ is beyond repair because it
conflates class-wide and specific types. Keeping them apart is essential to
the consistency of the types system.

>  What you seek is a better way of layering the compiler and extending the compiler,

I seek a better types system because of problems the current one causes,
like overuse of generics and run-time checks. I, as a programmer, need more
static checks, more reuse, far less debugging.

>> P.S. Putting up such lists is a completely wasted time, as nothing will
>> ever happen, until somebody with the influence of Ichbiah or Taft will nuke
>> the swamp again.
> 
> Your pessimism here presumes that neither Tucker Taft nor anyone else of
> visionary influence reads comp.lang.ada, which I suspect is entirely
> false.

ARG's decisions are not influenced by the noise generated here in c.l.a.

> Hence, when good ideas are well-formed, they might inspire those
> on the ISO standardization committee (or at AdaCore & the like) to work on
> such goals.

Ideas are secondary to a vision of the language as a whole and the
direction it has to evolve. This is vision is absent now.

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

Re: Making sense of predicates

[J-P. Rosen]

Le 22/10/2013 21:26, Dmitry A. Kazakov a écrit :
> ARG's decisions are not influenced by the noise generated here in c.l.a.
There are several of us who are reading c.l.a.

And we had issues that originated from questions here (well, valuable
questions, not noise ;-) )

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Making sense of predicates

[Dan'l Miller]

On Tuesday, October 22, 2013 2:26:28 PM UTC-5, Dmitry A. Kazakov wrote:
> On Tue, 22 Oct 2013 10:15:13 -0700 (PDT), Dan'l Miller wrote:
> > Ahhhh, you seek effectively the C++ vision,
>
> No idea what makes you think so.

And that is unfortunate, because I told you above.  I reiterate:  The A#1 mantra of major sectors of the C++ community (e.g., Boost) is to perform functionality in libraries whenever possible instead of in the core C++ language.  You seek that a substantially-similar goal, but perhaps via a different (unspecified by you, hinted at by me) style of programming than Boost's MTP via Boost.MPL or via Loki.

> >  What you seek is a better way of layering the compiler and extending the compiler,
>
> I seek a better types system because of problems the current one causes,
> like overuse of generics and run-time checks. I, as a programmer, need more
> static checks, more reuse, far less debugging.

Dmitry, please take a hint:  your type goals would be satisfied as a mere library by-product of accomplishing a much much MUCH more difficult goal of taming the beast of layered compilers that accomplish multistage programming, so that you don't travel the wicked C++ MTP path and merely port Boost's MTP-based templates to Ada somehow.  Writing that typing-system library will be the easy part once a language designer solves the layered-compiler problem for a multistage(-or-whatever) extensible compiler.

What is the demonstrable evidence that is the layered extensible compilation technology more difficult than the elegant typing-system building blocks usable to build higher-order type-safe libraries?  Such evidence is in C++ today, which has accomplished portions of the latter (quite contortedly, not backward compatibly), but has entirely failed on the former.  Note that Boost (and the subsequent C++ TRs) have largely provided a "library"-based approach to rich compile-time type-enforced semantics.  But the cost has been deleterious to numerous other valuable aspects of the C++ language, or any programming language for that matter:
1) deep nesting of arcane error messages within error messages within ... within error messages that often don't give even the slightest clue of what is wrong where,
2) excessive compile time,
3) fragility of the library,
4) fragility of app-domain code using the library,
5) fragmentation of the community between different incompatible (or barely not-incompatible) type-forests:  Qt, Boost, TR, homebrew, and so forth.
6) elaborate template-idiom syntax for historically implicit or trivial type semantics, where these template-idioms do not resemble (nor are backwards compatible with) the analogous historical C/C++ language's constructs.

These do not need to be the outcome.  It is merely the cascading ramification of the unwise path that C++ chose.

Re: Making sense of predicates

[Dmitry A. Kazakov]

On Tue, 22 Oct 2013 14:30:15 -0700 (PDT), Dan'l Miller wrote:

> On Tuesday, October 22, 2013 2:26:28 PM UTC-5, Dmitry A. Kazakov wrote:
>> On Tue, 22 Oct 2013 10:15:13 -0700 (PDT), Dan'l Miller wrote:
>>> Ahhhh, you seek effectively the C++ vision,
>>
>> No idea what makes you think so.
> 
> And that is unfortunate, because I told you above.  I reiterate:  The A#1
> mantra of major sectors of the C++ community (e.g., Boost) is to perform
> functionality in libraries whenever possible instead of in the core C++
> language. 

But this is not specific to C++, it is just a good language design
principle, which C++ does not follow anyway.

I merely responded to Randy's moan about the ARM's section about the
accessibility rules. To handle complexity you have to say good-bye to
monolithic design. Specifically regarding the accessibility rules, there is
no chance one could make them sensible. Pointers cannot be made safe.
Period. Investing into safe pointers is wasting time. One should rather do
into means helping the programmer to avoid pointers. Instead of that Ada
introduced access to subprogram, access discriminants, anonymous access
etc. What did you guys expect doing so?

>>>  What you seek is a better way of layering the compiler and extending the compiler,
>>
>> I seek a better types system because of problems the current one causes,
>> like overuse of generics and run-time checks. I, as a programmer, need more
>> static checks, more reuse, far less debugging.
> 
> Dmitry, please take a hint:  your type goals would be satisfied as a mere
> library by-product of accomplishing a much much MUCH more difficult goal
> of taming the beast of layered compilers that accomplish multistage
> programming,

So the point is that the type system is all OK? Or maybe you are with Randy
and others who believe that though it is not OK, but nothing substantial
could be accomplished and it is better to start a new language from
scratch, but we rather won't?

[...]

The reason to have it in a library is backward compatibility.

Now about fragility et al. Consider the subtype Positive. It is a library
thing defined in the standard library:

   subtype Positive is Integer range 1..Integer'Last;

Note that the language does not need Positive because it already has a more
generic mechanism of constrained subtypes which library uses.

Now, try to apply your points about fragility to Positive. Carefully
observe that while applications using Positive are indeed fragile. The
reason for that lies in the Positive itself. It is a target-dependent
[sub]type and thus ill-defined in a wider context of multiple targets. This
fragility is not because there is something wrong with Ada's subtypes!

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