passing parameters as strings v. numeric Topic is solved

[nnnik]

I guess we'll always have to use &( NumVar . "" )

Code: Select all

StrVar := "1234"
NumVar := 1234

MyGui := GuiCreate("", "Test")
MyEdit := MyGui.AddEdit("w400 h400")
MyGui.Show()
MsgBox("Passing StrVar")
SendMessage(0xC, 0, StrVar, , "ahk_id " . MyEdit.Hwnd) ; WM_SETTEXT := 0xC
MsgBox("Passing &StrVar")
SendMessage(0xC, 0, &StrVar, , "ahk_id " . MyEdit.Hwnd) ; WM_SETTEXT := 0xC
MsgBox("Passing NumVar")
SendMessage(0xC, 0, &"", , "ahk_id " . MyEdit.Hwnd) ; WM_SETTEXT := 0xC
SendMessage(0xC, 0, NumVar, , "ahk_id " . MyEdit.Hwnd) ; WM_SETTEXT := 0xC
MsgBox("Passing &NumVar")
SendMessage(0xC, 0, &( NumVar . "" ), , "ahk_id " . MyEdit.Hwnd) ; WM_SETTEXT := 0xC
MsgBox("Exit")
ExitApp

This seems to be consistent with the changes introduced to &numVar in v2.0-a048-573f142

Changed &(var:=1) to return var's 64-bit number buffer instead of its string buffer.

[just me]

Yes, I know. AHK v2 actually has 'typed variables'.

On AHK v1 each variable may have two buffers: The mandatory string buffer (which might be empty in case of pure numeric values) and the optional number cache. As far as I understand, v2 variables have only one buffer, which might contain a string, a binary int64, or a binary double, and the type of contents is determined by an internal type flag. IMO, things like &( NumVar . "" ) are poor workarounds.

[nnnik]

We can always fork and base the libraries that we write on this fork

[Helgef]

In v1, when you do &varcontainingpurenum, the number is converted to a string and put in the variable's string buffer, which the address of gets returned. (Helgef memory)

Luckily, that is fixed in v2

[nnnik]

In v1, when you do &varcontainingpurenum, the number is converted to a string and put in the variable's string buffer, which the address of gets returned. (Helgef memory)

Luckily, that is fixed in v2

Yeah that behaviour was very weird.

[just me]

IMO, it's a conceptual problem.

In v1 forced super-global classes were introduced without the counterpart of force-local functions. And the force-local mode has been implemented 'a bit later'.

In v2 typed variables have been implemented without the counterpart of built-in functions for type conversion. And ...

[lexikos]

Helgef, I'm not sure if I disagree or just don't get your point.

The vast majority of built-in function parameters either 1) accept a string or number and convert it to a string, or 2) accept a number or string and convert it to a number. SendMessage's wParam and lParam are now included in that majority. Requiring &address-of when passing a string by address is on par with DllCall(..., "Ptr", &String).

I suppose that "the quirk of numxxx in v1" is that it differentiates between the value x and a variable containing value y when x and y are exactly the same value and type. SendMessage doesn't do that.

NumPut and NumGet are AutoHotkey functions, and are subject to AutoHotkey's type system. Window messages and the native code which handles them are not.

Before, if you sent a message with a string to yourself, you got the string's address as a number. Now there is more symmetry.

No one should read the documentation for the message and try to deduce how to use the built-in function

Pick any random message; let's say, TVM_SETINSERTMARK. How do you use this message? What value and type should each parameter have?

Anyone sending a standard window message should read the documentation for that message before doing so. If you use the message without reading the documentation, you are probably copying someone else's code and using it without a proper understanding (or just making guesses?). I wouldn't recommend that, but at least you can blame someone else if the code was missing an ampersand.

In v2 typed variables have been implemented without the counterpart of built-in functions for type conversion. And ...

I haven't added them yet because there is already a trivial solution, and it is more succinct.

Should they be named after the types, Integer, String and Float?

Assuming that implicit conversion is to throw an exception for invalid input (1 + "a"), should the type conversion functions do the same, or be more permissive (e.g. produce 0), since they are explicit?

[nnnik]

This change will cascade though.
If you want to create a simple wrapper for SendMessage which requires sending strings or sending numbers ( e.g. the Scintilla Control system of AHK Studio ) you now have to differentiate between strings and normal integers if you don't want to make the users of your wrapper functionality write &string. If you make your users write &string during a function call you won't be able to do anything else with the string because you won't recognize it as string.
That is not neccessary in the case of drawing the line between the string type and the number type. As you said you are not using AutoHotkeys type system - you are using a different type system.
And thats fine honestly. I don't mind using DllCall( "SendMessage", "Ptr", wParam, "Ptr", lParam ) since DllCall has it's limits to how much I can just adjust it to AutoHotkeys type system directly.
I could easily write a wrapper function that adjusts this type system to AutoHotkeys as much as possible and make it more useable.
The result would be exactly the SendMessage function that we had before. The current SendMessage thats essentially just a short version for DllCall("SendMessage") is not a wrapper function.
It fails to fulfill the single reason why it should exist since you force another type system into AutoHotkeys function. On rare occasions ( stuff with NumPut ) that is neccessary.
I can only talk from experience here but even I have not seen that before though arguably I have not worked that much with SendMessage before.
Since we have established that introducing another type system for strings can save us many problems when working with this function and might not make it neccessary to use esoteric ways of passing our strings why are you still holding on to that &string idea? Especially since it might cause additional problems - and the only thing that it is really helping with is removing num+0.

[Helgef]

I suppose that "the quirk of numxxx in v1" is that it differentiates between the value x and a variable containing value y when x and y are exactly the same value and type. SendMessage doesn't do that.

The quirk, for the caller, is that it has a variable which contains what it wants to pass to the function, but it cannot pass its variable reference, it has to make an (supplementary) expression (-0). SendMessage now presents the same quirk (&) for the caller. Every now and then, someone has a variable containing a string which looks like a number, this person should realise it is an illusion and convert it to an actual number if it wants to pass it (to sendmessage) as such, it will benefit the person for several reasons. Fundamentally, if you have "1" in your variable when you want to pass 1, you have the wrong value in your variable. It makes no sense to supply a built-in function with information about a variable instead of passing it directly, cf.,

Code: Select all

strsplit(&str, &del, isobject(type(del))) ; ?

---

The vast majority of built-in function parameters either 1) accept a string or number and convert it to a string, or 2) accept a number or string and convert it to a number. SendMessage's wParam and lParam are now included in that majority.

There is no denying the fact, and as I said, or hinted, earlier, I am opposed it. AHK v2 variables distinguishes well between numbers and strings, there is no need (for the program) to ever treat a string as a number. If AHK is not going to throw exceptions on using strings in math functions / operations, it has no future, it is utterly ridiculous to produce an empty string instead of notifying the user of an obvious mistake, it is very dangerous to produce numbers from strings. How can this be acceptable?

Code: Select all

; User makes an obvious mistake
var := "01"
msgbox type(var)	; String
msgbox var+1		; Non-sensical result, 2

Furthermore, the address operator (&) is inconsistent, &(var:="1") should obviously return an address of an integer, not a string. "1" is a number, anyone can see it is ( ).

---

Anyone sending a standard window message should read the documentation for that message before doing so.

Of course, after one has read the documentation on how to use the built-in function.

Cheers .

(I do not mind being sligthly hyperbolic)

[jeeswg]

- I think there's a big difference between numbers/strings being interchangeable when passed to a function v. when used within expressions.
- @lexikos: Thanks for explaining this so well. It sums up my position, and it's the position that I expected most people to either have, or to at least be sympathetic to.

The vast majority of built-in function parameters either 1) accept a string or number and convert it to a string, or 2) accept a number or string and convert it to a number. SendMessage's wParam and lParam are now included in that majority.

[jeeswg]

- I couldn't find information in the documentation re. addition. If anyone can point me in the right direction. I've tried to figure out the logic.

Code: Select all

var1 := 1
var2 := "1"
var3 := "a"
MsgBox(1 + 1) ;2
;MsgBox("1" + 1) ;error
;MsgBox("a" + 1) ;error
MsgBox(var1 + 1) ;2
MsgBox(var2 + 1) ;2
MsgBox(var3 + 1) ;(blank)

What are the logical rules here?
E.g. for MsgBox(X + 1). Is it:
Starts with numeric: succeeds.
Starts with numeric string: error.
Starts with non-numeric string: error.
Starts with numeric var: succeeds.
Starts with numeric string var: (converted to numeric) succeeds.
Starts with non-numeric string var: blank.

- Is this quote correct? Both have a non-numeric input, so they should be compared alphabetically, giving false in both cases.
Variables and Expressions
https://lexikos.github.io/v2/docs/Variables.htm

If either of the inputs is not numeric (or both are strings), they are compared alphabetically. For example, 2 < "10" is true whereas "2" < "10" is false.

[nnnik]

I am not sympathetic to this view in the slightest.

[just me]

In v2 typed variables have been implemented without the counterpart of built-in functions for type conversion. And ...

I haven't added them yet because there is already a trivial solution, and it is more succinct.

I prefer clear solutions, even if less succinct. (I've been a COBOL programmer for many years - in the main COBOL-74 and COBOL-85 -and bound to strict programming guidelines. )

Should they be named after the types, Integer, String and Float?

That might be the best.

Assuming that implicit conversion is to throw an exception for invalid input (1 + "a"), should the type conversion functions do the same, or be more permissive (e.g. produce 0), since they are explicit?

Though I feel that v2 already introduced many more exceptions which must be handled I'd prefer an exception.

[Helgef]

- Is this quote correct? Both have a non-numeric input, so they should be compared alphabetically, giving false in both cases.

Of course It is correct. In 2 < "10" both are numeric, but both aren't strings, so they are not compared alphabetically, in "2" < "10" both are strings, hence, they are compared alphabetically. As you see, your desire to mix numbers and strings causes you a head ache, it amuses me endlessly .

It sums up my position

It was a statement of fact, not a statement of position, although it might very well be lexikos' position that the stated fact is desirable.

I'd prefer an exception.

+"1"

I am not sympathetic to this view in the slightest.

Cheers .

[jeeswg]

2 < "10"
- For this, I would say that '10' has a string type, but numeric content. If I had to describe it as either a string or numeric, I would describe it as a string.
- So I would say that the documentation ought to be clearer here.
- It's similarly awkward to describe 'a key whose name is an integer of numeric/string type', I asked elsewhere if there was a handy short way of saying this.
- @Helgef: I'm surprised at how certain you seemed re. 2 v. 10, also you say 'endlessly' but this discussion is still quite new. And re. saying that I what said wasn't an opinion, but that it was fact, well, thank you, I do try to base what I say on the facts. Cheers.

[Helgef]

saying that I what said wasn't an opinion, but that it was fact

I didn't say that what you said was a fact, I said that the quote

The vast majority of built-in function parameters either 1) accept a string or number and convert it to a string, or 2) accept a number or string and convert it to a number. SendMessage's wParam and lParam are now included in that majority.

from lexikos, which you said summed up your posisition, wasn't a statement of posisition, but a statment of fact.

- So I would say that the documentation ought to be clearer here.

There wouldn't be any confusion if strings where treated as strings and pure numbers as numbers.

endlessly

Maybe it is not the correct word. I mean that the amount it amuses me has no end, and that it will amuse me forever.

Cheers.