newRPL: Making RPL more readable
|
12-01-2016, 09:08 PM
Post: #1
|
|||
|
|||
newRPL: Making RPL more readable
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:
In a way it simplifies declaring multiple subroutines inside a larger program. Any other similar ideas? |
|||
12-02-2016, 02:34 AM
(This post was last modified: 12-02-2016 04:32 PM by compsystems.)
Post: #2
|
|||
|
|||
RE: newRPL: Making RPL more readable
Is very important in some way, control of the scope of the variables
ORIGINAL USER RPL HP48 PHP Code: « NEW RPL I: full scope PHP Code: « II limited scope, individual declaration NEW RPL PHP Code: « III limited scope, group declaration NEW RPL (LOCALS CMD) for n vars PHP Code: « |
|||
12-02-2016, 12:39 PM
Post: #3
|
|||
|
|||
RE: newRPL: Making RPL more readable
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. Graph 3D | QPI | SolveSys |
|||
12-02-2016, 02:20 PM
Post: #4
|
|||
|
|||
RE: newRPL: Making RPL more readable
(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: 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:
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:
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:25 PM
Post: #5
|
|||
|
|||
RE: newRPL: Making RPL more readable
(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:
|
|||
12-02-2016, 03:52 PM
(This post was last modified: 12-02-2016 10:03 PM by compsystems.)
Post: #6
|
|||
|
|||
RE: newRPL: Making RPL more readable
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: « The above code 100% RPN must be 1 'a' -> // The operator -> (LOCAL) (postfix notation) operand operand operator 100% RPN PHP Code: « or 100% RPN PHP Code: « 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: « 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: « I suggest using keywords, your? PHP Code: « or PHP Code: « or PHP Code: « PHP Code: « In my programs I also use, variable statics PHP Code: main A possible syntax in NEWRPL PHP Code: « or PHP Code: « |
|||
12-04-2016, 08:37 PM
Post: #7
|
|||
|
|||
RE: newRPL: Making RPL more readable
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, 11:35 PM
Post: #8
|
|||
|
|||
RE: newRPL: Making RPL more readable
(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-05-2016, 03:57 PM
Post: #9
|
|||
|
|||
RE: newRPL: Making RPL more readable
(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, 05:52 PM
Post: #10
|
|||
|
|||
RE: newRPL: Making RPL more readable
(12-05-2016 03:57 PM)compsystems Wrote: What do you think of what I propose? 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) 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 } -> 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 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-05-2016, 06:03 PM
Post: #11
|
|||
|
|||
RE: newRPL: Making RPL more readable
(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. |
|||
12-05-2016, 07:43 PM
(This post was last modified: 12-05-2016 07:44 PM by Han.)
Post: #12
|
|||
|
|||
RE: newRPL: Making RPL more readable
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.) Graph 3D | QPI | SolveSys |
|||
12-06-2016, 01:08 PM
Post: #13
|
|||
|
|||
RE: newRPL: Making RPL more readable
(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. 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-06-2016, 01:31 PM
Post: #14
|
|||
|
|||
RE: newRPL: Making RPL more readable
(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:
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:
(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-07-2016, 06:41 AM
Post: #15
|
|||
|
|||
RE: newRPL: Making RPL more readable | |||
12-07-2016, 07:37 AM
Post: #16
|
|||
|
|||
RE: newRPL: Making RPL more readable
(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. Graph 3D | QPI | SolveSys |
|||
12-07-2016, 08:06 AM
Post: #17
|
|||
|
|||
RE: newRPL: Making RPL more readable
Excellent, Han. Identifying blocks was exactly what I had on my mind.
|
|||
12-07-2016, 12:04 PM
(This post was last modified: 12-07-2016 12:50 PM by Vtile.)
Post: #18
|
|||
|
|||
RE: newRPL: Making RPL more readable
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 Code:
|
|||
12-07-2016, 12:44 PM
Post: #19
|
|||
|
|||
RE: newRPL: Making RPL more readable
(12-07-2016 07:37 AM)Han Wrote:(12-07-2016 06:41 AM)Thomas Radtke Wrote: Printing keywords in boldface would be nice. 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, 01:23 PM
Post: #20
|
|||
|
|||
RE: newRPL: Making RPL more readable
(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. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: