Ada OOP alternatives?

Ada OOP alternatives?

[raould]

might anybody know what the different designs were for OO in Ada? what
was Ichbiah's design, vs. the one that went through? thanks.

Re: Ada OOP alternatives?

[Robert A Duff]

raould <raould@gmail.com> writes:

> might anybody know what the different designs were for OO in Ada? what
> was Ichbiah's design, vs. the one that went through? thanks.

Interesting question.

As far as I know, Ichbiah didn't have a design for OO in Ada 95.
He wanted the syntax to be something like "class type T is...",
as opposed to "type T is tagged...", and he _very_ much wanted
"class" to be a reserved word, rather than a mere attribute.

I don't remember Ichbiah proposing any detailed semantics
for "class type T is...".  His concern, as far as I know,
was syntax-oriented.

Of course Ichbiah knew all about OO when he designed Ada 83 -- I'm told
he was familiar with Simula 67, for ex., which is the Mother of all OOP
languages.  He left OO out of Ada 83 deliberately.  I've no idea whether
that was his own choice, or forced by some requirements document like
Steelman.

And Ichbiah invented Ada's derived types, upon which Tucker Taft based
OO in Ada 95.  I've no idea whether Ichbiah had that sort of thing in
mind when he invented derived types.  But I've been told that derived
types were controversial for Ada 83 -- the reviewers thought they were
useless nonsense, but Ichbiah insisted on keeping them in the language
design.

As for other (non-Ichbiah) designs, well I've seen various
proposals for "package types", treating Ada packages like "classes" in
languages like Simula-67, Java, C++, etc.  I'm not sure that works.
E.g. the question arises whether types declared in two different
"package objects" of the same "package type" should be the same type.
I'm not sure it does _not_ work, either.  ;-)

- Bob

Re: Ada OOP alternatives?

[Georg Bauhaus]

Robert A Duff wrote:

> As for other (non-Ichbiah) designs, well I've seen various
> proposals for "package types", treating Ada packages like "classes" in
> languages like Simula-67, Java, C++, etc.  I'm not sure that works.
> E.g. the question arises whether types declared in two different
> "package objects" of the same "package type" should be the same type.
> I'm not sure it does _not_ work, either.  ;-)

Hasn't the package type returned---or at least a flavor of
package type---as JGNAT's or AppletMagic's or MGNAT's
Ada tagged <-> VM class? :-) E.g.

  package P is

     type P_Obj ...  -- AppletMagic
     type Typ ...  -- JGNAT

  end P;


Meyer has collected a question about Ada's type syntax which
is, Why hasn't Ada used the same syntax for the pair (type,
operations) which is does use for (protected type, operations)?

Re: Ada OOP alternatives?

[Alex R. Mosteo]

Georg Bauhaus wrote:

> Meyer has collected a question about Ada's type syntax which
> is, Why hasn't Ada used the same syntax for the pair (type,
> operations) which is does use for (protected type, operations)?

I guess this is one of the first things that ring "strange" to a newbie
learning the language. I sure noticed it.

The need to expose the privates of a public protected type is also a bit
disturbing; I guess there are good compiler design reasons so it couldn't be
done somehow differently.

Re: Ada OOP alternatives?

[Dmitry A. Kazakov]

On Wed, 16 Jul 2008 11:54:52 +0200, Alex R. Mosteo wrote:

> Georg Bauhaus wrote:
> 
>> Meyer has collected a question about Ada's type syntax which
>> is, Why hasn't Ada used the same syntax for the pair (type,
>> operations) which is does use for (protected type, operations)?
>
> I guess this is one of the first things that ring "strange" to a newbie
> learning the language. I sure noticed it.
> 
> The need to expose the privates of a public protected type is also a bit
> disturbing; I guess there are good compiler design reasons so it couldn't be
> done somehow differently.

I don't think so. Probably one simply copied the design of task types,
carrying the error of binding operations to single type with it.

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

Re: Ada OOP alternatives?

[Robert A Duff]

Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> writes:

> Meyer has collected a question about Ada's type syntax which
> is, Why hasn't Ada used the same syntax for the pair (type,
> operations) which is does use for (protected type, operations)?

You want the operations of a private type to have visibility on the
components of all visible objects of the type.  E.g. P(X,Y) should
be able to see the implementation details of X and Y (assuming P is
in the package where the type is declared).

You want the operations of a protected type to have visibility
on the components of just that object (the one that was locked
when entering the operation) -- not other objects that happen
to be of the same type.

- Bob

Re: Ada OOP alternatives?

[Robert A Duff]

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> The need to expose the privates of a public protected type is also a bit
> disturbing; ...

Private parts are a kludge.  I don't think they should exist.
And if they do exist, they should not be syntactically attached
to the visible part -- they should normally be stored in a
separate source file.

The "disturbing" thing you mention is not specific to protected
types -- the same problem occurs if you have a package nested
within the visible part of another package.

- Bob

Re: Ada OOP alternatives?

[Dmitry A. Kazakov]

On Wed, 16 Jul 2008 10:03:15 -0400, Robert A Duff wrote:

> You want the operations of a protected type to have visibility
> on the components of just that object (the one that was locked
> when entering the operation) -- not other objects that happen
> to be of the same type.

Yes, this shows why the idea of a hidden parameter (the protected object =
self) is bad. The object should have been passed as a plain parameter to
all operations of its type.

   protected type T is
      procedure Foo; -- More operation of T than others...
   end T;
   procedure Bar (X : in out T);

It is annoying that Foo and Bar being both operations of the type T have
different status.

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

Re: Ada OOP alternatives?

[(see below)]

On 16/07/2008 15:07, in article wcciqv56hxs.fsf@shell01.TheWorld.com,
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:

> Private parts are a kludge.  I don't think they should exist.
> And if they do exist, they should not be syntactically attached
> to the visible part -- they should normally be stored in a
> separate source file.

IIRC, in LIS Ichbiah went for a 3-component module, with interface (spec),
representation (private) and implementation (body) files.

I always wondered why Ada departed from that.
-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Ada OOP alternatives?

[Robert A Duff]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> IIRC, in LIS Ichbiah went for a 3-component module, with interface (spec),
> representation (private) and implementation (body) files.

Interesting.  So he knew about the idea, and/or invented it,
but neglected to put it in Ada!

> I always wondered why Ada departed from that.

Strange.  Seems obviously superior to the Ada way of doing
private parts.

I'd still rather eliminate private parts altogether.

- Bob

Re: Ada OOP alternatives?

[(see below)]

On 17/07/2008 01:05, in article wcc3am9gytt.fsf@shell01.TheWorld.com,
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:

> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
> 
>> IIRC, in LIS Ichbiah went for a 3-component module, with interface (spec),
>> representation (private) and implementation (body) files.
> 
> Interesting.  So he knew about the idea, and/or invented it,
> but neglected to put it in Ada!
> 
>> I always wondered why Ada departed from that.
> 
> Strange.  Seems obviously superior to the Ada way of doing
> private parts.
> 
> I'd still rather eliminate private parts altogether.

How would you do that while allowing ADT clients to access objects directly
(i.e. not via a pointer a la Java)?

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Ada OOP alternatives?

[Robert A Duff]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> On 17/07/2008 01:05, in article wcc3am9gytt.fsf@shell01.TheWorld.com,
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
>> I'd still rather eliminate private parts altogether.
>
> How would you do that while allowing ADT clients to access objects directly
> (i.e. not via a pointer a la Java)?

I'd have the compiler take a peek at the body when compiling the client.
After all, that's what Ada compilers already do for pragma Inline.
And I think incremental compilation can be a big win.

In fast-compile mode, I might tolerate the "via pointer" way.
It doesn't need to be a pointer into the heap, as in Java.

We're just talking about the size of the type, really -- you say
"access objects", but clients can't access the record components
of a private type -- all they can do is declare objects and
pass them around.

Java, like many languages, doesn't even _have_ separate specs.
(And it _still_ insists on pointers for almost everything!)
So it's clearly feasible to have information in bodies used
when compiling clients.

- Bob

Re: Ada OOP alternatives?

[(see below)]

On 17/07/2008 02:36, in article wccy741fg0z.fsf@shell01.TheWorld.com,
"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:

> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
> 
>> On 17/07/2008 01:05, in article wcc3am9gytt.fsf@shell01.TheWorld.com,
>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
>>> I'd still rather eliminate private parts altogether.
>> 
>> How would you do that while allowing ADT clients to access objects directly
>> (i.e. not via a pointer a la Java)?
> 
> I'd have the compiler take a peek at the body when compiling the client.
> After all, that's what Ada compilers already do for pragma Inline.

Good point.
That does induce a bit more compile-time overhead, though, as all clients
would have to be recompiled on every update to the body.

> And I think incremental compilation can be a big win.
> In fast-compile mode, I might tolerate the "via pointer" way.
> It doesn't need to be a pointer into the heap, as in Java.
> 
> We're just talking about the size of the type, really -- you say
> "access objects", but clients can't access the record components
> of a private type -- all they can do is declare objects and
> pass them around.

And copy them.
Yes, but to do that well, they need to know at least the size of the
representation.
 
> Java, like many languages, doesn't even _have_ separate specs.
> (And it _still_ insists on pointers for almost everything!)

I loathe the Java type system's incoherence.

> So it's clearly feasible to have information in bodies used
> when compiling clients.

Certainly.

To what extent do you think that the (optical) visibility of the
representation in the Ada private part offsets a need to give the client's
programmer a more formal statement of the semantics of the ADT?
-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Ada OOP alternatives?

[Dmitry A. Kazakov]

On Wed, 16 Jul 2008 21:36:28 -0400, Robert A Duff wrote:

> So it's clearly feasible to have information in bodies used
> when compiling clients.

It is feasible, but makes little sense. Why there should be bodies then?
What is the property of a body the specification does not have, and
reverse?

In other words, provided the compiler could not compile specifications
without bodies, why the code reader/maintainer should be able to do this?

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

Re: Ada OOP alternatives?

[Robert A Duff]

"(see below)" <yaldnif.w@blueyonder.co.uk> writes:

> On 17/07/2008 02:36, in article wccy741fg0z.fsf@shell01.TheWorld.com,
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
>
>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>> 
>>> On 17/07/2008 01:05, in article wcc3am9gytt.fsf@shell01.TheWorld.com,
>>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
>>>> I'd still rather eliminate private parts altogether.
>>> 
>>> How would you do that while allowing ADT clients to access objects directly
>>> (i.e. not via a pointer a la Java)?
>> 
>> I'd have the compiler take a peek at the body when compiling the client.
>> After all, that's what Ada compilers already do for pragma Inline.
>
> Good point.
> That does induce a bit more compile-time overhead, though, as all clients
> would have to be recompiled on every update to the body.

That's why I mentioned incremental compilation.

I find that all too often, I have to recompile the world because I
changed a private part, or I changed a generic body.  That shouldn't be
the case.  I shouldn't have to recompile the world if I add a
new procedure to a visible part, either (which is tricky to get
right in the presence of overloading and use clauses!).

Unless computers get a lot faster than they are, any compiler needs at
least two modes:

    debug mode -- fast compilation, poor optimization, good debugging

    production mode -- slow compilation, fast generated code, confused
    debugger

In debug mode, I'd treat sizes of private types as dynamic (i.e. don't
peek at the body).  In production mode, peek at the body.

And I'd redesign generics so they aren't semantically based on macro
expansion.  In debug mode, the compiler would not have to look at
generic bodies when compiling clients that use the generics.  In
production mode, the compiler could duplicate code for some instances --
sort of like the way inlining works in Ada.  Possibly the compiler
could guess when to duplicate code, or possibly have a pragma to
give hints, or possibly both.

>> And I think incremental compilation can be a big win.
>> In fast-compile mode, I might tolerate the "via pointer" way.
>> It doesn't need to be a pointer into the heap, as in Java.
>> 
>> We're just talking about the size of the type, really -- you say
>> "access objects", but clients can't access the record components
>> of a private type -- all they can do is declare objects and
>> pass them around.
>
> And copy them.

Right.  But the compiler doesn't need to know the size to generate the
code for copying.  After all, we already have dynamic sizes:

    X : String (1..Read_From_Keyboard(...));

and ":=" works.

"=" also needs to know the size -- again, not necessarily at compile
time.

> Yes, but to do that well, they need to know at least the size of the
> representation.

Right -- "do that well" = what I called "production mode" above.

In production mode, the compiler would know the size (unless it truly is
dynamic).  But with incremental compilation, it still doesn't mean
recompiling the world when that body changes -- only when the size
actually changes.

