newRPL: Output to a text console

[Claudio L.]

One of the things I don't like much about RPL is that the display can only be used temporarily, and you have to FREEZE it so the user can see it. After that, everything you displayed is immediately lost.

So here's an idea (not exactly a *new* idea since text consoles have been around for quite some time...): Add a text console, something like PICT but for text. You can clear it, output as much formatted text as you want, then leave it there for the user to see it (whenever he wants!). There would have to be a console viewer, just like there is a PICT viewer. The contents of the console should be able to be copied to the stack, the clipboard and/or saved to a text file on the SD card.

And the big question: what for?
* Most old Fortran and BASIC programs use PRINT and similar to a console, so it should make it simpler to port code from other platforms to newRPL.
* The user can write programs that produce formatted text output that can be saved to SD card and printed on a PC to document the calculations made. Very often I find myself redoing something in Excel that I already have finished on the calc, just because I need to document it.


Discussion is open: is this something worth putting time on?

[Francois Lanciault]

Yes definitely!

Console are also very useful while debugging.

Francois

[DavidM]

I believe this is a worthy goal. I'll be interested in seeing if others perceive the same need for this, though. My use of calculators nowadays is probably far less
"math-focused" than most here.

Several recent programs I've worked on seem to have all benefited from presenting multi-line output in the form of a large string object that was then displayed using the 50g's built-in editor (SysRPL InputLine). This allows the user to scroll the text as needed to see the output, which has a very natural feel to it IMHO. A console would fit nicely with this model, and could perhaps extend it to be more interactive as well (allowing, say, input as well as output).

An example of where a console would have been handy:

I recently created a "Body Metrics" program to help me track my Body Mass Index and several related measurements. I used an input form to present/edit the five variables, then a series of 9 items are determined from that input and presented (along with the original values) in list form. As I also have a printer handy, this list can be printed at the touch of a button. Having a console to display the info would have been very useful, especially if that console enabled features such as navigation/scrolling and printing.

To help illustrate this, here's the input form (obviously not my data ):


...part of the output (scrolled down) on the display:


...and the actual text of the output:

Code:

------------------------
Gender: Female
Age:    35 yr
Weight: 59.0 kg
Height: 162.6 cm
ActLvl: Active
------------------------
BMI:    22.31 kg/m^2
Nrm Wt: 48.9 - 66.1 kg
Class:  Normal Weight
IBW:    54.7 kg
ABW:    N/A
LBW:    42.1 kg
BSA:    1.648 m^2
BMR:    1270 kcal
DlyCal: 2190 kcal

[Claudio L.]

OK, so it's not just me liking a console therefore this project will begin.

It will definitely be interactive with (fast) scrolling.
For aesthetics I thought of 2 possibilities (more ideas are welcome):
a) The console pops from the top (like Quake's console) and covers the stack as you write to it. When the console contains only a couple of lines it will look like a message popup on top of the screen.
b) The console is always fullscreen, and upon first write it replaces the stack view until the user chooses to stop viewing it.

In both cases there will be a key that will bring the console viewer (much like the PICT key would display the graphics screen).

Option a) I think could be interesting for cases when you want to ask something with INPUT. The user will get the input message shown above the command line, the command line will open at the usual place, but you could also clear the console and print perhaps 2 or 3 lines with an explanation of what your program is asking of the user.
So you would see the explanation from the top, then the prompt and the command line at the bottom.

[Vtile]

Sounds handy feature. The UserRPL output commands are indeed a bit cumbersome to use and I find myself usually just dumping the explanary text as a string object to the stack. While it works and the console is pretty identical between, the stack do have limitation in formatting and in the fact that there is no "Page break" inbuild to system to separate parts of the stack for easy cleaning, copying and so forth. With console you would have the sketch paper (stack) and final copy (console). I wouldn't mind if the console would also allow a grob objects as input and show them statically (without editor functionality) in that line of prompt where they were included. That way you could also include a infographic in your output if needed (it would be then close to a virtual printer).

So you need a new object called console and it is stored in the current directory like pictures??

[Claudio L.]

(01-13-2017 10:37 AM)Vtile Wrote:  Sounds handy feature. The UserRPL output commands are indeed a bit cumbersome to use and I find myself usually just dumping the explanary text as a string object to the stack. While it works and the console is pretty identical between, the stack do have limitation in formatting and in the fact that there is no "Page break" inbuild to system to separate parts of the stack for easy cleaning, copying and so forth. With console you would have the sketch paper (stack) and final copy (console). I wouldn't mind if the console would also allow a grob objects as input and show them statically (without editor functionality) in that line of prompt where they were included. That way you could also include a infographic in your output if needed (it would be then close to a virtual printer).

So you need a new object called console and it is stored in the current directory like pictures??

I like the idea of being able to mix text and graphics on the console. But not GROB objects per se. The idea is for newRPL to have PLOT objects, which are vector graphics, in a compact format designed to be similar to SVG so it can easily be exported to SVG.
I think vector graphics are much more flexible for the type of sketches and function plots that are usually needed in engineering, and can be rescaled for printing without losing quality. Also PICT will be a PLOT object, therefore you should be able to insert a function plot directly into the console output.

So now we'll have a text console that can mix-in some vector graphics... starting to sound too much like a web browser (I can see it coming: compsystems will request javascript support :-). On the positive side, it would be nice to be able to export the console text to HTML with embedded SVG sketches, so whatever you worked on your calc can be viewed on any browser.

Regarding where to store the console, if we think applications will be organized (enclosed) in a directory, it makes sense for each application to have its independent console, so that running an app doesn't overwrite the output of another. Putting the console in a (hidden? visible?) variable 'CONSOLE' or 'Console' (to make it less conflictive with user variables) seems like a good choice. And don't forget, to avoid directory clutter you can always create a local variable with that name before writing to the console. All writes to the console will be directed to your local variable, working more like "private" consoles for each routine, that get cleaned up automatically when the local variable goes out of scope.

[Claudio L.]

Another idea, that deviates a bit from a traditional console (expanding on DavidM's idea above):

Extending the idea of putting graphics: how about putting input controls? and evaluation of formulas? or running code?
Then this console browser will become the replacement of the INFORM system. The console would become more like a MathCAD sheet than an actual console.

I'm still not sure what format this would have, here's an early proposal (all text):

Code:


"@! TITLE Triangle solver

@! EVAL 'CHANGEMENU'

Side A: @! INPUTVAR 'A' 1
Side B: @! INPUTVAR 'B' 1
Side C: @! INPUTVAR 'C' 1
Angle ɑ: @! INPUTVAR 'Alpha' ∡60°
Angle β: @! INPUTVAR 'Beta'  ∡60°
Angle ɣ: @! INPUTVAR 'Gamma'  ∡60°

@! EVAL 'TRIANGSOLVER'
@! EVAL 'UPDATESKETCH'

@! INCLUDE 'SKETCH'

@! INCLUDE 'LAWOFSINESFORMULA'
@! INCLUDE 'LAWOFCOSINESFORMULA'

@! IFEXISTS 'HAVESOLUTION'
Solution:
Side A: @! FORMAT 'A' #.###
Side B: @! FORMAT 'B' #.###
Side C: @! FORMAT 'C' #.###
Angle ɑ: @! FORMAT 'Alpha' ∡#°
Angle β: @! FORMAT 'Beta' ∡#°
Angle ɣ: @! FORMAT 'Gamma' ∡#°

@! ELSE
No solution yet.
@! ENDIF


"

In the example above, the @! lines have special commands for the browser. In this example, @! INPUTVAR creates an edit control, the value after the variable name is the initial default value in the editor if the variable doesn't exist.
@! EVAL will simply evaluate the given variable, in the example, 'UPDATESKETCH' contains a program that will plot a sketch of the triangle to a PLOT object and store it in the variable 'SKETCH'. 'CHANGEMENU' contains a program that changes the current menu to the "app" menu, for example with options to exit the app, export the solution, reset the app, etc.
@! INCLUDE will insert the content of the given variable into the console. The variable can contain text, graphics or even more console browser pseudocode, so you can make the sheet dynamic. Also, formulae should be converted to pretty print automatically when included with @! INCLUDE, so the lines including 'LAWOFSINESFORMULA' would display nicely.
@! IFEXISTS, @! ELSE and @! ENDIF here does the obvious: check if a variable exists, then include a portion of text or the other.

The idea is that any change would automatically trigger a reevaluation of the entire sheet, so if the user edits a variable value while browsing, the menu will change again, the solution recalculated and the sketch will be updated.

This sheet should perhaps go into a variable called 'Form', then the 'Form' is evaluated following all the pseudo-commands and the output goes to 'Console'. The browser displays 'Console' and allows interaction with its input fields. Then again, any change will cause 'Form' to be rescanned and a new 'Console' generated and displayed.

Does it seem a reasonable syntax? Does it improve over the old INFORM system?

[Han]

This seems like a convoluted way to write a program whereas an actual program would probably be easier to code and read. Was it Unix that had the idea that each command should really just do one thing and do it well? Maybe I'm remembering it wrong. It seems to me that a "text viewer" (or terminal screen) has become "Emacs-ized" to include everything but the kitchen sink. I'm exaggerating, of course, by why should a terminal screen also take on the role of ... well... text editor, compiler, and executor?

I do think that a generic parameterized outer loop would be nice to have, though.

EDIT: Why not just recreate the INFORM command, but open up the command entirely. On the HP48, you had to use SysRPL in order to get any "real" use out of the INFORM command. Since we are trying for backward compatibility, why not recreate the INFORM command, and then extend it to allow users to use the message handlers, etc.? Then they can control every single aspect of the input form. This would mean users can also make use of their knowledge of the HP48/HP49/HP50 input form and not have to learn (and for you, to create) a new syntax. This can all be done separately from a terminal console (which I think is nice to have)

[Claudio L.]

(01-13-2017 03:22 PM)Han Wrote:  This seems like a convoluted way to write a program whereas an actual program would probably be easier to code and read.

Yes it is! These millenials... :-), always separating programs in a front-end and a back-end. Me, I use my programs loose in a directory, always from the stack with no UI at all.

Are you sure a program with the nine-argument POL in sysRPL is less convoluted and easier to read than these worksheets? I challenge you to post the skeleton of a triangle solver with a full POL that displays and updates a sketch dynamically, similar to what I did in the worksheet example and let's compare notes.

(01-13-2017 03:22 PM)Han Wrote:  Was it Unix that had the idea that each command should really just do one thing and do it well? Maybe I'm remembering it wrong. It seems to me that a "text viewer" (or terminal screen) has become "Emacs-ized" to include everything but the kitchen sink. I'm exaggerating, of course, by why should a terminal screen also take on the role of ... well... text editor, compiler, and executor?

Well, this follows that Unix philosophy. RPL is good for number crunching, so why try to make RPL work a UI? Let's have a UI engine that does that well (and that alone), and an RPL language that crunches the numbers well.
This proposal of Forms/Console or worksheet or whatever you want to call it basically allows simple front-end prototyping with a text-editor, while you leave RPL code to work in the back end.
If you look at my example, you can see the solver is an independent RPL program, you don't need to run the Form to use the program. The worksheet only helps organize the input, and organize and display the output so it can be captured.

(01-13-2017 03:22 PM)Han Wrote:  I do think that a generic parameterized outer loop would be nice to have, though.

I can give you a POL (like the sysRPL POL), as a matter of fact everything in newRPL is designed to do so. But for the average person, I think it would be easier to write a worksheet than it is to code a whole UI with a blank canvas POL.

[rprosperi]

(01-13-2017 03:26 AM)Claudio L. Wrote:  In both cases there will be a key that will bring the console viewer (much like the PICT key would display the graphics screen).

Suggest this not take a key assignment by default; since this will be unsed only by serious programmers, and every programmer will undoubtedly reassign this anyhow, no need to waste a valuable default key.

(01-13-2017 03:26 AM)Claudio L. Wrote:  Option a) I think could be interesting for cases when you want to ask something with INPUT. The user will get the input message shown above the command line, the command line will open at the usual place, but you could also clear the console and print perhaps 2 or 3 lines with an explanation of what your program is asking of the user.
So you would see the explanation from the top, then the prompt and the command line at the bottom.

Clever idea! Most programs don't provide useful prompts because it's a PITA to do so; this will take the pain out of providing useful prompts and/or pop-up help, when used with the console 'activation' key discussed above.

[Han]

(01-13-2017 04:40 PM)Claudio L. Wrote:  Yes it is! These millenials... :-), always separating programs in a front-end and a back-end. Me, I use my programs loose in a directory, always from the stack with no UI at all.

Yeah, I honestly never used INFORMs once I got really comfortable with the stack (of course, that process took a while). But if I were to use them now ... :-)

Quote:Are you sure a program with the nine-argument POL in sysRPL is less convoluted and easier to read than these worksheets? I challenge you to post the skeleton of a triangle solver with a full POL that displays and updates a sketch dynamically, similar to what I did in the worksheet example and let's compare notes.

It would not have to be nine arguments -- in fact, no more than what you are proposing or less depending how you want to redesign such a POL. Only the original INFORM command need be backward compatible. The SysRPL version could certainly be adjusted however you see fit. And while a user could in theory write a single program with all nine components there, I imagine that most would program each component separately, and provide just the names of the programs as the nine arguments. Practically speaking, it's not that different from what you are proposing. But rather than now using a string as a "worksheet", I am merely suggesting that what you need is already there. It seems to me that using a string to ALSO be a program is a bit convoluted when a program would already achieve this.

Just thinking aloud...

Code:


<<
@ arg 1 is a list of "fields"
{
  { "Just a text field here; blah blah" } @ think of blocks of text as just a big field label
  { GROB } @ just a graphics field but essentially another "field label"
  { "Side a" a "Enter the length of side a"} @ format: { "label" var "help" default_val reset_val }
  { "Side b" b "Enter the length of side b"}
  ...
  { "Angle A" A "Enter the measure of angle A"}
  ...
}

@ arg 2 is the menu
{
  { "SOLVE" TRISOLVER } @ typical menu key object, e.g. { "label" program }
  ...
}

@ arg 3 optional handlers
{ } @ empty list for default or { fields_handler display_handler menu_handler ... }
INFORM
>>

The TRISOLVER program could simply specify a new "arg1" (fields component) using a new list and something like IFSETFIELDS to update the input fields. The inform would refresh the screen. Any and all commands of the form IF<command> would generate errors if no running input form is active.

Assuming all the components are saved into separate variables:

Code:

<< SCREEN1 MENU1 INFORM >>

SCREEN1 is the variable containing the fields for input
SCREEN2 is the variable that contains the fields for output, to be used by IFSETFIELDS
MENU1 is the menu above (with the SOLVE softkey)
MENU2 is the menu used during the display of the output (presumably inlcudes INPUT as a softkey to return to the input screen)
TRISOLVER is the variable that solves the system and saves values to a, b, c, A, B, C and presumably calls IFSETFIELDS and IFSETMENU to display the results and new menu.

Quote:Well, this follows that Unix philosophy. RPL is good for number crunching, so why try to make RPL work a UI? Let's have a UI engine that does that well (and that alone), and an RPL language that crunches the numbers well. This proposal of Forms/Console or worksheet or whatever you want to call it basically allows simple front-end prototyping with a text-editor, while you leave RPL code to work in the back end.

If you look at my example, you can see the solver is an independent RPL program, you don't need to run the Form to use the program. The worksheet only helps organize the input, and organize and display the output so it can be captured.

Worksheet is sounding more like a spreadsheet (which I like, too).

Quote:I can give you a POL (like the sysRPL POL), as a matter of fact everything in newRPL is designed to do so. But for the average person, I think it would be easier to write a worksheet than it is to code a whole UI with a blank canvas POL.

The POL need not be a blank canvas. It could provide defaults where components are not supplied by the user. The more I think about it the more it seems we are saying the same other than how to provide the interface to the user: as a long string with special tokens vs. components to be run by a POL with default behaviors for unspecified components.

Again, I'm just thinking aloud... please don't take my posts as persuasion to abandoning your ideas. Right now I am just having a hard time seeing what you are proposing as being different from an INFORM/POL other than dressing the inputs as arguments inside a large string.

[Claudio L.]

(01-13-2017 08:12 PM)Han Wrote:  Just thinking aloud...

Code:


<<
@ arg 1 is a list of "fields"
{
  { "Just a text field here; blah blah" } @ think of blocks of text as just a big field label
  { GROB } @ just a graphics field but essentially another "field label"
  { "Side a" a "Enter the length of side a"} @ format: { "label" var "help" default_val reset_val }
  { "Side b" b "Enter the length of side b"}
  ...
  { "Angle A" A "Enter the measure of angle A"}
  ...
}

@ arg 2 is the menu
{
  { "SOLVE" TRISOLVER } @ typical menu key object, e.g. { "label" program }
  ...
}

@ arg 3 optional handlers
{ } @ empty list for default or { fields_handler display_handler menu_handler ... }
INFORM
>>

I have to confess, your example looks a lot like mine, save for the different syntax (I didn't expect that, for whatever reason).
What I was proposing was mainly text with embedded graphics, input fields, and other code to be run, what you are proposing is an RPL list with the exact same text, graphics, input fields, etc.

(01-13-2017 08:12 PM)Han Wrote:  SCREEN1 is the variable containing the fields for input
SCREEN2 is the variable that contains the fields for output, to be used by IFSETFIELDS
MENU1 is the menu above (with the SOLVE softkey)
MENU2 is the menu used during the display of the output (presumably inlcudes INPUT as a softkey to return to the input screen)
TRISOLVER is the variable that solves the system and saves values to a, b, c, A, B, C and presumably calls IFSETFIELDS and IFSETMENU to display the results and new menu.

Again, your organization looks a lot like mine, with different variables holding the code, the menu, etc.

(01-13-2017 08:12 PM)Han Wrote:  Worksheet is sounding more like a spreadsheet (which I like, too).

A spreadsheet without rows and columns, I'm not sure if you ever used MathCAD or similar programs, but that's exactly what it is.

(01-13-2017 08:12 PM)Han Wrote:  Again, I'm just thinking aloud... please don't take my posts as persuasion to abandoning your ideas. Right now I am just having a hard time seeing what you are proposing as being different from an INFORM/POL other than dressing the inputs as arguments inside a large string.

No worries, you persuade me to think deeper, not to abandon ideas. I like these discussions because the result improves a lot.

Since your proposal and mine almost match, I think the same worksheet can be written as an RPL program, much faster to process than text, something like:

Code:


<<
@ INPUT/OUTPUT FIELDS
<<
    "Triangle solver" FIELD.TITLE
    "This is a triangle solver" FIELD.STATIC
    "Side A: " 'A' 1 FIELD.INPUT
    "Side B: " 'B' 1 FIELD.INPUT
    "Side C: " 'C' 1 FIELD.INPUT
    "Angle ɑ: " 'Alpha' ∡60° FIELD.INPUT
    "Angle β: " 'Beta'  ∡60° FIELD.INPUT
    "Angle ɣ: " 'Gamma'  ∡60° FIELD.INPUT
    
    'SKETCH' FIELD.STATIC
    'LAWOFSINESFORMULA' FIELD.STATIC
    'LAWOFCOSINESFORMULA' FIELD.STATIC
    'RESULTS' FIELD.STATIC
>>
'Form.Fields' LSTO

@ EVENT HANDLERS
<< CHANGEMENU >> 'Form.Init' LSTO
<< TRIANGSOLVER UPDATESKETCH  FORMATRESULTS >>
'Form.InputChange' LSTO

DOFORM

>>

Where DOFORM would be a much improved INFORM. instead of putting arguments in the stack, the arguments will go into local variables 'Form.XXX'. Also, the form engine should evaluate variables of the same syntax on certain events. In the example above, 'Form.InputChange' will be evaluated when the user changes the input, 'Form.Init' when the user enters the form, etc.
The engine would take the 'Form.Fields' as the "worksheet template" and simply do EVAL on it. It will add the fields to the Form for display/interaction. And now we have "Forms" with fields that are a mix of text, graphics, etc.

Before:
Console = Text with interactive fields, graphics, etc.
Console browser = Runs the whole interaction with the user
Now:
Forms = List of text, interactive fields, graphics, etc.
DOFORM engine = Runs the whole interaction with the user

Programs that don't want to use Forms can simply output static text fields to it and not define any 'Form.XXX' handlers. Running DOFORM will work as a console, no user interaction.

Now we need to compare and decide.

Text worksheets vs RPL Forms:
* Worksheets are easier for rookies, no need to define event handlers, etc.
* Worksheets allow more control in the layout of text and items (since it's text).
* Forms are a superset of worksheets, allowing much more powerful user interaction (many events can be trapped and handled to the user).
* Forms can be nested within each other, creating very complex UI's.


I personally like the power of Forms defined this way (even a file explorer could be written in this engine), but the text worksheets have their own appeal, not sure which way is better.

[Claudio L.]

Officially decided to go 2 ways:

a) Simplified console output:
--------------------------------
Plain text with simple tags between @ symbols:

Code:


"This is a sample tag @TAG@.
There's two types of tag, @TAG@ will display the content of the variable TAG.
Then @=TAG@ will EVAL variable TAG and display the result left in the stack.
This is so you can include pretty print formulas like this:
@MYEQ@ = @=MYEQ@
"

The example speaks for itself, if MYEQ contains 'X^2/2', it will render the equation in pretty print, then the equal sign and finally the result. TAG can contain any object, in particular PLOT objects and equations are of interest to document results.

b) Full-blown Apps and Forms engine:
------------------------------------------
Applications will be contained in a directory.
The directory contains a variable 'Forms' with a list of IDENTS of forms the user can enter to. This allows more than one view in an application. A key on the keyboard will go from Stack view to cycle between all the forms in the list. For example:
{ 'TriangSolver' 'ODESolver' } 'Forms' STO
Tells the system in this directory there's 2 forms, the idents are the root name of all the variables required to define the form:
'TriangSolver.Fields' will contain the text in the form of the simplified console above. The tags in the text can be interactive fields.
'TriangSolver.Enter' runs when you switch into the form
'TriangSolver.Exit' runs when you switch to a different form or the stack
... etc.
many many more events that are called from the engine, if they don't exist the system quietly does nothing.
For other forms, the same thing: 'ODESolver.Fields', etc.
Fields are also defined the same way: an arbitrary name trailed by events. For example, in the triangle solver, the side 'A' will become input field 'A' when:
'A' contains the value of the length of the side as expected
'A.Type' has the type of interactive field (an edit control, a button, a check mark, etc). Just the existence of this variable indicates this is an interactive field.
'A.Default' gets the initial default value
'A.Format' gives hints on how to format the value of A
'A.Units' gives a set of preferred units to display A into
'A.Depend' provides a list of other fields this one depends on. A change in any of those fields means the 'A.Update' event gets called.

... etc. many more field properties, each type will have its own properties.
And then a few events as well:
'A.Draw' gets called to redraw the field, contents of A are displayed if this is not defined.
'A.Action' gets called when the user selects the widget and hits Enter
'A.Update' provides a formula or a program to update the value of the field based on other actions.
... and many more events.

A simple example:
Let's say we have a formula: Y=X^2/2.
We create a variable X, and we make it a field by creating some additional variables:
X.Type=EDIT
X.Format="#.###" (display the value with 3 decimal digits)
X.Default=0
Now we create the resulting field Y by creating:
Y.Formula='X^2/2'
Y.Format="#.###"
Y.Depend= { X }

And finally our form:
'MyForm.Fields'= "This is our test form
Please enter X = @X@

Solution of Y= @Y.Formula@ = @Y@

Done!
"

Seems like a lot of work, but it's quite simple.