-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
single-line function declarations #442
Comments
What about the |
This would be instead of introducing There is one major advantage that
But I guess we could achieve the same effect with an annotation:
(Or something.)
I'm trying to avoid introducing
|
So I want to go a little further down this path. But first I need to bring up a missing feature of named argument lists that we're going to need when we get up to using them to build user interfaces. What we need is the ability to declare a named value inside a named argument list, and access that value "further down the tree". For example:
Given the current syntax for named arg lists, the line But if we can now define functional arguments using the new syntax proposed above, i.e.
Then perhaps it's not as important to be able to do this anymore:
And it would be OK to force you to use the
Note that this would be extremely consistent with how this stuff works for Thoughts? |
i.e. what I'm saying is you could write either:
or:
|
P.S. Of course, you would also be able to use the syntax for refining
That's going to be really convenient. |
There's one thing that strikes me here: how increasingly similar named argument invocations and class bodies are getting. And especially when considering the planned ad-hoc refinement with named arguments (interface instantiation) it seems that a named argument invocation (of a type) basically is an inline object declaration. I think we should seriously explore if there is a way to merge the syntax of named arguments with that of object bodies. |
FTR, I have always considered it a strong goal that they should be very
|
I find that confusing because I get the impression that |
Regarding allowing local variables in named-param calls, I find it pretty confusing to read. Not only that but if we suddenly require I'd rather have a I think we should wait until the need for something like that arises. I haven't had it yet. |
You will need it the very second you first try to write a user interface in Ceylon. |
I never got that idea (yet). I am on the other hand pretty sure that I'd do this sort of trick in an HTML template:
|
I have implemented the first step of this: making stuff like the following work:
And wow, updating the tests, I realize I like this syntax soooo much better! |
The following is now essentially working:
Pretty cool :-) |
There's something I don't like about this:
One of these behaves different than the others, and I find that not very obvious. That was the big advantage of Also, I could imagine that getters would be a typical case where the one-line syntax would be useful because getters are often very simple. But as far as I can tell there's currently no way to apply that syntax to getters, isn't it? |
@ikasiuk I agree, it's the one downside of this, and as mentioned above, it's likely we'll want to add some kind of |
I used to be able to write
but this is no longer considered well-typed. I guess a
it suddenly becomes well-typed. Is that a bug in the current implementation, or a "feature"? |
That's a feature. You're assigning a value of type Of course the following is not well-typed:
|
This feature has been implemented:
FTR, @FroMage and @emmanuelbernard talked me into the fat arrow syntax
To finish off this work, we need to do #466. We also need to think some more on my idea above: |
What does it mean to have it in the parameter? Is it the default value? |
Of course. |
This is something that came up in tangential discussions in #363 and #377.
Currently we let you write:
or
both of which define the function
intRange()
by reference, makingintRange
essentially an alias forRange
. This was something I settled on a very long time ago, without it ever having been exposed to much discussion. I'm now more and more inclined to think that this is not the best way to go. I think we should instead give you the choice between:and
i.e. the parameters of the function would be in scope on the RHS of
=
and the type of the RHS expression would be expected to be the return type of the function, not the callable type of the function. This would:give you a lot more flexibility, allowing shit like:
Indeed,
= something;
would now just mean{ return something; }
.be much more consistent with the way type alias declarations work currently, where the type parameters are in scope on the RHS (but not the ordinary parameters, curiously, which would be fixed under this proposal).
be consistent with the traditional notation in mathematics and, I think, usually more readable.
simply look a lot more symmetric and "balanced".
The only subtle thing that I can think of here is with forward declaration and named arguments. Currently, the following things are natural:
Now, that seems, initially to clash with the new syntax. But not if we let you write the following as well:
In fact, this seems to work out pretty neatly (assuming it can be easily parsed).
Indeed, given this new syntax
repeat { do(Progress p) = run(p); };
, we might wind up just simplifying the whole syntax of named argument lists!The text was updated successfully, but these errors were encountered: