entry_barrier, entry_body & entry_declaration

entry_barrier, entry_body & entry_declaration

[ada_student]

One of the problems in Ada is that the language (incorrectly) requires
that "entry_barrier" be specifyable in an  "entry_body" and NOT
an  "entry_declaration". This is a mistake!

"entry_barrier" logically belongs in the spec.

Any reasons why the designers opted otherwise?

Re: entry_barrier, entry_body & entry_declaration

[Maciej Sobczak]

ada_student@yahoo.com wrote:
> One of the problems in Ada is that the language (incorrectly) requires
> that "entry_barrier" be specifyable in an  "entry_body" and NOT
> an  "entry_declaration". This is a mistake!
> 
> "entry_barrier" logically belongs in the spec.
> 
> Any reasons why the designers opted otherwise?

Entry barrier can refer to the stuff which is not visible in the spec, 
but is visible in the body.


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: entry_barrier, entry_body & entry_declaration

[Georg Bauhaus]

On Thu, 2006-01-19 at 06:17 -0800, ada_student@yahoo.com wrote:
> One of the problems in Ada is that the language (incorrectly) requires
> that "entry_barrier" be specifyable in an  "entry_body" and NOT
> an  "entry_declaration". This is a mistake!
> 
> "entry_barrier" logically belongs in the spec.

Do you mean that, logically, callers should take care
of the barriers? Or should barriers be just like
functions informing about the state of the associated
object?

What if a private variable is used in the barrier,
invisible to clients of a protected object, say?

Will it make sense to write for example

    entry e
      when e'count = 42
    is

where, I think, the Boolean expression is
exposing a view of an implementation detail?

> Any reasons why the designers opted otherwise?

Just guessing from the above, maybe the viewpoint on the subject
(purpose of barriers) differs from yours. (Another guess,
entry barriers and subprogram preconditions are not of the
same kind.)


-- Georg 

Re: entry_barrier, entry_body & entry_declaration

[ada_student]

Sorry I am unable to relate to the phrase "subprogram preconditions".

I can only guess that they refer to favorable conditions surrounding
a procedure call[as in controlling a procedure call by a predicate].

Let us take the producer/consumer example. In this case, the barrier
condition belongs to the spec although the object used to store
the barrier state does not have to. Perhaps this is the reason then
for the design decision. My point is that of logical design.
The actual language rules stem from Ada's source inclusion
model(i.e. separate spec and body).

However, what the designers clearly overlooked is that they need
to allow the programmer to differentiate in the spec between an
entry with a barrier and one without[since we have stated in
the previous paragraph that part of the barrier belongs in
the spec].

Re: entry_barrier, entry_body & entry_declaration

[Martin Krischik]

ada_student@yahoo.com wrote:

> Sorry I am unable to relate to the phrase "subprogram preconditions".

http://en.wikibooks.org/wiki/Computer_programming/Design_by_Contract

> However, what the designers clearly overlooked is that they need
> to allow the programmer to differentiate in the spec between an
> entry with a barrier and one without[since we have stated in
> the previous paragraph that part of the barrier belongs in
> the spec].

Why. - Why would the (human) user of a package need to know?

The compiler knows anyway. Have a look at:

http://en.wikibooks.org/wiki/Ada_Programming/Pragmas/Inline

The Text is not finished yet so the interesting part is missing: The inline
function is also defined in the body - but it can still be inlined into
other packages.

Ada is designed to to be used with a library management system which needs
to supply far more informations then a simple ".o" or ".obj" file could do.
If the compiler need to carry informations about the barrier from one
package to the next then it will do so behind the scenes.

This may come as a suprise - for the the compiler/linker object where never
complete black boxes. An .o/.obj file will allways advertice the entry
points for function, size of the data segment, entry point for the package
initialization. There is no mention if a body has an init code - yet it has
to be called sometime.

So informations hidden in the body are carried outside - on a need to know
basis.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: entry_barrier, entry_body & entry_declaration

[ada_student]

> Why. - Why would the (human) user of a package need to know?

Why declare private entries in the spec?
Why declare private types in the spec?

Re: entry_barrier, entry_body & entry_declaration

[Jeffrey R. Carter]

ada_student@yahoo.com wrote:

> However, what the designers clearly overlooked is that they need
> to allow the programmer to differentiate in the spec between an
> entry with a barrier and one without[since we have stated in
> the previous paragraph that part of the barrier belongs in
> the spec].

Barriers only exist on entries of protected units. All entries of protected 
units must have barriers, so there is no distinction. It's useful for the client 
to know when an entry blocks and what will open it, but that's generally more 
abstract than the actual barrier.

-- 
Jeff Carter
"This school was here before you came,
and it'll be here before you go."
Horse Feathers
48

Re: entry_barrier, entry_body & entry_declaration

[Pascal Obry]

ada_student@yahoo.com a �crit :
> Why declare private entries in the spec?
> Why declare private types in the spec?

I think this was only for efficiency reasons (but could be wrong) when
designed for Ada83. With the full declaration in the spec there is no
need to look into the body. Since Ada 95 the private section is also
used to shared types/objects or routines with the children packages.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: entry_barrier, entry_body & entry_declaration

[Ed Falis]

On Thu, 19 Jan 2006 15:26:54 -0500, Pascal Obry <pascal@obry.net> wrote:

