"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.wwung605ule2fv@cardamome...
Le Fri, 10 May 2013 00:19:14 +0200, Randy Brukardt <randy@rrsoftware.com>
a �crit:
>> Again, no one said anything about them being isolated. Although I do 
>> think
>> that vast majority of types ought to be separate from other types -- the
>> interactions being handled in the operations, not in the types 
>> themselves.
>
>Right, except while you say this, the only static check sub-programs or 
>primitive operations provide, is the one applying on the types of their 
>arguments. So there is nothing handled by operations (at least, so far).
>
>The point is still good enough, as at first sight, seems there are 
>operations which cannot said to be owned by a single type, so that may 
>looks hard to focus on type with this picture. Or else, there is a need 
>for a type representing sub-program signature (something I wanted to reply 
>to Dmitry in another message), the arguments tuple, then optionally the 
>result tuple, and optionally both tuples, say the type of a transition as 
>an example. With this, interactions between types can be represented with 
>types.

One of the reasons I chose "profile" for the name of the thingy that I was 
describing on top of types was that I expected it to include profile 
operations. That's because I figured that a redesign of Ada would have 
first-class subprogram types; (along with subprogram objects); there is no 
good reason to use explicit "access" values for this. (Object access values 
are so different from the subprogram kind that there is virtually no 
commonality, so it's confusing to treat them as the same sort of thing.) And 
of course, any first-class type would need an associated profile.

                                     Randy.