Syntax... (errata)

[Reinier Zwitserloot]

Sure, there are plenty of syntax concerns, but in most proposals, there's
some sort of unique symbol or keyword used to mark a closure. I vote that we
use 'fn' or '#' and not 'fun', because that looks, frankly, ridiculous to
me. A taste thing I guess. So, consider it just a vote, no more, and no
less.

The problem with:

p(1, 2)

where 'p' is an identifier pointing at a closure, is namespace collisions.
Java has separate namespaces for variables versus method calls, so when the
compiler meets a statement of the form:

identifier '(' paramList[opt] ')'

it doesn't know what to do. There are 3 possible rules, all of which suck
(IMO):

rule #1: If 'identifier' refers to a legal variable name, then attempt to
run 'apply closure' on it. Otherwise, check if there's a method named
'identifier' and run that instead. This will totally break backwards
compatibility, as now variable names shadow method names. Unacceptable.
Letting the compiler check both and generate an error on conflict does not
avoid breaking backwards compatibility.

rule #2: If 'identifier' refers to an existing variable name *whose type is
a closure*, run apply closure on it. Otherwise (so, if the identifier isn't
a variable name in the current lexical scope, or it is, but that variable's
type isn't a closure type), check the method namespace. Technically
backwards/migration compatible, but this would mean that changing the type
of a variable pointing at a closure from the closure type to 'Object' makes
the code do something else and may not even generate an error. Highly
undesirable. This idea might be acceptable if the closure type space is
entirely separate (so, #(int)int would not be a subtype of
java.lang.Object).

rule #3: Like rule #1, except reverse priorities: If there's a method and a
variable both with the same name, and you write 'name(params);', then the
method is run, not the closure. Backwards compatible, but will probably be
rather confusing, and sets a weird precedent: In java, you can usually use
the same name for variables as for methods, except when these variables are
to be used for closures, then you can't.

Apologies if this issue has been raised before on closures-dev, or if
someone has found a solution. If not, I propose we relegate the idea of
applying closures via 'varname '(' params[opt] ')' into the dustbin. Is
writing 'varname.apply/invoke/run(params);' really that much worse?

--Reinier Zwitserloot



On Sun, Nov 22, 2009 at 12:46 PM, <tronicek at fit.cvut.cz> wrote:

> It is not only 'fun' vs. '#'. Compare:
>
> #String(int, double) throws IOException | InterruptedException p;
>
> vs.
>
> fun String p(int, double) throws IOException, InterruptedException;
>
> or
>
> #String p(int, double) throws IOException, InterruptedException;
>
>
> And
>
> p.invoke(42, 3.14);
>
> vs.
>
> p(42, 3.14);
>
>
> Z.
> --
> Zdenek Tronicek
> FIT CTU in Prague
>
>
> Reinier Zwitserloot napsal(a):
> > fun? + a few million to the idea of using 'fn' or # instead.
> >
> > Zdenek, I'm guessing that you find:
> >
> > fun X => {codeblock}
> >
> > readable primarily because you have experience with plenty of other
> > languages. Java users that don't take an interest to closures-dev usually
> > don't have that experience, so any statements about whether something
> > looks
> > 'natural' or 'feels java-like' by any of us is probably not worth all
> that
> > much. We've been tainted by too much knowledge :)
> >
> >  --Reinier Zwitserloot
> >
> > On Sun, Nov 22, 2009 at 10:25 AM, <tronicek at fit.cvut.cz> wrote:
> >
> >> Hi,
> >>
> >> this is very readable for me. In grammar, commas between params are
> >> missing and there is ambiguity:
> >>
> >> fun X => { throw new NullPointerException(); }
> >>
> >> because X can be a name of closure or a return type. But probably this
> >> is
> >> not crucial, because anonymous lambda and named functions will not
> >> appear
> >> on the same place.
> >>
> >> Z.
> >> --
> >> Zdenek Tronicek
> >> FIT CTU in Prague
> >>
> >>
> >> Vladimir Kirichenko napsal(a):
> >>
> >> > a) Anonymous lambda:
> >> >
> >> > EBNF:
> >> >
> >> >       /AnonymousLambda/:
> >> >               fun /TypeSpec/ => /Body/
> >> >       /TypeSpec/:
> >> >               /Type/? /ParamsSpec/? /ThrowsSpec/?
> >> >       /ParamsSpec/:
> >> >               ( /Param/+ )
> >> >       /Param/:
> >> >               /Type/ ID
> >> >       /ThrowsSpec/:
> >> >               throws /ExceptionType/+
> >> >       /Body/:
> >> >               /Expression/ | { /StatementList/ }
> >> >
> >> ...
> >> > b) Named function declaration:
> >> >
> >> > It's very similar to the anonymous lambda except it has identifier,
> >> uses
> >> > assignment operator instead of implication ( => ), and has no param
> >> > identifiers:
> >> >
> >> > EBNF:
> >> >
> >> >       /Function/:
> >> >               fun /TypeSpec/ /Assignment/?
> >> >       /Assignment/:
> >> >               = /AnonymousLambda/
> >> >       /TypeSpec/:
> >> >               /Type/? ID /ParamsSpec/? /ThrowsSpec/?
> >> >       /ParamsSpec/:
> >> >               ( /Type/+ )
> >> >       /ThrowsSpec/:
> >> >               throws /ExceptionType/+
> >> >
> >> ...
> >> > c) Named function declaration aka short form. Difference between c)
> >> and
> >> > b) are IDs in param spec and implication (=>) instead of assignment.
> >> So
> >> > basically it's Anonymous lambda with name:
> >> >
> >> > EBNF:
> >> >
> >> >       /Function/:
> >> >               fun /TypeSpec/ => /Body/
> >> >       /TypeSpec/:
> >> >               /Type/? ID /ParamsSpec/? /ThrowsSpec/?
> >> >       /ParamsSpec/:
> >> >               ( /Param/+ )
> >> >       /Param/:
> >> >               /Type/ ID
> >> >       /ThrowsSpec/:
> >> >               throws /ExceptionType/+
> >> >       /Body/:
> >> >                /Expression/ | { /StatementList/ }
> >> >
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091122/b0e91e53/attachment-0001.html