Re: What's it's name again?

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

Robert A Duff wrote:

> Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
>> I see, but there is also a difference. The body of a subroutine is not a
>> part of its declaration, so you can continue compilation of
>> specifications no matter how the body looks like.
> 
> Not if you're trying to inline the code.

In a specification? OK if the function is called to determine a 
constraint for some subtype, should that be made legal...

>>... In contrary to this the size of a type
>> is a function of its declaration. So there might be no difference when
>> some other comilation unit is being compiled, but for a compilation the
>> package's specification I think there is a difference.
> 
> I don't see any difference, in principle.  If the compiler doesn't know
> the size of the type, it has to generate less efficient code.

The question is how big will be the impact. If a function is not inlined it 
is not a disaster. If objects will be allocated in the heap instead of 
stack and all that depending on things looking very innocent to an 
untrained eye?

>> There is a problem that Foo will see no package body, which might contain
>> some implementation-dependent things it needs.
> 
> Everything Foo references must *also* be moved to the spec for this idea
> to work.  That's annoying, but it is not in principle different from the
> fact that everything a private type refers to must be in the spec:

This means that a decision to inline or not should be met very early. 
Presently it is just an option that has no big impact on the design.

>>... I has not much thought about it,
>> but we must ensure absence of any circular dependencies, which could
>> prevent compiler from calculation of the object size.
> 
> Yes.  Ada already has a rule that type T cannot have a [sub]component of
> type T (the programmer has to insert a level of indirection).  This rule
> would have to be removed, because the compiler doesn't always see the
> full type.  This would mean that the *compiler* would be responsible for
> inserting the extra level of indirection.  (This is similar to what
> happens in Java and other "everything's a pointer" sorts of languages --
> in those languages, there is *always* an extra level of indirection.)

In other words, all types completed in the package body are wrapped by 
pointers. Would not it be easier to make sort of transparent pointers?

package ... is
   type X is access all; -- Do not know which target type
   procedure Foo (A : X); -- A primitive operation
   ...
end ...;

package body ... is
   type T is ...;
   type X renames access all T;
   ...
end ...;

Then for a transparent pointer any its use is an equivalent to ".all".

> Another problem is parameter passing mechanisms.  Ada defines it to be
> by-copy for some types, by-reference for some types, and compiler-choice
> for some types.  It would be pretty disgusting (from an efficiency point
> of view) if this choice had to be made at run time. But this is an
> Ada-specific issue.  I don't like the Ada rules here, and we're talking
> about languae design (an Ada-like language that is not Ada), so it's
> fair for me to ignore this issue.

You mean, that wrapped pointers are always by-copy no matter what is the 
target type? That's OK.

> Also, there's the issue of with_clauses.  It would be nice to attach
> with_clauses to the private_part.

Oh, yes.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de