> On 12 Aug 2026, at 12:32, Josep Maria Blasco <[email protected]> > wrote: > > Maybe exposing all of bin/ would be too much. I could try to refactor the > parser so that only the utilities like highlight, elements, etc and the > parser package itself can be found, in the same way as yaml.cls or json.cls. > The real bulk of the package could reside in its own subdirectory.
+1 > > Josep Maria > > Missatge de Rony G. Flatscher <[email protected] > <mailto:[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. 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.
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
