newRPL: Output to a text console

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