Re: light weight types
On Sun, 4 Oct 2009, Joshua Cranmer wrote:
On 10/04/2009 02:06 AM, Kenneth P. Turvey wrote:
On Sat, 03 Oct 2009 17:12:18 -0700, Roedy Green wrote:
[Snip]
Generics lack the elegance of other Java features. The syntax is ad hoc,
unshaved, irregular, Perlish, unfinished.
[Snip]
I find them more useful than you seem to, but your right about the
syntax. It is quite, quite ugly.
What syntax would you use then?
public class TreeMap BINDING GENERIC-TYPE E WHERE E IMPLEMENTS
GENERIC-TYPE Comparable RECURSIVELY BINDING GENERIC-TYPE E implements
SortedMap RECEIVING BINDING GENERIC-TYPE E AS E
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:
One of the main objections to closure proposals in any language (well,
java and python) is that the syntax is dreadful. But in all cases, this is
only because the proposers have for some reason chosen incredibly,
gratuitously, bad syntax. In python, in particular, there's a possible
closure syntax that is an incredibly natural extension of the current
function syntax. So where we write functions:
def foo(a, b): return a + b
We might write closures:
foo = def(a, b): return a + b
But somehow, all the proposals which got any traction were for things
like:
foo = LET CLOSURE-DEFINITION BINDING a, b RESOLVE DOWNWARDLY expr {{ a + b; return }}
Well alright, not quite, but really, they were bad.
The BGGA examples you quote are correspondingly horrible. What idiot is
responsible for this?
Can't we copy C's function pointer syntax, where function pointer types
look like cut-down function definitions?
void() a; // function taking no arguments and returning nothing
int() b; // could be a counter or something
double(double, double) c; // elementary arithmetic operations and the like
ResultSet(Date, Graphics) d; // i dread to think
Is there anywhere where this would be syntactically ambiguous? This is
fine:
public double(double) makeMultiplier(final double k) {
// ...
}
Because if you see a paren after what looks like return type but before a
method name, you know it's a function type.
The literal syntax, used to define closures, is harder. This is natural,
if a little verbose (note that this doesn't preclude the existence of
shorthands for small functions - maybe we could omit the 'return' and the
semicolon in such a case):
return double(double x) {return k * x;};
I can't think of a situation where it's genuinely ambiguous with any
existing syntax, but it might take a lot of lookahead to resolve - you
can't tell it's a function type rather than a function definition until
you hit the {. Plus, it looks a bit too much like an anonymous class
definition that happens to be missing the 'new'. It just feels a bit
shaky.
I'm tempted to steal that # you no longer need for generics syntax and do:
return #double(double x) {return k * x;};
But that's fugly. It would annoy Smalltalkers, though, so that's a plus.
Thinking of Smalltalkers, maybe we should put the parameter list (which is
also a type specification in java) inside the braces:
return {double(double x): return k * x;};
tom
--
The Impossible is True