jeremy c b nicoll

I do disagree.

For expression evaluation you don't need it. You could do it as follows:

a) read the expression from the user
b) write to a temporary file a complete rexx exec that evaluates that
expression and places the result in a second file
c) run the created exec
d) read the result string and display it to the user

If you want the user to be able to enter a series of expressions with latter
ones involving use of results of the earlier ones, you'd need also to store
the results of earlier ones. You can do that with value().


--
Jeremy C B Nicoll - my opinions are my own.

brandon cherry

Just to throw this one out there as an option to anyone that might be
going from OS2 to Linux for case insensitivity in general. JFS has an
option (it's '-O') when you create the partition to make it
case-insensitive. Just 'man mkfs.jfs' to find out more information. You
could create a mount point to store your rexx scripts to help with your
transition.

As previously stated on SysFileTree, the file system was the limitation.
--
Brandon Cherry

spamgate@hotmai1.com

Or http://en.wikipedia.org/wiki/Reverse_Polish_notation. Not the best
of sources, but I cannot find anything like INTERPRET in postfix.bas
and it includes some pointers to how to process such data, although
that's rather obvious. 1+2*3=A[o1]B[o2]C, [o2]=*, [o1]=+, process
B&C using [o2] (2*3=6), and next [o1] that with A (6[+][1]). You may
even replace "3" with "Words('a few words')", there's no reason why
that shouldn't be possible to implement. But then again, I doubt if
any user of a meaningfull app ever needed to use that to replace the
"3", albeit we could use it to show off our impressive Rexx-skills.

And an advantage is that it adds more control, INTERPRET '"A+B"' can
be intercepted (there's no need to alays make the output look like
Rexx's limited set of error messages).

e) Complain that this HelloWorld.EXE could have a size of a few MB's,
including an embedded, seamless translater/compiler, just because
INTERPRET could occur in it and our beloved user just may not have
installed the required translator/compiler, thinking of Java... :-)

Well, like I said before, this a-d is something a developer could use,
for example with the already mentioned "special case" of RexxTry. In
any other situation, assuming a meaningfull app, INTERPRET is always
avoidable/replacable. A calculator is a meaningfull app, and there's
more than one way to build a perfectly working one with a compiler
without INTERPRET-support. The resulting *.EXE may become huge and
slow, the original Rexx source code may expand by a few lines, but
it's possible. Just because INTERPRET adds no features to a language
that's already being interpreted, the math is that easy.

FWIW, there's more than one way to add this INTERPRET wishlist-item.
Instead of including a-d, perhaps with some calculator having to deal
with "disk full"-errors, e's HelloWorld.EXE can include an interpreter
too, using mixed code. The resulting *.EXE still will be both bigger
and slower than existing command-line calculators, it's not perfect
too, but it's yet another way to ignore compilation of an INTERPRET.

Please note then one may end up with a Rexx interpreter instead of an
optimized result, so not avoiding the use of INTERPRET has little or
no benefits at all w.r.t. e.g. execution speed: you may obtain stand-
alone Rexx interpreters (*.EXE'es including a *.REX, basicly replacing
a Rexx interpreter (*.EXE running *.REX'es). That's not going to show
gains I'ld expect from executing compiled, meaningfull code.

---

bob martin

What about OS/2 ? ;-)

spamgate@hotmai1.com

Replace "Java" with "(O)Rexx", replace "namely" with "excluding", and
it still should make some sense... :-)

And just in case someone starts thinking that OS/2 was always ignored
by the BSF4Rexx-author, which thought wouldn't be fair:

http://www.google.com/search?q=bsf4rexx+OS%2F2+-rexxla

---

rony

Actually, the idea for BSF4Rexx was induced by the desire to allow creation of openplatform apps
with Rexx on OS/2 and being able to later move the applications to Windows (and eventually to Linux)
and vice versa, to allow OS/2 users to use BSF4Rexx apps which got developed on Linux or Windows.

In the many years (since the inception) quite a few changes took place. About two years ago I tried
to get my hands on OS/2 again in order to create an OS/2 DLL from BSF4Rexx.cc, which I did not
succeed. After having tried a day or two and getting help from some up-to-date C++ coder from the
OS/2 world it still was not possible to use the compiled DLL (something going astray in the JNI
code). That was the time where I stopped putting any more efforts into it.

