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

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

On Mon, 06 May 2013 17:15:36 +0200, Yannick Duchêne (Hibou57) wrote:

> Le Mon, 06 May 2013 16:16:02 +0200, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:
>>> Theoretically. In practice, GNAT don't agree (*). It has a pragma for
>>> that, `pragma Restrictions (No_Dispatching_Calls)` which should even
>>> enforce it in a whole application, but seems even with this active, it
>>> still requires the whole part of the runtime dedicated to it, a part  
>>> which depends on this part,
>>
>> I suppose it would be difficult to implement this so that the code used to
>> maintain dispatching tables and tags could be removed. It may require two
>> versions of the compiler. Furthermore there are packages defining
>> operations on tags which could require some of the stuff.
>>
>> Why do you bother? Especially, because dispatching calls are deterministic
>> and could be done time bounded, unless you manipulate tags. (Not everything
>> in people write in their guidelines for RT projects makes sense.)
> 
> That's not real‑time, that's just saving dependencies (have to be static)  
> and memory (static linking easily make it big) and to be sure to know  
> what's running beneath (no implicit heap allocation, no secondary stack,  
> bounded stack, no output to standard I/O streams except if the program do  
> it explicitly, and so on).

I don't see how dispatching calls could be relevant to these constraints
which apply to both dispatching and specific calls. Dispatching call is a
bogeyman under the bed.

> Initially I just wanted to get ride of function  
> returning unconstrained types and the exceptions runtime (I don't like  
> exceptions used to return the status of an operation anyway) and keep only  
> the last‑chance handler, but it appears the high level parts of the  
> runtime depends on the exceptions support (ex. direct or indirect  
> dependencies to Ada.Exceptions and al.).

Instead of banishing exceptions one should put contracts on them.

>>> However and in the large, I
>>> agree with you and share the same understanding of the topic, at least
>>> theoretically.
>>
>> There are far reaching consequences of having classes for all types.
> 
> Interfaces for all types :-D

Yes, this is more or less same as having classes.
 
>> What is in the interface cannot be decided before you have
>> interfaces properly articulated. Thus type system overhaul is the first
>> step to make.
> 
> Saying “overhaul”, you will always get this reply: “no way, don't break  
> compatibility” (something which in the meanwhile is easily understood).

Usual hand waving used by people who don't want to discuss it seriously.
And they do not.

> May be there would be a hope to do something similar to what SPARK did,  
> just with bigger consequences, re‑factoring Ada outside of Ada (which is  
> unavoidable to go ahead without fears to break compatibility).

I thought about it, but this is far larger than one-man project and there
is too much things which nobody did before and nobody knows how to do.
Before doing this one should clearly understand it, and before
understanding it there should be a serious discussion about it. And before
that starts there should be a desire in the community to fix the language,
which is clearly absent. Ada 2012 became a patchwork under which one can
barely see its original ideas.

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