[seek-dev] [Fwd: Re: extending the type system]

Chad Berkley berkley at nceas.ucsb.edu
Mon Oct 13 13:18:05 PDT 2003


Here is the response from pthackers....not too promising, but I think we 
may be able to modify their code to do what they actually intended to do 
with it in the first place, then submit it back to them and maybe they'd 
add it to the code base.

chad

-------- Original Message --------
Subject: Re: extending the type system
Date: Mon, 13 Oct 2003 12:42:09 -0700
From: "Stephen Andrew Neuendorffer" <neuendor at eecs.berkeley.edu>
To: Chad Berkley <berkley at nceas.ucsb.edu>,	ptolemy-hackers 
<ptolemy-hackers at eecs.berkeley.edu>

Modifying the type hierarchy in this way is difficult: We haven't yet
implemented a good way to make it extensible in this way.
Part of the problem is that the type lattice is somewhat hardcoded into
operations on the token classes.  Modifying the type hierarchy in
significant ways is not currently possible without modifying the existing
token classes at the same time.  I have some ideas on improving the
situation, but I haven't had time to implement them yet.

The one way that the type hierarchy *can* be simply extended is that it
allows the addition of new data types that are incomparable with
the existing types (other than UNKNOWN and GENERAL, of course).  If you
define a new Token class, and a corresponding type class, then this type
will be correctly type checked.

There are other ways to get the behavior you desire..  One is through an
(unimplemented) structured type called "Union" which operates similar
Unions in C...  This should be relatively easy to implement, we just
haven't gotten around to it.  Your type is then Union(double, event) or
something similar.
Another way is to use side information (a boolean, for instance) to
determin whether or not the "double" is valid.
Another way is to use a less constrained Model of Computation (like SR or
DE) which has a built-in notion of absent.
Any one of these would probably be significantly simpler than modifying the
existing double token....

Steve

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



----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: ptolemy-hackers-request at ptolemy.eecs.berkeley.edu

-- 
-----------------------
Chad Berkley
National Center for
Ecological Analysis
and Synthesis (NCEAS)
berkley at nceas.ucsb.edu
-----------------------




More information about the Seek-dev mailing list