Map question

[kdmoyers]

Why does this program fail? 

Code: Winbatch

  a["q"] = "abc"
  a["w"] = mapkeyfind(a,"w","") : "x"

The error is "Variable could not be converted to string"   What variable?
(running version 2020C)

[JTaylor]

This reminds me I need to update.

Probably the MapKeyFind() response.   You are concatenating the response with "x" so it needs to have something it can convert to a string to join with "x".   I have encountered errors like this before when accidentally  trying to display an array rather than an array element.    I wonder if the default value is returning NULL rather than a blank space?   What happens if you change the default value to "z"?

Jim

[td]

Sorry but a bit of comp sci theory is needed to properly explain what is going on...

The problem is the result of how the WIL interpreter evaluates expressions.  The interpreter is an LL2 parser which means that expressions are evaluated from left to right.  The "a["w"]" expression is evaluated when the parser encounters the equal sign (=). That is the "2" part of an LL2 parser.  Because the "a["w"]" expression is creating a map key, the call to MapKeyFind does find the key "w" in the map.  However, because the assignment hasn't finished yet there isn't a value for the key "w".  The statement is equivalent to the statement "a["w"] = a["w"]" which generates a slightly different error.  In other words, WIL needs to allow map keys without values or you couldn't dynamically create new key entries in a map but you can't use the key on the right-hand side of an assignment statement until the key has a value. Without a value, the expression a["w"] evaluates to undefined when it is part of an expression on the right-hand side of an assignment operator.  The colon ( : ) operator encounters the undefined value and issue's the error.

The MapKeyFind function could flag a key with an undefined value as an error when it performs the lookup but that isn't technically an error state because keys with undefined values are allowed in maps. Using the default value when the found key is undefined isn't quite accurate either but that or not changing anything at all may be the best solution. Will have to think about that one a bit.

To answer the specific question the variable is the temporary variable create when a subexpression is evaluated by the parser.  In this case, it is the temporary variable created to hold the result of the evaluations of the subexpression "mapkeyfind(a,"w","")".

[kdmoyers]

Cool, I think I understand.  Boy maps do have their subtleties don't they!

Here what I'll use instead, which is more readable anyway:

Code: Winbatch

   if mapkeyexist(a,"w") then a["w"] := "x"
                         else a["w"]  = "x"

Thanks for the help!
-K

[td]

This problem isn't unique to maps.  It is also true of regular WIL arrays.  Consider

Code: Winbatch

a[1] = a[1]

or even

Code: Winbatch

x = x

It has more to do with dynamic creation of data structures than anything else.

[kdmoyers]

Yup.  I think I just sorta confused myself. (chuckle)
-K

[td]

You raised an interesting question that has resulted in a change to the way the error is handled so it is good that you confused yourself.

[stanl]

Maybe OT: but I'm still on the sidelines about Maps. What is the significance over dictionaries; fabricated recordsets [which can be typed], Powershell hash tables, even Json... all of which exists in WB.

[td]

If their uses are not self-evident to you then don't use them. But please don't disparage those who find them a handy addition to the language.

[stanl]

disparage is a harsh word; not meant in my post... just asking a question. Appreciate you not taking out of context in the future.

[td]

You have asked some version of the same question about maps multiple times and the question has been at least partially answered. At some point, a question becomes more than just a question.  I have no idea of your intentions since I can't read a person's mind but I can certainly understand how the repeated question might be taken in a less than positive way.