[kepler-dev] Re: zero-length arrays

[Bertram Ludaescher]

>>>>> "SAN" == Stephen Andrew Neuendorffer <neuendor at eecs.berkeley.edu> writes:
SAN> 
SAN> The simple answer is that {} would seem to be an empty array and an empty 
SAN> record....
SAN> The expression language didn't support this...

... so therefore the expression language syntax should disambiguate
this, right? Certainly an empty record and an empty array (or empty
list) are (a) perfectly legal and (b) perfectly different data
structures and thus should be identifiable as such lexicographically.
This is "good information" for the type checker and should not be left
unused (how about a new presidental campaign: "leave no nil-literal
behind"!  ;-)

SAN> The more complicated answer is that {} is not an array of int, and its not 
SAN> an array of double, but
SAN> it's an array of an unknown type.  

yes, but that shouldn't be a problem either. For example in Haskell
the function:

length                  :: [a] -> Integer
length []               =  0
length (x:xs)           =  1 + length xs

returns for a given list of elements of type a ("alpha") the list
length as an integer. No need to worry what type [] is. It's of type
list(alpha).

SAN> In the typelattice, this would be 
SAN> represented by the type
SAN> {unknown}.  Currently, this type is not instantiable and if types resolve 
SAN> to this, it is considered a
SAN> type error.  

Why?

SAN> Making it instantiable causes difficulty in the code 
SAN> generator, which often must operate
SAN> in the presence of incomplete type information.

The problem with instantiation is clear: if you have list(alpha) but
don't know what alpha is, the best you can do is have "special values" 
which denote instances of yet unresolved types.

In your syntax, instead of {unknown}, maybe {$alpha} would work!?

SAN>  For about 3 months, we 
SAN> allowed this, but it was
SAN> causing problems so I removed it:

do you recall what the problems were?

SAN> revision 1.49
SAN> date: 2002/04/30 23:33:50;  author: neuendor;  state: Exp;  lines: +22 -25
SAN> removed ability to create empty array tokens.  This was not supported in the
SAN> expression language and was limiting the functionality of the code generator.

it should be part of the expression language I think.
Unless of course there is an insurmountable (or very hard) problem.
But what is it?

SAN> I'm willing to take a look at it again, but I have zero time to invest in 
SAN> this at the moment,
SAN> especially if it causes further problems with the code generator...


the zero time probably still holds!?

;-)

cheers

Bertram


FYI (further reading, not very closely related...)

the following paper presents an interesting technique for
optimizing away (in lazy functional language) some intermediate data
structures; it uses type inference on lists to do so:
http://www.cs.kent.ac.uk/pubs/2000/1900/content.pdf

also the "existential" types (as opposed to the usual universal
polymorphic types used in FP) are quite interesting: 
http://www.cs.kent.ac.uk/research/groups/tcs/pgradTrain/fpCourse/SMK/types.ppt

for a bit of lighter reading on "What is Null" see here:
http://c2.com/cgi/wiki?WhatIsNull



SAN> 
SAN> At 05:30 PM 8/11/2004, Tobin Fricke wrote:
>> I was all set to implement a 'filter' [higher-order] function:
>> 
>> filter = function(p:(function(x:general)(boolean)), list:{general})
>> concatenate( map( function(x:general)(p(x) ? {x} : {}), list))
>> 
>> But it seems that zero-length arrays are explicitly forbidden:
>> 
>> public ArrayToken(Token[] value) throws IllegalActionException {
>> if (value.length == 0) {
>> throw new IllegalActionException("The "
>> + "length of the specified array is zero.");
>> }
>> 
>> Why are zero-length arrays illegal?  Is it because the syntax "{}" is
>> ambiguous, or is there another reason?
>> 
>> Tobin
>> 
>> 
>> ----------------------------------------------------------------------------
>> 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