[kepler-dev] Re: type signatures in the expression language

Stephen Andrew Neuendorffer neuendor at eecs.berkeley.edu
Tue Aug 3 16:16:46 PDT 2004

Yes it would..

Unfortunately, implementing this in practice is a little hard, since the 
map() function is discovered through
Java's reflection mechanism which searches for methods with particular 
The 'right' thing to do is to find all of the functions with the name 'map' 
with the correct number of arguments,
and return a function closure that invokes the right Java function based on 
the type of the arguments.
Associated with this function is a type constraint that does the same 
thing, but instead of applying the function,
returns its result type.  This is all rather complex, and in most cases is 
unnecessary, since we 'know' the argument
types beforehand.  So, basically to avoid going through all the above steps 
to do it 'right', we cheat and use the types
of the arguments to reflect only the right map function.  This alone is 
already rather complicated, since
looking up java functions does fancy things like implicitly mapping 
functions over arrays, when possible,
and automatic ptolemy type conversions.

If we wanted to get really fancy, then we could process all of the methods 
at startup and build big lookup tables
for every set of function arguments and every function name, what is the 
right java method to invoke.  Note that
Java and C++ do not do this, since the tables can grow large when you are 
performing method selection based
on all the arguments.  Java and C++ both simply the problem significantly 
by performing virtual method invocation
only using the first argument of a method (corresponding to the object that 
the method is being invoked on).
This can be easily compiled into an array that maps the class number of the 
first argument onto the correct
method to call, called a vtable.


At 04:00 PM 8/3/2004, Tobin Fricke wrote:

> >> f = function(x:int) x + 3
>(function(x:int) (x+3))
> >> f
>(function(x:int) (x+3))
> >> map
>The ID map is undefined.
> >> map(f,{0,2,3})
>{3, 5, 6}
>Instead of this behavior, would it make sense for functions like 'map' to
>evaluate to something?
>kepler-dev mailing list
>kepler-dev at ecoinformatics.org

More information about the Kepler-dev mailing list