[kepler-dev] Re: zero-length arrays

Bertram Ludaescher ludaesch at sdsc.edu
Thu Aug 12 04:03:37 PDT 2004

>>>>> "TF" == Tobin Fricke <tobin at splorg.org> writes:
TF> On Wed, 11 Aug 2004, Bertram Ludaescher wrote:
>> But I fear there might be a completely different reason for their
>> special non-handling of empty arrays...
TF> A closer look at the code leads me to believe that it's because the type
TF> of an array is always inferred from the type of its 0th element.

that will obviously break down for empty lists (and it should, because 
an instance of an empty list, *by itself*, does not allow to make any
inference; the type should be of course "list(alpha)" with alpha being 
determined "later" or "as needed"...)

TF> It seems that that could be fixed by storing the type information in an
TF> additional field.

yep. And unless more is known, it would be "alpha" (use of type
variables such as alpha and beta seem preferable over "unknown" since
it allows one to easily express some type constraints)

TF> But that reveals what's wrong with the "{}" syntax for an empty array --
TF> there's no way to infer the type of the array.  tricky!

semi-tricky I'd say ;-)

TF> Still, that seems surmountable.
TF> It looks (from comments in the source) like ArrayTokens are supposed to
TF> have a type that is determined by the least upper bound of their
TF> components, but because the code generator doesn't understand 'least upper
TF> bound', the current implementation of arrays requires that all of the
TF> elements have the same type exactly.  (Otherwise you could have a
TF> heterogeneous array, whose type would be elevated to {general}.)

ouch... is that how Haskell and other Hindley Milner (HM) type systems
would do it? But then again, maybe HM is not the best for the very
flexible needs in a Ptolemy/Kepler like system... not sure..

TF> An empty array created from "{}" could have type "{general}", and an empty
TF> array created from subarray operations, or repeat(0,"foo"), could have
TF> more specific types, and appending something to zero-length array could
TF> have the type recomputed on the resulting array (neglecting the
TF> non-element and its possibly 'general') type... eh?

I think we should at least give HM a chance... 

all of these typing issues are very interesting and get even more so,
as we start adding "semantics"...

another day...


TF> ...
TF> Tobin

More information about the Kepler-dev mailing list