In principle it should be possible to get a working version of the DLL (that's actually all you need
to touch for a port, everything else - be it compiled Java or Rexx - is available in an openplatform
manner already. A person being able to do that should know C/C++, Java 1.1.8 and Java 1.3/1.4 at the
JNI level (there are a few hickups possible here, like configuration issues). So if you find someone
who would try the port of "BSF4Rexx.cc" and succeeds, I would like to learn about it in order to add
the DLL to the distribution!

---rony

P.S.: Quite a few of the small (nutshell) sample programs coming with BSF4Rexx were originally
created on OS/2 many years ago! They have been running *unchanged* on MacOSX, Linux and Windows!

P.P.S.: Also, if the OS/2 community is still alive then there may be some developers who could port
ooRexx to it. ooRexx has been gaining new features and will do so constantly. The ooRexx support in
BSF4Rexx can be expected to take advantage of such new features.

imc@comlab.ox.ac.uk (ian

In a previous episode of comp.lang.rexx, Jeremy C B Nicoll was heard to
say:


That's INTERPRET by the back door, really. And it's a problem if your
evaluated expression wants to refer to variables or internal functions
that are only present within the main program.

It's not necessary to write the result to a file, incidentally; you
ought to be able to call the program as a function and collect the
result directly.
--
---- Ian Collier : imc@comlab.ox.ac.uk : WWW page (including REXX section):
------ http://users.comlab.ox.ac.uk/ian.collier/imc.shtml

New to this group? Answers to frequently-asked questions can be had from
http://www.rexxla.org/faq.html .

jeremy c b nicoll

Yerss, but that back-door interpret is the one that absolutely has to be
present in the interpreter.


Yes, of course. Unfortunately my brain wasn't properly plugged in when I
posted my suggested workaround.

--
Jeremy C B Nicoll - my opinions are my own.

spamgate@hotmai1.com

a few adjustments, e.g. using more than one *.TMP file):

/* BackDoor.REX (using a file, if you want that) */
PARSE PULL rexxtry

/* Was: "INTERPRET rexxtry" */
CALL LineOut 'MyRexx.TMP','/**/;'||rexxtry||';EXIT'
'@XLATE.EXE MyRexx.TMP MyRexx.2C /quiet' '@COMPILE.EXE MyRexx.2C MyExe.EXE'
'@MyExe.EXE > MyRexx.TMP'


All you have to have installed is a XLATE.EXE and your COMPILE.EXE. A
genuine user of a meaningfull app doesn't have to install those, nor
does ...

/**/;PARSE PULL rexxtry;rexxtry;EXIT

.... expand to 10+ MB's because "INTERPRET" could be used here. But a
developer should understand having to have all additional tools which
are required by th back-door.

Perhaps this XLATE.EXE could automatically expand "INTERPRET" to a
BackDoor.REX-like construction, but that gives less control than an
own attempt to avoid using INTERPRET. Do you want to use a file, the
RexxVariablePool, shared memory, just the screen, ...?

The above is a way to avoid INTERPRET, it doesn't present it. If it
would, a Rexx compiler like this could very well be a complicated way
to re-do a source code-hider, while waisting MB's and forgetting about
speed gains and optimization. The same could be true for supporting
the execution of mixed code (compiled SAY, interpreted INTERPRET),
just like executing this back-door will process rather slowly.

---

spamgate@hotmai1.com

I wouldn't count on many users, the typical Rexx app turns out to be
an INSTALL.CMD instead of an impressive demonstration of the power
of additional external tools (Rexx DLL's, BSF4Rexx, ...), no matter
how great the tool is.

Nevertheless, isn't there some comp.os.os2.* newsgroup devoted to this
kind of porting. If so, have you ever dropped the issue there with an
overseeable ammount of possible porting problems to be met?

I don't have the numbers to proove nor deny it, but don't be surprised
if the OS/2&eCS community still is Rexx's largest pc installed based
and the largest pc user base.

This has been discussed before, but maybe not here. Ship it with eCS
(so it doesn't become an additional external tool), integrate it with
the OS in a seamless way (to avoid "ooRexx.EXE MyRexx.CMD").

OS/2'ers already have (O)Rexx, there's no desperate need for it, and I
haven't seen any OO apps yet. That means the market is supply-driven,
not emand-driven. "It would be nice to have".

Earlier you mentioned that people already worked on it, but I cannot
recall anyone posting why that sub-project stopped, nor did I see an
advertisement w.r.t "Wanted: C++ developer".

For the OS/2 community, ooRexx isn't that important. But it can help
the RexxLA-goals. You know how starting with OS/2's Rexx could later
turn out to download e.g. ooRexx for Windows, so that user base could
grow later too (and Rexx may need that too, just count the number of
unique (!) downloads of ooRexx and next substract all downloads w.r.t.
pc's/bussinesses controlled by RexxLA-members, it's a small world). I
think this could be more important than going OO, which back then I'ld
have called (a slightly neutral) "remarkable, funny".

I don't need it desperately, but at least I do prefer some maintained
(o(o))Rexx interpreter, and IIRC Regina has stopped due to ooRexx, so
that' not an option anymore. All we/you have for the future is ooRexx
nowadays, and the market isn't driven (enough) by demand.

That may mean that, besides some kind words, the RexxLA (/ooRexx.org)
perhaps doesn't have to write ooRexx/2 for me, I may not share their
goals (the furthering of, and so on) w.r.t. the language too, but it
may be an idea to maximize the efforts to obtain such port of ooRexx.

Contact developers/eCS, tell what earlier problems encountered are, is
there some level of support/experience/help available? IMHO such an
active approach would be better than to mention it in line 83 of an
article. I'm not saying it'll result in a working port, maybe due to a
lack of a true need for it (or Rexx, as such), but it may become the
best effort so far. If that doesn't succeed? Well, bad luck...

After all, supplying the source code of ooRexx didn't result in a port
too, so I assume there's more required than just a "The source code is
available for download!".

---