newRPL: Making RPL more readable

[Claudio L.]

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

[Claudio L.]

(12-07-2016 01:23 PM)Thomas Radtke Wrote:  

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

[Han]

(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 '}'
}

[Claudio L.]

(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 '}'
}

All good points, need to think about this some more.

[compsystems]

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_IDENTIFIER
X TYPE @ DOM_ALGEXPR
'X' RCL TYPE @ DOM_ALGEXPR

'Z' TYPE @ DOM_IDENTIFIER
Z 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'  } PURGE
Y '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´ OK
4 '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 @ -> 1
FALSE EVAL @ -> 0

DOM_REAL EVAL -> 1
DOM_INTEGER EVAL ->  1.2
DOM_BININTEGER EVAL ->  1.3
DOM_COMPLEX EVAL->  1.4
DOM_STRING EVAL -> 2
DOM_LIST EVAL -> 3
DOM_MATRIX EVAL -> 3.1
DOM_IDENTIFIER EVAL -> 4
DOM_ALGEXPR EVAL -> 5
DOM_UNIT EVAL -> 5.1
DOM_PROGRAM -> 6
DOM_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 .. 


[compsystems]

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:

dirName
DIR

prg00
<<
libraryName.id00
>>

prg01
<<
...
>>

...

END_DIR 


PHP Code:

libraryName
LIB

id00
<<
...
>>

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:

dirName
DIR

LOCK prg00
<<
libraryName.id00
>>

LOCK HIDDEN prg01
<<
...
>>

HIDDEN prg02
<<
...
>>

...

END_DIR 


PHP Code:

LOCK dirName
DIR

...

END_DIR 


[Claudio L.]

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

[compsystems]

(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 #1000
DIR
  ID1 obj1

  ID2 obj2

  ID3 obj3

  ID4 obj4

  $VISIBLE { ID1, ID2, ID3 }

  $HIDDEN { ID4 }

  $ROMID 1000
  $CONFIG « 1000 ATTACH »

  $TITLE "LIB1NAME"
END CRLIB

@LIBRARY #1001
DIR
  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 #1001
END_DIR

LIB1NAME
LIBRARY
  ID1 obj1

  ID2 obj2

  ID3 obj3

  ID4 obj4

  HIDEVAR ID4 
END_LIBRARY

LIB2NAME
LIBRARY
  ID1 obj1

  ID2 obj2

  ID3 obj3

  ID4 obj4

  HIDEVAR ID4 
END_LIBRARY 


Any better idea?