light weight types
in [Java Help]
|
Prev: Putting passwords in a properties file?
Next: Interview
From: Joshua Cranmer on 4 Oct 2009 15:44 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
From: Joshua Cranmer on 4 Oct 2009 16:18 On 10/04/2009 03:44 PM, Joshua Cranmer wrote: > 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. catch(DanglingFootnoteError e) { [1] In my work with JavaScript, I've come to strongly dislike this feature. Since a function is a closure, it keeps its context for all enclosing scopes while the function (say, a listener function) is live. All the local variables of the enclosing scopes are therefore still in scope, and therefore still alive. Now, when you throw in a reference counted system, that means that it is very easy to generate refcount cycles simply because you added a listener. } -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Roedy Green on 4 Oct 2009 17:39 On Sun, 04 Oct 2009 08:35:38 -0400, Jeff Higgins <oohiggins(a)yahoo.com> wrote, quoted or indirectly quoted someone who said : >Cathedral. >Not that the Bazaar if you are puzzled by that reference, see http://mindprod.com/jgloss/cathedral.html -- Roedy Green Canadian Mind Products http://mindprod.com Smart data structures and dumb code works a lot better than the other way around. ~ Eric S. Raymond The Cathedral and the Bazaar
From: Tom Anderson on 4 Oct 2009 18:37 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
From: Lew on 4 Oct 2009 20:31
Tom Anderson wrote: > Well: > > foo = lambda a, b: a + b > is already legal! Not in Java it isn't. > 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? Maybe once Java has such a lambda syntax we could. -- Lew |