Type inference keyword for lambda parameters

[ghost]

Currently, the following is allowed:

function print(String string(Integer integer), Integer times) => // ...

print(function(i) => i.string, 12);

I think that instead it should be:

print(function(value i) => i.string, 12);

And also:

void foo(Bar bar(Baz baz())) => noop();

foo(function(function baz()) => nothing);

This would allow us to annotate a parameter and simultaneously have its type inferred, which is impossible today as far as I know, besides being more regular...

[gavinking]

@Zambonifofex do you have any usecases for annotating a parameter of an anonymous function?

[ghost]

@gavinking well, you can annotate it variable to be able to set it... And I suppose for documentation purposes... I think documentation is the only reason to actually allowing people to create their own annotations, is it not?

[gavinking]

Well a variable parameter is already pretty weird and I've never needed that in an anonymous function.

As for ceylondoc annotations I don't think they belong on the parameters of an anonymous function at all because (1) they would be ignored by ceylondoc (there is no doc generated for an anon function) and (2) adding doc strings and annotations in the middle of an expression seems just a bit awful.

There are lots of other uses for annotations, but they're uses that only really apply to APIs, not to anonymous functions which are fundamentally internal implementation details of a body of something.

So I guess I just don't see this.

[ghost]

No, I mean documentate it for people reading the source code. For example: Someone might make a ignored annotation for arguments that are ignored, and use it, so people don't get confused wondering "What about this parameter? Did they just forget to use it?"... I wasn't thinking about the doc annotation - I would also very much prefer to use comments to documentate the behavior of a lambda if needed, rather than to awkwardly fit a string in there... Either way, my main point is that it's more regular, at least in my opinion, to use a keyword to represent type inference, similar to how it's done with values/functions.

You don't do:

foo = bar;

Instead, you do:

value foo = bar;

Similarly, you don't do:

foo(function(bar) => baz));

Instead, you do:

foo(function(value bar) => baz));

[gavinking]

No, I mean documentate it for people reading the source code.

Well that's what comments are for, no? :)

Annotations are for tools and frameworks.

[gavinking]

Either way, my main point is that it's more regular,

Ah I see. But:

foo(function(bar) => baz));

is a shortcut for:

foo(function(bar){ Bar bar; return baz; });

It's already regular :-)

[ghost]

Sure, but in my opinion, it's better to be explicit about the fact that you are declaring a new thing... At least allowing people to use a keyword can't be a bad thing, can it? :-P As well as allowing them to use the keyword if it's declared in the function body:

foo(function(bar) { value bar; return baz; });

I don't know... I just don't like seeing bar sitting there by itself, representing a whole declaration... xP

[luolong]

The way I see this, it adding this little extra bit of explicit annotation is certainly more regular but that regularity does not buy us anything that would warrant the cost of more verbosity.

Ceylon has so far managed to strike a pretty good balance between verbose keyword heavy declarative syntax and concise expressive code.

I would argue that adding more verbose syntax to anonymous functions would tip that balance to the point where using anonymous functions becomes almost as verbose as declaring those functions on the top level explicitly and using function references explicitly. This is undesirable in my mind, as this will encourage wrong style of programming -- the code that makes sense only in the context of an anonymous function call site, will be divorced of it's context.

I'd say, the anonymous function syntax in Ceylon is really just as light weight as it needs to be and no lighter than it has to be.

[ghost]

I agree, but as I said,

At least allowing people to use a keyword can't be a bad thing, can it? :-P

Not forcing, but allowing. Similar to for loops. Currently, all the following are valid:

for(Character character in "Hello")
{}

for(character in "Hello")
{}

for(value character in "Hello")
{}