Hi René, Thanks for your comments. I've been doing some tests under Regina (latest version, under Ubuntu). Regina exhibits some striking differences compared to ooRexx:
- There's no concept of the "same" (or caller's directory). If you put a routine R in the same directory as the calling program, you can't Call R and expect it to work. - The search order is (1) REGINA_MACROS (environment variable), (2) current directory, (3) PATH (compare that to (1) caller's directory, (2) current directory, (3) application-specified path, (4) REXX_PATH, (5) PATH in ooRexx). - If the program name "contains a file path specification", then the search order is completely bypassed. Notice that this is much more stringent than ooRexx: in ooRexx, you can Call lib/my.rex and expect the search order to work, but in Regina the search order will be bypassed because the program name contains a slash. - This last point is *documented* in 1.4.2 (p. 15 of the 3.9.5 version of regina.pdf): "Note that the search algorithm to this point is ignored if the program name contains a file path specification. eg. if "CALL .\MYPROG" is called, then no searching of REGINA_MACROS or PATH is done; only the concatenation of suffixes is carried out." - There is no notion of "same extension". If an extension is present, only this extension is searched. Otherwise, "the file name is extended by the extensions [1] "" (empty string), [2] ".rexx", [3] ".rex", [4] ".cmd", and [5]".rx" in this order. The file name case is ignored on systems that ignore the character case for normal file operations like DOS, Windows, and OS/2." Please notice that the null extension (that is, no extension) is the *last* one in the ooRexx search, but the *first* one in the Regina search. - The list of extensions is also different. Compare it to [1]".cls" (for ::requires only), [2] the same extension, the application-defined extensions, [3] ".rex" and [4] no extension for ooRexx. - There is a REGINA_SUFFIXES environment variable. If present, its contents are placed after the empty extension "". - If I read the docs correctly, I get the impression that the search order in Regina is *directory-first*, that is, all extensions are tried in a directory, then all extensions are tried again in the next directory, etc. ooRexx is *extension-first: *all the directories are searched for a given extension, then all the directories are searched again for the next extension, etc. All the points except the last one have been tried with a test program that I will upload shortly somewhere, and post the URL here. I will also try to prepare a comparison chart and a high-level description of the different search algorithms, so that we can compare them thoughtfully. Re: BRexx -- Can somebody please point me to a precompiled version for Windows, preferably the 32 bit version? I'd like to extend my test programs to be able to work under BRexx too. Kind regards, Josep Maria Blasco Missatge de René Jansen <rvjan...@xs4all.nl> del dia dc., 8 de febr. 2023 a les 12:37: > Hi Josep, > > thank you for this investigation which I am sure we all have read with > great interest. > > On 7 Feb 2023, at 11:35, Josep Maria Blasco <jose.maria.bla...@gmail.com> > wrote: > > Once more: I don't think there's a clear, evident way to settle this > conversation. A *decision* has to be taken. And it has to be *explained* > (i.e., > documented) and, if possible, *justified*. The last part is optional, of > course: one can define a language as one sees fit. > > The weight, if any, of my contribution, is only to emphasize two things: > > - Other languages tackle this problem in a particular, coincident way. > - And that way is the most economic in terms of describing the search > procedure. > > This does not mean that what I am proposing should be accepted. It's only > my point of view. > > > I think this needs to be well documented (for all platforms Rexx is > running on, with additions for the oo variants. There is a new Rexx ARB > starting up where work can be done to isolate the different components of > the question where things are found - I think one of the most important > questions one encounters when trying to make something non-trivial. > > There is the component of history - CMS and TSO were there before the > DOS/OS2/Unix world. There is the language philosophy angle - other > languages make choices the might not be the Rexx way (those full of curly > braces or significant spaces), while on some platforms (NetRexx - Java) the > choices of the latter are like gravity. > > One question that comes up is if you compared the way ooRexx 5.X does this > to Regina, Brexx or OS/2. I think one of the things an extended standard > document could do is to help describe this and propose a standard way of > implementing this which is straightforward on Windows/Linux(including other > Unix like platforms like macOS). > > It could be argued that this is not part of the language but of the > implementation - but I am doubting that the documentation of a > function(method) call or the CALL statement is complete without a > specification where it finds what it calls. > > Economy in terms of describing - well, that is relative I think - the > procedure for finding and overriding a BIF in VM at least requires a > flowchart in the VM documentation (and the way Brexx does it is different) > but it expresses a common goal of being able to override a > built-in-function. In z/OS we have lpa (flpa, mlpa), link list, sysproc and > sysexec concatenation (and the alt library) where a compiled Rexx program > could live and I would not be able to economically describe that, but they > are all there for a reason. > > Thank you again for bringing up this discussion. > > Could you mail me that zip file so I can put it somewhere where more > people can look at it? > > best regards, > > René Jansen. > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel >
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
