Ada202X: Easy to use "UML private"-like components

Ada202X: Easy to use "UML private"-like components

[Martin]

I occasionally have the need to explain to people that Ada can support UML public, protected, private class data member scoping but to say it's confusing and clunky would be putting it mildly...

Firstly, I have to public - that's easy:

package CLA is
   type UML_Public is tagged record
      I : Integer; -- public to all, UML "public"
      F : Float;
   end record;
end CLA;


Secondly, I have to explain that using Ada "private" gives you "UML protected":

package CLA is
   type UML_Protected is tagged private;
private
   type UML_Protected is tagged record
      I : Integer; -- private to everyone excepted derived, UML "protected"
      F : Float;
   end record;
end CLA;

Finally, I have to explain that to get "UML private", you need to use an "opaque type" and and "access type":

package CLA is
   type UML_Private is tagged private;
private
   type Opaque;
   type UML_Private is tagged record
      I : Integer; -- private to everyone excepted derived, UML "protected"
      O : access Opaque;  -- has to be access, as compiler doesn't
                          -- know what Opaque is!
   end record;
end CLA;

package body CLA is
   type Opaque is record
      I : Integer; -- private to everyone, UML "private"
      F : Float;
   end record;
end CLA;




By now, the other person is usually rolling their eyes in disbelief and I'm nearly joining them...



There's nothing we can do about Ada "private" v UML "protected" but I think there is a relatively small addition that could be made to the language that would at least avoid the embarrassment of the third part.



My proposal would be to allow an optional "private component list" to record definitions, e.g.

package CLA is
   type UML_Private is tagged private;
private
   type UML_Private is tagged record
      I : Integer; -- private to everyone excepted derived, UML "protected"
   private
      F : Float; -- private to everyone - even derived, UML "private"
   end record;
end CLA;


Where a record had nothing but private components, it could either use:

Option 1:
   type T is tagged record
   private
      F : Float;
   end record;

or

Option 2:
   type T is tagged record
      null;
   private
      F : Float;
   end record;


I prefer Option 2.

Thoughts?

-- Martin

Re: Ada202X: Easy to use "UML private"-like components

[Dmitry A. Kazakov]

On Fri, 21 Jun 2013 01:43:05 -0700 (PDT), Martin wrote:

> Secondly, I have to explain that using Ada "private" gives you "UML protected":

Ada's private gives both protected for children of the package and private
for non-children.

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

Re: Ada202X: Easy to use "UML private"-like components

[Martin]

On Friday, June 21, 2013 10:23:51 AM UTC+1, Dmitry A. Kazakov wrote:
> On Fri, 21 Jun 2013 01:43:05 -0700 (PDT), Martin wrote: > Secondly, I have to explain that using Ada "private" gives you "UML protected": Ada's private gives both protected for children of the package and private for non-children. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de

But no easy means of keeping member data private from children.

-- Martin

Re: Ada202X: Easy to use "UML private"-like components

[G.B.]

On 21.06.13 11:33, Martin wrote:
> On Friday, June 21, 2013 10:23:51 AM UTC+1, Dmitry A. Kazakov wrote:
>> On Fri, 21 Jun 2013 01:43:05 -0700 (PDT), Martin wrote: > Secondly, I have to explain that using Ada "private" gives you "UML protected": Ada's private gives both protected for children of the package and private for non-children. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
>
> But no easy means of keeping member data private from children.

But no pointers needed; I hope the following example
is a reasonably accurate paraphrase of a hint given
by Tucker Taft some years ago, memory is vague. Not
sure if UML has a concept for capturing this, but confident
that Grady Booch knows Ada's visibility rules well.
(Or should one find a sentence that has "possibilities"
instead of "rules"?)

package Opaque is

    type Exposed is tagged private;

private

    package Invisible is
       type T is tagged private;
    private
       type Scalr is range 1 .. 2;
       type T is tagged record
          Comp_1 : Scalr;
       end record;
    end Invisible;

    type Exposed is new Invisible.T with null record;
end Opaque;

private package Opaque.Child
is
    A : Invisible.T;
    Y : Invisible.Scalr := A.Comp_1;
end Opaque.Child;


Compiling: opaque-child.ads (source file time stamp: 2013-06-21 10:06:44)

      4.    Y : Invisible.Scalr := A.Comp_1;
                         1          2
         >>> "Scalr" is not a visible entity of "Invisible"
         >>> no selector "Comp_1" for private type "T" defined at 
opaque.ads:8

  5 lines: 2 errors

Thus, even a private child cannot see anything behind
doubled fences. I imagine that explaining this needs
some spin doctoring.

Re: Ada202X: Easy to use "UML private"-like components

[Martin]

On Friday, June 21, 2013 11:14:12 AM UTC+1, G.B. wrote:
> On 21.06.13 11:33, Martin wrote: > On Friday, June 21, 2013 10:23:51 AM UTC+1, Dmitry A. Kazakov wrote: >> On Fri, 21 Jun 2013 01:43:05 -0700 (PDT), Martin wrote: > Secondly, I have to explain that using Ada "private" gives you "UML protected": Ada's private gives both protected for children of the package and private for non-children. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de > > But no easy means of keeping member data private from children. But no pointers needed; I hope the following example is a reasonably accurate paraphrase of a hint given by Tucker Taft some years ago, memory is vague. Not sure if UML has a concept for capturing this, but confident that Grady Booch knows Ada's visibility rules well. (Or should one find a sentence that has "possibilities" instead of "rules"?) package Opaque is type Exposed is tagged private; private package Invisible is type T is tagged private; private type Scalr is range 1 .. 2; type T is tagged record Comp_1 : Scalr; end record; end Invisible; type Exposed is new Invisible.T with null record; end Opaque; private package Opaque.Child is A : Invisible.T; Y : Invisible.Scalr := A.Comp_1; end Opaque.Child; Compiling: opaque-child.ads (source file time stamp: 2013-06-21 10:06:44) 4. Y : Invisible.Scalr := A.Comp_1; 1 2 >>> "Scalr" is not a visible entity of "Invisible" >>> no selector "Comp_1" for private type "T" defined at opaque.ads:8 5 lines: 2 errors Thus, even a private child cannot see anything behind doubled fences. I imagine that explaining this needs some spin doctoring.



Yeah, ok...hadn't thought of that way...

But really, it's still a bit embaressing and it's almost as bad as the access type solution...almost...

-- Martin

Re: Ada202X: Easy to use "UML private"-like components

[Dmitry A. Kazakov]

On Fri, 21 Jun 2013 02:33:11 -0700 (PDT), Martin wrote:

> But no easy means of keeping member data private from children.

On the contrary, don't make them children.

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

Re: Ada202X: Easy to use "UML private"-like components

[Robert A Duff]

Martin <martin@thedowies.com> writes:

> Secondly, I have to explain that using Ada "private" gives you "UML protected":

Not exactly.  Ada "private" means clients can't see it, but child
packages (which should be thought of as part of the same abstraction)
can.

It's a completely different visibility model than UML.  I don't see any
reason to be embarrassed about that.

> Option 2:
>    type T is tagged record
>       null;
>    private
>       F : Float;
>    end record;
>
>
> I prefer Option 2.
>
> Thoughts?

I don't think making Ada more like UML is a worthwhile goal.  If it
were, I'd prefer your option 1.  But I don't see the point:  In Ada,
packages are about visibility.  That's different from languages that
conflate the concept of "module" and "type" (which has both advantages
and disadvantages).  Overall, I prefer the Ada way.

If you want derived types to see their parent types components, you put
the derived types in a child package; if you don't, then you don't.
Attempts to mimic UML in Ada lead to a mess, as you've shown.

I share your disdain for what you called "opaque" types -- it forces you
into heap management, which leads to extra trouble.  But I object to
calling them "opaque" types.  Ada folks usually call them "stt access
types" and "stt incomplete types", or "Taft amendment types", because
they were invented by Tucker Taft and added to Ada 83 at the last minute
when nobody realized all the headaches they cause for compiler writers.
The term "opaque type" comes from Modula-2, IIRC, and is more like
an Ada private type, with some annoying restrictions added.

- Bob

Re: Ada202X: Easy to use "UML private"-like components

[Martin]

On Friday, June 21, 2013 3:51:32 PM UTC+1, Dmitry A. Kazakov wrote:
> On Fri, 21 Jun 2013 02:33:11 -0700 (PDT), Martin wrote:
> 
> 
> 
> > But no easy means of keeping member data private from children.
> 
> 
> 
> On the contrary, don't make them children.


But then I loose visibility of the classes protected operations...

-- Martin

Re: Ada202X: Easy to use "UML private"-like components

[Dmitry A. Kazakov]

On Sat, 22 Jun 2013 04:16:55 -0700 (PDT), Martin wrote:

> On Friday, June 21, 2013 3:51:32 PM UTC+1, Dmitry A. Kazakov wrote:
>> On Fri, 21 Jun 2013 02:33:11 -0700 (PDT), Martin wrote:
>> 
>>> But no easy means of keeping member data private from children.
>> 
>> On the contrary, don't make them children.
> 
> But then I loose visibility of the classes protected operations...

No operation can be both protected and private, not even in UML...

The point is that Ada offers the same choice as UML does. However the roles
are different. UML follows C++ where it is the provider of the type who
must choose between public/protected/private. In Ada its public vs. not
public for this role. Protected vs. public is to be decided by the user,
i.e. much later.

It is a good approach IMO, because protected vs. private choice is
frequently far to premature for the provider. A too heavy burden to do, as
usage of C++ shows. In the end the most sound policy for C++ is to avoid
private operations except for the cases when Ada programmer would a
subprogram into the package body.

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

Re: Ada202X: Easy to use "UML private"-like components

[Niklas Holsti]

On 13-06-21 21:36 , Robert A Duff wrote:

> I share your disdain for what you called "opaque" types -- it forces you
> into heap management, which leads to extra trouble.  But I object to
> calling them "opaque" types.  Ada folks usually call them "stt access
> types" and "stt incomplete types", or "Taft amendment types", because
> they were invented by Tucker Taft and added to Ada 83 at the last minute
> when nobody realized all the headaches they cause for compiler writers.
> The term "opaque type" comes from Modula-2, IIRC, and is more like
> an Ada private type, with some annoying restrictions added.

According to the Modula-2 Reference at
http://www.modula2.org/reference/modules.php, when a Modula-2 definition
module declares an opaque type,

"The corresponding implementation module must contain a full type
declaration for any opaque types declared in the definition module.  The
full type declaration must define a pointer type."

I take this to mean that a Modula-2 opaque type uses indirection through
a pointer type, just as the "stt access types" in Ada, and unlike Ada
private types in general.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Ada202X: Easy to use "UML private"-like components

[Dennis Lee Bieber]

On Sat, 22 Jun 2013 19:41:00 +0300, Niklas Holsti
<niklas.holsti@tidorum.invalid> declaimed the following:

>
>"The corresponding implementation module must contain a full type
>declaration for any opaque types declared in the definition module.  The
>full type declaration must define a pointer type."
>
>I take this to mean that a Modula-2 opaque type uses indirection through
>a pointer type, just as the "stt access types" in Ada, and unlike Ada
>private types in general.

	I suspect that limitation comes about as lacking any knowledge of a
structure, only the type name, the compiler doing the import has to make
assumptions about the storage space of the type -- only a pointer would
have a common, preknown, storage size for all imported opaque types.

	From "Programming in Modula-2: 3rd, corrected edition" [N. Wirth; 1985
Springer-Verlag], page 169:

"""
Definition modules imply the use of qualified export. Type definitions may
consist of the full specification of the type (in this case its export is
said to be transparent), or they may consist of the type identifier only.
In this case the full specification must appear in the corresponding
implementation module, and its export is said to be /opaque/. The type is
known in the importing client modules by its name only, and all its
properties are hidden. Therefore,  procedures operating on operands of this
type, and in particular operating on its components, must be defined in the
same implementation module which hides the type's properties. Opaque export
is restricted to pointers. Assignment and test for equality are applicable
to all opaque types.
"""

	Ada puts the details of the "hidden" part into the specification, where
the compiler is capable of determining required space and generating
instructions to copy (assign) or otherwise manipulate the structure -- even
while preventing the programmer importing the specification from taking
advantage of that knowledge.

	The use of a Modula-2 opaque export doesn't see it as a pointer -- it
just a variable of the named type; the implementation module is where it is
defined a pointer to some structure. Note that a strict reading of PiM-2 is
not defining an "opaque type" but rather an "opaque export" <G>.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Ada202X: Easy to use "UML private"-like components

[Niklas Holsti]

On 13-06-22 22:05 , Dennis Lee Bieber wrote:
> On Sat, 22 Jun 2013 19:41:00 +0300, Niklas Holsti
> <niklas.holsti@tidorum.invalid> declaimed the following:
> 
>>
>> "The corresponding implementation module must contain a full type
>> declaration for any opaque types declared in the definition module.  The
>> full type declaration must define a pointer type."
>>
>> I take this to mean that a Modula-2 opaque type uses indirection through
>> a pointer type, just as the "stt access types" in Ada, and unlike Ada
>> private types in general.
> 
> 	I suspect that limitation comes about as lacking any knowledge of a
> structure, only the type name, the compiler doing the import has to make
> assumptions about the storage space of the type -- only a pointer would
> have a common, preknown, storage size for all imported opaque types.

Of course. The same consideration applies to the Ada "stt access type".

> 	Ada puts the details of the "hidden" part into the specification, where
> the compiler is capable of determining required space and generating
> instructions to copy (assign) or otherwise manipulate the structure -- even
> while preventing the programmer importing the specification from taking
> advantage of that knowledge.

For private types, yes; for "stt access types", the details of the
accessed type are deferred to the package body, as for Modula-2 opaque
types/exports.

> 	The use of a Modula-2 opaque export doesn't see it as a pointer -- it
> just a variable of the named type;

Just as for an Ada private type which (in the private part of the spec)
is completed as an "stt access type". I think this is the usual way in
which "stt access types" are used in Ada: their "access" nature is not
made public.

> the implementation module is where it is
> defined a pointer to some structure.

But, since Modula-2 allows only pointer types to be opaque, the Modula-2
compiler knows that the type is a pointer even when compiling the
definition module and before compiling the implementation module. Just
as for Ada "stt access types".

Maybe my post was unclear: I tried to contradict Bob Duff's recollection
that an opaque type in Modula-2 is more like an Ada private type than
like an "stt access type". I think that a Modula-2 opaque type is very
similar to an "stt access type". Do you agree with me?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Ada202X: Easy to use "UML private"-like components

[Dennis Lee Bieber]

On Sun, 23 Jun 2013 01:57:17 +0300, Niklas Holsti
<niklas.holsti@tidorum.invalid> declaimed the following:

>
>Maybe my post was unclear: I tried to contradict Bob Duff's recollection
>that an opaque type in Modula-2 is more like an Ada private type than
>like an "stt access type". I think that a Modula-2 opaque type is very
>similar to an "stt access type". Do you agree with me?

	Having just refetched a few days of the thread to find out what "stt
access type" means, I can not comment on your assertion.

	My first exposure with Ada, proper, was in January of 1981 when
Lockheed sent a cadre to a class -- a point in time when the NYU Ada/Ed
Translator was the only thing almost available, and just three weeks after
Mil-Std 1815 was announced (I'd had earlier exposure to the SIGPlan Notices
publication of the proposed Ada Language RM and Rationale, and a thin blue
book introducing the language). Only to end up in an assignment that used
FORTRAN-77... My next chance at Ada was 15 years later, when I encountered
AdaGIDE and GNAT. So any contentious features in Ada-83 passed me by
totally. It was nearly another 10 years before I actually got to use Ada at
work (and that required getting laid-off, rehired for some VC++ [on a W98
laptop!], and a few bouts of Python while trying to avoid another lay-off).

	So whatever these "stt access types" are, they are not something I've
encountered in my use of Python -- they sound a lot like a programming
convention for subverting what the compiler was designed to handle.
Modula-2's opaque exports, OTOH, are the compiler's requirement for
handling data abstraction -- not something a programmer just uses in lieu
of some other paradigm.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Ada202X: Easy to use "UML private"-like components

[Niklas Holsti]

On 13-06-23 06:26 , Dennis Lee Bieber wrote:
> On Sun, 23 Jun 2013 01:57:17 +0300, Niklas Holsti
> <niklas.holsti@tidorum.invalid> declaimed the following:
> 
>>
>> Maybe my post was unclear: I tried to contradict Bob Duff's recollection
>> that an opaque type in Modula-2 is more like an Ada private type than
>> like an "stt access type". I think that a Modula-2 opaque type is very
>> similar to an "stt access type". Do you agree with me?
> 
> 	Having just refetched a few days of the thread to find out what "stt
> access type" means, I can not comment on your assertion.

The term was also unfamiliar to me, before Bob Duff's post. To make it
clear, I think ( :-) ) we are discussing a structure of this form:

   package Pkg is
      type T is private;
      ... operations on T ...
   private
      type Object; -- Will be completed in the body of Pkg.
      type T is access Object;
   end Pkg;

Here Pkg.T is the type used by the clients, and is the "stt access
type", because it is an access to an incompletely declared type,
Pkg.Object. The type Pkg.Object is completed in the package body:

   package body Pkg is
      type Object is ... whatever ...
      ... operation bodies ...
   end Pkg;

Pkg.T corresponds to a Modula-2 opaque type (or opaque eport, if you
prefer). Both the Ada compiler and the Modula-2 compiler know, based on
the package declaration or the definition module, that Pkg.T is a
pointer. Neither compiler knows anything about the type of the object to
which Pkg.T points, until the package body or implementation module is
compiled.

As far as I can see, the main difference between Ada and Modula-2 is
that the Ada package declaration has to name the underlying type
(Pkg.Object), because it has to declare Pkg.T as "access Object". That
is not necessary in the Modula-2 definition module, because the opaque
type declaration in Modula-2 implies that the type is a pointer. (As I
understand it, Modula-2 has no other concept of "private type".)

> 	So whatever these "stt access types" are, they are not something I've
> encountered in my use of Python -- they sound a lot like a programming
> convention for subverting what the compiler was designed to handle.

They provide further separation of the declaration and implementation o
the type, just as the Modula-2 opaque types do, and with the same
drawbacks (see below).

> Modula-2's opaque exports, OTOH, are the compiler's requirement for
> handling data abstraction -- not something a programmer just uses in lieu
> of some other paradigm.

Because Modula-2 has no other way to privatize types.

In Ada, the "private type" feature lets you hide the structure of a type
from clients, yet reveal it fully in the package declaration, for the
compiler's benefit. You can then decide whether or not to use an access
type, i.e. an "stt access type" such as Pkg.T above. If you use an
access type, you can defer the full declaration of the underlying type
(and the necessary "with" clauses) to the package body, but this usually
requires heap allocation of the objects.

I tend to use "stt access types" when the type in question (e.g. Pkg.T)
needs reference semantics and heap allocation anyway. (Being rather
conservative in my programming style, I haven't yet leapt fully into
controlled types.)

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Ada202X: Easy to use "UML private"-like components

[Robert A Duff]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> Maybe my post was unclear: I tried to contradict Bob Duff's recollection
> that an opaque type in Modula-2 is more like an Ada private type than
> like an "stt access type". I think that a Modula-2 opaque type is very
> similar to an "stt access type". Do you agree with me?

Yes, given your quotes from Wirth, I agree that Modula-2 opaque types
are much like stt access types.  I had remembered the restriction
differently:  the type was required to fit in the size of a pointer,
which included integers and enums and small records.  Probably the
Modula-2 compiler I used had a nonstandard extension -- or else I am
misremembering.

- Bob

Re: Ada202X: Easy to use "UML private"-like components

[Robert A Duff]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> Pkg.T corresponds to a Modula-2 opaque type (or opaque eport, if you
> prefer). Both the Ada compiler and the Modula-2 compiler know, based on
> the package declaration or the definition module, that Pkg.T is a
> pointer. Neither compiler knows anything about the type of the object to
> which Pkg.T points, until the package body or implementation module is
> compiled.

The compilation model is that when compiling something, the compiler
looks at information coming from the specs of imported things, but not
their bodies.  Modula-2 compilers actually work that way, and this
is the reason for the must-be-pointer (or must be the same size as
a pointer, or smaller, as I had (mis?)remembered it).

It is also the reason for the private part kludge: the compiler sees
the size of the full type for a private type (assuming it is known
at compile time).  But this reasoning makes no sense to me, because
that's not how Ada compilers work.  Any reasonable implementation
of generics and inlining needs to look at bodies.  So full types
should be in bodies, and compilers should look there (at least
in optimizing mode) to find out their size.

On the other hand, the private part kludge wouldn't be so bad if
the syntax were different:  The private part should be a separate
syntactic compilation_unit, with its own with clauses, and should
normally be stored in a separate source file from the visible part.
There's an awful lot of horrible code duplication caused by the
fact that the private part is in the same file as the visible part.
Separating it out into a different file would not prevent the
compiler from looking at it!

- Bob

Re: Ada202X: Easy to use "UML private"-like components

[Dmitry A. Kazakov]

On Sun, 23 Jun 2013 09:12:53 -0400, Robert A Duff wrote:

> It is also the reason for the private part kludge: the compiler sees
> the size of the full type for a private type (assuming it is known
> at compile time).  But this reasoning makes no sense to me, because
> that's not how Ada compilers work.  Any reasonable implementation
> of generics and inlining needs to look at bodies.  So full types
> should be in bodies, and compilers should look there (at least
> in optimizing mode) to find out their size.

... or there should be no generics.

The kludge here rather is generics and inlining, both basically are macro
expansions.

To have public and private parts of the specifications makes much sense to
me, as well as to have bodies which are not allowed for looking into (e.g.
for shared libraries, remote objects etc).

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

Re: Ada202X: Easy to use "UML private"-like components

[Shark8]

On Sunday, June 23, 2013 7:12:53 AM UTC-6, Robert A Duff wrote:
> 
> 
> On the other hand, the private part kludge wouldn't be so bad if
> the syntax were different:

Perhaps something like this?

Package Example is
   Type Opaque is private;
private
   Type Opaque is separate COMPLETE_NAME;
   -- This flags to the compiler that the full type appears in the
   -- package body (as COMPLETE_NAME) and the public 'Opaque' is
   -- actually a pointer/reference/(not null access) to COMPLETE_NAME,
   -- also any primitive ops for Opaque are transitively private ops 
   -- of COMPLETE_NAME.
end;


>  The private part should be a separate
> syntactic compilation_unit, with its own with clauses, and should
> normally be stored in a separate source file from the visible part.

I don't know. Certainly for consistency's sake yes, but getting compiler writers to implement that as well might have been a death-knell for Ada 83.
Moreover, we would need some way to flag there isn't a PRIVATE area, like PRIVATE IS NULL; (Or conversely have the private section optionally in the spec, as it is now, but with PRIVATE IS SEPARATE as the trigger for an external private section.)


> There's an awful lot of horrible code duplication caused by the
> fact that the private part is in the same file as the visible part.

I'm not sure about that. Consider this:
Type K;

Type J is record
 Item : K; -- might need to be access K.
end record;

Type K is new Integer Range 0..100;

Sure "Type K" appears twice, but that's required so that we have some name for the type of J.Item. The items (full declarations) in the PRIVATE section are likewise.

Re: Ada202X: Easy to use "UML private"-like components

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> ... or there should be no generics.
>
> The kludge here rather is generics and inlining, both basically are macro
> expansions.

Semantics defined by macro-expansion is confusing, and should be
avoided.  I'd prefer to have generic types rather than generic
packages, and don't use macro-expansion semantics.  Eiffel shows
one way to do this.

Inlining, on the other hand, has no semantics.  Or should have none.
And it can be turned off when you want faster recompiles but slower
run time.  And inlining is inherently a macro expansion.

> To have public and private parts of the specifications makes much sense to
> me, as well as to have bodies which are not allowed for looking into (e.g.
> for shared libraries, remote objects etc).

Well, yeah, you can't very well inline across shared libraries, but I
don't see any need for that to be part of the language syntax.

- Bob

Re: Ada202X: Easy to use "UML private"-like components

[Robert A Duff]

Shark8 <onewingedshark@gmail.com> writes:

> On Sunday, June 23, 2013 7:12:53 AM UTC-6, Robert A Duff wrote:
>> 
>> 
>> On the other hand, the private part kludge wouldn't be so bad if
>> the syntax were different:
>
> Perhaps something like this?

No, that's not at all what I meant.  I meant that a package would
come in three parts:

    package P is
        ...
    end P;

    package private P is -- Just making up syntax here.
        ...
    end P;

    package body P is
        ...
    end P;

Normally stored in 3 separate source files.  There would be no
private part syntax like we currently have.

I'm not suggesting this is the best idea -- I'm just suggesting
that it would fit in with the compilation model the Ada 83 designers
had in mind.  I would ditch that model, thus making the above
suggestion irrelevant.

> Package Example is
>    Type Opaque is private;
> private
>    Type Opaque is separate COMPLETE_NAME;
>    -- This flags to the compiler that the full type appears in the
>    -- package body (as COMPLETE_NAME) and the public 'Opaque' is
>    -- actually a pointer/reference/(not null access) to COMPLETE_NAME,
>    -- also any primitive ops for Opaque are transitively private ops 
>    -- of COMPLETE_NAME.
> end;

No, it's a bad idea to force the explicit use of pointer/heap when it's
not logically necessary.  C does that a lot.  Ada less, but it could
be even less.

>>  The private part should be a separate
>> syntactic compilation_unit, with its own with clauses, and should
>> normally be stored in a separate source file from the visible part.
>
> I don't know. Certainly for consistency's sake yes, but getting
> compiler writers to implement that as well might have been a
> death-knell for Ada 83.

