Re: Augusta: An open source Ada 2012 compiler (someday?)

["Randy Brukardt" <randy@rrsoftware.com>]

<Stefan.Lucks@uni-weimar.de> wrote in message 
news:alpine.DEB.2.10.1403251025030.10474@debian...
>On Mon, 24 Mar 2014, Randy Brukardt wrote:
>
>> "J Kimball" <spam@example.com> wrote in message
>> news:lgopof$unl$1@loke.gir.dk...
>
>>> Ada has become the American tax code. It's becoming abundantly clear
>>> that there has to be a massive break in backward compatibility in the
>>> next revision of the language that makes writing compilers easier, not
>>> just keeping AdaCore in business, but breaking out of the framework of
>>> Ada 95.
>>
>> I'd be in favor of that, but I'm dubious that the customers that support
>> Ada would want to make that sort of change. And if the customers don't
>> come along, then there is little energy for anything to happen. After
>> all, most hobbyest driven projects tend to wane after a couple of years,
>> and that's not going to work for the sorts of long-lived projects that
>> Ada is best at.
>
>What about moving not-so-often used language features into an annex?
>
>Thus, if your customers demand the feature, you are allowed to support it.
>Furthermore, anyone supporting that feature would do so so in a completely
>compatible way.
>
>But if you don't want to support that feature, or you can't for some
>reason, you are allowed to support Ada 20XY without that annex.

This would work, but it wouldn't have any effect on simplifying the Standard 
(since the wording in the Standard would have to be prepared to handle the 
feature -- that's especially likely to be an issue for things like 
interfaces, which have an effect on virtually every definition in the 
Standard). And if one doesn't simplify the Standard, it's fairly unlikely 
that you're actually going to simplify implementation that much.

>As an example, I would consider interfaces. The support for multiple
>inheritance from "interface" could could be moved into an annex, and thus
>become optional for the language implementer. The key-word "interface"
>should remain reserved, for compatibility reasons.

Right.

But as always, the difficulty would be agreeing on what goes into such an 
index. I'd vote for interfaces and anonymous access types, but I'm sure the 
fans of those features would not be very happy. And they probably have some 
features that I find important that they think ought to be in the junk bin.

You'd be amazed at how hard it is to even move a feature into Annex J 
(Obsolescent Features), even those are required to be implemented. I'm still 
hearing flack about the decision to move aspect pragmas there, even though 
entity-specific pragmas was one of worst ideas ever known to mankind. :-)

                                    Randy.