newRPL: Making RPL more readable

[Claudio L.]

(12-05-2016 06:03 PM)ColinJDenman Wrote:  Well, in the other thread, you noted the "ugly senseless sequence of tokens", so I would think that is a fruitful area to attack. Emphasising the grouping of tokens into larger units, perhaps with varying font or other delimiting marks.

Here's what I was planning to implement for that:
The decompiler will "ask" libraries for hints while decompiling text. Those hints will be for example "add newline after this token", "increase indent" "decrease indent" and others that we can come up with.
While running a decompile session, the decompiler will act or not on those hints depending on what the user wants (some flags could control how you like your sources decompiled), for example if the user wants all the text in a single line, the decompiler won't add any newlines or indent spacing.
When decompiling for example <<, the library will suggest the decompiler to add a newline and increase indent. While decompiling THEN for example, the hint would be "newline before, decrease indent before, increase indent after, newline after", so that:

Code:


    IF @ NEWLINE AFTER, INCREASE INDENT AFTER
        1 2 ==
    THEN @ NEWLINE BEFORE, REDUCE INDENT TO LINE IT UP WITH IF, THEN NEWLINE AFTER AND INCREASE INDENT.
        ...
    END @ NEWLINE BEFORE, DECREASE INDENT BEFORE, NEWLINE AFTER

This way, each command can be customized in its presentation. Another hint could be a weak newline, indicating that when the line has several commands, this is a good place to end the line. For example the STO command could hint a weak newline after.

Code:


10 2 / + 'X' STO 4 'V' STO DROP SWAP @ WITHOUT ANY HINTS THE DECOMPILER DOESN'T KNOW WHEN TO STOP

@ VERSUS:
10 2 / + 'X' STO @ THERE'S 6 TOKENS ON THIS LINE, SO IT'S A GOOD PLACE TO SUGGEST A NEWLINE
4 'V' STO DROP SWAP @ ONLY 3 OBJECTS AT STO, SO DON'T ADD A NEWLINE YET

(12-05-2016 06:03 PM)ColinJDenman Wrote:  If, on the other hand your interest lies in moving away from RP to an ALGOL style, then you might as well adopt the Prime PPL style and have done with it. I would have nothing to say in that regard.

Not really moving "away" from RP, just making it more readable. Many semantic constructs in the language are not RP:

IF ... THEN ... ELSE ... END
While the true RP version is:
test-clause true-statement false-statement IFTE

The idea is to add other similar constructs that could make it readable but without departing too much from the RPL concept.