Improvements to the PARSE function
It's long been suggested that some improvements to PARSE would be useful. I know that many of you want these. I want them too.
R3 is the place to make such changes, because we have allowed ourselves the luxury of breaking just about everything... in order to make improvements. For example, Unicode has forced changes in PARSE already.
So, I think we can make some improvements to PARSE, but to succeed in doing so, we must be quite strict about the project. After all, PARSE is not a function to be modified casually.
Specifically:
- All improvements should be gathered into a single list posted on DocBase where they can be openly added and edited. Each improvement should be given a reference identifier of some kind. (Note that a few developers have already started listing ideas, so they may want to contribute that to this project.)
- Someone should search RAMBO and gather all the related PARSE requests and post them to the DocBase list.
- We should agree (as much as possible) on the priority of changes. See my notes below.
- Each improvement will require test code be provided that would certify its correctness. No test code, no improvement. (Sorry... you often ask me what you can do to help. Please don't put the burden of testing such changes on me.)
- Any features that may be affected or changed as a result of the improvement should be noted and also must include tests.
- All changes need user documentation. (The DocBase list is probably a start, but more examples are necessary.)
- We need one person to volunteer to be in charge as the main editor/manager of this project. This is important. That does not mean you will have to write the docs, tests, etc. only that you will help urge other people to do so.
Priorities
Regarding priorities, it is always difficult for a group of people to agree on anything specific. So, here's how we will rank the priorities:
| | High | Changes that are critical, but not highly complicated. For example, providing a NOT command seems easy enough, and it is now critical because using complemented charsets is problematic (due to the Unicode enhancements).
|
| | Medium | Changes that are essentially "easy" and provide much greater usability (or ease-of-use) in PARSE. For example a FAIL command to force a rule to fail.
|
| | Low | Changes that very few people would use, or they are quite difficult to implement. To recognize these, if you suggest an enhancement, but the algorithm seems mysterious or unclear, then it's probably of this rank.
|
There are also some priorities that fall in-between.
You can also post your suggestions in the comment section here... if you don't want them to be lost.
Links
53 Comments
|
