Re: light weight types
On 10/04/2009 03:03 PM, Tom Anderson wrote:
On Sun, 4 Oct 2009, Joshua Cranmer wrote:
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
Introducing new keywords is an issue I didn't discuss, but suffice to
say that it's something that many of the people with a say in the future
of Java want to avoid.
We might write closures:
foo = def(a, b): return a + b
foo = lambda a, b: return a + b ?
foo = LET CLOSURE-DEFINITION BINDING a, b RESOLVE DOWNWARDLY expr {{ a +
b; return }}
The C++0x proposal amounts to something like the following:
auto foo = [](int a, int b) { return a + b; }
(I use the `auto' because I'm not even going to try figuring out what
type that construct is. Also, the first set of brackets is for the
variables the construct will capture.)
But as you point out, the ideal closure syntax in a language is closest
to the native definition of a function. In JavaScript and Python, all
functions are automatically closures [1]. Also, all closures seem to
automatically include all variables in enclosing instances in scope,
which I'm not sure is the best idea.
In any case, the use of { => } for function pointer syntax is completely
and utterly horrid; its use in closures is probably a continuation of
the same syntax for stylistic decisions.
The BGGA examples you quote are correspondingly horrible. What idiot is
responsible for this?
I always associate Neil Gafter with BGGA the most.
Can't we copy C's function pointer syntax, where function pointer types
look like cut-down function definitions?
Using a generics-like syntax might be the most tenable proposition, but
I'm not enthusiastic about what that would look like.
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:
ResultSet(Date, Graphics) d; would require until the `d' to disambiguate
between an attempt at a function call and an attempt at a function
pointer definition. That might make the resulting language something
other than LL(1), but I'm not entirely sure. In any case, it would make
writing a parser for the language interesting :-).
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth