!standard  1(0)                                    18-12-14    AC95-00309/00
!class Amendment 18-12-03
!status received no action 18-12-03
!status received 18-10-10
!subject Better Ada
!summary

!appendix

From: John Barnes
Sent: Wednesday, October 10, 2018  1:59 PM

It might be interesting to ask what did we put in to previous version of Ada
that now seem to have been a waste of time?  Are some of these forms of 
expressions maybe another thing that might be regretted later.

What do we perhaps regret already now?

I don’t think we regret adding anything in particular in to Ada 95.

But, in Ada 2005 the wretched anonymous access types were introduced. A pain 
in the neck. I don’’t think we are convinced that they are correct even now.

And then in Ada 2012, type invariants seem a bit of a waste of time because 
they are not foolproof. I remember the meeting in Edinburgh that discussed 
the  things. Pah humbug.

The language is big already. I assume that I will have to redo my book. It is 
already 950 pages and would be over a thousand if I had put in all the 
answers.

My apologies for grumpy outburst.

***************************************************************

From: Tucker Taft
Sent: Wednesday, October 10, 2018  2:21 PM

I agree it would be interesting to see what could be removed without any great 
loss.  My "ParaSail" language experiment was largely about trying to remove as
much as possible, before adding back in parallel programming and annotations.

Intriguingly, the anonymous access types are emerging as useful for 
implementing the notion of temporarily borrowing an object in the context of 
"owning" access types.  See AI12-0240-1:

    http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0240-1.txt?rev=1.9

This AI probably won't make it into Ada 2020, but the SPARK folks are in the 
process of adding a stripped-down version of it to SPARK, as these kind of 
access types can ensure that there is never more than one "owning" pointer to 
a given object, important for preserving the "very controlled aliasing" needed
for doing practical proofs.

In SPARK, Ada 2012 type-invariants and subtype predicates are fully checked at 
analysis time, even though full run-time checking is not performed.  I think 
that is OK, because when testing, the run-time checks are really there just to
help validate that the annotations and the implementation are consistent -- 
that typically doesn't require a run-time check at all points where the 
invariant might be affected, so long as it is detected soon thereafter.

***************************************************************

From: Arnuad Charlet
Sent: Wednesday, October 10, 2018  2:51 PM

> It might be interesting to ask what did we put in to previous version 
> of Ada that now seem to have been a waste of time?

That's definitely a very relevant question (and we should go back also to 
Ada 93 and perhaps Ada 83 in that respect) for the future since keeping adding
stuff is a real issue. How to handle "compatibility" and potential 
"transition" to a different, simpler(?) language is an interesting question.

> Are some of these forms of
> expressions maybe another thing that might be regretted later.

I don't think so.

From what we've seen from customers, Ada 2005 was not a game changer at all 
and was pretty much skipped by many users as "not interesting enough" 
although anonymous access types allowed to give generally available to all 
Ada users a ready to use C binding generator at reasonable cost, which is 
quite an achievement by itself.

Ada 2012 is really different and a game changer: people who look at it 
definitely see the benefit of these new assertions/contracts and the related 
need for more powerful expressions is a natural (and required) complement.

Perhaps type invariants were a mistake and we should at stayed by subtype 
predicates, although at least that's a sufficiently isolated feature that if
you don't need it by itself, you don't suffer any particular side effect/ 
consequence, and indeed most users can probably live without it.

We also shouldn't ignore what's happening in the world outside Ada and in 
other programming languages, and declare expressions is one of these features
that can be debated in a very "heated" or controversial manner, in particular
by those that don't see the benefit (while others will "get it right away"
and see the "obvious" benefit instantly), and in the end once people have 
started using it, nobody will ask the question ever again (or will rather 
ask "how did we do without it before").

Interestingly, this very feature caused a heated debate in the Python 
community and this (the required level of energy to convince people of the 
usefulness of this feature) is what convinced the Python creator to resign 
from his role.

If you're curious, see e.g. 
https://developers.slashdot.org/story/18/07/12/201231/python-language-founder-steps-down 
for the story, and the related python "AI" which is PEP 572.

> What do we perhaps regret already now?
> 
> I don???t think we regret adding anything in particular in to Ada 95.

I beg to disagree, or rather, I regret for instance the way OO was added in 
Ada 95 (should remind some of you folks some other "interesting" debates :-)). 
I don't want to get started on this topic, but the way "classes" are declared 
and (wrongly) scoped in Ada 95 is a big mistake that we should fix one day 
IMO. That doesn't mean that Ada 95 wasn't overall a huge step forward 
addressing many of the complains about Ada 83.

> And then in Ada 2012, type invariants seem a bit of a waste of time 
> because they are not foolproof. I remember the meeting in Edinburgh 
> that discussed the things. Pah humbug.

Perhaps. Certainly not enough to throw away the Ada 2012 baby with it though.

> The language is big already. I assume that I will have to redo my 
> book. It is already 950 pages and would be over a thousand if I had put in 
> all the answers.

That's fine, nobody prints books anymore :p

***************************************************************

From: Randy Brukardt
Sent: Friday, October 12, 2018  8:36 PM

>It might be interesting to ask what did we put in to previous version 
>of Ada that now seem to have been a waste of time?  Are some of these forms 
>of expressions maybe another thing that might be regretted later.
>
>What do we perhaps regret already now?

I've been thinking about "better Ada" off-and-on for years now. I never seem 
to find time to write a properly blog article about it. I've twice worked out
a list of a dozen or so items mentally, but never get time to write them down.

>I don't think we regret adding anything in particular in to Ada 95.

I regret (now) some of the decisions of Ada 83!

Here's an unsupported list off the top of my head:

(1) Coextensions [the effect can be gotten from managed access types - Editor.]
(2) Anonymous access types (all versions); rather, use aspects to give special 
    capabilities to named access types (dynamic accessibility, closures,
    etc.)
(3) Strings are not arrays!! (That conflates representation and semantics, 
    and leads to the wide-wide nonsense.)
(4) All containers should have the same syntax (meaning dedicated array 
    operations vanish; that's helped by the previous item since things like 
    slices and ordering operators mainly exist for string operations). Means
    that "array" is a container (possibly built-in to a compiler). We have 
    loads of stuff now that work on containers and arrays -- but these really
    are the same thing.
(5) Optional stuff should be required: ids after end, uninitialized objects 
    (":= <>"), "in" mode, probably other things as well.
(6) "constant" should be the default (meaning a "variable" keyword).
(7) Context clause use clause (seems redundant, expensive to implement).
(8) Objects/exceptions should be overloadable (the profile is obvious).
    [Unfortunately, this one breaks the "easy" implementation of quantified 
    expressions/declare expressions/aggregate iterators.]
(9) Untagged type decls should be allowed inside of protected specifications
(10) Simplify "characteristics"; the nested package cases are bizarre.
(11) Do we really need generic in out parameters?
(12) Could nesting be simplified to avoid some of the bizarre cases? (Dunno.)
(13) Allow extensions to exceptions so that data can be passed if necessary.
(14) Figure out some rules so that non-null extensions for most types can be 
     declared in generic specs (needs auto-extension for defaulted components,
     like we do for null extensions).
(15) Untagged derived types? Either get rid of them or make them useful!
     They ought to be something more than a technique for Steve B. to generate 
     unlikely anomalies. Maybe class-wide operations? [Also: Real different 
     representations (even if there are primitive routines)? - Editor.]

Probably enough for now. ;-)

P.S. I'd personally probably include interfaces, but I know that I'm close to 
     a minority of one on that, and they might come in handy for the 
     string/container design. [If they're kept, figuring out how to allow
     Root_Stream_Type and the root controlled types to be interfaces would
     we valuable - Editor.]

[Editor's note: A few more in case anyone reads this in the future, like me
 to write that blog post I've planned forever:
(A) Renames should require static matching; some special case so operators 
    work as expected without 'Base all over.
(B) Constrained scalar objects should always be valid if not abnormal. (Ergo,
    uninitialized such objects usually would raise Constraint_Error; 
    presumably, any attempt to declare one would cause a warning or error.)
    Unconstrained objects, like Integer'Base could be uninitialized.
    Predicates should always be enforced on newly created objects. (See item
    (5)).
(C) Adopt a static elaboration model similar to GNAT's.]

***************************************************************