Re: light weight types

On 10/04/2009 02:06 AM, Kenneth P. Turvey wrote:


What syntax would you use then?
If you go for something that distinguishes between left and right
delimiters, you have just four choices: (), [], {}, and <> [1]. {}
denotes a block, so it is entirely the wrong thing to use IMHO. ()
denotes either overriding precedence, a type conversion, or a method
call, and I think it is already more than overloaded.

If you perhaps want only one token to separate the generics parameter
from the rest, you have many more choices. `:', `;', `,', and `.' are
untenable for what I hope are obvious reasons. `%', `^', `&', `*', `|',
`/', `+', `-', and `=' are all binary operator tokens, which means using
them as a delimiter in identifiers is again problematic (think name
lookup). `~', `!', `?' are unary (or ternary, in the last case)
operators, which eases on the problems of using them as a delimiter
token (id <TOK> id is unambiguously the generics invocation), but
reusing them would be awkward. That leaves us with `@', `#', and ``' and
`\' as possible tokens for unary style (`$' and `_' are both valid in
identifier names).

We can therefore reduce the syntax into one of six possible styles:
List[Integer]
List<Integer>
List@Integer
List#Integer
List`Integer
List\Integer

The last one has a `\u' problem (it's translated before tokens are
read), so that is pretty much out of the question. Using ``' is
aesthetically horrendous, if you ask me. Annotations used `@' first;
besides, Integer@List looks more meaningful anyways (nothing stops one
from using it in that format anyways).

What List[Integer] has going for it is that the array syntax fits closer
into a notation of what a generics type generally does: it's a container
of some object. On the other hand, it looks like an array access, which
means that the parser would look rather interesting.

On the other hand, List#Integer is perhaps the second most appealing of
possible unary-style formats (following List$Integer, but that's a valid
identifier already!). The pound sign is unused as a token in Java, which
means the syntax is wholly unambiguous. Unary tokens have the notable
drawback that nested and/or multiple types are hard to write (should
A#B#C be A<B, C> or A<B<C>>? or do you do A#B, C?). You can get around
this by requiring the end token (e.g., List#Integer#), but then the
appeal of the single unary token rapidly vanishes.

In the end, the only one that ends up being rather possible is
List<Integer>. If you drop the objection to curly braces delimiting
blocks, List{Integer} also looks somewhat visually appealing, but I
think that so severely overloading the { is out of the question IMHO.

FWIW, if you think the generics syntax is bad, look at the BGGA closures
proposal. IMO, the single worst part about function pointers is that
there is no easy way to write them. Examples:

static { => int } answer = { => 42 };
{ int => String } toBinary = { int x => Integer.toBinaryString(x) };
{ String => int } parseInt = Integer#parseInt(String);
{ Box => int } getX = Box#getX();
{ String => Set<String> } singleton =
   Collections#<String>singleton(String);
static for void eachEntry(int[] values, { int ==> void } block) {
   for (int p : values) {
     block.invoke(p);
   }
} [2]

And, at one point (I think this part was backed out though), the
statement `return 42' meant something completely different from the
similar `return 42;'. Yowsers.

[1] In principle, you could also include \/ or perhaps /\ in this list,
but I'm just going to toss that possibility out from the get-go on the
basis that \u causes magic to happen before even the tokenization step,
so including that as part of an identifier is not recommended.

[2] I noticed as I was getting examples that some closures seemed to use
=> and others ==>. I think over the course of development, the closures
construct was changed to use ==> instead of =>, while the type
definition for function pointers remained =>.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth