Fat arrow =>

Discuss the future of the AutoHotkey language
Helgef
Posts: 3163
Joined: 17 Jul 2016, 01:02
Contact:

Re: Fat arrow =>

31 Mar 2018, 06:05

I'd say it would be nice, but your particular example can be acheived with ?:. And as said by lexikos, the benefits diminishes when the function becomes longer. In particular, I think mulitline function definitions in a function call becomes quite ugly with only a few lines of code, and especially if it is not in the last parameter, or if done in mulitple parameters. Further, when naming a function, it is much more sensical to me, to do so separate from a function call. So you might aswell use a nested function for more elaborate code. Eg,

Code: [Select all] [Download] GeSHi © Codebox Plus

myFunc(){
gui := guicreate()
Gui.OnEvent( "Close", "closeApplication")
closeApplication(){ ; Adding '=>' here adds no convenience
if ( msgbox( "Do you really want to exit?") = "Yes" ) ;imagine the button options as Yes/No
ExitApp()
}
gui.show("w200 h200")
}

cheers.
lexikos
Posts: 6130
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Fat arrow =>

31 Mar 2018, 06:12

Helgef wrote:Regarding () => { statements }, I do not think it would add a whole lot unless you could do same line statements, eg, while(x) y() or while(x) { ... }.
To be clear, I wrote it without line breaks so that it would appear as part of the sentence, but the actual code would have line breaks. It would be a standard block of code. I guess you thought otherwise, since I can't imagine why else same-line statements would matter.

Either only permit braces on multiline definitions or always demand, i.e, () => { {} }, the latter is less desirable imo.
That won't work. Object literals are allowed to contain hard line breaks. What is () => { {} } supposed to be? A block containing an empty block? If the point is to interpret anything that starts with { and isn't a valid expression as a block... no. That would be complicated to implement and hard for users to tell one from the other. Something like this could be interpreted both ways:

Code: [Select all] [Download] GeSHi © Codebox Plus

x.OnEvent(y, () => {
begin:
MsgBox("flop")
})
{{ ... }} wouldn't be ambiguous, but why go that far? There's really no reason to use => with a block in the first place when () {} is both unambiguous and more familiar (especially if the function is named). => can exclusively mean a function which returns the following expression.

Actually, C# also uses => for expression-bodied members.
User avatar
nnnik
Posts: 3218
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Fat arrow =>

31 Mar 2018, 09:14

Helgef wrote:I'd say it would be nice, but your particular example can be acheived with ?:.

Thats ugly.


[/code]
cheers.[/quote]

Further, when naming a function, it is much more sensical to me, to do so separate from a function call. So you might aswell use a nested function for more elaborate code. Eg,
;Adding '=>' here adds no convenience

Yes it adds convenience - it decreases redundance.

Actually, C# also uses => for expression-bodied members.

Quite a few languages support this expression.
C# also allows for statements though.
https://docs.microsoft.com/en-us/dotnet ... nt-lambdas

Heres a list of all languages that do according to Wikipedia:
https://en.wikipedia.org/wiki/Anonymous ... _languages
Recommends AHK Studio
Helgef
Posts: 3163
Joined: 17 Jul 2016, 01:02
Contact:

Re: Fat arrow =>

31 Mar 2018, 14:16

lexikos wrote:To be clear, I wrote it without line breaks so that it would appear as part of the sentence, but the actual code would have line breaks. It would be a standard block of code. I guess you thought otherwise, since I can't imagine why else same-line statements would matter.

It was clear, I mean that allowing a multiline function body after => wouldn't add much unless a regular function body had good support for same line statements, hence you could still do your fat arrow with statements on one line, or at least few. More elaborate code might as well be (nested) functions (an existing feature, hence the wouldn't add much part).
What is () => { {} } supposed to be?

It should be () => { return {} }, meaning I made a (logical) mistake, not that it should be interpreted as such by the program.
Object literals are allowed to contain hard line breaks

I over looked that. When expr is an object literal, it would have to be enclosed in (), then (...) => expr with implied return and (...) => {statements} would work.
nnnik wrote:Yes it adds convenience - it decreases redundance.

Some in your original example (disregarding that you named it), the contrary in my modification of it. I think fat arrow followed by a block of code makes most sense when making unnamed functions outside of all functions. Inside a function or method, a nested function is fine. But sure, I imagine your example looks better than doing it with ?:.

Cheers.
lexikos
Posts: 6130
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Fat arrow =>

31 Mar 2018, 23:40

v2.0-a092 fixes the errors Helgef reported.
lexikos
Posts: 6130
Joined: 30 Sep 2013, 04:07
GitHub: Lexikos

Re: Fat arrow =>

06 Apr 2018, 19:19

I wrote:I'll address the issues with static initializers in another post.

Static initializers and auto-execution

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 4 guests