|
|
Post by Robert on Nov 24, 2023 13:44:31 GMT -5
George,
SPF_Parse does a good job of categorizing macro keyword-style operands, but it has limitations. It makes two assumptions:
(1) All macro operands, from first to last, are unconditionally parsed;
(2) All macro operands must "appear" to look like existing primary-command operands in current use.
These limitations mean that you can't define a macro that uses some unusual syntax that doesn't exist in any current primary command. If you could tell the parse to 'skip' some unusual operands, that could address it, but that feature isn't available.
For instance, I tried to write a macro that took a hypothetical find-string of H'2' as the first parameter. SPF_Parse returns an error of,
Unknown literal type code in Operand #1
I see two possible ways to address this.
1. When the parse finds an operand it can't categorize, you would put it into an "other" list. Then, to fetch any such operands, you would call Get_Arg_Other(n). If you didn't want to all 'odd' operands, you could verify that Get_Arg_Other(1) = "". In such cases, finding an operand you could not categorize would no longer be treated as an error.
2. You could allow the behavior of SPF_Parse to be altered, in some way, by calling some kind of "option-setting" function beforehand.
Suppose you had a function named SPF_Parse_Options(). It might be able to define which parameters you wanted parsed (or, not parsed), and perhaps allowed other types of options.
I don't want to over-specify this. It's just a general idea right now.
Note: There doesn't appear to be any way to capture the 'line' and 'column' flags @ and # using SPF_Parse, unless you know something I don't.
Oh I see, you convert @ and # into pairs of column numbers and .nnn line references. Got it.
R
|
|
|
|
Post by Stefan on Nov 25, 2023 10:49:59 GMT -5
Hmm, the existing command syntax already copes admirably with ' unpredictable text literals'.
The conventional way in which SPFLite (commands like FIND and CHANGE) solves this is to require users to enter such literals as quoted strings, and SPFLite accepts several types of quotation marks. So the ability to handle unconventional literals already exists in SPF_Parse - enter them as a quoted string e.g. "H'2' " and let the macro do it's thing.
I know the example looks clumsy, but that's due to the chosen notation of H'2' which already uses quotes and H'something' isn't a known construct in SPFLITE command syntax. |
|
|
|
Post by Robert on Nov 25, 2023 12:25:02 GMT -5
Yeah, but that's the whole point. You might want to parse something that SPF_Parse doesn't know how to parse.
What I thought might be possible is to alter SPF_Parse to accept an optional first parameter which was an array of strings:
DIM my_tokens(n) AS STRING
Then, you'd call SPF_Parse(my_tokens, ...other parameters...)
Then, the parsing would only be applied to the specific tokens you give the parser, and NOT always the ones on the macro command line.
That way, you could parse any list of tokens you wanted.
R
|
|
|
|
Post by George on Nov 25, 2023 13:08:06 GMT -5
Robert: The error message you got is because SPF_Parse uses the normal command parser to do preliminary parsing. If your new H'n' is actually specifying length, or column boundaries, why put them inside a H'n' string, just ask for them as numeric operands.
I do not want to muck around thith the 3-400 lines of weird code inside SPF_Parse without a very good justification.
George
|
|
|
|
Post by Robert on Nov 25, 2023 13:21:25 GMT -5
Why use the H'n' format? Because numeric operands specify column bounds. If there were column bounds, AND a hex-literal length, it would be hard to tell which was which. Besides, H'n' was part of a proposal. If you weren't going to implement it, the question of H'n' wouldn't matter any more. Besides, I wanted to create a prototype to see if any of it made sense. This effort is part of the prototyping work.
The mucking around part (I presume) would amount to replacing the macro ARG string array with a user-provided one. Would that really be hard to do? This would only be in the beginning of it. I can't see how all 400 lines of code would need to be tampered with. Perhaps you could explain, or tell me where the code is so I could look at it myself.
The justification would be to allow the parser to parse any user-provided list of tokens, not just the exact ones on the macro command line. That would make the parser more generalized. If that wasn't done, then the one and only purpose of SPF_Parse is to parse the command line unmodified. Imagine if TB's parser functions were so limited. You'd be going "grr.." and "sheesh".
R
|
|
|
|
Post by George on Nov 25, 2023 13:40:14 GMT -5
Robert: SPF_Parse was never intended to be a universal, all-in-one, do-everything parser. It was designed to mimic the normal SPFLite parsing and to provide a more powerful and simpler option over the other TWO macro parse methods we provide. Altogether we provide THREE parsing methods for macros, I doubt any other macro language does that.
Those other two methods are still available and would allow you to do whatever the heck you like.
And please, as of yet, I have not agreed to proceed with this whole thing. I'd like to hear from some other users as to the desirability of this. You have some great ideas, but so far nobody else seems to care, and I'll not proceed without a lot more support. Remember, I have said I want to reduce SPFLite activity, and I mean it.
|
|
|
|
Post by Robert on Nov 25, 2023 14:08:50 GMT -5
As you put it in your other post, whatever floats your boat. I believe I can continue with my prototype without any code changes from you, if you had no interest in it.
Unfortunately, "nobody seems to care" and the silent majority has long been a problem around here. You said recently that you still loved to write code, but you also say you want to reduce your activity. If your real wishes are, "no more suggestions", I will respect that. I just need to know your feelings on the matter. Just tell me how you want it.
R
|
|
|
|
Post by Robert on Nov 25, 2023 14:33:16 GMT -5
Further SPF_Parse testing has revealed an interesting quirk in the general primary command parser. If I say,
MYMAC ABC DEF WORD WORD
and I have defined WORD as part of a "group", then when I say WORD WORD like this, I get an SPF_Parse error, since keywords in groups are not supposed to be duplicated. However, that is a greater stringency than the main command parser imposes. If I say,
CHANGE ABC DEF WORD WORD
the command parser is perfectly fine with it. I never realized that until now, since I don't (generally) try to type stupid commands. I am sure this is another case of "nobody cares". I hope I will be forgiven, but I actually do care about how exactly this all works. It's important to me; it always has been.
R
|
|
|
|
Post by George on Nov 26, 2023 10:17:50 GMT -5
Robert: I'm sure there are a lot of quirks in parse and the way it works. As to describing how it works and documenting it - sorry even I don't know/remember stuff like that. Remember, the basics of all that were written about 20 years ago. I can hardly remember what we had for dinner last night.
George
|
|
