Re: light weight types
On Sun, 4 Oct 2009, Joshua Cranmer wrote:
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.
I would like to clarify that my suggestion was not entirely serious. I was
merely demonstrating that a skilled programmer can write COBOL in any
language. Although making it compile is another matter.
We might write closures:
foo = def(a, b): return a + b
foo = lambda a, b: return a + b ?
Well:
foo = lambda a, b: a + b
is already legal! I can't remember why everyone thinks we can't extend the
lambda syntax to handle multiple statements. There must be a good reason,
though, right? Right?
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.)
The square brackets are somewhat horrible. Interesting idea to make
capture explicit, though - i don't recall any of the python proposals
proposing that, probably because lambda doesn't at the moment.
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.
Oh yeah, and Gilad Bracha. Both complete troublemakers. I love the idea
that a guy who works on C# and believes java is dying is an influential
force, rather than being burned in effigy.
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.
I don't see why that would be a good idea. Closures and generics are
completely orthogonal, aren't they? So why reuse the syntax? And how would
you write generic closures? For example, Collection<E> needs to able to
take a function mapping E to boolean as a parameter to the removeAll and
retainAll overloads it will surely grow.
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 :-).
I would not only make it not LL(1), it would make it not LL(k) for any k.
It would be LL(n), if that even means anything.
Okay, bring on the hashes!
tom
--
Also, a 'dark future where there is only war!' ... have you seen the
news lately? -- applez