Conceptual Problems Encountered While Writing This
This is pretty straightforward as tasks go. And certainly the PARSE-based code is more pleasing to look at than many versions. But I'll list a few gripes.
The C code I looked at to model from used a variable called
first for the starting "direction". I used the same name and obliviously overwrote FIRST the Rebol operation. This made later code not work. It's certainly a cautionary tale for the casual overwriting of standard library functions...which makes you wonder if there's anything we could do to warn you about doing this accidentally, and then have an override notation. Something in the function header? Something on the LET itself? What would cause these warnings and why?
I've explained my reluctance to embrace locals-gathering via SET-WORD! as a built-in idea. It may be good for some things, but I think it needs more control. The solution I've proposed which co-opts a single word vs. all possible set words is LET, but I'm m still in a gray area about how LET is going to work. This continues to be a heavy concern, but I'm exploring what code in the LET-world would look like here.
Cards usually are written the other way, as 4♠ and not 4 (something about rendering in Discourse seems to think the latter notation is worthy of a much bigger spade...no idea why, might be worth finding out). But that would not be legal as a Rebol WORD!. The impedance match of such things is not a unique problem of Rebol, and there are more options like <4♠> while most languages would just have one string type. But it was a bit disappointing nonetheless to have to make the concession.
Returning OBJECT! still makes me uncomfortable, as I feel there's a real inelegance to the single OBJECT! coming back as MAKE OBJECT! [...], and it goes out of the domain of concrete parts fast. I'm worried about adding methods and having that look ugly. I've written about wanting to maybe find some grand unifying theory where OBJECT! is just some constrained optimized BLOCK!. But that feels distant. In short, I'm just a bit torn over the return format here... I want to feel like we made it better than the PBN, not worse.
Technical Issues Encountered While Writing This
I deliberately chose to use the UTF-8 characters for card suits in the code. Partially to make it look "cool", but also to exercise the code paths.
One of the big problem areas with doing so was the Windows Console. If I tried to paste any code containing the card suits, they'd be invisible. This is because the console layer has no idea what a PASTE is, so what Windows does is it simulates key-down and key-up events for every character as if you were typing them. They must have gotten something wrong, because the card suits were not getting key downs... only key ups. Others have faced this problem and worked around it., so I incorporated their workaround.
Next is that I got it in my head that I wanted to use the lighter notation of 'N to match a letter in the input rather than "N" or #"N". It's 3 fewer apostrophe-style marks than a string, and it seems there's no harm in allowing you to match WORD!s against strings. After all, Rebol2/Red/R3-Alpha allow you to FIND that way:
>> find "abchellodef" 'hello
So I went ahead and added that ability, for both WORD!s and INTEGER!s in strings. This kind of opens a can of worms--as we might ask why looking for an INTEGER! in a string wouldn't be searching for the codepoint. But you can do that with find some-string to char! some-int. BINARY! is another story, and with doors open for searching binaries for strings it's the case that searching for integers finds the byte value and not the string-ized representation of that integer as ASCII. It's something to think about.
I decided to use COLLECT, but when I did I realized the thing I was collecting was not KEEPing material from the input, but a synthesized card symbol. The KEEP we had has the default interpretation of assuming you mean a pattern:
>> parse "aaa" [collect data [some [keep "a"]]]
== ["a" "a" "a"]
But what if each time I see an "a", I want to keep a "b"? That's not coming from the input.
@rgchris and I have been discussing the three things you might want to do with DO-style code embedded into a parse:
vaporize the result (currently ()) - this is usually the traditional behavior of GROUP! in PARSE. But when used as a parameter to a rule, this could vary. e.g. change [some parse rule] (some code) will use the code to generate what to change to.
treat the result as a rule (currently :()) - this has become a favorite of mine, as it frees us from the oddity of PARSE's IF and trying to map control structures into PARSE. You don't have to pre-COMPOSE a PARSE rule, but every time the code is visited it effectively re-runs a composition.
fabricate material unavailable in input (currently :) - when you look at things like CHANGE or the particular need to KEEP something that isn't in the input series, you have to be able to run code to make that new data.
So the answer with this setup of "match a but keep b" would look like:
>> parse "aaa" [collect data [some ["a" keep :["b"]]]]
== ["b" "b" "b"]
Whatever our beliefs about notation, these are desires you can have. In this case I made : work as described so I could keep my synthesized data.
I wanted to make the KEEP rule look like:
keep :[join suit (either rank = 'T  [rank)]
Because I had the idea that if you matched a WORD! in your text input, that the SET would come back as the WORD! for the character... not the character itself. This is a concept that needs to be thought out more, because I'm not sure we completely understand the rationale discerning SET and COPY and what their behavior should be.
As usual, Rebol-ish code can be nice to look at once it's written...but the path to getting there can be pretty hard. As usual: a debugger would really help.