Re: [sv-ec] Class extension and scheduling (Issue 240)

Neil Korpusik wrote:
> Some comments on Gordon's writeup.
> 
> Issue 1.
> Proposal 1
> 
>   The end of Section 17.2 says
> 
>      "Type and data declarations within the program are local to the program
>      scope and have static lifetime."


It isn't clear to me what the intent is of this sentence.

The first interpretation is that all types used by a program must be
declared in a program.  This seems far too restrictive -- everyone,
including Arturo, has been assuming that use of package types is valid.

The second interpretation is that a type in a program can't "escape"
from the program.  Since programs can't instantiate modules and hierarchical
type references aren't legal, this seems to be a given.

So, I don't quite know what to do with this.  I'm assuming that this is
a redundant sentence and that the second interpretation is correct.


>      "References to program variables from outside any program block shall be
>      an error."


We are not proposing any change to this.


>      This proposal appears to change the first of these two restrictions.
>      I'm assuming that you are not proposing to change the second restriction.
> 
>   If I understood your description, this proposal implies:
> 
>       A class handle may be declared within the design, a program or a package
>       with no restrictions on where the corresponding class has been
>       declared (program, design, package). The scheduling semantics of method
>       calls shall be based solely on the location of the thread making the call.
>       Neither the location of the class declaration nor the location of the
>       handle declaration shall have any effect on the scheduling semantics of
>       method calls.
> 
>       When a class handle is declared within a program it may only be accessed
>       from within a program block.


Your understanding is consistent with our intent.


>   I don't understand why you use the phrase "Any task re-activations following
>   a suspension". I assume we are discussing all method calls.


This was really a side comment.

One of the claims that have been heard is that one can tell from the
context of the declaration of a routine which region its code will
run in.  The task comment was just to note that even without making
code contingent on the thread, there are still cases where uncertainty
exists.



One the the nice things about Proposal I is that we don't end up with
any arguments about "mixed regions" of types.  In the context of the
restricted class inheritance that Arturo is proposing to resolve the
region conflicts, Proposal I ends up with class methods behaving in
the same manner.  Rather than restricting extension and type use
to deal with conflicts, we avoid the issue by decoupling the type
from the scheduling.  I think that it is more natural to think
about the scheduling being based on the thread than the declarative
context of the declaration in any case.

Gord

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil,  Staff Engineer               503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com