12-07-2016, 02:49 PM
Post: #21
 Claudio L. Senior Member Posts: 1,696 Joined: Dec 2013
RE: newRPL: Making RPL more readable
(12-07-2016 12:04 PM)Vtile Wrote:  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.

You are hitting it right on the nail: How can we preserve the user preferred folding across compile/decompile cycles? We simply can't! unless we store some "debug info" in the actual code, that's a waste of space.
That's why the only option is that the decompiler, with the help of the libraries, will have to decide for the user what's the best folding, indentation, etc.
If you want to keep the user's formatting, we could simply store the source code in a string after the object, again a waste of space that might be justified on some (future) hardware with more RAM, but not on the 50g target.
One thing that's already done, is that (persistent) comments include the newlines, so the user can permanently store newlines by adding empty comments. Not great, but it's a start!

(12-07-2016 12:04 PM)Vtile Wrote:  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)

This is more or less what the code would look like if you simply align the persistent comments, which can be done with the library "hint" system.
12-07-2016, 03:02 PM
Post: #22
 Claudio L. Senior Member Posts: 1,696 Joined: Dec 2013
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.

I think proper indent spacing is better than bold and grey background. If the end markers are visible on the screen, it is easy to identify where the block ends. If it's not on the screen, then the entire text on the screen will be bold/grey and you still don't know where it starts/ends.
If your code is way to the right, you know you are deep.
12-07-2016, 10:12 PM (This post was last modified: 12-07-2016 11:46 PM by Han.)
Post: #23
 Han Senior Member Posts: 1,820 Joined: Dec 2013
RE: newRPL: Making RPL more readable
(12-07-2016 03:02 PM)Claudio L. Wrote:  I think proper indent spacing is better than bold and grey background. If the end markers are visible on the screen, it is easy to identify where the block ends. If it's not on the screen, then the entire text on the screen will be bold/grey and you still don't know where it starts/ends.
If your code is way to the right, you know you are deep.

Unless the markers are unmatched. Even though the editor may properly place indentations, when a user makes an edit that adds/removes markers and their edits are on a single line (wider than the screen width -- quite possible and plausible), then it may not be so clear.

In this case, they could presumably re-run a menu command that "re-indents" everything (which could become a mess when markers are not properly matched) or they could have the editor attempt to locate a block through highlighting. In the former case, re-indentation could leave a mess of the source up until the problem is fixed and re-indentation is applied again. One could argue that the former case may also be a bit jarring since the screen would be refreshed to show presumably newly indented code. The latter case simply identifies blocks without modifying the user's source.

Another question I had regarding indentation is whether it will be similar to the HP48 which only indented key words (due to too little real estate to have too much be given to indentation). Will it be similar? Or closer to what is done on IDEs running on typical computers?

EDIT:

In the following example, seeing the markers on screen would suggest this nested list is properly formed. A highlight would show that the closing } is actually for the list of menu items and not the outer list.
Code:
{   { menuitem1 menuitem2 menuitem3 menuitem4 @ width larger than screen and no proper closing '}' }

Graph 3D | QPI | SolveSys
12-08-2016, 10:18 PM
Post: #24
 Claudio L. Senior Member Posts: 1,696 Joined: Dec 2013
RE: newRPL: Making RPL more readable
(12-07-2016 10:12 PM)Han Wrote:
(12-07-2016 03:02 PM)Claudio L. Wrote:  I think proper indent spacing is better than bold and grey background. If the end markers are visible on the screen, it is easy to identify where the block ends. If it's not on the screen, then the entire text on the screen will be bold/grey and you still don't know where it starts/ends.
If your code is way to the right, you know you are deep.

Unless the markers are unmatched. Even though the editor may properly place indentations, when a user makes an edit that adds/removes markers and their edits are on a single line (wider than the screen width -- quite possible and plausible), then it may not be so clear.

In this case, they could presumably re-run a menu command that "re-indents" everything (which could become a mess when markers are not properly matched) or they could have the editor attempt to locate a block through highlighting. In the former case, re-indentation could leave a mess of the source up until the problem is fixed and re-indentation is applied again. One could argue that the former case may also be a bit jarring since the screen would be refreshed to show presumably newly indented code. The latter case simply identifies blocks without modifying the user's source.

Another question I had regarding indentation is whether it will be similar to the HP48 which only indented key words (due to too little real estate to have too much be given to indentation). Will it be similar? Or closer to what is done on IDEs running on typical computers?

EDIT:

In the following example, seeing the markers on screen would suggest this nested list is properly formed. A highlight would show that the closing } is actually for the list of menu items and not the outer list.
Code:
{   { menuitem1 menuitem2 menuitem3 menuitem4 @ width larger than screen and no proper closing '}' }

12-18-2016, 04:11 AM (This post was last modified: 12-18-2016 12:42 PM by compsystems.)
Post: #25
 compsystems Senior Member Posts: 1,258 Joined: Dec 2013
RE: newRPL: Making RPL more readable
Hello,

1: coding on hp48/ 50 I always had problems to differentiate a variable from an algebraic expression.

X ^ 1 -> X is an algebraic expression and not a variable

I propose IDENTIFIER NAMES between the containers '' (39 ASCII)
AND ALGEBRAIC EXPRESSIONS between the containers ´´ (180 ASCII)

PHP Code:
{ 'X' 'Y'  'Z'  'W' } PURGE´Y´ 'X' STO´Y^2´ 'Z' STO« 1 2 + » 'W' STO'X' TYPE @ DOM_IDENTIFIERX TYPE @ DOM_ALGEXPR'X' RCL TYPE @ DOM_ALGEXPR'Z' TYPE @ DOM_IDENTIFIERZ TYPE @ DOM_ALGEXPR'W' TYPE @ DOM_IDENTIFIER'W' RCL TYPE @ DOM_PROGRAM

2: Another problem is that the variables within a list when evaluated, if they contain the container '' should be left as is

A trick to keep it is labeling it
PHP Code:
CLEAR{ 'X' 'Y'  } PURGEY 'X' STO{ X } EVAL     @ 'Y' OK{ 'X' } EVAL   @ 'Y' =(, 'X' =){ ::'X' } EVAL @  ::'X' OK{ ::'X' } EVAL DTAG @ 'X' OK« 1 2 + » 'W' STO{ W } EVAL     @ 3 OK{ 'W' } EVAL    @ 'W' OK´Y^2´ 'Z' STO{ Z } EVAL     @ ´Y^2´ OK{ 'Z' } EVAL     @  'Z' OK{ ´Y^2´  } EVAL    @ ´Y^2´ OK4 'Y' STO{ ´Y^2´  } EVAL  @ ´Y^2´ OK{ ´Y^2´ EVAL } EVAL  @ 16 OK

3: So that the codes are auto-documented using keywords, for several constants

PHP Code:
TRUE EVAL @ -> 1FALSE EVAL @ -> 0DOM_REAL EVAL -> 1DOM_INTEGER EVAL ->  1.2DOM_BININTEGER EVAL ->  1.3DOM_COMPLEX EVAL->  1.4DOM_STRING EVAL -> 2DOM_LIST EVAL -> 3DOM_MATRIX EVAL -> 3.1DOM_IDENTIFIER EVAL -> 4DOM_ALGEXPR EVAL -> 5DOM_UNIT EVAL -> 5.1DOM_PROGRAM -> 6DOM_DIR -> ......

PHP Code:
IF 'W' RCL TYPE DOM_PROGRAM == THEN ...
Instead of, that is not known that is #6
PHP Code:
IF 'W' RCL TYPE 6 == THEN ..
12-20-2016, 01:11 PM
Post: #26
 compsystems Senior Member Posts: 1,258 Joined: Dec 2013
RE: newRPL: Making RPL more readable
Hi, one of the problems of the hp48/50 series libraries is that they use an identifier number
And if two users create a library with the same number, there will be a conflict, my proposal is to use the name of the library as reference

PHP Code:
dirNameDIRprg00<<libraryName.id00>>prg01<<...>>...END_DIR

PHP Code:
libraryNameLIBid00<<...>>id01<<...>>...END_LIB

Another problem is that IDs in a directory are easily rewritten, a LOCK CMD is required to block. And another to hide variables, which can only be visible from the FILES KEY

PHP Code:
dirNameDIRLOCK prg00<<libraryName.id00>>LOCK HIDDEN prg01<<...>>HIDDEN prg02<<...>>...END_DIR

PHP Code:
LOCK dirNameDIR...END_DIR
12-20-2016, 09:22 PM
Post: #27
 Claudio L. Senior Member Posts: 1,696 Joined: Dec 2013
RE: newRPL: Making RPL more readable
(12-18-2016 04:11 AM)compsystems Wrote:  I propose IDENTIFIER NAMES between the containers '' (39 ASCII)
AND ALGEBRAIC EXPRESSIONS between the containers ´´ (180 ASCII)

Straight to the point... I think it's redundant, what exactly does it achieve?
If X is 3 then
'X' EVAL
´X´ EVAL
are exactly the same thing.
What if you have an identifier and you try to operate on it?
'X' 2 / --> ´X+2´ (change of type???)

If the sole purpose is so the symbolic type can also have independent identifiers, it doesn't help much, as a number is also an algebraic expression, and it needs special treatment anyway.

(12-18-2016 04:11 AM)compsystems Wrote:  3: So that the codes are auto-documented using keywords, for several constants

Enums and other system convenience constants could be a good idea.

(12-20-2016 01:11 PM)compsystems Wrote:  Hi, one of the problems of the hp48/50 series libraries is that they use an identifier number
And if two users create a library with the same number, there will be a conflict, my proposal is to use the name of the library as reference
And now you have name conflicts, very little improvement, and significant slowdown if every command has to be searched by library name,.

(12-20-2016 01:11 PM)compsystems Wrote:  Another problem is that IDs in a directory are easily rewritten, a LOCK CMD is required to block. And another to hide variables, which can only be visible from the FILES KEY
HIDEVAR is already implemented and working, you can hide any variables you want. I didn't think of the LOCKVAR mechanism, I think it would be nice to lock programs from being overwritten, I'll implement this.
12-22-2016, 04:58 PM (This post was last modified: 12-22-2016 05:10 PM by compsystems.)
Post: #28
 compsystems Senior Member Posts: 1,258 Joined: Dec 2013
RE: newRPL: Making RPL more readable
(12-20-2016 01:11 PM)compsystems Wrote:  Hi, one of the problems of the hp48/50 series libraries is that they use an identifier number
And if two users create a library with the same number, there will be a conflict, my proposal is to use the name of the library as reference
> And now you have name conflicts,
It is better to know that there is conflict by name than by number

See full example below
PHP Code:
DIR  PRG1 ID1 @ ID1 FROM LIB #1000 OR #1001?  PRG2 ID2 @ ID2 FROM LIB #1000 OR #1001?  PRG3 ID3 @ ID2 FROM LIB #1000 OR #1001?END

> significant slowdown if every command has to be searched by library name,.
From user RPL I think it is the only solution to know that ID belongs to a certain library

@ CURRENT RPL FOR LIBS AND LIBS
PHP Code:
@LIBRARY #1000DIR  ID1 obj1  ID2 obj2  ID3 obj3  ID4 obj4  $VISIBLE { ID1, ID2, ID3 }$HIDDEN { ID4 }  $ROMID 1000$CONFIG « 1000 ATTACH »  $TITLE "LIB1NAME"END CRLIB@LIBRARY #1001DIR ID1 obj1 ID2 obj2 ID3 obj3 ID4 obj4$VISIBLE { ID1, ID2, ID3 }  $HIDDEN { ID4 }$ROMID 1001  $CONFIG « 1001 ATTACH »$TITLE "LIB2NAME"END CRLIB------------------------------DIR  PRG1 ID1 @ ID1 FROM LIB #1000 OR #1001?  PRG2 ID2 @ ID2 FROM LIB #1000 OR #1001?  PRG3 ID3 @ ID2 FROM LIB #1000 OR #1001?END------------------------------@NEW RPL (MY IDEA)DIRECTORY  PRG1 LIB1NAME.ID1 @ ID1 FROM LIB #1000  PRG2 LIB1NAME.ID1 @ ID1 FROM LIB #1001  PRG3 LIB2NAME.ID2 @ ID2 FROM LIB #1001END_DIRLIB1NAMELIBRARY  ID1 obj1  ID2 obj2  ID3 obj3  ID4 obj4  HIDEVAR ID4 END_LIBRARYLIB2NAMELIBRARY  ID1 obj1  ID2 obj2  ID3 obj3  ID4 obj4  HIDEVAR ID4 END_LIBRARY

Any better idea?
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)