C++11 lambdas
Reinier Zwitserloot
reinier at zwitserloot.com
Mon Mar 15 13:33:15 PDT 2010
Once you add enough delimiters to eliminate all ambiguity in this syntax,
Remi, you'll arrive pretty much at the closure proposal that's the status
quo right now.
For example, your syntax cannot differentiate between multiple exceptions
and a listing of types:
void(int() throws Exception1, Exception2)
Is this:
A) a function type that returns nothing and takes 1 parameter: int() throws
Exception1, Exception2
B) a function type that returns nothing and takes 2 parameters: int() throws
Exception1, as well as parameter of type Exception2?
Second example:
int();
Is this:
A) A syntax error: A function type representing a return type of int with no
arguments, by itself and thus invalid?
B) A syntax error: The invocation of a method named 'int', which is not
valid because 'int' is a reserved keyword?
What error should the compiler generate? Can you tell what was intended?
Vague error messages or error messages that don't do a good job of
explaining what you did wrong is something that java doesn't have that much
trouble with compared to for example Scala. It's a significant cost to bear
if this means the compiler starts generating confusing, vacuous, or
downright wrong error messages.
I wrote down a few more examples, and anytime I made even a single change to
some syntax, the meaning became _completely_ different. A far too heavy
price, in my opinion. I actually like the # as a clear visual signal that
there's a closure definition around.
--Reinier Zwitserloot
On Sun, Mar 14, 2010 at 5:14 PM, Rémi Forax <forax at univ-mlv.fr> wrote:
> Le 14/03/2010 15:31, Neal Gafter a écrit :
> > On Sun, Mar 14, 2010 at 5:21 AM, Stephen Colebourne<scolebourne at joda.org
> >wrote:
> >
> >
> >> - no function types
> >>
> >>
> > Correction: C++ has had function types all along. so it hasn't been
> > necessary to add them. They are invariant.
> >
> >
>
> Yes, seeing that I wonder if we are not going in the wrong direction by
> trying
> to protect lambda and function type by a # or some enclosing parens.
>
> Why not trying something simpler ?
>
>
> A function that takes an int and returns an int:
> int(int)
>
> A function that takes an int and returns nothing:
> void(int)
>
> A function that takes two ints and returns an int:
> int(int, int)
>
> A function that throws an Exception:
> int(int) throws Exception
>
> A function that takes a function that throws an Exception:
> int(int(int) throws Exception)
>
> A function that throws an Exception and takes a function
> int(int(int)) throws Exception
>
> A function that takes an int and returns a function that returns an int
> int() (int)
>
> curry!
> R() throws E (R(A) throws E, A) curry = ...
>
> Grammar:
> ResultType ( TypeList ) throws ExceptionList
>
>
> And removing the # in the lambda syntax:
>
> int(int) fun = (int x) (x); // lambda expression
> int(int) fun = (int x) { return x; }; // lambda block
>
> A method that returns a lambda:
> int(int,int) plus() {
> return (int x, int y) (x+y);
> }
>
> A method that takes two function types and returns a lambda:
> int(int,int) filter(int(int) filter, int(int,int) operation) {
> return (int x, int y) {
> return operation.(filter.(x), filter.(y));
> };
> }
>
>
> Rémi
>
>
More information about the lambda-dev
mailing list