Scripting: repeated variable processing

[admin]

Here's a mean little problem. Currently I first resolve user vars, then XY vars. This leads to the problem shown below (The The <clipboard> is exploding! is exploding!). In msg $a first $a is correctly resolved to "The <clipboard> is exploding!", but immediately after <clipboard> is filled with the current clipboard contents. This can be fixed by reversing the order of resolving. But as you see below, this of course leads straight to a new and analogue problem, that has not been there before.
In short, the problem is that user vars can contain XY vars, and vice versa (the same game can be played with Environment vars...), leading to repeated processing. Reordering is no solution.

Examples:

1: First resolve user vars, then XY vars
2: First resolve XY vars, then user vars

::copytext 'The <clipboard> is exploding!'; set $a, <clipboard>; msg $a
1: > The The <clipboard> is exploding! is exploding!
BAD
2: > The <clipboard> is exploding!
GOOD

::set $c, 'ROAAR!!!'; copytext '$c'; msg <clipboard>
1: > $c
GOOD
2: > ROAAR!!!
BAD

I know I solved the problem of repeated processing yesterday for user vars containing other user vars. But the solution is not good for mixed var types.

A possible (bad) solution
Drop automatic resolving of ENV and XY vars, and move the task to special commands.
Unfortunately, scripting will become a bit clumsy then...
BEFORE
::msg '%TMP% = ' . %TMP%;
::msg "The time is <date hh:nn:ss>."
AFTER
::setenv $temp, %TMP%; msg "%TMP% = $temp";
::setxy $time, <date hh:nn:ss>; msg "The time is $time."

Not so nice...

... (meditation mode) ...

Thanks for listening -- I think I know what to do now...

[admin]

Thanks for listening -- I think I know what to do now...

But it's incredibly difficult and nasty. So, if anybody has an inspiration leading to a more enlighted solution, let's hear it... I'll give it a day until I start working.

[jacky]

Thanks for listening -- I think I know what to do now...

But it's incredibly difficult and nasty. So, if anybody has an inspiration leading to a more enlighted solution, let's hear it... I'll give it a day until I start working.

Well, could have helped to know what you were thinking you had to do...

I don't know how you resolved things yesterday, but in my mind it would be done the way I then described, and when done that way (as in resolving vars when they're set/assigned & moving forward) I'm not sure I see a problem.

With the case of ::copytext 'The <clipboard> is exploding!'; set $a, <clipboard>; msg $a
- when creating $a you resolve <clipboard> to what it is (The <clipboard> is exploding!) and nothing more
- when using $a (with msg) you resolve $a for what is is (The <clipboard> is exploding!) and nothing more, I don't think there should be any recursion here.

Again, as I said yesterday, if after resolving user vars you resolve XY vars, it's okay because you resolve them from the source (passed to msg, so "$a") not the results. So msg $a does say "The <clipboard> is exploding!" because that was in $a, but msg $a : <clipboard> would say "The <clipboard> is exploding! : The <clipboard> is exploding!" of course.

Same goes with ::set $c, 'ROAAR!!!'; copytext '$c'; msg <clipboard>
- $c is set to "ROAAR!!!"
- you copy to the clipboard "$c" since it's between single-quotes
- on msg you resolve <clipboard> to what it is ($c) and nothing more, again no recursion. And if you had use copytext "$c"; then you would have then copied what $c resolved to (ROAAR!!!) so that would have been in the clipboard/shown on msg

In that way, a user var cannot contain any var, because when it's set it is set to whatever the vars resolved to.

Copy (outside of XY) this to your clipboard: <date>
Then, in XY, run this:

Code: Select all

  msg <clipboard>;
  set $cb, <clipboard>;
  msg $cb;

Now, today the first popup would say "<date>", normal, but the second would say something like "28/08/2008 13:23:42". With my way of seeing things, that wouldn't be the case, it would remain "<date>" as that is what's in $cb and there's no reason to do recursive resolving.

In fact, what could then maybe be added is e.g. a command resolve, so if we replace set $cb, <clipboard>; with resolve $cb, <clipboard>; would then have the second popup say an actual date & time, because resolve would take its input, solving vars as it happens everywhere else (so using "<date>") but then it would resolved it once again.

EDIT: Oh, I see a new 7.50.0001 is out, maybe I should have played with it first... Maybe I should review my scripts first, also...

[admin]

Thanks for listening -- I think I know what to do now...

But it's incredibly difficult and nasty. So, if anybody has an inspiration leading to a more enlighted solution, let's hear it... I'll give it a day until I start working.

Well, could have helped to know what you were thinking you had to do...

I don't know how you resolved things yesterday, but in my mind it would be done the way I then described, and when done that way (as in resolving vars when they're set/assigned & moving forward) I'm not sure I see a problem.

With the case of ::copytext 'The <clipboard> is exploding!'; set $a, <clipboard>; msg $a
- when creating $a you resolve <clipboard> to what it is (The <clipboard> is exploding!) and nothing more
- when using $a (with msg) you resolve $a for what is is (The <clipboard> is exploding!) and nothing more, I don't think there should be any recursion here.

Again, as I said yesterday, if after resolving user vars you resolve XY vars, it's okay because you resolve them from the source (passed to msg, so "$a") not the results. So msg $a does say "The <clipboard> is exploding!" because that was in $a, but msg $a : <clipboard> would say "The <clipboard> is exploding! : The <clipboard> is exploding!" of course.

Same goes with ::set $c, 'ROAAR!!!'; copytext '$c'; msg <clipboard>
- $c is set to "ROAAR!!!"
- you copy to the clipboard "$c" since it's between single-quotes
- on msg you resolve <clipboard> to what it is ($c) and nothing more, again no recursion. And if you had use copytext "$c"; then you would have then copied what $c resolved to (ROAAR!!!) so that would have been in the clipboard/shown on msg

In that way, a user var cannot contain any var, because when it's set it is set to whatever the vars resolved to.

Copy (outside of XY) this to your clipboard: <date>
Then, in XY, run this:

Code: Select all

  msg <clipboard>;
  set $cb, <clipboard>;
  msg $cb;

Now, today the first popup would say "<date>", normal, but the second would say something like "28/08/2008 13:23:42". With my way of seeing things, that wouldn't be the case, it would remain "<date>" as that is what's in $cb and there's no reason to do recursive resolving.

In fact, what could then maybe be added is e.g. a command resolve, so if we replace set $cb, <clipboard>; with resolve $cb, <clipboard>; would then have the second popup say an actual date & time, because resolve would take its input, solving vars as it happens everywhere else (so using "<date>") but then it would resolved it once again.

EDIT: Oh, I see a new 7.50.0001 is out, maybe I should have played with it first... Maybe I should review my scripts first, also...

Yep, left-to-right one-by-one resolving. This is the way to go. It's just that I have to rewrite lots of optimized time-tested stuff to get this done. But okay, ... There's always somebody rewriting...

Command resolve... yes, might be an idea for later...

[PeterH]

Something like jacky: I know it as a "function" named value - for
value(varname)
the contets of varname is interpreted as a varname and resolved, so
set $x '<date>';
msg value($x);
would show the date.

As long as there are no functions, it would have to be like:
set $x, '<date>';
value $y, $x;
msg ($y);

Instead of just interpreting 1 variable it could handle the contents of the variable like a unquoted string - but: then every possible variable would be resoved.

By the way: I know "execute" - this treats the contents of a variable as 1 or more statements and executes them