> ada_student@yahoo.com a écrit :
>> Why declare private entries in the spec?
>> Why declare private types in the spec?
>
> I think this was only for efficiency reasons (but could be wrong) when
> designed for Ada83. With the full declaration in the spec there is no
> need to look into the body. Since Ada 95 the private section is also
> used to shared types/objects or routines with the children packages.

My way of thinking about it is that the public part of a spec provides the  
logical interface, and the private part the physical interface needed by  
the compiler to support separate compilation.  Private children add  
another dimension to this by opening up the latter to more access at the  
logical level within their private parts.

- Ed

Re: entry_barrier, entry_body & entry_declaration

[Frank J. Lhota]

ada_student@yahoo.com wrote:
> Why declare private entries in the spec?
> Why declare private types in the spec?

The specification of a compilation unit defines the public interface of 
that unit. This interface must satisfy the needs of two different readers:

1.   the human reader who wishes to understand the public interface; and
2.   the compiler, in order to facilitate separate compilation.

Now for human reader does not need the private type declarations. The 
compiler, however, does need this information for compiling other units 
that depend on this specification.

-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tutor Turtle"

Re: entry_barrier, entry_body & entry_declaration

[Randy Brukardt]

<ada_student@yahoo.com> wrote in message
news:1137694936.037209.266520@g44g2000cwa.googlegroups.com...
...
> However, what the designers clearly overlooked is that they need
> to allow the programmer to differentiate in the spec between an
> entry with a barrier and one without[since we have stated in
> the previous paragraph that part of the barrier belongs in
> the spec].

Not at all. The interesting property to the client is whether or not the
call can block. And that is *clearly* describable in the syntax: either it
can block (use a protected entry) or it can't block (use a protected
procedure).

Also, remember that there are other ways for a protected entry to block:
specifically requeue. Many of my protected objects have entries with a True
barrier; it's the entry body that decides whether or not the call needs to
wait, and then requeues it if it does. Just putting the barrier into the
spec. would only show part of the equation.

Similarly, task entries can block even without a barrier, simply because the
task may not be executing an appropriate accept statement at the time the
entry is called. So all task entries can block, and there is nothing
interesting about that.

To give more information than just block/no block, Ada would need a formal
precondition notation, which would be in the specification. But Ada doesn't
have this for any sort of call, so their lack for entries is hardly unusual
or surprising. Indeed, few programming languages have any serious support
for preconditions (Eiffel is one exception). We looked at remedying this in
Ada 200Y, but the features to do so turned into complex runtime checks --
and that is the opposite direction as most systems are going (more
compile-time checks) -- and thus it wasn't clear that the features were a
real (as opposed to preceived) benefit to the language and community.

So, you have to describe in the comments for the entry the intended use, and
obviously such comments can't be formally checked. But the description of
functions, procedures, and entries is an important part of the specification
of an Ada callable entity -- the language can only go so far.

                                           Randy.

Re: entry_barrier, entry_body & entry_declaration

[Georg Bauhaus]

On Thu, 2006-01-19 at 10:22 -0800, ada_student@yahoo.com wrote:

> I can only guess that they refer to favorable conditions surrounding
> a procedure call[as in controlling a procedure call by a predicate].

Just to make sure I understand correctly, in your view, does
an entry barrier inform an external caller of the entry of when
it is o.K. to call?

> Let us take the producer/consumer example. In this case, the barrier
> condition belongs to the spec although the object used to store
> the barrier state does not have to.

I don't think it's obvious that the barrier must belong to
the spec of producer/consumer as an abstraction, although
it seems natural to think of barring in the producer/consumer
example.

First, read/write can be declared in a package spec,
but the protecting object can well be declared no earlier than
in the package's body. Clients of the package just call
read/write procedures in the package spec. They don't even
have to "know" that there exists a protected object controlling
read/write.

Second, what should the barrier be here, in your view:

generic
   type Item is private;
package p is

   protected Sink is
      entry put(it: in Item);
   end Sink;

end p;


> However, what the designers clearly overlooked is that they need
> to allow the programmer to differentiate in the spec between an
> entry with a barrier and one without[since we have stated in
> the previous paragraph that part of the barrier belongs in
> the spec].

An entry always has a barrier (and a queue), as has already been
mentioned, other callable entities being available for different
purposes (without entry_barrier).
I'd actually venture a guess that the designers have not overlooked
the issue. Given how a barrier works, exposing it will unnecessarily
force implementation details to become visible.

(I have had the same question. But I think
I have learned that entry barriers are actually a part
of an implementation description. Hence they don't belong
in in the specification.)

-- Georg 

Re: entry_barrier, entry_body & entry_declaration

[Georg Bauhaus]

On Thu, 2006-01-19 at 11:58 -0800, ada_student@yahoo.com wrote:
> > Why. - Why would the (human) user of a package need to know?
> 
> Why declare private entries in the spec?
> Why declare private types in the spec?

BTW, a protected object need not have private
variables, yet an entry barrier may refer to
items invisible where the protected object is
declared, for example, body variables.

Re: entry_barrier, entry_body & entry_declaration

[ada_student]

I guess the killer Ada feature that "irons out the creases" is
the facility for "when true" in entry_barrier.

Optimizer is happy, compiler is happy.