HP Forums - newRPL: Making RPL more readable

Pages: 1 2

When reading this thread, I started thinking that there must be a way to make RPL look more human and modern without completely changing it.
I'm opening this thread to discuss ideas to achieve this.

I'll throw the first idea to start a discussion:

Declare local variables with infix notation:

LOCAL 'a' obj1
LOCAL 'b' obj2

where << LOCAL 'a' obj >> is simply an alias for:
obj 'a' LSTO

An example:

Code:

<<

     LOCAL 'avg'

             << + 2 / >>

      LOCAL 'rms'

              << * √ >>

     @ MAIN PROGRAM

     2 4 avg

     2 4 rms

>>

In a way it simplifies declaring multiple subroutines inside a larger program.

Any other similar ideas?

Is very important in some way, control of the scope of the variables

ORIGINAL USER RPL HP48

PHP Code:

«
  @ Definition and declaration of LOCAL VARS
  « * SQRT  »
  « + 2 / »
  -> rms avg
  « @ Initiates the scope of local variables: rms, avg
    @ MAIN PROGRAM
    2 4 avg
    2 4 rms
  » @ Finish the scope of local variables, rms, avg
  avg @ returns 'avg' : OK Variable not defined
» 

NEW RPL
I: full scope

PHP Code:

«
  @ Definition and Declaration of LOCAL VARS
  LOCAL 'rms' « * v  » 
  LOCAL 'avg' « + 2 / » 
  @ Initiates the scope of local variables: rms, avg
    @ MAIN PROGRAM
    2 4 avg
    2 4 rms
» @ Finish the scope of local variables, rms, avg 

II limited scope, individual declaration
NEW RPL

PHP Code:

«
  @ Declaration of LOCAL VARS
  LOCAL 'rms'
  LOCAL 'avg'
  « @ Initiates the scope of local variables: rms, avg
    @ MAIN PROGRAM
    @ Definition
    « * SQRT  » 'rms' STO
    « + 2 / » 'avg' STO
    2 4 avg
    2 4 rms
  » @ Finish the scope of local variables, rms, avg
  avg @ returns 'avg' : OK Variable not defined
» 

III limited scope, group declaration
NEW RPL (LOCALS CMD) for n vars

PHP Code:

«
  @ Declaration of LOCAL VARS
  LOCALS 'rms' 'avg'
  « @ Initiates the scope of local variables: rms, avg
    @ MAIN PROGRAM
    @ Definition
    « * SQRT  » 'rms' STO
    « + 2 / » 'avg' STO
    2 4 avg
    2 4 rms
  » @ Finish the scope of local variables, rms, avg
  avg @ returns 'avg' : OK Variable not defined
» 

I suppose I am a bit more conservative with respect to the syntax. As more features are added (whether for legibility or ease of use), the language becomes a mixed bag of pre- and post-fix and coding becomes an exercise in which command uses which syntax.

Is:

obj 'name' LSTO

that much more legible than:

LOCAL 'name' obj

(do note that it takes a few more characters to type LOCAL vs LSTO). If the obj is large then neither case really has an advantage over the other.

(12-02-2016 12:39 PM)Han Wrote: [ -> ]I suppose I am a bit more conservative with respect to the syntax. As more features are added (whether for legibility or ease of use), the language becomes a mixed bag of pre- and post-fix and coding becomes an exercise in which command uses which syntax.

Good point. There needs to be limits to the changes, and any new syntax needs to be more natural than the old, otherwise there's no point. I'm with you in keeping it clean.

(12-02-2016 12:39 PM)Han Wrote: [ -> ]Is:

obj 'name' LSTO

that much more legible than:

LOCAL 'name' obj

(do note that it takes a few more characters to type LOCAL vs LSTO). If the obj is large then neither case really has an advantage over the other.

In the example I proposed, no. But in larger programs, reading the name of the subroutine *before* the code gives you much more understanding of what you are reading, especially if you are reading it on a small screen.
You see:

Code:

<<

LOCAL 'Average'

<<

...

And you know the code that follows is a subroutine named Average, and you can decide if you want to read it or skip over that code into more interesting things.
Versus:

Code:

<<

<<

...

In this case you need to scroll all the way to the end of the code to see if the coder even bothered naming it.

For simple variables I agree there's no advantage:
4 'a' LSTO and LOCAL 'a' 4 is about the same thing because you can see it all at once.

I guess the same could be achieved simply by reversing the arguments:

Code:

'Average'

<<

...

>>

LSTO

Could work as well. I think I could add that if Level 1 is not an IDENT but level 2 is, then STO and LSTO would simply reverse the arguments. The only ambiguous case would be if two idents are given, in such case the classic syntax would prevail.

(12-02-2016 02:34 AM)compsystems Wrote: [ -> ]Is very important in some way, control of the scope of the variables

newRPL already has scoped locals, you can define a scope any time using :: ; (in addition of the classic syntax: -> var1 ... varn << ... >> )

Code:

<<

1 'a' LSTO

@ FROM NOW ON 'a' EXISTS IN THIS << >> BLOCK

::

@ 'a' STILL EXISTS IN HERE

1 'b' LSTO

@ 'b' EXISTS FROM HERE ON, BUT ONLY WITHIN THE :: ; DELIMITERS

;

@ 'b' NO LONGER EXISTS HERE, BUT 'a' STILL DOES

>>

@ 'a' NO LONGER EXISTS HERE

Hello: the user RPL (hp48) is not 100% RPN (Reverse Polish notation)

sample
1 -> a // The operator -> (LOCAL) is in the middle (infix notation) operand operator operand

PHP Code:

«
  0 1 -> z a @ infix notation for LOCAL operator (->)
  « 
    2 -> b 
    « 
       z @ returns 0. var 'z' STILL EXISTS IN HERE
       a @ returns 1. var 'a' STILL EXISTS IN HERE
       b @ returns 2. var 'b' EXISTS FROM HERE ON
    »  
    z a b @ returns 0, 1, 'b', var 'b'  NO LONGER EXISTS HERE, BUT 'a' &  'z' STILL DOES
  » 
   z a b @ returns 'z' 'a' 'b'
» 

The above code 100% RPN must be
1 'a' -> // The operator -> (LOCAL) (postfix notation) operand operand operator

100% RPN

PHP Code:

«
  0 'z' ->
  1 'a' -> 
  « 
    2 'b' -> 
    « 
       z @ returns 0. var 'z' STILL EXISTS IN HERE
       a @ returns 1. var 'a' STILL EXISTS IN HERE
       b @ returns 2. var 'b' EXISTS FROM HERE ON
    »  
     z a b @ returns 0, 1, 'b'. var 'b'  NO LONGER EXISTS HERE, BUT 'a' &  'z' STILL DOES
  » 
   z a b @ returns 'z' 'a' 'b'
» 

or

100% RPN

PHP Code:

«
  { 0, 1 } { z a } ->
  « 
    2 'b' -> 
    « 
       z @ returns 0. var 'z' STILL EXISTS IN HERE
       a @ returns 1. var 'a' STILL EXISTS IN HERE
       b @ returns 2. var 'b' EXISTS FROM HERE ON
    »  
     z a b @ returns 0, 1, 'b'. var 'b'  NO LONGER EXISTS HERE, BUT 'a' &  'z' STILL DOES
  » 
   z a b @ returns 'z' 'a' 'b'
» 

but I agree more with prefix notation (POLISH NOTATION) that infix notation.
Prefix notation, at only some parts of the code, for example to declare local & static variables

PHP Code:

«
  -> 'z' 0 @ LOCAL 0 'z'
  LOCAL 'a' 1 
  « 
   ....
  »
» 

I do not like ( :: ; ) for a sub-block or scope, It gives the appearance of low-level language, and less readable. In addition :: ; these delimiters do not comply with the rule opening-close as [ ] or { } or < > or « » or ´ ` or ( ).
The colon can be used for other purposes such as labeling
(3,4) "x1" ->TAG, But keep it when stored (3,4) "x1" ->TAG 'sol1' STO
sol1 [enter] :x1: (3,4)

PHP Code:

«
  1 -> a @ 1 'a' LSTO
  « @ ::
    2  -> b @ 2 'b' LSTO
    « @ ::
       a @ 1
       b @ 2
    »  @;
    a b @ 1 'b'
  » @;
» 

I suggest using keywords, your?

PHP Code:

«
  LOCAL 'z' 0 
  LOCAL 'a' 1
  BLOCK 
   ....
  ENDBLOCK
» 

PHP Code:

«
  LOCAL { z a } { 0 1 }
  BLOCK 
   ....
  ENDBLOCK
» 

PHP Code:

«
  { 0 1 } { z a } LSTO
  BLOCK 
   ....
  ENDBLOCK
» 

PHP Code:

«
  LOCAL { a b c d e f g ... } 0 @ Assigns to all variables the value of 0
  BLOCK 
   ....
  ENDBLOCK
» 

In my programs I also use, variable statics

PHP Code:

main
«
   0 -> <-a
  «
     <-a @ 0
      f1
     <-a @ 1 
      f1 
     <-a @ 2
      f2 
     <-a @ 8
  »
»

f1
«
  <-a 1 + '<-a' STO
»

f2
«
  <-a 3 ^ '<-a' STO
» 

A possible syntax in NEWRPL

PHP Code:

«
  STATIC 'z' 0
  STATIC 'a' 1
  BLOCK 
   ....
  ENDBLOCK
» 

PHP Code:

«
  { 0 1 } { 'z' 'a' } SSTO
  BLOCK 
   ....
  ENDBLOCK
» 

Perhaps the issue is more one of improving presentation rather than altering syntax and semantics. More visual sugar in editor or prettyprinting than altering the language. RP is to my mind still an attractive and desirable form.

(12-04-2016 08:37 PM)ColinJDenman Wrote: [ -> ]Perhaps the issue is more one of improving presentation rather than altering syntax and semantics. More visual sugar in editor or prettyprinting than altering the language. RP is to my mind still an attractive and desirable form.

For example? What kind of visual sugar could we implement to make it more readable? Indenting the code is a given, what else should the editor do?

(12-04-2016 08:37 PM)ColinJDenman Wrote: [ -> ]Perhaps the issue is more one of improving presentation rather than altering syntax and semantics.

first work on the language (syntax and semantics) then on the presentation (pretty-print)

What do you think of what I propose?

1: Sentence body between keywords
::
...
;

=>

BLOCK
...
ENDBLOCK

3: Syntax as PN (prefix notation) only for declarations and definitions of vars, not IN (infix notation)

LOCAL { z a } { 0 1 }

LOCAL { a b c d e f g ... } 0 @ Assigns to all variables the value of 0

{ 0, 1 } { z, a } ->
In place of
0 1 -> z a @ IN (infix notation)

4: static vars

«
STATIC 'z' 0
STATIC 'a' 1
BLOCK
....
ENDBLOCK
»

(12-05-2016 03:57 PM)compsystems Wrote: [ -> ]What do you think of what I propose?

1: Sentence body between keywords
::
...
;

=>

BLOCK
...
ENDBLOCK

Too much to type, perhaps we can choose some Unicode brackets, or some combination, similar to the normal brackets:
«: :»
«[ ]»
«| |»

and assign them to the keyboard near the << >> brackets.

(12-05-2016 03:57 PM)compsystems Wrote: [ -> ]3: Syntax as PN (prefix notation) only for declarations and definitions of vars, not IN (infix notation)

LOCAL { z a } { 0 1 }

LOCAL { a b c d e f g ... } 0 @ Assigns to all variables the value of 0

This is the same grammar I proposed but accepting lists, it can be done.

(12-05-2016 03:57 PM)compsystems Wrote: [ -> ]{ 0, 1 } { z, a } ->
In place of
0 1 -> z a @ IN (infix notation)

Existing syntax has to remain untouched for compatibility, so the -> operator will remain the same. The old syntax is good when it's used at the beginning of a routine, it shows clearly what the arguments are, I like that syntax.

(12-05-2016 03:57 PM)compsystems Wrote: [ -> ]4: static vars

«
STATIC 'z' 0
STATIC 'a' 1
BLOCK
....
ENDBLOCK
»

I don't know what you mean by static vars, if you mean "compiled" as the manual calls them, they don't exist in newRPL, they were just an artifact of how old RPL worked more than a feature of the language.

(12-04-2016 11:35 PM)Claudio L. Wrote: [ -> ]For example? What kind of visual sugar could we implement to make it more readable? Indenting the code is a given, what else should the editor do?

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.

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.

If we can use \ for escape characters, perhaps newRPL can use a special escape sequence as an alias for << (the actual character, not my poor representation using two "less than" symbols). Similarly for >>. And \BS for the actual backslash character (or whatever the standard escape sequence is for this character). Maybe \LP and \RP for "left program" and "right program" symbols? This makes it easier to program on a PC without needing character translation.

(Basically, bypassing any translation that would normally occur during file transfers like back in the HP48 days would be good since most people are going to get more speed from their SD card.)

(12-05-2016 07:43 PM)Han Wrote: [ -> ]If we can use \ for escape characters, perhaps newRPL can use a special escape sequence as an alias for << (the actual character, not my poor representation using two "less than" symbols). Similarly for >>. And \BS for the actual backslash character (or whatever the standard escape sequence is for this character). Maybe \LP and \RP for "left program" and "right program" symbols? This makes it easier to program on a PC without needing character translation.

(Basically, bypassing any translation that would normally occur during file transfers like back in the HP48 days would be good since most people are going to get more speed from their SD card.)

You mean adding a preprocessing step to replace all the backslashes? We could have a separate command to escape/unescape (is that even a word?) those sequences. However, most modern editors on a PC are Unicode compatible, so there's no translation needed, all symbols will look the same on the editor. All you'd need to do is create a few macro key assignments on your favorite editor for the most common RPL symbols.
Right now there's no "translation" during file transfer. All text in newRPL is written as-is to text files. Escaping characters would *add* a translation layer.

(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.

(12-04-2016 11:35 PM)Claudio L. Wrote: [ -> ]For example? What kind of visual sugar could we implement to make it more readable? Indenting the code is a given, what else should the editor do?

Printing keywords in boldface would be nice.

(12-07-2016 06:41 AM)Thomas Radtke Wrote: [ -> ]
(12-04-2016 11:35 PM)Claudio L. Wrote: [ -> ]For example? What kind of visual sugar could we implement to make it more readable? Indenting the code is a given, what else should the editor do?
Printing keywords in boldface would be nice.

I think a program would likely have lots of key words and most of it may end up being bolded. But what about bolding keywords that form blocks when the cursor is on one of the components? And similarly for brackets/parentheses/lists. In most programming editors, one can place a cursor on a delimiter and it will highlight the paired symbols. In this case, we could use bold. Similarly, if someone places a cursor on an IF THEN END block, then the key words "IF" "THEN" and "END" could be bolded (or even the entire block itself) until the cursor is moved out of the block. Or since we have greyscale, leave the font as is and just change the background to a light grey. This would allow a bold font to be used by the user without causing confusion with bold having some other meaning.

Excellent, Han. Identifying blocks was exactly what I had on my mind.

Even a decent editor with proper code folding would make the RPL programs a light year more readable, compared to the current state where once edited the program looks like a dropped through the blender. That is with the regular editor that comes with the 50g. Edit. That said, the problem with automatic code folding will come with the highly modular library system that is on the NewRPL I would quess, so if the programs would retain the same folding as the user have typed in might be the most efficient solution instead of trying to create "do it all" system where the code folding information would need to be written in the libraries. If that is what will be done (the code folding information to libraries) I would like to see it as optional information that can be stripped down, in case of you need those bytes to something more important things in your calculator.

One other big deal with the programs (while mine aren't complex) is the use of repeated stack manipulation which often makes the program hard to read after some time. Paired with unability to write even tiny few letter persistent comments makes it pita. Edit. So I come with this idea of "split screen mode" copied from the AUR, where on the left is the code and on the right are the (first) comments per line. With one key you could cycle the comment half of the sceen OFF/Double view/full screen. (example S7 IL code: http://1.bp.blogspot.com/-8p6aBJ_3AR4/Ti...bslawl.png)

These aren't much of the language, but more of the IDE side of the things. As a side note, I like the ability to write some mathematical formulas in algebraic format.

There is not much in general that you can do with the tiny screen of the calculator so KISS.

Code:

<< DEPTH Y → X Y 

<< 2 'Y' STO

2 X START

Y PICK

2 Y + 'Y' STO

NEXT

X →LIST

X ROLLD

X 1 - DROPN

OBJ→ DROP

>>

>>

Code:

<< 

 DEPTH Y → X Y         @Crte LVars

 <<                          @Main sub.

  2 'Y' STO                @Save starting value

   2 X START             @Main loop

     Y PICK                 @Which item to pick

     2 Y + 'Y' STO           

   NEXT                    @END Main loop

  X →LIST

  X ROLLD

  X 1 - DROPN           @Count format conversion

  OBJ→ DROP            

 >>                         @END Main Sub

>>

(12-07-2016 07:37 AM)Han Wrote: [ -> ]
(12-07-2016 06:41 AM)Thomas Radtke Wrote: [ -> ]Printing keywords in boldface would be nice.

I think a program would likely have lots of key words and most of it may end up being bolded. But what about bolding keywords that form blocks when the cursor is on one of the components? And similarly for brackets/parentheses/lists. In most programming editors, one can place a cursor on a delimiter and it will highlight the paired symbols. In this case, we could use bold. Similarly, if someone places a cursor on an IF THEN END block, then the key words "IF" "THEN" and "END" could be bolded (or even the entire block itself) until the cursor is moved out of the block. Or since we have greyscale, leave the font as is and just change the background to a light grey. This would allow a bold font to be used by the user without causing confusion with bold having some other meaning.

This kind of bolding will work efficiently only with the depth of 1, not when there is ie. depth of 3 or 13 of IF structures etc.

(12-07-2016 12:44 PM)Vtile Wrote: [ -> ]This kind of bolding will work efficiently only with the depth of 1, not when there is ie. depth of 3 or 13 of IF structures etc.

Why not?

Of course, one could use a grey background for the outer block, a light grey one for the first block inside, again grey for the next level and so on.

Pages: 1 2