My suggestion is trivial to implement.  And it wouldn't be "as well",
it would be "instead of".

>...Moreover, we would need some way to flag
> there isn't a PRIVATE area, like PRIVATE IS NULL; (Or conversely have
> the private section optionally in the spec, as it is now, but with
> PRIVATE IS SEPARATE as the trigger for an external private section.)

No, my suggestion is that there is NEVER a "private area", so there's
no need to indicate that there is none.

I'm not suggesting this as a change to Ada -- I'm suggesting that
it would have been a better way to design Ada 83.

>> There's an awful lot of horrible code duplication caused by the
>> fact that the private part is in the same file as the visible part.
>
> I'm not sure about that. Consider this:
> Type K;
>
> Type J is record
>  Item : K; -- might need to be access K.
> end record;
>
> Type K is new Integer Range 0..100;
>
> Sure "Type K" appears twice, but that's required so that we have some
> name for the type of J.Item. The items (full declarations) in the
> PRIVATE section are likewise.

Sorry, I wasn't clear.

That's not the duplication I'm talking about.  I'm talking about the
case where you have an abstraction with multiple implementations.
This happens often in the GNAT runtimes, for example.  Since the
private part is part of the implementation, you need multiple copies
of it for different platforms/environments.  Given Ada as it is,
that forces you to make multiple copies of the visible part,
which is a violation of the DRY principle.

- Bob

Re: Ada202X: Easy to use "UML private"-like components

[Bill Findlay]

On 23/06/2013 16:28, in article wccppvc26ef.fsf@shell01.TheWorld.com,
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
> No, that's not at all what I meant.  I meant that a package would
> come in three parts:
> 
>     package P is
>         ...
>     end P;
> 
>     package private P is -- Just making up syntax here.
>         ...
>     end P;
> 
>     package body P is
>         ...
>     end P;
> 
> Normally stored in 3 separate source files.  There would be no
> private part syntax like we currently have.
> 
> I'm not suggesting this is the best idea -- I'm just suggesting
> that it would fit in with the compilation model the Ada 83 designers
> had in mind.  I would ditch that model, thus making the above
> suggestion irrelevant.

That is exactly what Ichbiah's previous language, LIS, had:
IIRC interface, representation, and implementation parts as separate
compilation units.

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Ada202X: Easy to use "UML private"-like components

[Dmitry A. Kazakov]

On Sun, 23 Jun 2013 11:15:15 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> ... or there should be no generics.
>>
>> The kludge here rather is generics and inlining, both basically are macro
>> expansions.
> 
> Semantics defined by macro-expansion is confusing, and should be
> avoided.  I'd prefer to have generic types rather than generic
> packages, and don't use macro-expansion semantics.

Still macro expansion it is (if meant as textual substitution).

It is no matter how you reinterpret the expanded text: as a package, as a
type, as a statement, identifier, declaration etc. Generic types would be
no better than generic packages.

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

Re: Ada202X: Easy to use "UML private"-like components

[Robert A Duff]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sun, 23 Jun 2013 11:15:15 -0400, Robert A Duff wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> ... or there should be no generics.
>>>
>>> The kludge here rather is generics and inlining, both basically are macro
>>> expansions.
>> 
>> Semantics defined by macro-expansion is confusing, and should be
>> avoided.  I'd prefer to have generic types rather than generic
>> packages, and don't use macro-expansion semantics.
>
> Still macro expansion it is (if meant as textual substitution).

No, as I said above, "don't use macro-expansion semantics"!
One can have "Sequence of Integer" and "Sequence of Whatever"
without any macro-expansion/textual-substitution semantics.
And with full type safety (can't pluck a Mumble out of a
"Sequence of Integer").

> It is no matter how you reinterpret the expanded text: as a package, as a
> type, as a statement, identifier, declaration etc. Generic types would be
> no better than generic packages.

There should be no "expanded text" in my view.  Maybe that's what
you mean when you say "no generics", but then you should say
"no Ada-style generics" (or C++-style templates).

- Bob

Re: Ada202X: Easy to use "UML private"-like components

[Robert A Duff]

Bill Findlay <yaldnif.w@blueyonder.co.uk> writes:

> That is exactly what Ichbiah's previous language, LIS, had:
> IIRC interface, representation, and implementation parts as separate
> compilation units.

Interesting.  I think maybe I've given my rant before, and maybe you
have replied with the above information before, but I've forgotten
it.  I don't know LIS at all, and I'm too lazy to google it right
now -- maybe one of these days.

But why, oh why, then, didn't Icbiah include that obvious idea in
Ada 83?!

- Bob

Re: Ada202X: Easy to use "UML private"-like components

[Bill Findlay]

On 24/06/2013 00:43, in article wccmwqgmlzg.fsf@shell01.TheWorld.com,
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:

> Bill Findlay <yaldnif.w@blueyonder.co.uk> writes:
> 
>> That is exactly what Ichbiah's previous language, LIS, had:
>> IIRC interface, representation, and implementation parts as separate
>> compilation units.
> 
> Interesting.  I think maybe I've given my rant before, and maybe you
> have replied with the above information before, but I've forgotten
> it.  I don't know LIS at all, and I'm too lazy to google it right
> now -- maybe one of these days.
> 
> But why, oh why, then, didn't Icbiah include that obvious idea in
> Ada 83?!

50% increase in compilation overheads?

-- 
Bill Findlay
with blueyonder.co.uk;
use  surname & forename;

Re: Ada202X: Easy to use "UML private"-like components

[Dmitry A. Kazakov]

On Sun, 23 Jun 2013 19:38:47 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sun, 23 Jun 2013 11:15:15 -0400, Robert A Duff wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>> ... or there should be no generics.
>>>>
>>>> The kludge here rather is generics and inlining, both basically are macro
>>>> expansions.
>>> 
>>> Semantics defined by macro-expansion is confusing, and should be
>>> avoided.  I'd prefer to have generic types rather than generic
>>> packages, and don't use macro-expansion semantics.
>>
>> Still macro expansion it is (if meant as textual substitution).
> 
> No, as I said above, "don't use macro-expansion semantics"!
> One can have "Sequence of Integer" and "Sequence of Whatever"
> without any macro-expansion/textual-substitution semantics.
> And with full type safety (can't pluck a Mumble out of a
> "Sequence of Integer").
> 
>> It is no matter how you reinterpret the expanded text: as a package, as a
>> type, as a statement, identifier, declaration etc. Generic types would be
>> no better than generic packages.
> 
> There should be no "expanded text" in my view.  Maybe that's what
> you mean when you say "no generics", but then you should say
> "no Ada-style generics" (or C++-style templates).

OK, but if not "expansion" then Ada already has such types: discriminated
subtypes and tagged types. Both are dynamically parametric types. Neither
requires looking into the bodies.

Maybe they could be augmented in order to deal with more complex kinds of
parametrization, e.g. for container types (sequence of Integer indexed by
String). But again, please, without opening up the bodies.

You don't need the body unless you "expand".

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

Re: Ada202X: Easy to use "UML private"-like components

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccmwqhkm22.fsf@shell01.TheWorld.com...
...
> The compilation model is that when compiling something, the compiler
> looks at information coming from the specs of imported things, but not
> their bodies.  Modula-2 compilers actually work that way, and this
> is the reason for the must-be-pointer (or must be the same size as
> a pointer, or smaller, as I had (mis?)remembered it).
>
> It is also the reason for the private part kludge: the compiler sees
> the size of the full type for a private type (assuming it is known
> at compile time).  But this reasoning makes no sense to me, because
> that's not how Ada compilers work.  Any reasonable implementation
> of generics and inlining needs to look at bodies.  So full types
> should be in bodies, and compilers should look there (at least
> in optimizing mode) to find out their size.

Baloney. Maybe *most* Ada compilers work this way, but certainly not all: 
Janus/Ada works exactly like your description of Modula-2 compilers. 
Generics are implemented with universal code sharing in Janus/Ada for 
precisely this reason -- our compiler never looks in a body other than to 
compile it. (We were fanatical about minimizing compilation dependencies, 
because when a single compilation took 2-4 minutes, building anything 
significant took hours.)

Janus/Ada doesn't do inlining at all, other than of things visible in 
specifications (expression functions make a significant expansion of what 
can be inlined -- one of the reasons the idea was invented in the first 
place, many years ago). If it ever does do inlining of subprograms, it would 
do it at bind-time, (and mostly automatically).

I think Ada's allowing of those extra compilation dependencies caused most 
compilers to have insanely long build cycles in the early days of Ada, and 
probably caused a lot of damage to Ada's reputation. As such, this was one 
of the worst decisions of Ada. (I have to agree it doesn't matter so much 
anymore, but no one is building Ada compilers from scratch.)