Representation clauses and pragma Pack present some
interesting issues. ;-)

>> Java, like many languages, doesn't even _have_ separate specs.
>> (And it _still_ insists on pointers for almost everything!)
>
> I loathe the Java type system's incoherence.
>
>> So it's clearly feasible to have information in bodies used
>> when compiling clients.
>
> Certainly.
>
> To what extent do you think that the (optical) visibility of the
> representation in the Ada private part offsets a need to give the client's
> programmer a more formal statement of the semantics of the ADT?

I think the optical visibility is not a big deal.  But I want all
implementation details (including what's now in the private part) stored
in a separate file from the visible part, so it can be managed
separately in the CM system.  I want to be able to ask "did the
interface of so-and-so change since last week?".

Suppose I need a package that does something different on windows
vs. unix.  Ideally, I'd like the interface to be the same, and hide the
differences in the body -- i.e.  have two versions of that body.  But
Ada forces some of those differences to appear in the private part,
which means two copies of the spec file, which means it's hard to ensure
that the interfaces are indeed identical.  And it causes evil code
duplication.

- Bob

Re: Ada OOP alternatives?

[Robert A Duff]

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

> On Wed, 16 Jul 2008 21:36:28 -0400, Robert A Duff wrote:
>
>> So it's clearly feasible to have information in bodies used
>> when compiling clients.
>
> It is feasible, but makes little sense. Why there should be bodies
> then?

I think you mean, "Why there should be specs then?".  ;-)

> What is the property of a body the specification does not have, and
> reverse?
>
> In other words, provided the compiler could not compile specifications
> without bodies, why the code reader/maintainer should be able to do this?

I want separate specs and bodies, not for the compiler's benefit, but
for the programmer's benefit.  I want to be able to read a concise spec,
without having to wade through the entire body.

The compiler should check legality without looking at other bodies.  But
it should look at bodies when generating code (at least if optimization
is turned on).

- Bob

Re: Ada OOP alternatives?

[Dmitry A. Kazakov]

On Thu, 17 Jul 2008 12:50:31 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Wed, 16 Jul 2008 21:36:28 -0400, Robert A Duff wrote:
>>
>>> So it's clearly feasible to have information in bodies used
>>> when compiling clients.
>>
>> It is feasible, but makes little sense. Why there should be bodies
>> then?
> 
> I think you mean, "Why there should be specs then?".  ;-)

I used to review C code that packed almost 80% of executable code in the
header files... (:-))

>> What is the property of a body the specification does not have, and
>> reverse?
>>
>> In other words, provided the compiler could not compile specifications
>> without bodies, why the code reader/maintainer should be able to do this?
> 
> I want separate specs and bodies, not for the compiler's benefit, but
> for the programmer's benefit.  I want to be able to read a concise spec,
> without having to wade through the entire body.

There are two problems with that. The first one is that the difference is
not obvious. Why legality check is less than "full compilation", so that
the delta cannot be left for the binder/linker. The second one is that if
the delta is sufficient, then the reader should probably become aware of
it. In short, it is difficult to drive a margin.

> The compiler should check legality without looking at other bodies.  But
> it should look at bodies when generating code (at least if optimization
> is turned on).

But what would you do with dynamically linked libraries, remote partitions
and other lately bound stuff? I think that the time of monolithic systems
is gone.

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

Re: Ada OOP alternatives?

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccy741fg0z.fsf@shell01.TheWorld.com...
> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>
>> On 17/07/2008 01:05, in article wcc3am9gytt.fsf@shell01.TheWorld.com,
>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
>>> I'd still rather eliminate private parts altogether.
>>
>> How would you do that while allowing ADT clients to access objects 
>> directly
>> (i.e. not via a pointer a la Java)?
>
> I'd have the compiler take a peek at the body when compiling the client.
> After all, that's what Ada compilers already do for pragma Inline.

That's what *some* Ada compilers do. Personally, I think that violates the 
spirit of Ada (Ichbiah version) by adding unnecessary compilation 
dependencies. Indeed, I think the whole design of pragma Inline is wrong in 
Ada.

...
> We're just talking about the size of the type, really -- you say
> "access objects", but clients can't access the record components
> of a private type -- all they can do is declare objects and
> pass them around.

Ugh. That's surely not true, either, unless you insist on allocating all 
objects contiguously. And I see absolutely no reason to do that in 
general -- the limitations that it puts on the programmer are unnecessary 
and impossible to see. (Particular cases for particular [usually 
safety-critical] programs are a very different story of course -- but 
safety-critical users are going to put all kinds of restrictions on 
themselves which don't mean that they are a good idea for the rest of us.)

There are a lot of different ways to design a compilation system, and one 
thing we've clearly learned from the ARG is that making any sort of 
assumptions about how "everyone" is going to implement something are almost 
certainly wrong. Language design has to be more general than that (unless 
you are willing to have a sole-source language like Eiffel, and those are 
almost never interesting).

                                                       Randy.

Re: Ada OOP alternatives?

[Robert A Duff]

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

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccy741fg0z.fsf@shell01.TheWorld.com...
>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>
>>> On 17/07/2008 01:05, in article wcc3am9gytt.fsf@shell01.TheWorld.com,
>>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
>>>> I'd still rather eliminate private parts altogether.
>>>
>>> How would you do that while allowing ADT clients to access objects 
>>> directly
>>> (i.e. not via a pointer a la Java)?
>>
>> I'd have the compiler take a peek at the body when compiling the client.
>> After all, that's what Ada compilers already do for pragma Inline.
>
> That's what *some* Ada compilers do. Personally, I think that violates the 
> spirit of Ada (Ichbiah version) by adding unnecessary compilation 
> dependencies. Indeed, I think the whole design of pragma Inline is wrong in 
> Ada.

Not sure what you mean.  In order to inline a call, the compiler has to
look at the body of the callee -- no way around that.  And when the body
of the callee changes, the code at the inlined call site needs to be
changed.  It's certainly annoying when unrelated changes in the
same file where the inlined body lives trigger recompilation of the
world.  And that is avoidable via incremental compilation.

As to the inline violating spirits, Ichbiah presumably designed whatever
"spirit" you mean, and also designed pragma Inline, so are you saying
Ichbiah violated the spirit of Ada?  It's certainly possible...

Anyway, what's your idea about how the design of inline should be?

> ...
>> We're just talking about the size of the type, really -- you say
>> "access objects", but clients can't access the record components
>> of a private type -- all they can do is declare objects and
>> pass them around.
>
> Ugh. That's surely not true, either, unless you insist on allocating all 
> objects contiguously.

I'm confused.  I don't see how allocating noncontiguously contradicts
what I said -- which part were you referring to.

>...And I see absolutely no reason to do that in 
> general -- the limitations that it puts on the programmer are unnecessary 
> and impossible to see. (Particular cases for particular [usually 
> safety-critical] programs are a very different story of course -- but 
> safety-critical users are going to put all kinds of restrictions on 
> themselves which don't mean that they are a good idea for the rest of us.)

I agree with that general point.

> There are a lot of different ways to design a compilation system, and one 
> thing we've clearly learned from the ARG is that making any sort of 
> assumptions about how "everyone" is going to implement something are almost 
> certainly wrong.

Well, I suppose so, but "everyone" has to implement whatever language
they're implementing in a way that is correct.  (E.g. using a one-pass,
bottom-up overload resolution algorithm is just plain wrong, for Ada.)

And it is the responsibility of the language designer to make sure that
there is at least one viable implementation strategy -- not to make sure
that every imaginable implementation strategy is viable.

>... Language design has to be more general than that (unless 
> you are willing to have a sole-source language like Eiffel, and those are 
> almost never interesting).

I think Eiffel has more than one implementation.

- Bob

Re: Ada OOP alternatives?

[Robert A Duff]

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

> I used to review C code that packed almost 80% of executable code in the
> header files... (:-))

What fun!  ;-)

>> I want separate specs and bodies, not for the compiler's benefit, but
>> for the programmer's benefit.  I want to be able to read a concise spec,
>> without having to wade through the entire body.
>
> There are two problems with that. The first one is that the difference is
> not obvious. Why legality check is less than "full compilation", so that
> the delta cannot be left for the binder/linker. The second one is that if
> the delta is sufficient, then the reader should probably become aware of
> it. In short, it is difficult to drive a margin.

I don't understand.  To (e.g.) determine whether a procedure call is
legal, you need to know its name, parameter types, etc.  (Whether "you"
is the human or the compiler.)  To generate code, you need to know more
-- which register to put the parameter in, etc -- and if inlined, what
code is in the body.

>> The compiler should check legality without looking at other bodies.  But
>> it should look at bodies when generating code (at least if optimization
>> is turned on).
>
> But what would you do with dynamically linked libraries, remote partitions
> and other lately bound stuff?

I don't see what that has to do with organization of the source code.
These things are implemented using "extra" levels of indirection at run
time.  E.g. you can't very will inline a call in an executable, and then
expect that updating a shared library used by that executable will
update the call by magic.  So don't inline across such boundaries.

>... I think that the time of monolithic systems
> is gone.

I don't think so.  Certainly some embedded systems are monolithic,
and should be.

- Bob

Re: Ada OOP alternatives?

[Dmitry A. Kazakov]

On Fri, 18 Jul 2008 08:54:54 -0400, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> There are two problems with that. The first one is that the difference is
>> not obvious. Why legality check is less than "full compilation", so that
>> the delta cannot be left for the binder/linker. The second one is that if
>> the delta is sufficient, then the reader should probably become aware of
>> it. In short, it is difficult to drive a margin.
> 
> I don't understand.  To (e.g.) determine whether a procedure call is
> legal, you need to know its name, parameter types, etc.  (Whether "you"
> is the human or the compiler.)  To generate code, you need to know more
> -- which register to put the parameter in, etc

But call convention could be a subject of specification (choosing pragmas
for that was probably a mistake). Register allocation can be postponed (if
the architecture supports renaming) etc. It is not obvious why namely the
body shall determine such things.

> -- and if inlined, what code is in the body.

Inlining should not influence the semantics. Thus if the body is not
available, the client should still be compilable.

>>> The compiler should check legality without looking at other bodies.  But
>>> it should look at bodies when generating code (at least if optimization
>>> is turned on).
>>
>> But what would you do with dynamically linked libraries, remote partitions
>> and other lately bound stuff?
> 
> I don't see what that has to do with organization of the source code.
> These things are implemented using "extra" levels of indirection at run
> time.  E.g. you can't very will inline a call in an executable, and then
> expect that updating a shared library used by that executable will
> update the call by magic.  So don't inline across such boundaries.

I don't want such decisions to propagate into specifications. To me it is
an implementation detail. If an ability to compile without the bodies is
not constant, then something in the specifications shall tell if it is a
pure specification or else that the body will be required. I don't like
this. It would mean mixing interfaces and implementations.

>>... I think that the time of monolithic systems
>> is gone.
> 
> I don't think so.  Certainly some embedded systems are monolithic,
> and should be.

Maybe, though, newer embedded systems have to communicate with other
systems in the outer world. Anyway, Ada is a general purpose language. I
buy some performance loss if it comes to cleaner separation of interface
and implementations. Baked sand is cheap... (:-))

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

Re: Ada OOP alternatives?

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcc63r3pdi7.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
>> news:wccy741fg0z.fsf@shell01.TheWorld.com...
>>> "(see below)" <yaldnif.w@blueyonder.co.uk> writes:
>>>
>>>> On 17/07/2008 01:05, in article wcc3am9gytt.fsf@shell01.TheWorld.com,
>>>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote:
>>>>> I'd still rather eliminate private parts altogether.
>>>>
>>>> How would you do that while allowing ADT clients to access objects
>>>> directly
>>>> (i.e. not via a pointer a la Java)?
>>>
>>> I'd have the compiler take a peek at the body when compiling the client.
>>> After all, that's what Ada compilers already do for pragma Inline.
>>
>> That's what *some* Ada compilers do. Personally, I think that violates 
>> the
>> spirit of Ada (Ichbiah version) by adding unnecessary compilation
>> dependencies. Indeed, I think the whole design of pragma Inline is wrong 
>> in
>> Ada.
>
> Not sure what you mean.  In order to inline a call, the compiler has to
> look at the body of the callee -- no way around that.  And when the body
> of the callee changes, the code at the inlined call site needs to be
> changed.  It's certainly annoying when unrelated changes in the
> same file where the inlined body lives trigger recompilation of the
> world.  And that is avoidable via incremental compilation.
>
> As to the inline violating spirits, Ichbiah presumably designed whatever
> "spirit" you mean, and also designed pragma Inline, so are you saying
> Ichbiah violated the spirit of Ada?  It's certainly possible...
>
> Anyway, what's your idea about how the design of inline should be?

I believe that pragma Inline should either not exist at all (in favor of a 
more general way of specifying optimization parameters), or just be a hint 
to the compiler. It should surely should not have a semantic effect of any 
kind.

And I agree with you about the multiple modes. Indeed, the grand design for 
Janus/Ada is exactly that. The "conventional compilation" mode is for 
getting executables fast (for debugging and development). The "production 
compilation" mode would (it never got built because we didn't have enough 
memory back then) push all optimization and code generation as late as 
possible - at least as late as link-time. (Aside: that's effectively what 
Java does, although Just-in-Time compilation probably is going too far for 
many uses.)

>> ...
>>> We're just talking about the size of the type, really -- you say
>>> "access objects", but clients can't access the record components
>>> of a private type -- all they can do is declare objects and
>>> pass them around.
>>
>> Ugh. That's surely not true, either, unless you insist on allocating all
>> objects contiguously.
>
> I'm confused.  I don't see how allocating noncontiguously contradicts
> what I said -- which part were you referring to.

You need to know a lot more than just the size of the object in order to 
create a non-contiguous object: for instance, you need to know the 
dependences of the subparts on the discriminants in order to allocate memory 
for those subparts. That has to be done before construction, else you won't 
have anywhere to evaluate the constructor expressions.

...
>> There are a lot of different ways to design a compilation system, and one
>> thing we've clearly learned from the ARG is that making any sort of
>> assumptions about how "everyone" is going to implement something are 
>> almost
>> certainly wrong.
>
> Well, I suppose so, but "everyone" has to implement whatever language
> they're implementing in a way that is correct.  (E.g. using a one-pass,
> bottom-up overload resolution algorithm is just plain wrong, for Ada.)
>
> And it is the responsibility of the language designer to make sure that
> there is at least one viable implementation strategy -- not to make sure
> that every imaginable implementation strategy is viable.

Here I think I disagree, at least to a point. A good language (intended to 
have a long life!) allows a broad array of potential implementation 
strategies, because things that seemed like a good idea in 1980 aren't 
today.

To take a specific example. You've been talking about incremental 
compilation. One thing that Pascal always used to harp on is how much that 
depends on not breaking privacy. It would be trivial to define a language so 
that incremental compilation wasn't practical; but it surely would still 
have "one viable implementation strategy".

So I think a good language design has to go beyond "one viable 
implementation strategy" to allow as many as practical. (Of course, there 
better be at least one implementation available, and knowing the existence 
of that is important.)

                                           Randy.

Re: Ada OOP alternatives?

[Adam Beneschan]

On Jul 16, 6:36 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> "(see below)" <yaldni...@blueyonder.co.uk> writes:
> > On 17/07/2008 01:05, in article wcc3am9gytt....@shell01.TheWorld.com,
> > "Robert A Duff" <bobd...@shell01.TheWorld.com> wrote:
> >> I'd still rather eliminate private parts altogether.
>
> > How would you do that while allowing ADT clients to access objects directly
> > (i.e. not via a pointer a la Java)?
>
> I'd have the compiler take a peek at the body when compiling the client.
> After all, that's what Ada compilers already do for pragma Inline.
> And I think incremental compilation can be a big win.

You know, I'm still dreaming of the day when we can get rid of our
current "object file" model of compilation, or whatever it's called,
in which we assume that the compiler is going to compile individual
library units into object code almost completely, so that the process
of building the complete executable from all of its compilation units
(linking) consists mostly of just patching addresses.  This technology
has been around for a long time, but why are we still stuck with it?
It seems to me that it ought to be possible to have a compiler that
compiles individual source files into some sort of "intermediate"
representation that is not quite machine code, and then when the
complete executable is built, the intermediate code is then used to
generate the actual code.  This final process wouldn't be as fast as a
linker that just patches addresses; for a large program, when one
compilation unit changes, the final build would have to reprocess all
of the compilation units that go into the program.  But it seems like
it ought to be possible to design an intermediate representation that
could be converted fairly easily with a minimal amount of processing,
so that given the speed of today's computers (as compared with 1983),
this extra processing wouldn't be much of an issue.  This would make
it possible to dispense with private parts and put all of the
"private" stuff into package bodies.  And if the language rules make
privacy leakage impossible, then all legality errors would still be
caught at "compile" time; there shouldn't be any case where an error
isn't found until "final build".

But I realize that I'm just dreaming...

                              -- Adam

Re: Ada OOP alternatives?

[Ludovic Brenta]

Adam Beneschan writes:
> On Jul 16, 6:36 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>> "(see below)" <yaldni...@blueyonder.co.uk> writes:
>> > On 17/07/2008 01:05, in article wcc3am9gytt....@shell01.TheWorld.com,
>> > "Robert A Duff" <bobd...@shell01.TheWorld.com> wrote:
>> >> I'd still rather eliminate private parts altogether.
>>
>> > How would you do that while allowing ADT clients to access objects directly
>> > (i.e. not via a pointer a la Java)?
>>
>> I'd have the compiler take a peek at the body when compiling the client.
>> After all, that's what Ada compilers already do for pragma Inline.
>> And I think incremental compilation can be a big win.
>
> You know, I'm still dreaming of the day when we can get rid of our
> current "object file" model of compilation, or whatever it's called,
> in which we assume that the compiler is going to compile individual
> library units into object code almost completely, so that the
> process of building the complete executable from all of its
> compilation units (linking) consists mostly of just patching
> addresses.  This technology has been around for a long time, but why
> are we still stuck with it?  It seems to me that it ought to be
> possible to have a compiler that compiles individual source files
> into some sort of "intermediate" representation that is not quite
> machine code, and then when the complete executable is built, the
> intermediate code is then used to generate the actual code.  This
> final process wouldn't be as fast as a linker that just patches
> addresses; for a large program, when one compilation unit changes,
> the final build would have to reprocess all of the compilation units
> that go into the program.  But it seems like it ought to be possible
> to design an intermediate representation that could be converted
> fairly easily with a minimal amount of processing, so that given the
> speed of today's computers (as compared with 1983), this extra
> processing wouldn't be much of an issue.  This would make it
> possible to dispense with private parts and put all of the "private"
> stuff into package bodies.  And if the language rules make privacy
> leakage impossible, then all legality errors would still be caught
> at "compile" time; there shouldn't be any case where an error isn't
> found until "final build".
>
> But I realize that I'm just dreaming...

I'm not so sure you're dreaming.  Isn't this how LLVM works?  And I
think one of the proprietary Ada compilers also works that way with a
somewhat "standard" intermediate representation.

-- 
Ludovic Brenta.

Re: Ada OOP alternatives?

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:c721e61c-464a-4ace-8aa8-7b051794fa7c@y38g2000hsy.googlegroups.com...
...
> It seems to me that it ought to be possible to have a compiler that
> compiles individual source files into some sort of "intermediate"
> representation that is not quite machine code, and then when the
> complete executable is built, the intermediate code is then used to
> generate the actual code.
...
> But I realize that I'm just dreaming...

Why? That's the basic design of Janus/Ada. As I've previously said, we never 
built that version of the back-end because the machines back in the day 
couldn't handle it, and haven't done it more recently simply because there 
isn't enough hours in the day. But that's how inlining should work.

One could argue that this is exactly how Java works, after all. Except there 
they never bother to compile it at all (at least until runtime). Indeed, one 
could make the argument that there isn't anymore need to compile at 
link-time than there is in the current file-at-a-time scheme.

                                           Randy.

Re: Ada OOP alternatives?

[Dmitry A. Kazakov]

On Tue, 22 Jul 2008 13:32:20 -0700 (PDT), Adam Beneschan wrote:

> This would make
> it possible to dispense with private parts and put all of the
> "private" stuff into package bodies.

Hmm, I would consider private declarations rather as a private interface.

It is quite common that things are implemented incrementally, with children
packages encapsulating the increments. In effect a huge "private land"
stretches between pure specifications and pure implementations. It is
difficult to invent something instead. I remember how awkward it was in Ada
83. Removing private interfaces would mean a sort of monolithic all-at-once
design. How are you going to handle that?

In the rest I agree with you. Further, I would like to see a support for a
kind of "non-cooperative model of visibility." By this I mean the linker or
what else would be used instead, to map the private stuff read-only, in the
contexts where only public view is available. I.e. "non-visibility rules"
enforced by memory mapping.

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

Re: Ada OOP alternatives?

[Alex R. Mosteo]

Ludovic Brenta wrote:

> Adam Beneschan writes:
>> On Jul 16, 6:36 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
>> wrote:
>>> "(see below)" <yaldni...@blueyonder.co.uk> writes:
>>> > On 17/07/2008 01:05, in article wcc3am9gytt....@shell01.TheWorld.com,
>>> > "Robert A Duff" <bobd...@shell01.TheWorld.com> wrote:
>>> >> I'd still rather eliminate private parts altogether.
>>>
>>> > How would you do that while allowing ADT clients to access objects
>>> > directly (i.e. not via a pointer a la Java)?
>>>
>>> I'd have the compiler take a peek at the body when compiling the client.
>>> After all, that's what Ada compilers already do for pragma Inline.
>>> And I think incremental compilation can be a big win.
>>
>> You know, I'm still dreaming of the day when we can get rid of our
>> current "object file" model of compilation, or whatever it's called,
>> in which we assume that the compiler is going to compile individual
>> library units into object code almost completely, so that the
>> process of building the complete executable from all of its
>> compilation units (linking) consists mostly of just patching
>> addresses.  This technology has been around for a long time, but why
>> are we still stuck with it?  It seems to me that it ought to be
>> possible to have a compiler that compiles individual source files
>> into some sort of "intermediate" representation that is not quite
>> machine code, and then when the complete executable is built, the
>> intermediate code is then used to generate the actual code.  This
>> final process wouldn't be as fast as a linker that just patches
>> addresses; for a large program, when one compilation unit changes,
>> the final build would have to reprocess all of the compilation units
>> that go into the program.  But it seems like it ought to be possible
>> to design an intermediate representation that could be converted
>> fairly easily with a minimal amount of processing, so that given the
>> speed of today's computers (as compared with 1983), this extra
>> processing wouldn't be much of an issue.  This would make it
>> possible to dispense with private parts and put all of the "private"
>> stuff into package bodies.  And if the language rules make privacy
>> leakage impossible, then all legality errors would still be caught
>> at "compile" time; there shouldn't be any case where an error isn't
>> found until "final build".
>>
>> But I realize that I'm just dreaming...
> 
> I'm not so sure you're dreaming.  Isn't this how LLVM works?  And I
> think one of the proprietary Ada compilers also works that way with a
> somewhat "standard" intermediate representation.

Also, the current trend to do inlining at link time I guess is somehow related
with this.

Re: Ada OOP alternatives?

[Robert A Duff]

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

> On Tue, 22 Jul 2008 13:32:20 -0700 (PDT), Adam Beneschan wrote:
>
>> This would make
>> it possible to dispense with private parts and put all of the
>> "private" stuff into package bodies.
>
> Hmm, I would consider private declarations rather as a private interface.

If what currently goes in the private part were moved to the body, then
child package bodies would need visibility on their parent's body.

- Bob

Re: Ada OOP alternatives?

[stefan-lucks]

On Wed, 23 Jul 2008, Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
> > On Tue, 22 Jul 2008 13:32:20 -0700 (PDT), Adam Beneschan wrote:
> >
> >> This would make
> >> it possible to dispense with private parts and put all of the
> >> "private" stuff into package bodies.
> >
> > Hmm, I would consider private declarations rather as a private interface.
> 
> If what currently goes in the private part were moved to the body, then
> child package bodies would need visibility on their parent's body.

Maybe, that reveals an issue with the way how Ada95 introduced child 
packages? 

In the book, "Ada in Action", 
  <http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/aia/> 
the author criticises the way how Ada95 introduced child packages. The 
issue is that changing the private parts of a package P may break the 
child P.C. In most cases, one may hope that P.C just doesn't compile any 
more. But the risk is always that P.C compiles cleanly and silently does 
something wrong, due to the change of the private parts of P. 

Stefan

-- 
------ Stefan Lucks   --  Bauhaus-University Weimar  --   Germany  ------
               Stefan dot Lucks at uni minus weimar dot de
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Ada OOP alternatives?

[Dmitry A. Kazakov]

On Thu, 24 Jul 2008 12:20:07 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:

