Coming back to this subject, after having given it some thought. The parser, currently, is *enormous*. It includes a lot of different subproducts (the highlighter, the identity compiler, RexxPub), and a lot of utilities (highlight, rxcheck, elements, all the md2* tools, etc). It also includes alpha software (md2slides, more about that in some weeks), and even a CGI publication framework which would should be superseded by RexxHTTP.
Additionally, I understand that if a product becomes part of the ooRexx distribution, it should, if at all possible, be documented as the rest of ooRexx is. And this documentation *constitutes a contract.* Some of the APIs are fixed and stable, like the element API. The whole Highlighter is written against it. No objection to document it. The Tree API is *experimental*. I'd rather not document it: it's not yet frozen and cannot constitute the text of a contract. Similarly, there's a number of decisions to be made. If we want to offer the Parser as a first-class citizen, one should be able to ::REQUIRE parser and start using it. But all the supporting classes and rexxettes should, most probably, go to their own directory, say parser/. Still, maybe not all utilities should be first-class. rexxtry is first-class, while rexxcps is second-class: you have to go to samples/ to run it. Maybe rxcheck should be first class (too useful -- rename it to rexxcheck?), while others are very technical, like elements, and they should go to samples? Finally, most of RexxPub and all of the CGI framework are helpers and derivatives -- they should go apart. And some developments, like the LaTeX driver, are uncared for. They shouldn't be published as part of the official ooRexx distro. What's emerging in my mind is the following idea: maybe I could do a major refactor of the "core" Parser+Highlighter: assume that parser.cls resides in the Rexx path, and the rest of the classes in parser/. Rework all the utilities so that they work against the new setup. Make a proposal about which utilities should be in the path, and which ones should go to samples/. What do you think? Josep Maria Missatge de Rony G. Flatscher <[email protected]> del dia dc., 12 d’ag. 2026 a les 22:02: > On 12.08.2026 12:58, Jean Louis Faucher wrote: > > ... cut ... > > > Missatge de Rony G. Flatscher <[email protected]> del dia dc., 12 > d’ag. 2026 a les 11:52: > >> RFE # 878, <https://sourceforge.net/p/oorexx/feature-requests/878/>, >> proposes to add Jose Maria >> Blasco's Rexx parser to the ooRexx distribution. >> >> Here is the link to the current homepage of the Rexx parser: >> https://rexx.epbcn.com/rexx-parser/ >> >> The Rexx parser is included in net-oo-rexx already: >> https://github.com/RexxLA/net-oo-rexx/ >> >> The main reason for this RFE is the incredible utility it offers for many >> different application >> needs. One example is the ability it supplies for syntax coloring of the >> Rexx code in the ooRexx >> documentation, which can be automated with tools supplied with the Rexx >> parser like (a very >> flexible) syntax highlighting. >> >> The Rexx parser would allow for creating apps that are able to >> cross-reference variables, >> attributes, methods, classes, routines, and the like; another possibility >> would be to use it for >> reformatting (oo)Rexx code to different styles, and much more, confined >> only by the phantasy and >> creativity of (oo)Rexx programmers. >> >> Any suggestions on how to install such a toolset on the different >> platforms? Just put the path to >> Rexx parser's bin directory to the PATH environment variable on all >> platforms? >> >> Any comments? >> >> > I don't have a strong opinion about a toolset installation, so I asked for > a review of several languages. > > Great idea, thank you very much! > > This is just a warm-up for a discussion on this subject. > > We could also decide to be less generalist and put the rexx-parser > utilities directly in bin (a pragmatic approach, as proposed by JMB). > > https://chatgpt.com/share/6a7c4a99-198c-83eb-a04d-c7d108273dde > > I like this comment about Raku: > > Raku also deliberately distinguishes the compiler-only Rakudo distribution > from Rakudo Star. The former contains only a few basic modules, whereas > Rakudo Star includes many useful modules. > > Rakudo Star makes me think of net-oo-rexx, except that net-oo-rexx is a > portable delivery only. > > In conclusion, this RFE should not be overcomplicated by a generalist > approach. Let's go with the JMB proposal. > > Maybe another RFE could be opened for the generalist approach, but the > current level of contributions to ooRexx does not justify this complexity. > > No, not yet. But this would be a kick to think about a general solution > that will hold for the future on all operating systems. Once this is > established, we just need to add future tools to ooRexx. > > We need to agree upon a solution that will remain stable and work on both, > Windows and Unix. If it alters the search path for ooRexx it needs to be > done in a backwardly compatible manner, if possible. Also, currently, the > binaries and dll/so need to reside in the same directory or in sibling > directories (RPATH), so this needs to be considered as well in this > context. > > Josep Maria has analyzed and discussed the ooRexx search strategy (and > compared it to other Rexx interpreters like Regina), so it would be also > interesting what he thinks, resp. what solution he would suggest. > > ---rony > > > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
