[kepler-dev] NIL token

[Tristan King]

Ok this is a bit of a rant, and since i probably don't know even 5% of 
the internal workings of ptolemy/kepler i may be misguided in a lot of 
this rant so please correct me anywhere i need correction :).

Maybe we need to take a step back and look at what a Token actually is, 
and what we're actually trying to achieve from a nil token. From the 
javadoc in the Token class a Token is simply a container for standard 
java objects and native types.

So, What are we trying to achieve with a nil token? There must be a very 
good rationale to why we need such a mechanism, but i can't for the life 
of me figure out what it is. Are we trying to signify the lack of a 
variable, or a variable that has a null value?

If we are talking about the lack of a variable, i.e an empty container 
then for one, I think nil is the wrong syntax for this.

Now, should an empty container be allowed? Sure. But only for use as a 
trigger (i.e. the EventToken). I don't think it should be used to 
signify the lack of a value which may or may not exist.

If we are trying to say the value in the container is null. It just 
doesn't make sense.

If we look at the native types like ints doubles booleans etc, they 
cannot be null. They either exist, or they don't. So if the expression 
"int i = null;" is invalid in java, how can we say "IntToken i = 
Token.NIL;" (or IntToken.NIL)? I think forcing a specific condition to 
be handled as null can limit the programmer. Especially if they need to 
use the value Integer.MAX_VALUE and not have other actors view it as null.

So what about Objects that can be assigned to null?

What's wrong with something like:
Object o = null;
ObjectToken ot = new ObjectToken(o);

or
Object[] o = null;
ArrayToken at = new ArrayToken(o);

Sure, the null values stored in the Tokens may cause exceptions, but i 
think those exceptions should be handled by the programmer rather than 
avoided. I don't see why the container itself needs to know anything 
about the object it contains (except for the type).

I feel the current direction is moving more away from the Tokens being 
transport containers to actually being the variables themselves.

For example the StringToken container converts Strings which are null to 
  Strings which have a value "". This doesn't fit with the definition of 
a container. It's not just transporting the objects, it's manipulating 
them as well. There is a very distinct difference between a String set 
to null and "", this conversion adds ambiguity to the String object.

Another example is the ArrayToken container. When the Token is thought 
of as just being a container for arrays it makes no sense that empty 
arrays cannot be contained inside. Any array that is valid in java 
should be containable inside the token.

As with my problem, I'm not trying to alert the other actors of the lack 
of a token, I want to send them an array that has no values. In java 
there is a distinct difference between: "Object[] o = null;" and 
"Object[] o = Object[0];". The ArrayToken container should just 
transport my array object and not be concerned about how long it is etc.

What about the type of the array? maybe it should be specified by the 
programmer (the same way that ports have to be set), rather than being 
interpreted from the elements in the array, and have the base class as 
BaseType.OBJECT incase no type is specifically assigned. i've not put a 
lot of thought into this just yet, i'm sure i'll be doing a lot over the 
weekend :)

In conclusion, 1. Scrap the nil token idea, and think more of how you 
would represent the missing values in a normal java program, and how you 
could contain that representation in a Token. And 2. the ArrayToken (and 
possibly some of the other tokens) need to be reworked so they act more 
like containers.

Anyone else have any thoughts (anything to add, or critisisms) about the 
things i've brought up?

--Tristan

Edward A. Lee wrote:
> At 11:53 PM 3/29/2006, Christopher Brooks wrote:
>> I just checked in some changes so that some of the Tokens have their 
>> own NIL
>> token. Token.NIL, DoubleToken.NIL, IntToken.NIL, LongToken.NIL and all
>> of these NILs are of a new type, "NilType".  NilType is losslessly
>> convertible to (from?) DoubleType, IntType, LongType etc.
>>
>> I think we need these Token specific NILs so that the convert()
>> method will work.
> 
> This looks like the right solution to me...
> 
> An awkwardness is that every token class has to have a NIL
> and an appropriate convert method, but this awkwardness is
> only visible to token class developers.
> 
> I think that having an empty array be ArrayToken.NIL
> might be a very good solution too... We could then augment
> the expression language so that the string "{}" returns
> an instance of this.  It's element type is NilType.
> Since this is losslessly convertible to every type
> (including ArrayToken, by the way), then I think it should
> just work!
> 
> Amazing...  There may be a type system paper in this...
> 
> Edward
> 
> 
> 
> ------------
> Edward A. Lee
> Professor, Chair of the EE Division, Associate Chair of EECS
> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720
> phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal 
> 

-- 
Tristan King                            | Ph: (07) 4781 6911
DART project team                       | Email: Tristan.King at jcu.edu.au
James Cook University                   | Web: http://dart.edu.au
Townsville QLD 4814                     | http://plone.jcu.edu.au/dart/
Australia                               |