Hi Rony,
Thanks for raising this subject, and for your references to my work. A
minor comment about
the glossary: as it is specific to the parser, some of the concepts I am
using will probably be
too narrow to be applied to the whole of ooRexx as a language.
But, yes, as you point out, there are several concepts which are either
undefined, or are ambiguous.
There is also a multitude of sources: TRL1, TRL2, the ANSI standard, the
Dallas draft report,
and ooRexx files. Some concepts are horrible, for example
the "taken_constant"s of the ANSI and
Dallas BNFs. Others are cryptic, like the "vrefp" for parsing templates.
Others are simply missing,
as not all the new features of ooRexx 5.0 have their corresponding diagram.
Furthermore, the documentation does not include the EBNF definitions; this
means that there
is no formal definition of the ooRexx language, which is a Bad Thing in
itself. Of course,
you can download these from the Sourceforge SVN tree, but one would
expect that they
would all be collected in an Appendix in the reference manual, and, if at
all possible,
in a separate EBNF file.
Furthermore, the ENBF files that are used to produce the syntax diagrams
are written
--and this is very understandable-- with the purpose that the resulting
diagrams look nice
on the printed PDF. But a formal definition would probably need, at least
in some cases,
different identifiers. Identifiers name ("identify") concepts, and, in some
sense, contribute,
by this very act of naming, to their definition. The different ways to name
a thing produce
different technical ways of handling this thing. I would much prefer to
handle "names",
for example, instead of managing "taken constants".
This is important for language and tool implementers, and for technical
documentation writers,
as these identifiers end up being reflected in the names of the concepts
(like the book
you are writing) and in the names of classes and other entities, when one
is writing
a certain tool.
To summarize, I think that 1) ooRexx needs a formal definition; 2) this
formal definition should
be separate (parallel) to the one used to produce the diagrams, that is, it
should not be
unduly influenced by it; 3) names which are cryptic or inadequate should be
revised; and,
4) new names should be produced for the concepts which lack one, like code
bodies.
Josep Maria
Missatge de Rony G. Flatscher <[email protected]> del dia dj., 18 de
set. 2025 a les 17:51:
> Currently I am trying to update my book on "Introduction to Rexx and
> ooRexx" to include the most
> important additions to ooRexx since ooRexx 4.1, and there are *many* and
> *great* additions to
> ooRexx, especially by ooRexx 5.0 (a huge and great leap)!
>
> In this context it is important for me to use a terminology that is agreed
> upon in the ooRexx
> development community.
>
> As in the past years Josep Maria Blasco wrote an ooRexx parser in ooRexx
> (and a transpiler named
> TUTOR that allows one to create Unicode ooRexx programs that then can be
> run by ooRexx) he also hit
> the problem that newer concepts incorporated/used in ooRexx 5.0 are not
> formally/explicitly defined.
> Therefore he wrote a glossary for his ooRexx parser to communicate the
> terminology he has been using
> (trying to stick to ooRexx terminology as much as possible) for his ooRexx
> parser which can be
> studied here: <https://rexx.epbcn.com/rexx-parser/doc/glossary/>.
>
> I would like to use the term "code body" with the meaning that implicitly
> is present in the
> documentation and explicitly discussed in the glossary. Also, the term
> "package" needs to be defined
> in a manner, that is easily understandable, replacing/augmenting the term
> "program". The same is
> true for the term "prolog".
>
> Would anyone have any comments in this respect? Maybe even terminology
> definitions that should be used?
>
> ---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
