Skip to content
This repository has been archived by the owner on Apr 13, 2023. It is now read-only.

Type inference keyword for lambda parameters #4497

Closed
CeylonMigrationBot opened this issue Jul 27, 2015 · 11 comments
Closed

Type inference keyword for lambda parameters #4497

CeylonMigrationBot opened this issue Jul 27, 2015 · 11 comments
Milestone

Comments

@CeylonMigrationBot
Copy link

[@Zambonifofex] 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...

[Migrated from ceylon/ceylon-spec#1391]

@CeylonMigrationBot
Copy link
Author

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

@CeylonMigrationBot
Copy link
Author

[@Zambonifofex] @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?

@CeylonMigrationBot
Copy link
Author

[@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.

@CeylonMigrationBot
Copy link
Author

[@Zambonifofex] 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));

@CeylonMigrationBot
Copy link
Author

[@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.

@CeylonMigrationBot
Copy link
Author

[@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 :-)

@CeylonMigrationBot
Copy link
Author

[@Zambonifofex] 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

@CeylonMigrationBot
Copy link
Author

[@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.

@CeylonMigrationBot
Copy link
Author

[@Zambonifofex] 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")
{}

@ghost
Copy link

ghost commented Apr 14, 2017

@gavinking

I feel like this becomes even more needed in times of destructuring:

foo(function(value [a, b]) => a + b);

See #6446.

gavinking added a commit that referenced this issue Apr 14, 2017
as suggested by @Zambonifofex in #4497
(requires hack to backend to preserve BC)
gavinking added a commit to eclipse-archived/ceylon-sdk that referenced this issue Apr 14, 2017
@gavinking gavinking added this to the 1.3.3 milestone Apr 14, 2017
gavinking added a commit that referenced this issue Apr 15, 2017
@gavinking
Copy link
Contributor

I have changed the spec and typechecker to tolerate the syntax print((value i) => i.string, 12).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants