Re: What would you like in Ada202X?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 29 Apr 2012 15:27:10 -0400, Robert A Duff wrote:

>>> There's no need to prevent clashes.  If you say:
>>> 
>>>     X: constant Integer := 123;
>>>     X: constant Integer := 456;
>>> 
>>> (both in the same scope) then all references to X would be
>>> ambiguous.  So don't do that.
>>
>> I see this approach problematic, because ambiguity may stay undetected
>> until very late, in a context where it cannot be fixed anymore, ...
> 
> Can't happen.  If anybody writes code referring to X, it will
> be illegal.

And if he does not? Library packages declare lots of things they don't use
themselves.

> If you do proper unit testing,
> you'll catch it right away.

Here applies another language design principle: anything that can be
checked statically has to be.
 
> In fact, ARG desperately wants to design nice clean language
> features, and it's extremely frustrating when the requirement
> for compatibility prevents it.  That's why it's so much more
> fun to design a new language.
> 
> Of course, "nice clean" is somewhat a matter of opinion.

Yes, it seems that the trend is towards adding orthogonal features, which I
don't consider either nice or clean. To me "nice clean" is when features
are removed (moved to the library level) replaced by fewer, more general
ones.

>>> but I assure you ARG would be tarred and feathered if we
>>> threw compatibility concerns out the window.  And rightly so.
>>> The Ada 9X team and the ARG already get grumbling about the
>>> fairly modest incompatibilities that were introduced.
>>
>> There are plenty examples when incompatibility was introduced with no gain
>> (e.g. reserving words like "interface"),...
> 
> Don't blame that one on ARG.  ARG proposed to add non-reserved
> keywords several times, which would have been compatible,
> but WG9 (the parent committee of ARG) shot it down every time.

What was wrong with already existed

   abstract tagged null record

?

>>...or causing considerable damage
>> (changed semantics of returned limited objects).
> 
> I've never understood your viewpoint on that.

The semantics was changed, that is.

> You keep talking about "true constructors" or "proper
> constructors" or something, but you didn't outline your
> design in enough detail for me to understand.

I tried, but that is irrelevant.

As for constructors, the point, rather a trivial observation, is that you
cannot initialize raw memory with a subprogram in a sanely typed way. It is
up to you, a language designer, to come up with something else. The working
name for that thing is "constructor." Add here a few quite obvious
requirements on the design: safety upon inheritance, safety upon exceptions
raised in the middle of the process, safety against dispatch on not yet
constructed components, safety when some entities are tasks, prevention of
explicit invocation. Here you are.

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