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
