 |
Anaristos
Sorcerer
Joined: 17 Jul 2007
Posts: 821
Location: California
|
 Posted: Sat Sep 20, 2008 8:49 pm
An enhancement to auto typing.
|
I have found in the past the commands and functions that are expecting a "command" type argument cannot be easily parametrized. A case in point is:
| Code: |
#ALIAS temp {#VAR {%1} "";#CALL %vartype({%1},2)}
|
This won't work, of course, because no matter what auto typing is done to {%1}, it won't be acceptable to the %vartype function. In this case the typing would be "literal". By "won't work" I am referring to the result of the call to %vartype.
So either, when parsing this type of commands and functions, the arguments are not typed after interpretation, or a new type of variable is needed to solve this problem. The vartype would be applied to the argument before it would be passed along to be processed, of course. Since the param would be strongly typed, the function call would work in this example. Note that "not typing" and "auto typing" are not the same thing. Of course, if auto typing were to force the argument to be acceptable to the subject of execution, that would work also. |
|
_________________
Sic itur ad astra. |
 |
|
|
shalimar
GURU
Joined: 04 Aug 2002
Posts: 4774
Location: Pensacola, FL, USA
|
Posted: Sat Sep 20, 2008 9:05 pm
|
<alias name="temp" id="3270">
<value>#VAR %1 {}
#CALL %vartype(%param(1),2)</value>
</alias>
this works |
|
_________________
Discord: Shalimarwildcat |
|
|
|
Anaristos
Sorcerer
Joined: 17 Jul 2007
Posts: 821
Location: California
|
Posted: Sat Sep 20, 2008 9:20 pm
|
Ah, I see your point. But the reason it works is because the result of #VAR %1 {} is strongly typed to "string". The call to %vartype is ignored.
Try this:
| Code: |
#ALIAS temp {#VAR %1 {};#CALL %vartype(%param(1),8)}
|
or any other variable type, or remove the call to %vartype altogether. The result is that variable created by the alias is always of vartype "string". |
|
_________________
Sic itur ad astra. |
|
|
|
shalimar
GURU
Joined: 04 Aug 2002
Posts: 4774
Location: Pensacola, FL, USA
|
Posted: Sat Sep 20, 2008 9:45 pm
|
perhaps it is due to the fact that it is a %null variable? Have to tried to see if it works when the var actually contains data?
|
|
_________________
Discord: Shalimarwildcat |
|
|
|
Anaristos
Sorcerer
Joined: 17 Jul 2007
Posts: 821
Location: California
|
Posted: Sat Sep 20, 2008 10:52 pm
|
Very well, letīs look at this example. This is alias temp:
| Code: |
#VAR ctrl "x|y|z"
#VAR {%1} "x|y|z"
#VAR ctrl2 "x|y|z"
;;
#CALL %vartype(ctrl,4)
#CALL %vartype(%param(1),4)
|
The result is as follows:
| Code: |
Variable: + xyzs (Literal) x|y|z
Variable: + ctrl (StringList) x|y|z
Variable: + ctrl2 (Literal) x|y|z
|
The variable ctrl2 shows us that the default type is of "literal" (which would not happen if the double quotes were removed, in that case the type would have been "stringlist", which is not the point).
With that in mind, we see that the call to %vartype for the variable ctrl forces the correct (or intended) type, but not so to the parametrized variable, which remains type "literal" indicating that the call to %vartype was moot.
This, to me, indicates that the variable name must be hardcoded into the call to %vartype, which is what I am hoping will change.
EDIT: %vartype(%param(1)) will return a -1, which means to me, undefined type. The documentation doesn't specify AFAIK. |
|
_________________
Sic itur ad astra. |
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5187
|
Posted: Sun Sep 21, 2008 11:53 am
|
The return value of -1 indicates that no variable was found. The reason %1 or %param(1) does not work is that the parameter type of the first parameter to %vartype is "var". That type of parameter is treated as a literal string. You can see the same thing with the %pop function.
This could be changed, but it is generally necessary in order to work with local variables. For example:
$a="d|e|f"
#SHOW %pop($a)
Displays "d" and updates the $a variable to "e|f" correctly. If expansion occured then %pop would have been looking for a variable named "d|e|f", which is not what is wanted.
Changing it would cause everyone using local variables with such functions to need a rewrite like #SHOW %pop("$a"). This would be a severe break for thousands of users.
I would suggest that if you really need to apply indirection for this then you can use a string expansion trick.
#CALL %expand(%concat("%vartype(",%param(1),",2)")) |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
Anaristos
Sorcerer
Joined: 17 Jul 2007
Posts: 821
Location: California
|
Posted: Sun Sep 21, 2008 6:39 pm
|
Thank you, Vijilante. Your explanation is very good and right to the point. I can now clarify what my whole point was. I am not concerned with the "literal" typing of the variable and it makes perfect sense to me that it is that way.
If fact, what you say tells me that there is hope for my wish. What I would like is this type var variable to be explicitly declared. Then there would be no problems. So that, using my original example with the temp alias:
| Code: |
....
....
$varname = "test"
#CALL %vartype($varname,9)
....
temp $varname
.....
;;TEMP ALIAS
....
....
#VAR %1 %null
#CALL %vartype(%1,8)
....
....
|
In the preliminary script the local (or global) variable is loaded with a string that corresponds to a variable name. Then using my scheme, %vartype is called with a variable type of 9 indicated. This new type would tell the function that the contents of the first parameter is a var type value. That is, indirection would be automatic whenever this variable was encountered.
Futher:
| Code: |
....
$varlabel = "testvar"
#CALL %vartype($varlabel,9)
.....
#VAR $varlabel "This is a test"
....
#SHOW @testvar
....
|
Executing the #SHOW command would display "This is a test" on the screen.
The above is not a very good example but shows what I wish to happen. It seems a bit bizarre, I agree, but it would simplify many scripts and allow one to develop methodologies which are currently either awkwardly possible or just plainly impossible.
Of course, adding pointer variables would be another way to archive this. |
|
_________________
Sic itur ad astra. |
|
|
|
|
|
|