> On the other hand, the private part kludge wouldn't be so bad if
> the syntax were different:  The private part should be a separate
> syntactic compilation_unit, with its own with clauses, and should
> normally be stored in a separate source file from the visible part.
> There's an awful lot of horrible code duplication caused by the
> fact that the private part is in the same file as the visible part.
> Separating it out into a different file would not prevent the
> compiler from looking at it!

I still think this is a horrible idea; it certainly would be a complete 
earthquake for Janus/Ada, which only knows how to process one source file at 
a time. There would be no way to "look at" such a file when compiling the 
specification, and thus we'd end up having to create a "specification" file 
containing no useful information. It would be a total mess (especially as I 
can't imagine how compilation ordering could be made to work in such a 
scenario).

And this doesn't make any sense when combined with child packages. Once one 
allows visibility into the private part in some other unit (like a child 
unit), it's no longer really separate in any way.

Perhaps this would make sense in some Ada-like language, but not for Ada.

                                     Randy.

Re: Ada202X: Easy to use "UML private"-like components

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1im71djlxwm94$.fbjv1si7kmvj$.dlg@40tude.net...
> On Sun, 23 Jun 2013 09:12:53 -0400, Robert A Duff wrote:
>
>> It is also the reason for the private part kludge: the compiler sees
>> the size of the full type for a private type (assuming it is known
>> at compile time).  But this reasoning makes no sense to me, because
>> that's not how Ada compilers work.  Any reasonable implementation
>> of generics and inlining needs to look at bodies.  So full types
>> should be in bodies, and compilers should look there (at least
>> in optimizing mode) to find out their size.
>
> ... or there should be no generics.
>
> The kludge here rather is generics and inlining, both basically are macro
> expansions.

Or better, they can be done at bind time without any impact on what 
compilers look at. Bob is just plain wrong in the above -- perhaps that is 
how GNAT and AdaMagic works, but there is no reason that an Ada compiler has 
to (or *ought* to) work that way.

                   Randy.

Re: Ada202X: Easy to use "UML private"-like components

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:k32sqc8hss4r$.14d3n8qneksz7$.dlg@40tude.net...
...
> Maybe they could be augmented in order to deal with more complex kinds of
> parametrization, e.g. for container types (sequence of Integer indexed by
> String). But again, please, without opening up the bodies.
>
> You don't need the body unless you "expand".

You don't need the body even if you *do* "expand" (as Ada does). The Ada 
contract model is strict enough that universal code sharing works (and the 
contract model could be stronger still). I always thought it made more sense 
to code share first and then use inlining to eliminate the overhead later, 
because it's almost impossible to share code after generating it separately. 
(We never built the inlining part of the compiler, though, so we never quite 
proved that.)

                                        Randy.

Re: Ada202X: Easy to use "UML private"-like components

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccppvc26ef.fsf@shell01.TheWorld.com...
...
> No, that's not at all what I meant.  I meant that a package would
> come in three parts:
>
>    package P is
>        ...
>    end P;
>
>    package private P is -- Just making up syntax here.
>        ...
>    end P;
>
>    package body P is
>        ...
>    end P;
>
> Normally stored in 3 separate source files.  There would be no
> private part syntax like we currently have.
...
> My suggestion is trivial to implement.  And it wouldn't be "as well",
> it would be "instead of".

I don't buy this. The specification would not have enough information to be 
usable, so compilation of it would be worthless. But because of the separate 
sets of withs, you'd have to be able to separately compile the private part 
(it couldn't be required to compile at the same time), so the complications 
would be doubled (if not more). And compiling a specification is already 
painful (because of all of the stuff that has to be delayed and fixed up at 
the end), having to delay that stuff indefinitely would be much worse.

I'm think your suggestion could be implemented with enough effort, but it 
isn't within a country mile of being trivial.

                                             Randy.

Re: Ada202X: Easy to use "UML private"-like components

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccr4ftko44.fsf@shell01.TheWorld.com...
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>> Maybe my post was unclear: I tried to contradict Bob Duff's recollection
>> that an opaque type in Modula-2 is more like an Ada private type than
>> like an "stt access type". I think that a Modula-2 opaque type is very
>> similar to an "stt access type". Do you agree with me?
>
> Yes, given your quotes from Wirth, I agree that Modula-2 opaque types
> are much like stt access types.  I had remembered the restriction
> differently:  the type was required to fit in the size of a pointer,
> which included integers and enums and small records.  Probably the
> Modula-2 compiler I used had a nonstandard extension -- or else I am
> misremembering.

My recollection matches yours, Bob. Perhaps the rule was changed in later 
versions of the language. In any case, the Modula-2 obaque type is *not* a 
pointer type, so in that sense it is much more like an Ada private type than 
an access type of any sort. (I.e., I don't buy this analogy, especially as 
there isn't any such thing as an stt-access-type -- the operative thing is 
an stt-incomplete-type, which is nothing like a Modula-2 opaque type. The 
access type is completely normal, its the designated object that's special.)

                              Randy.

Re: Ada202X: Easy to use "UML private"-like components

[Niklas Holsti]

On 13-06-24 23:20 , Randy Brukardt wrote:
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccr4ftko44.fsf@shell01.TheWorld.com...
>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>>
>>> Maybe my post was unclear: I tried to contradict Bob Duff's recollection
>>> that an opaque type in Modula-2 is more like an Ada private type than
>>> like an "stt access type". I think that a Modula-2 opaque type is very
>>> similar to an "stt access type". Do you agree with me?
>>
>> Yes, given your quotes from Wirth, I agree that Modula-2 opaque types
>> are much like stt access types.

Good (but I don't know if my quote is from Wirth; it was from the web
page I cited).

>> I had remembered the restriction
>> differently:  the type was required to fit in the size of a pointer,
>> which included integers and enums and small records.

That seems likely to create program-portability problems - on a 64-bit
machine, a 64-bit record could be opaque, but it could not be opaque on
a 32-bit machine (unless all pointers are artificially made 64 bits
wide, too).

>> Probably the
>> Modula-2 compiler I used had a nonstandard extension -- or else I am
>> misremembering.
> 
> My recollection matches yours, Bob. Perhaps the rule was changed in later 
> versions of the language.

The Wikipedia entry on Modula-2 refers to several dialects of Modula-2,
of which the "PIM" dialect (from the book "Programming in Modula-2") is one.

The rules for opaque types do seem to vary between dialects; for
example, the site
http://freepages.modula2.org/report4/modula-2.html#SEC43 says: "Opaque
export is restricted to pointers and to subranges of standard types."

> In any case, the Modula-2 obaque type is *not* a 
> pointer type, so in that sense it is much more like an Ada private type than 
> an access type of any sort.

I can agree, if we consider only the user's point of view. Both opaque
types and stt-access-types are declared as private -- the user (client)
does not see their structure or nature.

However, even for the more permissive Modula-2 dialects, for example the
one quoted earlier in this post, I would guess that most cases of opaque
types in practice use pointers, to avoid the size restrictions.

The main difference is that in Ada, the unknown underlying type is named
-- what you call the stt-incomplete type. This type is of course
invisible to the users (clients) of the private type. Off hand, it does
not seem to me that such named-but-incomplete types should cause hard
problems for the compiler, but it appears that you have experienced such
problems. Perhaps they did not exist in Ada 83, but came about because
of other extensions such as controlled types?

> (I.e., I don't buy this analogy, especially as 
> there isn't any such thing as an stt-access-type -- the operative thing is 
> an stt-incomplete-type, which is nothing like a Modula-2 opaque type. The 
> access type is completely normal, its the designated object that's special.)

As I have understood it, the private definition of the stt-access-type
as an access to the stt-incomplete-type is simply an idiom, or trick, to
achieve the same effect as a Modula-2 opaque type, without introducing
the new concept "opaque" into Ada. That it gives a name to the
stt-incomplete-type is perhaps unfortunate, from the compiler-writer's
point of view.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Ada202X: Easy to use "UML private"-like components

[Robert A Duff]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> That seems likely to create program-portability problems - on a 64-bit
> machine, a 64-bit record could be opaque, but it could not be opaque on
> a 32-bit machine (unless all pointers are artificially made 64 bits
> wide, too).

Yes.  I was appalled by that feature for exactly that reason.
I'm a big fan of portability.

But given the time frame of Modula-2, I think your example should be
16-bit/32-bit not 32/64.  ;-)

In any case, in plain English, "opaque" doesn't have all these
pointer/heap implications, so I suggest saying something like
"Modula-2-style opaque types" rather than just "opaque types"
if that's what you mean.

> The main difference is that in Ada, the unknown underlying type is named
> -- what you call the stt-incomplete type. This type is of course
> invisible to the users (clients) of the private type. Off hand, it does
> not seem to me that such named-but-incomplete types should cause hard
> problems for the compiler, but it appears that you have experienced such
> problems. Perhaps they did not exist in Ada 83, but came about because
> of other extensions such as controlled types?

The implementation problems existed in Ada 83.  I'm not sure I remember
all the issues, but the most obvious is that there's an implicit
assumption that you can tell the size/representation of a pointer
without knowing what it points at.  There are various reasons that might
not be true.  In fact, it's not true in GNAT.

Also, I think it was legal to do "X.all" on those things (in the package
spec) in Ada 83.  It would always raise Constraint_Error, but the
"natural" implementation wants to know the size of X.all.  I fixed that
in Ada 95 by changing the freezing rules to make it illegal, IIRC.

- Bob

Re: Ada202X: Easy to use "UML private"-like components

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccmwqhkm22.fsf@shell01.TheWorld.com...
> ...
>> It is also the reason for the private part kludge: the compiler sees
>> the size of the full type for a private type (assuming it is known
>> at compile time).  But this reasoning makes no sense to me, because
>> that's not how Ada compilers work.  Any reasonable implementation
>> of generics and inlining needs to look at bodies.  So full types
>> should be in bodies, and compilers should look there (at least
>> in optimizing mode) to find out their size.
>
> Baloney. Maybe *most* Ada compilers work this way, but certainly not all: 
> Janus/Ada works exactly like your description of Modula-2 compilers. 
> Generics are implemented with universal code sharing in Janus/Ada for 
> precisely this reason -- our compiler never looks in a body other than to 
> compile it.

Perhaps I should have said "reasonably efficient implementation".
You can't implement generics efficiently (I'm talking about
run-time efficiency) without doing at least some macro expansion.

>... (We were fanatical about minimizing compilation dependencies, 
> because when a single compilation took 2-4 minutes, building anything 
> significant took hours.)

Yes, no-macro-expansion favors efficiency at compile time.

But you're going against the grain there -- your compiler design should
be dead easy, but it's quite complicated because the semantics are
defined in terms of macro expansion.  (Consider an exception declared in
a generic package body -- each instance must have a different exception.)

> Janus/Ada doesn't do inlining at all, ...

Well, there goes (run-time) efficiency.  Seriously, I don't see how
"don't do inlining" is a reasonable implementation of inlining.

>...other than of things visible in 
> specifications (expression functions make a significant expansion of what 
> can be inlined -- one of the reasons the idea was invented in the first 
> place, many years ago). If it ever does do inlining of subprograms, it would 
> do it at bind-time, (and mostly automatically).

"mostly automatically" is good.

But I don't see how bind time (i.e. link time) helps.  It's a reasonable
approach, but it takes just as long to generate code at link time as it
does at compile time, for the same generated code.  If you modify the
procedure body being inlined, you have to regenerate code at all call
sites, either way.

> I still think this is a horrible idea; it certainly would be a complete 
> earthquake for Janus/Ada, which only knows how to process one source file at 
> a time. There would be no way to "look at" such a file when compiling the 
> specification, and thus we'd end up having to create a "specification" file 
> containing no useful information. It would be a total mess (especially as I 
> can't imagine how compilation ordering could be made to work in such a 
> scenario).

I was suggesting that Ada 83 should have been different.  (And in fact,
somebody pointed out that Ichbiah's language LIS was in fact different
in that way!)  If that had been the case, you (and others) would have
designed your compiler differently.  It would not have been rocket
surgery.  (Yes, modifying a compiler after the fact could easily be
rocket surgery.

> And this doesn't make any sense when combined with child packages. Once one 
> allows visibility into the private part in some other unit (like a child 
> unit), it's no longer really separate in any way.

Yes, Tucker made a virtue out of necessity.  Private parts are a kludge.
The fact that child units can see into parent private parts is useful,
but it's not how I would design a language from scratch.

> Perhaps this would make sense in some Ada-like language, but not for Ada.

Right, an Ada-83-like language.  Today, my suggestion makes no sense.

- Bob

Re: Ada202X: Easy to use "UML private"-like components

[Dmitry A. Kazakov]

On Mon, 24 Jun 2013 15:11:11 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:k32sqc8hss4r$.14d3n8qneksz7$.dlg@40tude.net...
> ...
>> Maybe they could be augmented in order to deal with more complex kinds of
>> parametrization, e.g. for container types (sequence of Integer indexed by
>> String). But again, please, without opening up the bodies.
>>
>> You don't need the body unless you "expand".
> 
> You don't need the body even if you *do* "expand" (as Ada does). The Ada 
> contract model is strict enough that universal code sharing works (and the 
> contract model could be stronger still).

Here is a logical contradiction. If the model were that strong you would
need no bodies to look into, the public part declaration should be enough
for using the type.

But the model is not enough strong and it is not enough precise. You can
write

   type T is private;

and there is no contract put on T'Size. Without that contract you cannot
have

   type A is array (...) of T;

etc.

Either 

1. The contract model should be much more precise and explicit, e.g. with
interfaces:

                                                    -- Not Ada
   type T is new Abstract_Fixed_Size_Type_Interface with private;
   overriding function "'Size" (Object : T) return Universal_Integer;

or

2. You must have private part available for the compiler to deduce missing
information.

I prefer both.

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

Re: Ada202X: Easy to use "UML private"-like components

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:12c0h7muc9ab1$.1rn058nrhw3m8.dlg@40tude.net...
> On Mon, 24 Jun 2013 15:11:11 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:k32sqc8hss4r$.14d3n8qneksz7$.dlg@40tude.net...
>> ...
>>> Maybe they could be augmented in order to deal with more complex kinds 
>>> of
>>> parametrization, e.g. for container types (sequence of Integer indexed 
>>> by
>>> String). But again, please, without opening up the bodies.
>>>
>>> You don't need the body unless you "expand".
>>
>> You don't need the body even if you *do* "expand" (as Ada does). The Ada
>> contract model is strict enough that universal code sharing works (and 
>> the
>> contract model could be stronger still).
>
> Here is a logical contradiction. If the model were that strong you would
> need no bodies to look into, the public part declaration should be enough
> for using the type.

I'm not talking about the public part only; I'm definitely including the 
private part as well.

> But the model is not enough strong and it is not enough precise. You can
> write
>
>   type T is private;
>
> and there is no contract put on T'Size. Without that contract you cannot
> have
>
>   type A is array (...) of T;

Of course you can have that. Janus/Ada uses universal code sharing, so if T 
is a formal private type, you have precisely this situation -- and it works 
fine. The compiler simply has to insert a level of indirection; the 
programmer need not know that it is there -- the compiler can manage it for 
you (including all of the memory management). Just as with mutable 
discriminanted records, there is no reason that the complications have to be 
made visible to the programmer.

This is not done more mostly because compiler writers don't want the extra 
work. They don't much care that not having these features makes more work 
for the programmer, and so long as programmers don't demand this support, 
they aren't going to get it. (The excuse for not providing it is that 
systems that have strong verification requirements can't have the implicit 
allocation and deallocation that is implied. I suppose that's true, but even 
then why should the support be denied to everyone else?).

...
> 2. You must have private part available for the compiler to deduce missing
> information.

I was certainly assuming this in my original response. I'm not sure why you 
thought otherwise, as I was clearly talking about in current Ada and paying 
little attention to whatever Bob was talking about (it's misguided at best).

                                                Randy.

Re: Ada202X: Easy to use "UML private"-like components

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:b2rsmlFpmvmU1@mid.individual.net...
> On 13-06-24 23:20 , Randy Brukardt wrote:
...
>> In any case, the Modula-2 obaque type is *not* a
>> pointer type, so in that sense it is much more like an Ada private type 
>> than
>> an access type of any sort.
>
> I can agree, if we consider only the user's point of view. Both opaque
> types and stt-access-types are declared as private -- the user (client)
> does not see their structure or nature.

Only the client's point of view matters for both private and opaque types, 
as inside the package the full views are available. There is nothing of 
interest to say about private types from inside the package.

You're conflating the properties of full view (for opaque types, that's 
essentially an access-to-stt-incomplete, which of course is a possibility in 
Ada as well) with the properties of the partial view (which is what the 
client sees). These views can only be considered separately, as no one can 
see both.

...
> The main difference is that in Ada, the unknown underlying type is named
> -- what you call the stt-incomplete type. This type is of course
> invisible to the users (clients) of the private type. Off hand, it does
> not seem to me that such named-but-incomplete types should cause hard
> problems for the compiler, but it appears that you have experienced such
> problems. Perhaps they did not exist in Ada 83, but came about because
> of other extensions such as controlled types?

The real problem is that they're useless (at least for me), especially 
directly as the full type of a private type. Once you have an explicit 
access type somewhere, you also have to have explicit memory management. But 
there is no way to free objects when their objects go away unless the full 
object is controlled. Which means it is *not* an access type.

You have to have a controlled record type in the private part to contain 
that access-to-stt-incomplete, or you are going to leak memory. And you need 
to know the size of that record type; ergo, you have to have a private part 
or something like it.

I've tried many times over the years to use an stt-incomplete in the private 
part of a package (even as an access component of the private type, not the 
private type itself), but 90% of the time, some issue comes up that has 
forced me to move the declarations to the private part. I don't even bother 
to try anymore, it's simply not worth the hassle.

                           Randy.

Re: Ada202X: Easy to use "UML private"-like components

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccli5zqat1.fsf@shell01.TheWorld.com...
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>
>> That seems likely to create program-portability problems - on a 64-bit
>> machine, a 64-bit record could be opaque, but it could not be opaque on
>> a 32-bit machine (unless all pointers are artificially made 64 bits
>> wide, too).
>
> Yes.  I was appalled by that feature for exactly that reason.
> I'm a big fan of portability.
>
> But given the time frame of Modula-2, I think your example should be
> 16-bit/32-bit not 32/64.  ;-)
>
> In any case, in plain English, "opaque" doesn't have all these
> pointer/heap implications, so I suggest saying something like
> "Modula-2-style opaque types" rather than just "opaque types"
> if that's what you mean.
>
>> The main difference is that in Ada, the unknown underlying type is named
>> -- what you call the stt-incomplete type. This type is of course
>> invisible to the users (clients) of the private type. Off hand, it does
>> not seem to me that such named-but-incomplete types should cause hard
>> problems for the compiler, but it appears that you have experienced such
>> problems. Perhaps they did not exist in Ada 83, but came about because
>> of other extensions such as controlled types?
>
> The implementation problems existed in Ada 83.  I'm not sure I remember
> all the issues, but the most obvious is that there's an implicit
> assumption that you can tell the size/representation of a pointer
> without knowing what it points at.  There are various reasons that might
> not be true.  In fact, it's not true in GNAT.
>
> Also, I think it was legal to do "X.all" on those things (in the package
> spec) in Ada 83.  It would always raise Constraint_Error, but the
> "natural" implementation wants to know the size of X.all.  I fixed that
> in Ada 95 by changing the freezing rules to make it illegal, IIRC.

I think there was also an issue with constraints in Ada 83 that was fixed in 
Ada 95.

Note that stt-incomplete types were the basis for the "limited with" feature 
in Ada 2007, so it's not like the language designers have neglected the 
feature. (We thought that if stt-incomplete already worked, implementers 
couldn't complain about limited with - that turned out not to be quite 
true.)

                     Randy.

Re: Ada202X: Easy to use "UML private"-like components

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcctxknt2r7.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
>> Janus/Ada doesn't do inlining at all, ...
>
> Well, there goes (run-time) efficiency.  Seriously, I don't see how
> "don't do inlining" is a reasonable implementation of inlining.

It's unclear to me that inlining makes enough difference for the 
implementation earthquake that it would have represented in Janus/Ada 
(several man-years of work). Since Janus/Ada compiles statements directly 
from their syntax, the largest program structure that it can store is an 
expression tree (and that was a later change, necessitated by the 
requirements of Ada resolution - the original design was purely 
syntax-driven). That would allow inlining of expression functions (and 
functions that are similar to expression functions), but little larger. (One 
could imagine converting if statements into if expressions to allow a bit 
more inlining.)

>>...other than of things visible in
>> specifications (expression functions make a significant expansion of what
>> can be inlined -- one of the reasons the idea was invented in the first
>> place, many years ago). If it ever does do inlining of subprograms, it 
>> would
>> do it at bind-time, (and mostly automatically).
>
> "mostly automatically" is good.
>
> But I don't see how bind time (i.e. link time) helps.  It's a reasonable
> approach, but it takes just as long to generate code at link time as it
> does at compile time, for the same generated code.  If you modify the
> procedure body being inlined, you have to regenerate code at all call
> sites, either way.

Doing this at bind-time allows inlining stuff that neither the user nor the 
compiler really know might be inlined, and it also allows partial evaluation 
of calls based on what is actually present in the program (think about the 
second parameter to New_Line -- it's hardly ever used; code shared generics 
have a similar parameter for sharing information, of course). (It also 
allows other cross-procedural optimizations.)

Final code generation obviously has to occur after those optimizations, so 
it would always be done at bind-time in that scenario. So there wouldn't be 
any incremental cost to inlining (other than the cost of actually doing it). 
This wasn't a practical implementation in 1995 (which is why we didn't do it 
then), but it was always the intended end-game for Janus/Ada. (That code 
generation can be parallelized, and much of the cost of binding disappears 
if the code generation is delayed, so on a modern multi-core I wouldn't 
expect the binding time to grow that much.)

Anyway, if I spent less time writing about this implementation and more time 
creating it, we could see how well it works. ;-)

                                       Randy.

Re: Ada202X: Easy to use "UML private"-like components

[Martin]

On Friday, June 21, 2013 7:36:40 PM UTC+1, Robert A Duff wrote:
> Martin <martin@..........com> writes: > Secondly, I have to explain that using Ada "private" gives you "UML protected": Not exactly. Ada "private" means clients can't see it, but child packages (which should be thought of as part of the same abstraction) can. It's a completely different visibility model than UML. I don't see any reason to be embarrassed about that. > Option 2: > type T is tagged record > null; > private > F : Float; > end record; > > > I prefer Option 2. > > Thoughts? I don't think making Ada more like UML is a worthwhile goal. If it were, I'd prefer your option 1. But I don't see the point: In Ada, packages are about visibility. That's different from languages that conflate the concept of "module" and "type" (which has both advantages and disadvantages). Overall, I prefer the Ada way. If you want derived types to see their parent types components, you put the derived types in a child package; if you don't, then you don't. Attempts to mimic UML in Ada lead to a mess, as you've shown. I share your disdain for what you called "opaque" types -- it forces you into heap management, which leads to extra trouble. But I object to calling them "opaque" types. Ada folks usually call them "stt access types" and "stt incomplete types", or "Taft amendment types", because they were invented by Tucker Taft and added to Ada 83 at the last minute when nobody realized all the headaches they cause for compiler writers. The term "opaque type" comes from Modula-2, IIRC, and is more like an Ada private type, with some annoying restrictions added. - Bob


Back from holiday...I'll leave all the Modula-2 discussion well alone. I was just using "opaque" in the English dictionary definition sense - no implication of links to other languages implied...but thanks for the background!

I hindsight, all the recent changes to Ada-syntax style probably does favour Option 1.

Anyway, the keyword in the topic was "easy" - perhaps I should have written it in ALL-CAPS :-)

There are current options of how to achieve UML-like private-ness but all are clunky and some are horrific and, given their access-types not available for safety-critical systems (where coding standard still often forbid such usage).

As to making Ada more UML-like, that's not really my goal...but I'd certainly like to make common UML constructs easy to achieve in Ada.

It's a topic I've raised at various conferences for 10 years or more.

I had hoped a standard UML <-> Ada mapping could be agreed between the UML & Ada compiler tool vendors; certainly they all gave positive responses to such a move all those years ago. They all had company's developing their own Stereotype/Tag UML<->Ada solutions, so all saw this wheel being re-invented year after year, company after company.

Sadly, I expect the companies who were re-inventing these wheels, saw their work as "IP" and not to be shared with the wider community. Opportunity lost.

Interest has been raised in UML/Ada recently but sadly the current state-of-the-art is not as mature as the current UML/Java or UML/C++...and I live in a MDA focused s/w dept, where UML is a must and where auto-code generation is much used.

NB: Lots of recent s/w grads seem to be literal in only in UML + Java...it have become, for better or for worse, a UML world.

-- Martin

Re: Ada202X: Easy to use "UML private"-like components

[Simon Wright]

Martin <martin@thedowies.com> writes:

Hi Martin!

> On Friday, June 21, 2013 7:36:40 PM UTC+1, Robert A Duff wrote:

[stuff that Google Groups mangled even more horrifically than usual!]

> There are current options of how to achieve UML-like private-ness but
> all are clunky and some are horrific and, given their access-types not
> available for safety-critical systems (where coding standard still
> often forbid such usage).

Given that the UML private/protected distinction is only relevant to
inheritance, I'd have thought it would be irrelevant to safety-critical
systems!

Rational Rose used to have the additional visibility "implementation". I
took this to mean the same as "private" (and "protected").

> As to making Ada more UML-like, that's not really my goal...but I'd
> certainly like to make common UML constructs easy to achieve in Ada.

I have to ask, why? We have profiles to state what UML constructs will
have meaning in the translation, and what that meaning will be. Other
constructs - well, I'd forbid them on the grounds that no two team
members will have the same opinion as to what they mean, and they'll
probably get translated (if at all) into something different again.

> I had hoped a standard UML <-> Ada mapping could be agreed between the
> UML & Ada compiler tool vendors; certainly they all gave positive
> responses to such a move all those years ago. They all had company's
> developing their own Stereotype/Tag UML<->Ada solutions, so all saw
> this wheel being re-invented year after year, company after company.

Always seemed to me that people went overboard with that; why did they
feel the need to stereotype a class «Ada:Task» when it could just be
marked _active_? (actually, there is a reason for using a stereotype,
which is that tags are associated with stereotypes, and you'll need tags
for {priority} and {stack}; but why not use plain «active»?).

> Interest has been raised in UML/Ada recently

Oh, where?

Re: Ada202X: Easy to use "UML private"-like components

[Robert A Duff]

Martin <martin@thedowies.com> writes:

> NB: Lots of recent s/w grads seem to be literal in only in UML + Java...

Whereas in Ada, they are figurative?

;-) ;-) 

- Bob

Re: Ada202X: Easy to use "UML private"-like components

[Martin]

On Tuesday, July 9, 2013 10:43:34 PM UTC+1, Robert A Duff wrote:
> Martin <martin@thedowies.com> writes: > NB: Lots of recent s/w grads seem to be literal in only in UML + Java... Whereas in Ada, they are figurative? ;-) ;-) - Bob

Not even... ;-( ;-(

-- Martin

Re: Ada202X: Easy to use "UML private"-like components

[Martin]

On Tuesday, July 9, 2013 3:39:22 PM UTC+1, Simon Wright wrote:

> [stuff that Google Groups mangled even more horrifically than usual!]

It really is mangling stuff up...might be this PC...


> Given that the UML private/protected distinction is only relevant to
> inheritance, I'd have thought it would be irrelevant to safety-critical
> systems!

Depends on what you can agree with your IV&V.


> I have to ask, why? We have profiles to state what UML constructs will
> have meaning in the translation, and what that meaning will be. Other
> constructs - well, I'd forbid them on the grounds that no two team
> members will have the same opinion as to what they mean, and they'll
> probably get translated (if at all) into something different again.

But currently we have no *standard* profiles...but we do have various
in-house company profiles that are *very* similar.


> Always seemed to me that people went overboard with that; why did they
> feel the need to stereotype a class «Ada:Task» when it could just be
> marked _active_? (actually, there is a reason for using a stereotype,
> which is that tags are associated with stereotypes, and you'll need
> tags for {priority} and {stack}; but why not use plain «active»?).

I see what you mean...everything single thing tended to have a stereotype.

I think now we'll see a bit of that again (if we get UML tools to support
Ada2012!), with everything having an "aspect" stereotype/tag!! :-)


> Interest has been raised in UML/Ada recently Oh, where?

Here! Old projects never die...they just get re-hosted...and updated! :-)

-- Martin

Re: Ada202X: Easy to use "UML private"-like components

[Dmitry A. Kazakov]

On Tue, 9 Jul 2013 23:34:51 -0700 (PDT), Martin wrote:

> On Tuesday, July 9, 2013 10:43:34 PM UTC+1, Robert A Duff wrote:
>> Martin <martin@thedowies.com> writes:
>> NB: Lots of recent s/w grads seem
>> to be literal in only in UML + Java... Whereas in Ada, they are
>> figurative? ;-) ;-) - Bob
> 
> Not even... ;-( ;-(

We are asking applicants to write a program that tests if a given bit in a
byte is set. More than *half* of them fail. Quarter of the rest write a
loop...

P.S. It is not a joke, so there is no smiley.

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

Re: Ada202X: Easy to use "UML private"-like components

[Martin]

On Wednesday, July 10, 2013 9:24:11 AM UTC+1, Dmitry A. Kazakov wrote:
> We are asking applicants to write a program that tests if a given bit in a byte
> is set. More than *half* of them fail. Quarter of the rest write a loop...

And writing a loop to do it _isn't_ a fail?!?! :-O

-- Martin

Re: Ada202X: Easy to use "UML private"-like components

[Simon Wright]

Martin <martin@thedowies.com> writes:

> There are current options of how to achieve UML-like private-ness but
> all are clunky and some are horrific and, given their access-types not
> available for safety-critical systems (where coding standard still
> often forbid such usage).

If you were doing full translation you could implement UML private vs
protected at the translation stage.

Re: Ada202X: Easy to use "UML private"-like components

[Martin]

That's fine for one half the equation (implementing the "private" using one if the techniques mentioned before) but it still leaves using the "private" components...that's still a mess (my description!) isn't it?

-- Martin

Re: Ada202X: Easy to use "UML private"-like components

[Simon Wright]

Martin <martin@thedowies.com> writes:

> That's fine for one half the equation (implementing the "private"
> using one if the techniques mentioned before) but it still leaves
> using the "private" components...that's still a mess (my description!)
> isn't it?

I was thinking that for full code gen the translator could say "this
operation in the child class is trying to access a private attribute of
the parent! No!" and report a translation error.

Clearly not possible for framework-only generators.

My ColdFrame[1] (a) declares the instance record in the private part of
the class package, regardless of what you put in the model, (b) supports
provision of «accessor» operations, and (c) implements inheritance using
its own mechanisms rather than via tagged types; so "public" attributes
are those given accessors by the modeller, all others are "private". I
could automatically generate accessors for attributes marked "public",
but I think that people should be made to work a bit to get access to
instance variables of other classes!

[1] https://sourceforge.net/projects/coldframe/

Re: Ada202X: Easy to use "UML private"-like components

[Martin]

Sadly, our current UML tool comes with some strange defaults out-the-box, such that if you don't override the code-gen properties early (and preferably at top of model level) then all attributes are (C++) protected and not the visibly you selected for the attribute. And the visibility you selected for the attribute becomes the visibility of the set/get operations...ie what you see (on a Class Diagram) is _not_ what you get in the code!!! Horrific...and non-Do-178B (/C) compliant!!

-- Martin

Re: Ada202X: Easy to use "UML private"-like components

[Simon Wright]

Martin <martin@thedowies.com> writes:

> Sadly, our current UML tool comes with some strange defaults
> out-the-box, such that if you don't override the code-gen properties
> early (and preferably at top of model level) then all attributes are
> (C++) protected and not the visibly you selected for the
> attribute. And the visibility you selected for the attribute becomes
> the visibility of the set/get operations...ie what you see (on a Class
> Diagram) is _not_ what you get in the code!!! Horrific...and
> non-Do-178B (/C) compliant!!

Do you mean that it generates setters/getters for all the instance
variables? Evil! (and pointless, given what you say about the accessor
visibilities; why not just generate the attributes as required?)

Re: Ada202X: Easy to use "UML private"-like components

[Martin]

Yes, but I'd rather go through set/get - direct access to attributes is content coupling...that's evil!! :-) and they're useful for breakpoints etc to see which call stack is setting a particular value...

...the other big problem, is that what you see on a OMD or CD wrt visibilties is not what you get in the code.

Re: Ada202X: Easy to use "UML private"-like components

[Simon Wright]

Martin <martin@thedowies.com> writes:

> Yes, but I'd rather go through set/get - direct access to attributes
> is content coupling...that's evil!! :-) and they're useful for
> breakpoints etc to see which call stack is setting a particular
> value...
>
> ...the other big problem, is that what you see on a OMD or CD wrt
> visibilties is not what you get in the code.

I would have thought it'd make more sense to provide accessors for the
public attributes (and not for the others) while keeping the public
attributes themselves private (protected?), since derived(?) classes
_should_ be able to see the protected attributes?

But, that said, it doesn't seem unreasonable to map the model's
attribute visibilities to accessor visibilities. What else should you
do? 

Re: Ada202X: Easy to use "UML private"-like components

[Martin]

On Friday, July 12, 2013 7:57:28 AM UTC+1, Simon Wright wrote:
> I would have thought it'd make more sense to provide accessors for the
> public attributes (and not for the others) while keeping the public
> attributes themselves private (protected?), since derived(?) classes
> _should_ be able to see the protected attributes? But, that said, it
> doesn't seem unreasonable to map the model's attribute visibilities to
> accessor visibilities. What else should you do?

Exactly...esp as both attributes & their set/get can each have their own
visibility...and you can see those on any OMD...why would you *not* reflect
them as-is in the code?...

My assumption is that the out-the-box behaviour is lost in the mists of time
but they can't change it without being non-backwards compatible.

I guess it's a little like having to remember "-gnato" ;-)

-- Martin