Re: Seeking for papers about tagged types vs access to subprograms

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1bp6zlpetr5l4.12a9zcd1x3yya.dlg@40tude.net...
> On Wed, 8 May 2013 15:12:38 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:p0pf97g5w6xg.jhca6ztjwpde$.dlg@40tude.net...
>
>>> What I wish is to change the language foundation while keeping the
>>> semantics of existing types intact. The whole idea is to move them onto
>>> the library level rather than changing anything in them.
>>
>> That's precisely what I'm talking about. The result cannot be Ada, 
>> because
>> the result is not going to be close to 100% compatible with Ada (and that
>> should not be a criteria for a new language).
>
> I don't see obvious reason why. It is not about reworking exiting built-in
> types and type-algebraic operations. There is nothing wrong with them.
>
>> Despite your fantasies to the
>> contrary, there is no possibility of changing the models in any useful 
>> way
>> and retaining compatibility in subtle cases. Moreover, even if possible, 
>> the
>> pretzel-like rules needed would prevent the sort of overhaul that you 
>> really
>> desire. So why cling to the mistakes of the past - flush all of that down
>> the drain and start over.
>
> Because most of Ada semantics is OK. I don't see any mistakes. Even if 
> they
> were, it is irrelevant because I am looking for a more general model, 
> where
> mistake or not, it becomes just an implementation. So if you don't like a
> particular built-in type for whatever reason, you make your own. No
> problem.

When you say "semantics", you're really only talking about the dynamic 
semantics, that is the runtime model. But the compile-time model is just as 
important. You would have to reproduce every feature and flaw of the 
existing compile-time model with a totally new underlying model. And doing 
that would be very, very complex.

The problem is, when you do that, you'd have no way to determine whether or 
not it is really compatible. (After all, there is no formal model for Ada, 
and there never has been.) Ada's definition is just a mass of English text, 
and replacing it by a different mass of English text leaves one no practical 
way to prove compatibility. And it is very unlikely that there would be any 
interest in an incompatible version of Ada. Moreover, no one would be much 
interested in a version that's *almost* like Ada but would break almost 
everyone's code.

If one starts over, you eliminate that need for absolute compatibility. You 
might still be fairly close to the semantics of Ada (although I don't see 
the point; it should be simplified by removing corner cases and little used 
stuff and features that are duplicative), but there is no need to prove 
compatibility (or convince anyone of it). And you could fix obvious mistakes 
of Ada (objects don't overload, for one example, and the more general 
user-defined indexing that you would like, and so on) without having to 
worry about the effects in private parts of nested packages -- which is what 
prevents most progress today.

                                           Randy.