Re: [sv-ec] Questions on Arturo's class scheduling/extension approach

From: Arturo Salz <Arturo.Salz_at_.....>
Date: Wed Apr 27 2005 - 19:21:08 PDT
Gord,

I really would like to understand what user requirements are
 driving this complexity. Until we all understand why such
constructs are needed in a concrete form, comparison in the 
abstract will be meaningless. I can give you my best guess as
to how this might work, but you do realize that we are now
treading in the dangerous area of design-by-committee. Neither 
one of us (surely not me) has a working prototype nor anything 
that even remotely resembles actual user experience with these 
types of constructs. So devoid of any requirements, here is my
best guess as to how these constructs should behave:

  1) is there any correspondence to our "schedulefree" class?

There are two class forms that fit the description. A class that
is truly pure, that is, it contains no (blocking) tasks, and no side 
effects outside the class. Such a class is truly schedule free and
should exhibit no restrictions. The second class, is the proposed
parameterized class, that is, a class that has no pre-defined 
scheduling behavior. The scheduling of such parameterized classes 
is determined by their instantiation (in the same manner as any
other parameterized class). Once the class scheduling has been 
determined it can no longer be changed.
    
   2) under what conditions (if any) is one required to
      use the parametric form?  When (if ever) would it
      be an error?

The parametric form is useful for declaring a class with blocking
semantics once, and used in multiple contexts. Each such parameterized 
class would exhibit different scheduling behavior and would be subject 
to a different set of semantic restrictions. It would be an error to attempt 
to change via the parameter the behavior of a class whose scheduling 
semantics have already been fixed.

   3) what restrictions (if any) exist in terms of extension
      prior to and/or after defining the parametric binding?
      Some simple rules (similar to the three we proposed)
      would be useful.

It should permissible to use the parametric extension of any 
"schedulefree" class (as defined in item 1). The context binding 
can be left up to the next extension or fixed at any particular
extension. Once fixed, the context cannot be changed. If this
process results in a class with potentially mixed scheduling
semantics, it shall be an error.

   4) What is the relationship between predefined class
      types such as mailbox (C.2) and a context parametric
      class?

No relationship. A mailbox is a built-in class that exhibits some
properties that user-defined classes cannot easily replicate:
1) The built-in class can be instantiated with no specific type.
2) A mailbox instantiated with no type parameter has the ability 
    to perform run-time type checking
The mailbox class can be used freely in either a program or a
module/interface context. BTW, the mailbox is no different than
a user-defined class in a package (in the Active domain), but, as 
any other such classes, programs have access to them.

   5) Are there any restrictions regarding containment
      relationships?  How are those restrictions expressed?

There are no containment restrictions, other than the existing
visibility rules.

   6) It seems that any reusable class would have to be
      defined in a parametric manner.  

No. Only classes that exhibit blocking behavior that need to be
used in both an Active and a Reactive context would need to
be parameterized in this manner. I believe there are very few
classes (if any) that satisfy this criteria.

     Since, I believe,
      parametric types become instantiated types when
      passed through a type parameter, is there any
      mechanism for having something equivalent to a
      schedulefree class propagate through a module
      hierarchy?

I don't understand why such a complex mechanism is useful
or even desirable, but if this is necessary then users can stick
with a pure class (as defined in point 1) or parameterize the class 
at the top of the hierarchy: Since programs do not have structural 
hierarchy, a hierarchy implies strictly a module hierarchy. However, 
I stress once again that I have no user model on which to base these 
decisions.

    Arturo

----- Original Message ----- 
From: "Gordon Vreugdenhil" <gordonv@Model.com>
To: "SV_EC List" <sv-ec@eda.org>
Sent: Wednesday, April 27, 2005 9:55 AM
Subject: [sv-ec] Questions on Arturo's class scheduling/extension approach


Arturo,

In terms of your basic idea for using parameterization
in conjunction with classes, I would like to specifically
list some of the questions that I raised during the
face-to-face.  I think that we need to have some direct
comparison of the nature of the rules that result from
our suggestion versus your suggestion and your desire to
have stronger enforcement of program versus design.

Specifically:
   1) is there any correspondence to our "schedulefree" class?
   2) under what conditions (if any) is one required to
      use the parametric form?  When (if ever) would it
      be an error?
   3) what restrictions (if any) exist in terms of extension
      prior to and/or after defining the parametric binding?
      Some simple rules (similar to the three we proposed)
      would be useful.
   4) What is the relationship between predefined class
      types such as mailbox (C.2) and a context parametric
      class?
   5) Are there any restrictions regarding containment
      relationships?  How are those restrictions expressed?
   6) It seems that any reusable class would have to be
      defined in a parametric manner.  Since, I believe,
      parametric types become instantiated types when
      passed through a type parameter, is there any
      mechanism for having something equivalent to a
      schedulefree class propagate through a module
      hierarchy?

Once we see more details we can get a better idea if
this would be a feasible and clean approach.


Gord

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil,  Staff Engineer               503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
Received on Wed Apr 27 19:21:14 2005

This archive was generated by hypermail 2.1.8 : Wed Apr 27 2005 - 19:21:46 PDT