Post Reply 
newRPL: Making RPL more readable
12-07-2016, 02:49 PM
Post: #21
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.
Find all posts by this user
Quote this message in a reply
12-07-2016, 03:02 PM
Post: #22
RE: newRPL: Making RPL more readable
(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.
Find all posts by this user
Quote this message in a reply
12-07-2016, 10:12 PM (This post was last modified: 12-07-2016 11:46 PM by Han.)
Post: #23
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
Find all posts by this user
Quote this message in a reply
12-08-2016, 10:18 PM
Post: #24
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 '}'
}

All good points, need to think about this some more.
Find all posts by this user
Quote this message in a reply
12-18-2016, 04:11 AM (This post was last modified: 12-18-2016 12:42 PM by compsystems.)
Post: #25
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_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
'X' STO
} EVAL     @ 'Y' OK
'X' } EVAL   @ 'Y' =(, 'X' =)
{ ::
'X' } EVAL @  ::'X' OK
{ ::'X' } EVAL DTAG 'X' OK

« 1 2 
» 'W' STO
} EVAL     @ 3 OK
'W' } EVAL    @ 'W' OK

´Y
^2´ 'Z' STO
} EVAL     @ ´Y^2´ OK
'Z' } EVAL     @  'Z' OK

´Y^2´  } EVAL    @ ´Y^2´ OK
'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 .. 
Find all posts by this user
Quote this message in a reply
12-20-2016, 01:11 PM
Post: #26
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:
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 
Find all posts by this user
Quote this message in a reply
12-20-2016, 09:22 PM
Post: #27
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.
Find all posts by this user
Quote this message in a reply
12-22-2016, 04:58 PM (This post was last modified: 12-22-2016 05:10 PM by compsystems.)
Post: #28
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 #1000
DIR
  ID1 obj1

  ID2 obj2

  ID3 obj3

  ID4 obj4

  $VISIBLE 
ID1ID2ID3 }

  
$HIDDEN ID4 }

  
$ROMID 1000
  $CONFIG « 1000 ATTACH »

  $TITLE 
"LIB1NAME"
END CRLIB

@LIBRARY #1001
DIR
  ID1 obj1

  ID2 obj2

  ID3 obj3

  ID4 obj4

  $VISIBLE 
ID1ID2ID3 }

  
$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?
Find all posts by this user
Quote this message in a reply
Post Reply 




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