Post by Robert on Jul 13, 2024 15:12:55 GMT -5
George, when I first proposed using SET to somehow save a label value,
I suggested a syntax like:
SET .A = .ZFIND
As we know, this ended up becoming the LABEL command. Still, I remember what I was thinking with the SET notation. What I was thinking in the back of my mind was similar to what PL/I does with "label variables". Here is a PL/I piece of code that would use them:
DECLARE LL LABEL(3);
LL(1) = ONE;
LL(2) = TWO;
LL(3) = THREE;
ONE: PUT LIST ("ONE");
TWO: PUT LIST ("TWO");
THREE: PUT LIST ("THREE");
....
GOTO LL(3); /* = GOTO THREE */
-------
Anyway, Imagine that the new SPFLite LABEL command could create new labels this way, by assigning any line location to a "label variable". I see the most likely underlying way to implement this is by using label handles, and then associating them with a string.
Imagine doing something like this:
FIND "ABC" WORD
LABEL ._ABC .ZFIND
I am here using the line handle notation of ._ as a prefix.
What this would do is:
1. Determine the LNO of .ZFIND
2. Create a line handle associated with that LNO and get the numeric value of it
3. Create a "line variable" name of ._ABC in variable-length string array similar to the GLOBAL number feature.
4. Store an entry with the "._ABC" as the "key of this label variable, and the numeric value of the .ZFIND as the value of this entry.
To then use this concept, there would have to be a separate version of this "label variable array" for each file tab, and then the parser would have to recognize notation like ._ABC as label reference and then look up the LNO associated with that line variable, in order to use it.
I'm not sure how much you'd like this idea. Yes, it's another one of my crazy ideas. Perhaps a macro writer could make use of it.
What does this buy us that LABEL doesn't right now? Mainly that if you assign .ABC using LABEL and .ABC was already assigned, or there was already a label where that was, you'd wipe out the assigned label.
Example:
LABEL .ABC "ABC" LAST
LABEL .XYZ "XYZ" LAST
But what if the line in question has BOTH "ABC" and "DEF" - then the second LABEL command would wipe out the .ABC label and replace it with .XYZ. Using label variables would allow two ways to reference the same line:
LABEL ._ABC "ABC" LAST
LABEL ._XYZ "XYZ" LAST
Why do I suggest using line handles to represent a line label? In the prior example, if a line were deleted or added before the data line that had both "ABC" and "XYZ", then the line labels would have gotten invalidated. This way, that won't happen.
Comments invited. I wouldn't call this a priority by any means. It's just an idea to kick around. I you don't like it, I am OK with that. I just wanted to present this as an idea for you to think about.
Well, this is the idea.
I suggested a syntax like:
SET .A = .ZFIND
As we know, this ended up becoming the LABEL command. Still, I remember what I was thinking with the SET notation. What I was thinking in the back of my mind was similar to what PL/I does with "label variables". Here is a PL/I piece of code that would use them:
DECLARE LL LABEL(3);
LL(1) = ONE;
LL(2) = TWO;
LL(3) = THREE;
ONE: PUT LIST ("ONE");
TWO: PUT LIST ("TWO");
THREE: PUT LIST ("THREE");
....
GOTO LL(3); /* = GOTO THREE */
-------
Anyway, Imagine that the new SPFLite LABEL command could create new labels this way, by assigning any line location to a "label variable". I see the most likely underlying way to implement this is by using label handles, and then associating them with a string.
Imagine doing something like this:
FIND "ABC" WORD
LABEL ._ABC .ZFIND
I am here using the line handle notation of ._ as a prefix.
What this would do is:
1. Determine the LNO of .ZFIND
2. Create a line handle associated with that LNO and get the numeric value of it
3. Create a "line variable" name of ._ABC in variable-length string array similar to the GLOBAL number feature.
4. Store an entry with the "._ABC" as the "key of this label variable, and the numeric value of the .ZFIND as the value of this entry.
To then use this concept, there would have to be a separate version of this "label variable array" for each file tab, and then the parser would have to recognize notation like ._ABC as label reference and then look up the LNO associated with that line variable, in order to use it.
I'm not sure how much you'd like this idea. Yes, it's another one of my crazy ideas. Perhaps a macro writer could make use of it.
What does this buy us that LABEL doesn't right now? Mainly that if you assign .ABC using LABEL and .ABC was already assigned, or there was already a label where that was, you'd wipe out the assigned label.
Example:
LABEL .ABC "ABC" LAST
LABEL .XYZ "XYZ" LAST
But what if the line in question has BOTH "ABC" and "DEF" - then the second LABEL command would wipe out the .ABC label and replace it with .XYZ. Using label variables would allow two ways to reference the same line:
LABEL ._ABC "ABC" LAST
LABEL ._XYZ "XYZ" LAST
Why do I suggest using line handles to represent a line label? In the prior example, if a line were deleted or added before the data line that had both "ABC" and "XYZ", then the line labels would have gotten invalidated. This way, that won't happen.
Comments invited. I wouldn't call this a priority by any means. It's just an idea to kick around. I you don't like it, I am OK with that. I just wanted to present this as an idea for you to think about.
Well, this is the idea.
Labels stay with the line, how would they become invalid?