Function types versus arrays

[Howard Lovatt]

Hi Neal,

On 16 February 2010 09:48, Neal Gafter <neal at gafter.com> wrote:
> On Mon, Feb 15, 2010 at 1:57 PM, Howard Lovatt <howard.lovatt at iee.org> wrote:
>> Neal Gafter gave an array example on his blog:
>>
>> http://gafter.blogspot.com/
>>
>> Using:
>>
>> http://www.artima.com/weblogs/viewpost.jsp?thread=278567
>>
>> It is translated to:
>
> That's just not true.  Your post does not give any hint as to how
> throw clauses or exceptions in function types are to affect the
> translation.  The word "throws" doesn't even appear anywhere in your
> post at all.

The post notes in the ToDo section that checked exceptions could be
added (last point section 2.3). The reason for not detailing how was
twofold:

1. Checked exceptions weren't in the original stawman, hence not in my
proposal (which was based on the strawman).
2. As I am certain you will appreciate, you really want generics to be
extended to allow a vararg like systax for checked exceptions and that
the vararg list of exceptions could potentially be empty.

I will outline below how the scheme might be extended, but first as an
aside to comment that: you seem to equate an incomplete specification,
in this case of checked exceptions noted as potentially incomplete, as
a fundamental flaw. To me an incomplete specification does not mean it
is flawed, it means it's incomplete.

> But I'm glad to see that you're now considering some of
> the areas where your specification was completely lacking before.
>
> How would your translation scheme handle the code below?  Your post
> contains not a single hint.

As mentioned above I would need extensions to generics, but then so
would all schemes. For the moment lets assume that generics were
extended so that you could have a vararg type construct e.g.:

interface _Callable_0<R, throws E> { R call() throws E; } // E is a,
potentially empty, set of Throwables

(The above is an extension of section 4.1.) The set of Throwables, E,
needs a total ordering (I haven't thought through a suitable sorting
technique - I will *assume* that a total ordering is possible and also
*assume* that a set like data structure is suitable).

The hierarchy of your Exceptions are:

Throwable -> Exception -> IOException -> ChangedCharSetException
Throwable -> Exception -> IOException -> UnknownHostException
Throwable -> Exception -> SAXException -> SAXParseException
Throwable -> Exception -> AWTException

*Assuming* that a suitable total ordering is depth from Object
followed by alphanumerical sorting, then the total ordering for these
exceptions is:

Throwable, Exception, AWTException, IOException, SAXException,
ChangedCharSetException, SAXParseException, UnkownHostException

Using this ordering the type:

#void()(throws ChangedCharSetException, UnknownHostException,
> SAXParseException)

is _Callable_void_throws_ChangedCharSetException_SAXParseException_UnkownHostException
(extension of section 5.2.1), which is in turn:

abstract class _Callable_void_throws_ChangedCharSetException_SAXParseException_UnkownHostException
implements _Callable_0<Void, throws ChangedCharSetException,
SAXParseException, UnkownHostException> {
  public Void call() throws ChangedCharSetException,
SAXParseException, UnkownHostException {
    callPrimitive();
    return null;
  }
  public abstract void callPrimitive() throws ChangedCharSetException,
SAXParseException, UnkownHostException;
}

This is an extension of section 4.2.2 and:

#void()(throws ChangedCharSetException, UnknownHostException)

is _Callable_void_throws_ChangedCharSetException_UnkownHostException which is:

abstract class _Callable_void_throws_ChangedCharSetException_UnkownHostException
implements _Callable_0<Void, throws ChangedCharSetException,
UnkownHostException> {
  public Void call() throws ChangedCharSetException, UnkownHostException {
    callPrimitive();
    return null;
  }
  public abstract void callPrimitive() throws ChangedCharSetException,
UnkownHostException;
}

and:

#void()(throws IOException, AWTException, SAXException)

is _Callable_void_throws_AWTException_IOException_SAXException (note
ordering), which is:

abstract class _Callable_void_throws_AWTException_IOException_SAXException
implements _Callable_0<Void, throws AWTException, IOException, SAXException> {
  public Void call() throws AWTException, IOException, SAXException {
    callPrimitive();
    return null;
  }
  public abstract void callPrimitive() throws AWTException,
IOException, SAXException;
}

Then:

>   #void()(throws ChangedCharSetException, UnknownHostException,
> SAXParseException)[] array1 =
>      new #void()(throws ChangedCharSetException, UnknownHostException)[1];

Becomes:

_Callable_void_throws_ChangedCharSetException_SAXParseException_UnkownHostException[]
array1 =
_Array_From_void_throws_ChangedCharSetException_UnkownHostException__To_void_throws_ChangedCharSetException_SAXParseException_UnkownHostException.instance(
new _Callable_void_throws_ChangedCharSetException_UnkownHostException[1]
);

(the above translation is an extension of sections 5.2.2, 5.4, and 4.4) and:

>   #void()(throws IOException, AWTException, SAXException)[] array2 = array1;

becomes:

_Callable_void_throws_AWTException_IOException_SAXException[] array2 =
_Array_From_void_throws_ChangedCharSetException_SAXParseException_UnkownHostException__To_void_throws_AWTException_IOException_SAXException.instance(
array1 );

Therefore I think the technique, suitably extended for checked
exceptions, will work as expected for the example.

Cheers,

 -- Howard.
>
> Cheers,
> Neal
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
  -- Howard.