Syntax...

[Jakob Praher]

Hi,

thanks for your reply.

Neal Gafter schrieb:
> On Sat, Nov 21, 2009 at 5:21 AM, Jakob Praher <jp at hapra.at 
> <mailto:jp at hapra.at>> wrote:
>
>     File f = new FIle(".");
>     File[] textfiles = f.listFiles( new (File pathname) {
>     pathname.endswith("txt") } );
>
>
> The problem with "new" is that a lambda expression should not require 
> the creation of a new object at each evaluation.  If the lambda 
> captures no state from the enclosing context, the compiler should be 
> free to allocate it statically.
Ok. From this point of view it makes sense. On the other hand there is 
not always a 1:1 correspondance in Java regarding optimizability and 
syntax. E.g. virtual inlining at runtime. From a conceptional point of 
view it is a late bound method, actually it is inlined at runtime. My 
point here was that new is a common concept for creating  almost 
everything in Java, so people are famliar to use it.
>  
>
>     "new" is surely debatable and one could think about omitting
>     it.... Then one could also think about more scala like:
>
>     f.listFiles (File pathanme) {
>          return pathname.endswith("txt") ;
>     }
>
>
> I don't believe that can be retrofitted onto the Java language without 
> syntactic ambiguity.
Hmm. Personally after thinking over it I see some problems regarding 
expressiveness, especially if the existing method names are not changed. 
Here listFiles should then be called filterFilesBy or something similar. 
Syntaxwise I have played with the MethodInvocation 
production/nonterminals. Since the MethodInvocation expression has to be 
followed by a semicolon it could even be differentiated from nested 
blocks following a method call.  But one would maybe have to add a 
semicolon after the RPAR. Yet I have not had time to think about every 
corner case.

    f.listFiles(File p); {int x; ... }

vs .

    f.listFiles(File p) { int x; ... };

>     If the only argument to a method is a closure, one could leave out
>     the parenthesis and it looks much more readable IMHO.
>     Surely this would be a bigger burdon to the compiler, but even
>     with the parenthesis around it would be readable, no?
>
>     f.listFiles( (File pathanme) {
>          return pathname.endswith("txt") ;
>     });
>
>
> Yes, this was what we had back in BGGA version 1.  We'd really like to 
> eliminate the "return" boilerplate.
My point is here that this is something for the Java language to capture 
generally (for all statements/expressions), don't you think?
Why did you change to # for introducing function types and creating 
closures?

For instnace if one translates Ruby code (for selecting over 
collections[1]) to Java:

    int[] result = x.select( (int c) { return c % 2} );

I am not sure if it is really necessary to omit the outer parenthesis:

    int[] result = x.select (int c) {return c % 2 == 0; }

But I think having to write:

    int[] result = x.select( #(int c) c % 2 == 0)

is harder to read. Don't you think?


If one looks at other languages built for closures/blocks/anonymous 
functions, there is also a mixed way of representing it and almost 
always a dichotomy.

AFAIK in Scala:
    afunc {...}
is only allowed if it the parameter of afunc has no formal arguments.

Otherwise one uses:
    afunc (a :T1, b: T2) => { ... }
which is also a kind of strange, yet less since => is here the offiical 
way to represent functions as types. On the other hand it breaks with def.

Since def is used like:
    def myfunc (a: T1, b: T2) {
       ...
    }
not
   def myfunc = (a: T1, b: T2 ) => { ... }
or similar.

Here IMHO scheme/lisp's consistency is desirable:
    (define x (lambda (a b) ...))
is written identically to:
    (afunc (lambda (a b ) ...) )

I propably would stick with POLS (principle of least surprise) for Java.
IF closures are really used heavily I think having to ways of writing 
code rises the burden on the reader of the language.

Thanks
Jakob

[1] http://ruby-doc.org/core/classes/Enumerable.html#M003125