>>>> then in 80s, but it is no any problem now. IDEs do it better.
>>> Ada IDEs cannot affect semantics?
>> 
>> I am not sure what you mean... GPS does affect the semantics when you
>> change some project options.
> 
> I meant the semantics of child packages and separate units
> as given in the program text.

I lost your point. Can you elaborate it a bit more?

Just to remember, mine was that separate bodies were often used to
structure the source code in order to make it more maintainable and
readable. IDEs and tools are better suited for that. Another use I can
recollect was stubs [in top-down structured programming]. Unfortunately it
never really worked. Today we are using abstract primitive operations
instead.

>>> But suppose your implementation includes one subprogram,
>>>   procedure A(... : T; ...);
>>> that provides for one aspect of the solution made with T.
>>> If that one aspect depends on packages P3 and P4, but A is the
>>> only supbrogram in your package that depends on P3 or P4,
>>> why create another child just for this one aspect?
>> 
>> Which is exactly the problem. "Just one aspect" is an improper way of
>> problem decomposition.
> 
> Why, e.g., build an entire type when a single procedure
> is sufficient, and will be sufficient in the future?

How can you know that?

> It is possible to think of a procedure (or function etc.) as an
> abstract state machine.

Hmm, it is almost impossible.

Procedures describe transitions between states encapsulated by the
parameters and the results of (only the latter in pure functional
languages).

> Many languages have a function type
> built in, functions are objects.

But not in the sense of a stateful object of OO. They are language objects
(a completely unrelated thing, except that in an OOPL a stateful object is
a language object.).

>> 3. The "aspects" available for "separation" are often low level. Your
>> example nicely illustrates this point. It is a pure low-level procedural
>> decomposition.
> 
> OK but this shows very little. Without a procedure (as in "procedural
> decomposition"), a program does nothing. Should every procedure
> be a primitive operation?

Yep, very much so.

> This question is IMO worth asking
> when the task at hand is not "the general theory of problem
> decomposition using ADTs" but "how to write this specific program".

I was always wondering people saying such things. Yes, you can drive the
wrong side of the road so long there is no police officer watching you.

> There is a trade-off:

Really?

> Another ADT child package could become more
> general but introduces complexity. Artificial complexity as,
> I'm sure, some will say.

Well, well, Ada is complex, C is good. Why do you need that artificial
complexity. Everything is void * etc...

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

Re: Ada OOP alternatives?

[Georg Bauhaus]

Dmitry A. Kazakov wrote:
> On Thu, 24 Jul 2008 12:20:07 +0200, Georg Bauhaus wrote:
> 
>> Dmitry A. Kazakov wrote:
> 
>>>>> then in 80s, but it is no any problem now. IDEs do it better.
>>>> Ada IDEs cannot affect semantics?
>>> I am not sure what you mean... GPS does affect the semantics when you
>>> change some project options.
>> I meant the semantics of child packages and separate units
>> as given in the program text.
> 
> I lost your point. Can you elaborate it a bit more?


package News23 is

   type T is null record;
   procedure Op(Item: T);

end News23;

package body News23 is

   procedure Special_Case(Item : T);
   --  Makes XYZ(Item) known to neighbouring Funnix process Foo

   procedure Op(Item: T) is
   begin
      if True then   -- imagine real life conditional here
         Special_Case(Item);
      end if;
   end Op;

   procedure Special_Case(Item : T) is separate;

end News23;


with Ada.Text_IO;   -- or some Sockets, or ....
with All_Kinds_of_Things_Neccessary; -- for the special case

separate(News23)
procedure Special_Case(Item : T) is
begin
   null;
end Special_Case;

Observation 1:

Suppose you try to use an IDE in place of "separate",
to hide away the details of Special_Case. Then the dependences
on the with'ed package Ada.Text_IO and on All_Kinds_of_Things_Neccessary
will have to be listed for the entire package.
So IDEs cannot help with dependences. You need separate units
or child packages.

Observation 2:

The single Special_Case procedure will serve its purpose
by informing the other (Funnix) side as needed.

Now instead of just the procedure Special_Case, which does
what is needed, I could construct an ADT Special_Process.
This type should, IIUC, reflect a general Special-Case-Communications
idea so
1/ it matches the other side and
2/ is an ADT (reusable?).

package The_Far_Away_Company is

   subtype Code is Natural range 200 .. 599;

   type Message is new C.char_array;
   function To_Special_Message(ID: Code; Message: String);

   type Special_Process is private;
   procedure Send(The_Process: Special_Process;
      The_Message: Message);

end The_Far_Away_Company;

What amount of work is needed to make this reusable?

I'll just pack it into the local part of a very private
single-purpose procedure separated from the others in the body.

Granted, there are cases when a child package seems a
much better choice. For example, when the special communications
procedure needs to maintain state information that is of
no concern to any other subprogram anywhere.


>> Why, e.g., build an entire type when a single procedure
>> is sufficient, and will be sufficient in the future?
> 
> How can you know that?

Sometimes the future of a program is known.  For example,
known to end, because the strange device is no longer produced
and the support has ended.  The special case procedure dies
with the special case device/program.


>> Many languages have a function type
>> built in, functions are objects.
> 
> But not in the sense of a stateful object of OO.

Yes, there are function objects in the sense of a stateful object
of OO. They even have execution in steps, and can refer to relatively
global objects that might be updated during (virtually) stepwise
execution of the function.

Re: Ada OOP alternatives?

[Dmitry A. Kazakov]

On Fri, 25 Jul 2008 10:47:49 +0200, Georg Bauhaus wrote:

[...] 
> Suppose you try to use an IDE in place of "separate",
> to hide away the details of Special_Case. Then the dependences
> on the with'ed package Ada.Text_IO and on All_Kinds_of_Things_Neccessary
> will have to be listed for the entire package.

Yes, but it would not change dependencies. The difference is merely visual,
wth-es appears in the parent body. So what? I never read with clauses. They
are semantically useless, impose a maintenance problem (GNAT does not
always warn about superfluous with's).

Better, there should be a "without" clause/pragma (:-))

> Observation 2:
[...]
> What amount of work is needed to make this reusable?

I cannot tell, because the example is ill-designed in my eyes. IMO, it
should be designed as a [private] child with:

   type Special_T is new T with ...; -- The "special case" is this
   overrides procedure Op (Item : T); -- This is an implementation of

So, yes, an ADT, even if it is a singleton today.

> Granted, there are cases when a child package seems a
> much better choice. For example, when the special communications
> procedure needs to maintain state information that is of
> no concern to any other subprogram anywhere.

Bad, very bad, design. Only objects should have states. Global variables is
a no-no. There cannot be stateful procedures otherwise than impure, with
global variables.

>>> Why, e.g., build an entire type when a single procedure
>>> is sufficient, and will be sufficient in the future?
>> 
>> How can you know that?
> 
> Sometimes the future of a program is known.  For example,
> known to end, because the strange device is no longer produced
> and the support has ended.  The special case procedure dies
> with the special case device/program.

Even if a strange device is no more produced, it is still used by
customers. And customer requirements change. Bad design never pays off.

>>> Many languages have a function type
>>> built in, functions are objects.
>> 
>> But not in the sense of a stateful object of OO.
> 
> Yes, there are function objects in the sense of a stateful object
> of OO.

Hmm, if you mean active objects, like Ada task types, then observe that
they are not procedures. A task type has methods (entry points), which are
procedures.

If you mean a procedural abstraction of some external stateful thing, like
random generator, then it is a bad design. The state should be explicitly
bound to some visible object to which the procedure would be applied.

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

Re: Ada OOP alternatives?

[Georg Bauhaus]

Dmitry A. Kazakov schrieb:
> On Fri, 25 Jul 2008 10:47:49 +0200, Georg Bauhaus wrote:
> 
> [...] 
>> Suppose you try to use an IDE in place of "separate",
>> to hide away the details of Special_Case. Then the dependences
>> on the with'ed package Ada.Text_IO and on All_Kinds_of_Things_Neccessary
>> will have to be listed for the entire package.
> 
> Yes, but it would not change dependencies.

Yes, separate units can change the dependences of a package
body. E.g., in a good many cases, a package body can be compiled
without the separate unit. (It can be compiled without
a child package, too).

When the separate unit depends on a yet-to-be written/delivered
package, the parent body is not affected.  You cannot achieve this
kind of compilation advantage when you put the separate subprogram
into the parent body instead. (Not different from a child.)


> Better, there should be a "without" clause/pragma (:-))

:-)


> So, yes, an ADT, even if it is a singleton today.

For what?  I think that language theorists have ways to
associate a synthetic OO type with a singleton package
without loss.


>  Only objects should have states.

Yes, only objects can have states. I am assuming you mean that every
variable object of a scope other than the scope of an innermost
subprogram is evilly global?


> Global variables is
> a no-no. There cannot be stateful procedures otherwise than impure, with
> global variables.

When the "global" variable cannot be manipulated by
anything besides a visible procedure, this statement
is false.

private
package Parent.Singleton is
    procedure Bump(Item: Some_Type);
end;


I see you disagree with state variables hidden in singleton package
bodies. I claim that passing them around instead has potential for
creating spaghetti. Plus it requires a visible, private type
and a way to enforce only one object.

The weekend is near, I'll go for a walk if you don't mind.


--
Georg Bauhaus
Y A Time Drain  http://www.9toX.de

Re: Ada OOP alternatives?

[Dmitry A. Kazakov]

On Fri, 25 Jul 2008 18:24:26 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov schrieb:

>> So, yes, an ADT, even if it is a singleton today.
> 
> For what?  I think that language theorists have ways to
> associate a synthetic OO type with a singleton package
> without loss.

Sure. But the argument is to the code design. I used to have stateful
packages, it *always* ended quite painfully.

>>  Only objects should have states.
> 
> Yes, only objects can have states. I am assuming you mean that every
> variable object of a scope other than the scope of an innermost
> subprogram is evilly global?

Yes, if mutable.

> I see you disagree with state variables hidden in singleton package
> bodies.

Yep, I don't buy "package = class/object," a totally bogus idea. I am very
glad that Ada 95 didn't go that way.

> The weekend is near, I'll go for a walk if you don't mind.

The summer seems to be arrived. I have thought it will never come...

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

Re: Ada OOP alternatives?

[Jeff Koftinoff]

On Jul 22, 1:32 pm, Adam Beneschan <a...@irvine.com> wrote:
> On Jul 16, 6:36 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
> wrote:
>
> > "(see below)" <yaldni...@blueyonder.co.uk> writes:
> > > On 17/07/2008 01:05, in article wcc3am9gytt....@shell01.TheWorld.com,
> > > "Robert A Duff" <bobd...@shell01.TheWorld.com> wrote:
> > >> I'd still rather eliminate private parts altogether.
>
> > > How would you do that while allowing ADT clients to access objects directly
> > > (i.e. not via a pointer a la Java)?
>
> > I'd have the compiler take a peek at the body when compiling the client.
> > After all, that's what Ada compilers already do for pragma Inline.
> > And I think incremental compilation can be a big win.
>
> You know, I'm still dreaming of the day when we can get rid of our
> current "object file" model of compilation, or whatever it's called,
> in which we assume that the compiler is going to compile individual
> library units into object code almost completely, so that the process
> of building the complete executable from all of its compilation units
> (linking) consists mostly of just patching addresses.  This technology
> has been around for a long time, but why are we still stuck with it?
> It seems to me that it ought to be possible to have a compiler that
> compiles individual source files into some sort of "intermediate"
> representation that is not quite machine code, and then when the
> complete executable is built, the intermediate code is then used to
> generate the actual code.  This final process wouldn't be as fast as a
> linker that just patches addresses; for a large program, when one
> compilation unit changes, the final build would have to reprocess all
> of the compilation units that go into the program.  But it seems like
> it ought to be possible to design an intermediate representation that
> could be converted fairly easily with a minimal amount of processing,
> so that given the speed of today's computers (as compared with 1983),
> this extra processing wouldn't be much of an issue.  This would make
> it possible to dispense with private parts and put all of the
> "private" stuff into package bodies.  And if the language rules make
> privacy leakage impossible, then all legality errors would still be
> caught at "compile" time; there shouldn't be any case where an error
> isn't found until "final build".
>
> But I realize that I'm just dreaming...
>
>                               -- Adam

FWIW, the intel C++ compiler (icc) stores only intermediate meta-code
in object files and library files. All generation of assembly code and
optimizations, including inter-program inline optimizations, occur at
link time!

--jeffk++
www.jdkoftinoff.com