I like REXX, that would be a nice track to add.
I’d be, like @kotp, interested in helping a REXX track get up and running.
LATER
ooRexx or NetRexx?
1 Like
Oh yeah, forgot about that one.
1 Like
If some of y’all are committed to making this, then please open an issue at GitHub - exercism/generic-track 
1 Like
That was a reply to me, so I take that as an assignment, in task and in name.
– Signed, Some of Y’all
1 Like
Which “Flavor” of Rexx would we want to focus on?
- Regina Rexx
- NetRexx
- ooRexx
0 voters
1 Like
I went looking for opinion pieces of the kind “oorexx vs netrexx vs reginarexx”. One such response was https://groups.google.com/g/comp.lang.rexx/c/kW81-6pAyI0 and the opinions seemed to go more toward ooRexx. I don’t have much of an opinion myself. I don’t use the language and only know about it because of its pattern-matching sublanguage.
1 Like
Whichever you choose, it’ll need to run on Linux.
1 Like
So Regina or NetRexx, the latter targeting the JVM.
1 Like
The discussion seems to be very Windows-centric.
Knowing nothing about it, I’d suggest a none-JVM option is likely to be easier for the average person to install, and faster for our infrastructure to run (interpreted languages tend to be 6x faster than compiled ones), so Regina feels like the best option
Those are not the only three options, I am aware that there are 9 open source and free implementations. But I agree about the suggested requirements of Linux, Non-jvm (or other virtual machine) based equivalents. Things that focus on the Rexx language itself, with minimal setup dependencies.
I voted for Regina. If not Regina, then ooRexx.
I was thinking of starting this myself too. I was already looking up some testing frameworks and found this: GitHub - neopragma/t-rexx: Unit testing framework for Rexx
Since I believe other people have a lot more experience on Rexx than I have, it would be best to leave it to professionals. Other than that, I’d like to help out in any way I can.
You would have to return everything that your procedure returns pushed to stack since Rexx procedures don’t know how to return stems. There are many exercises that want you to return arrays. When doing COBOL track, I was thinking that it would be easier to return just strings instead of tables. So maybe the same applies here.
Not so! I was a jq newbie when I started that track. If you have the drive to learn Rexx and really want an exercism track, go for it! You’ll become an expert very quickly!
4 Likes
One particular attraction of the COBOL track, for me, is the simplicity of the unit testing (sorry to say, but the xUnit (and similar) examples I have seen in some tracks are very clever, but just too complicated, IMHO). From a solution contributor’s perspective, easy to read, and understand, and from a solution author’s perspective, I would imagine, easy to implement and maintain.
I believe a REXX track would benefit from a similar approach. The testing framework mentioned by @kapitaali looks promising in this regard.
Regarding string return values instead of stack-based returns or stems, I entirely agree.
You would need to run the stack server to implement a data stack using Regina (not sure how problematic this would be on the exercism infrastructure).
Alternatively, you could EXPOSE stems, and adopt a convention for returning values. Simplest of all, IMHO, would be the use of strings as suggested by @kapitaali. Regina offers a rich set of string manipulation capabilities with which to facilitate this.
Since my exercism experience, so far, is limited to contributing solutions, I’m going to try my hand authoring a COBOL exercise or two. I hope to then be in a better position to help out in implementing a REXX track.
2 Likes
The tests in Problem Specifications can indicate whatever it wants to, but it is up to the track to translate it to what makes sense for the language. So, try not to take too much from the technical structure of the test information presented there.
Also, hopefully, the tests themselves do not drive a specific implementation, as much as possible.
Given the tags on the language request, nothing’s going to happen until someone puts their hand up as maintainer. I’m still working on the 8th and openeuphoria tracks, so I’m not volunteering.
I am interested in contributing to both the COBOL and (potential) REXX track.
I did notice the REXX track requires a maintainer, however, since I have no experience in performing such a role, I have not nominated for it.
Am I being realistic, or too cautious ?
I am happy to volunteer if my current experience is acceptable. The approach I would take to performing the role would be to read through the commits of similar, existing tracks (I have forked the COBOL track), mimic and adapt steps taken there.
Open to suggestions / advice.