Post Reply 
newRPL: Output to a text console
01-13-2017, 08:12 PM
Post: #11
RE: newRPL: Output to a text console
(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...


@ 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 ... }

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:


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.

Graph 3D | QPI | SolveSys
Find all posts by this user
Quote this message in a reply
Post Reply 

Messages In This Thread
RE: newRPL: Output to a text console - Han - 01-13-2017, 03:22 PM
RE: newRPL: Output to a text console - Han - 01-13-2017 08:12 PM

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