[seek-dev] Re: extending the type system

[Edward A Lee]

Bertram:

Absence of a value (something that I think a "null" for a double
is intended to indicate) is a key property of a model of computation.
I'm not sure that representing it in a data type is a good approach.

In particular, a key property of process networks and dataflow is
that absence is not a well-defined concept.  This is a key way
in which they maintain determinacy.  This is why, when you call
hasToken() on a port in PN, the answer is always "true".

I think there are potentially two better solutions:

1) Use a different MoC that has a concept of absence.
    E.g., DE or SR.

2) Create a new subclass of PN or SDF, where, for example,
    if I send through a port an instance of NullToken,
    then at the far end, hasToken() returns false.

Having hasToken() return false will make it much easier
to re-use existing actors at the receiving end.  You will
still need new actors to send the NullToken, however.
I would look at approach 1, and only after coming up
with a clear understanding of why it isn't the right
solution, pursue approach 2.

Implementing (2) won't be totally trivial, primarily
because of the way types are enforced at run time.
It will probably require some refactoring of the
pertinent code.  But I'm sure it could be done cleanly...

Edward


At 09:49 PM 10/13/2003 -0700, Bertram Ludaescher wrote:

>Steve, Chad:
>
>Here is a related question (I had discussed this earlier today with
>Shawn) on "how to do things properly" in PTII:
>
>The type extension mentioned by Chad, let's call it "ndouble" for
>"nullable double" can (and probably should) be modeled as a
>*supertype* to "double" since its instances are precisely "double U
>null" (all double numbers plus null). The problem with this, however,
>is that any code that works for double (say an actor computing the
>running average of its stream of double values) now won't work for
>"ndouble" since the latter is a supertype of the former.
>If it were the other way round, i.e., ndouble being a subtype of
>double, we could assume that all code still works for the subtype. Of
>course this doesn't work as-is, since the double actors don't really
>know what to do with a null value.
>
>Bottom line (not surprising): for existing actors to work on a new
>type such as ndouble, something needs to be changed to take into
>account the new behavior (for nulls in this case). The question is how
>to best engineer this in general, and in PTII in particular.
>
>Any suggestions most welcome.
>
>It also seems that the following article by Castagna is relevant to
>this discussion:
>         Covariance And Contravariance:conflict Without A Cause (1994)
>         Giuseppe Castagna
>         http://citeseer.nj.nec.com/24009.html
>
>Bertram
>
>
> >>>>> "SAN" == Stephen Andrew Neuendorffer <neuendor at eecs.berkeley.edu> 
> writes:
>SAN>
>SAN> Modifying the type hierarchy in this way is difficult: We haven't yet
>SAN> implemented a good way to make it extensible in this way.
>SAN> Part of the problem is that the type lattice is somewhat hardcoded into
>SAN> operations on the token classes.  Modifying the type hierarchy in
>SAN> significant ways is not currently possible without modifying the 
>existing
>SAN> token classes at the same time.  I have some ideas on improving the
>SAN> situation, but I haven't had time to implement them yet.
>SAN>
>SAN> The one way that the type hierarchy *can* be simply extended is that it
>SAN> allows the addition of new data types that are incomparable with
>SAN> the existing types (other than UNKNOWN and GENERAL, of course).  If you
>SAN> define a new Token class, and a corresponding type class, then this type
>SAN> will be correctly type checked.
>SAN>
>SAN> There are other ways to get the behavior you desire..  One is through an
>SAN> (unimplemented) structured type called "Union" which operates similar
>SAN> Unions in C...  This should be relatively easy to implement, we just
>SAN> haven't gotten around to it.  Your type is then Union(double, event) or
>SAN> something similar.
>SAN> Another way is to use side information (a boolean, for instance) to
>SAN> determin whether or not the "double" is valid.
>SAN> Another way is to use a less constrained Model of Computation (like 
>SR or
>SAN> DE) which has a built-in notion of absent.
>SAN> Any one of these would probably be significantly simpler than 
>modifying the
>SAN> existing double token....
>SAN>
>SAN> Steve
>SAN>
>SAN> At 11:08 AM 10/13/2003 -0700, Chad Berkley wrote:
> >> Hello,
> >>
> >> We have a question about the extensibility of the Ptolemy II type system.
> >> In our project, we need to extend the type system by adding new
> >> data types and modifying the type hierarchy.  As an example, we need to
> >> incorporate a new double type (as a superclass of double) that accepts
> >> null, or missing, values.
> >>
> >> We would like to add new data types without altering the Ptolemy 
> codebase.
> >> It seems the way to do this is by overriding the TypeLattice class (to 
> add
> >> new edges for our new extended types).  We had the impression (e.g., as
> >> discussed in Chapter 12 of the manual) that this extensibility was
> >> possible.  However, it appears that the TypeLattice is hard coded, e.g.,
> >> it is not a parameter to the BaseType class, and instead, a default
> >> instance of TypeLattice is hard coded into BaseType.
> >>
> >> So, the questions are:  Are our ideas using the Ptolemy type system code
> >> in the way in which it was intended?  Are there other ways to extend 
> types
> >> without altering the Ptolemy code?  Do you have any suggestions as to our
> >> approach?
> >>
> >> thanks,
> >> chad
> >>
> >>
> >> --
> >> -----------------------
> >> Chad Berkley
> >> National Center for
> >> Ecological Analysis
> >> and Synthesis (NCEAS)
> >> berkley at nceas.ucsb.edu
> >> -----------------------
> >>
> >>
> >> 
> ----------------------------------------------------------------------------
> >> Posted to the ptolemy-hackers mailing list.  Please send administrative
> >> mail for this list to: ptolemy-hackers-request at ptolemy.eecs.berkeley.edu
>SAN>
>SAN>
>SAN>
>SAN> 
>----------------------------------------------------------------------------
>SAN> Posted to the ptolemy-hackers mailing list.  Please send administrative
>SAN> mail for this list to: ptolemy-hackers-request at ptolemy.eecs.berkeley.edu
>
>----------------------------------------------------------------------------
>Posted to the ptolemy-hackers mailing list.  Please send administrative
>mail for this list to: ptolemy-hackers-request at ptolemy.eecs.berkeley.edu

------------
Edward A. Lee, Professor
518 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0455, fax: 510-642-2739
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal