[Wish:] Again, wish the usage of "function definition expressions" to be eliminated

[V2User]

Wish the usage of "function definition expressions" in alpha version to be eliminated.
It already seems harder to read these codes below:

Code: Select all

SetTimer(
    tick() {
        static n := 3
        MsgBox n--,, 'T1'
        if n = 0
            SetTimer tick, false
    }, 1000)

image.png (102.82 KiB) Viewed 2914 times

To avoid "symbol hell" at the root, I wish the usage could be eliminated before it becoming stable version.
Details are in this I posted.

image.png (126.69 KiB) Viewed 2126 times

[lexikos]

Details are in this I posted.

What details? The link is invalid.

[cumulonimbus]

There are a lot of people who object to this way of defining things, but there are also a lot of people who like it, and what you think is "symbolic hell" may be a paradise of simplicity in the eyes of others.

[iseahound]

@lexikos

Did you consider the pros / cons of using () => {} instead? I personally am having trouble telling when an anonymous block is being used.

Your example pasted below isn't immediately obvious that an anonymous function is created and invoked.

Code: Select all

    IsSet(ref) && ((&alias) {
        alias ??= 0
        alias++  ; Multiple references, no need for explicit %dereferencing%.
        alias++
        alias++
    })(ref)

[lexikos]

() => {} is a fat arrow function which returns an empty Object. There is no need to overload this operator with ambiguity.

[bonobo]

Without this new syntax, defining custom methods like map, filter, reduce on arrays, which require looping, cannot be done conveniently, "in loco". Is that correct? You have to define a function elsewhere and use Call, like this:

Code: Select all

Array.Prototype.DefineProp("Map", {Call: MapArrayByFunc })

[iseahound]

No I meant as defined like:

Code: Select all

() => {
   return 7
}

which would be what ES6 uses. The anonymous functions are currently rather strange to my eyes, it's not clear to be what that assemblage of (){} may be doing in context.

[V2User]

Details are in this I posted.

What details? The link is invalid.

Sorry, not knowing what reason, the link is wrong. Now, I have updated it that you can access.
Details are in this I posted.

image.png (126.69 KiB) Viewed 2127 times

[lexikos]

@iseahound, so what?

This is already valid:

Code: Select all

a := () => {}
b := () => {}.DefineProp('call', {call: (this, a) => a is Object})
c := () => {
base:
    b()
}(a) ? MsgBox(1) : MsgBox(0)
c()

Exactly when do you propose that {} be interpreted as a block?

JavaScript has a very simple rule: => {} is always a block. Even then, it breaks expectations.

Returning object literals using the concise body syntax (params) => { object: literal } does not work as expected.
Source: Arrow function expressions - JavaScript | MDN

This rule would not be backward-compatible.

Besides which, "function definition expressions" are just function definitions inside an expression. Same syntax, same parsing code. The new additions are just workarounds for parser limitations.

[sirksel]

I know I may be in the minority in this thread, but I do appreciate this block-within-expression notation, and I wouldn't want it to be eliminated. There are certain things like statics, try-catch, etc. that are currently only possible within a block. If all I need is a static x in a one-liner callback, it is sure a shame to have to write a full function. This capability allows a solution for that and so much more. I trust @lexikos judgment on syntax and have generally grown to like even those syntax choices I didn't fully appreciate at the outset. Thanks for implementing this, and I do hope you keep it.

[iseahound]

I personally don't mind the syntax, but it seems to be complex to new programmers. As long as a novice can understand and decipher the syntax, I would be fine with it.

Regarding blocks / object literals, I suppose it's less "parser debt" to reuse existing code.

I am a little skeptical with some of the new additions such as x := (y?) which seem to come from parser limitations.

[V2User]

If all I need is a static x in a one-liner callback,

It will be three lines also. One line is not supported yet. It needs nearly the same inputs as before except that an f can be omited in f(){

[V2User]

If function definition expression is supported. Then another expression => can completely be removed.
Also, this feature is not compatible with the current static f(){ syntax, when an inner function definition needs to avoid becoming a closure. Any future modifiers like static for func definition, will not be supported with this feature too.
Also, #include syntax can be used within a function currently, but is not compatible with this feature. As #include can not be used within an expression.

[V2User]

There are a lot of people who object to this way of defining things, but there are also a lot of people who like it, and what you think is "symbolic hell" may be a paradise of simplicity in the eyes of others.

The only "simplicity" than before might be f can be omited in f(){.
Obviously, not so much, if this is a simplicity.

[sirksel]

@V2User, so I guess maybe I misread your request. From the title of this thread, it looked like you were asking for elimination of the new block-in-expression syntax. Sounds like your concern is maybe solely with the anonymous case? () { } Sorry if I misinterpreted your intention.

I use anonymous fat arrows often, and in a similar vein, I'll likely use anonymous function-defs-within-expressions. I think I understand what you mean about symbol overload sometimes. There are a lot of ()=> in my code today (functional programming, parameterless callbacks, etc.), and soon there will be a lot of () { }. It's a small price to pay for the terse functionality it unlocks however. And it's purely opt-in. Anyone can just name all their functions if they like that look better.

But I do get your point about the symbol overload. I have an idea about this, which I will write up in a separate topic when I have a little more time.

[V2User]

it looked like you were asking for elimination of the new block-in-expression syntax.

This is really my main intention.
Because this feature nearly doesn't save input even when you use the anonymous case. Therefore, what good will really be in it? This is what I want to express.

[lexikos]

There are many situations where a single-use function may be passed to a function or method, or assigned to a variable or property, or returned from a function. Requiring that the function be defined separately to the expression, that it be named, that the name be repeated, is not doing anyone any favours. If an author doesn't want to or can't come up with a meaningful name for the function, forcing them to give it a meaningless name is not doing anyone any favours.

JavaScript supports both function xxx() {...} and function() {...} in an expression, but the existence of => (which came later) seems to show that many people prefer the less verbose way. Surely => is just as cryptic until you learn what it does. Unlike AutoHotkey, JavaScript's => doesn't even permit the function to be named, let alone require it.

[V2User]

Requiring that the function be defined separately to the expression, that it be named, that the name be repeated, is not doing anyone any favors.

So, at least, the function must not be named if it is used as an expression. Once the function is named, it cannot be within an expression and should be formally defined. How is that?
Codes are not all. There are not only codes but also comments are needed too. Why should we write comments even if all codes are written? This just goes to show that code reading is at least equally important as code writing. Once double of the function names is omitted within an expression, perhaps later we will have to write much more comments on average for each this "less-words" usage, for youself to read afterward, and maybe for others as well.
Therefore, subtracting the reading convenience, is it really "convenient"?

[lexikos]

@V2User
If you are suggesting that only anonymous functions be permitted in an expression, you are making no sense. On one hand you are saying that providing a function name makes the code easier to understand, and on the other hand you are denying anyone from doing that within an expression, thereby making function expressions less readable according to your own standard.

And you are missing the point. Imposing arbitrary restrictions will not force anyone to write readable code. Each author is free to write the code in whatever way he finds best, within the constraints of the language. I have no reason to take your opinion of what is readable as law. If an author wants to write unreadable code, he is free to do that as well, within the constraints of the language.

An example of where I would use the new capability: I wrote this recently to debug an issue relating to keyboard messages. When I come back to this code at a later date, it will be obvious to me that it is registering several functions to act on specific messages. I chose to name the functions to make the code more self-documenting, but I probably wouldn't have if I had bothered to name the message constants instead.

Code: Select all

#requires AutoHotkey v2.1-alpha.4
((){
    ListVars
    ControlSetText "", "Edit1", A_ScriptHwnd
    print(line) {
        SendMessage 0xB1, -2, -1, "Edit1", A_ScriptHwnd
        EditPaste line "`r`n", "Edit1", A_ScriptHwnd
    }
    OnMessage 0x100, KeyDown(vk, *) {
        print "KD  " GetKeyName(Format("vk{:x}", vk))
    }
    OnMessage 0x104, SysKeyDown(vk, *) {
        print "SKD " GetKeyName(Format("vk{:x}", vk))
        return 1 ; Disable menu
    }
    OnMessage 0x101, KeyUp(vk, *) {
        print "KU  " GetKeyName(Format("vk{:x}", vk))
    }
    OnMessage 0x105, SysKeyUp(vk, *) {
        print "SKU " GetKeyName(Format("vk{:x}", vk))
        return 1 ; Disable menu
    }
    OnMessage 0x102, Char(ch, *) {
        print "C   " Chr(ch)
    }
    OnMessage 0x106, SysChar(ch, *) {
        print "SC  " Chr(ch)
    }
    OnMessage 0x20A, MouseWheel(wParam, *) {
        print "W   " (wParam << 32 >> 48)
    }
})()

Requiring extra line breaks and duplicating names would not help in any respect. Without the new capability, I may have chosen to write each function as a => expression across multiple lines. Sometimes one way or the other is more readable, and sometimes I end up needing to convert from => to a full function for whatever reason (like others have mentioned).

The construct ((){...})() establishes a local scope for the function names, so I can drop this into another script without it adding global names. (The original purpose was to create a local scope for a variable to collect the output, but then I changed it to just append to the Edit control.) Apparently this is commonly known as a "self-invoking function", though I'd say that's inaccurate.

[bonobo]

On the topic of function definition expressions, what's the reason this code works but the one below doesn't?


working code:

Code: Select all

	DefinePropPrim := Object().DefineProp
	DefinePropPrim(String.Prototype, "f1", {Call: (str, mode){
		if mode==1
			return "one"
		else if mode==2
			return "two"
	}})

	Msgbox("test_str".f1(2))

error-throwing code:

Code: Select all

	DefinePropPrim := Object().DefineProp
	DefinePropPrim(String.Prototype, "f1", {Call: (str, mode){
		Switch mode
		{
		 	Case 1:
		 		return "one"
		 	Case 2:
		 		return "two"
		}
	}})
	Msgbox("test_str".f1(2))