The Museum of HP Calculators

HP Forum Archive 21

[ Return to Index | Top of Index ]

Grouping programs on the HP Prime
Message #1 Posted by Michael de Estrada on 3 Nov 2013, 10:11 a.m.

When I first started writing programs on the HP Prime I noticed that when I invoked the User menu in the Toolbox that every program appeared with a submenu to the the right that contained a single entry with the name associated with the EXPORT statement. By default when using the New soft key to create a new program, the names would be the same, but could be edited such that they differed. Furthermore, I figured out that if I placed multiple program blocks with EXPORT namex BEGIN statements END; in the program, that they would appear in a list to the right of the program name and could be executed separately. This is very useful when you have multiple actions that you want to perform under a single topic heading and greatly reduces the clutter in the main User menu. For example, I want to change the Entry Mode to the choices of Textbook, Algebraic or RPN, so I created a program named "Entry_Mode" that contained three blocks named Textbook, Algebraic and RPN as follows:

Entry_Mode

EXPORT Textbook()
BEGIN
Entry:=0;
END;
EXPORT Algebraic()
BEGIN
Entry:=1;
END;
EXPORT RPN()
BEGIN
Entry:=2;
END;

When I select Entry_Mode in the User program menu, the three choices Textbook, Algebraic and RPN appear to the right. When I select the choice and press Enter, the name appears in the command line and another Enter creates the result in the Home or CAS screen. For example, Textbook appears as:

Textbook ----> 0.0000

assuming number format is FIX 4

Another example is polar to rectangular and rectangular to polar coordinates conversion. Originally, I had two separate programs named Rect_to_Polar and Polar_to_Rect, but I've now consolidated them into a single program under the name PR_Convert, as follows:

PR_Convert

EXPORT Rect_to_Polar(X1,X2)
BEGIN
LOCAL CRP,CIP,CTOT;
CRP:=(X1^2+X2^2)^.5;
CIP:=ATAN(X2/X1);
CTOT:=(CRP,CIP);
RETURN CTOT;
END;
EXPORT Polar_to_Rect(X1,X2)
BEGIN
LOCAL CRP,CIP,CTOT;
CRP:=X1*COS(X2);
CIP:=X1*SIN(X2);
CTOT:=(CRP,CIP);
RETURN CTOT;
END;

Upon selection and execution, the user is prompted on the command line to enter the two coordinate parameters, e.g.:

Rect_to_Polar(3,4) ----> (5.000,5301) in degrees mode

      
Re: Grouping programs on the HP Prime
Message #2 Posted by cyrille de Brébisson on 4 Nov 2013, 1:46 a.m.,
in response to message #1 by Michael de Estrada

Hello,

That is exactly the intention. The aim is for 1 'program' source to group multiple related routines together. not to have 1 program per function (they way you had in the 48 or even the 39).

Cyrille

            
Re: Grouping programs on the HP Prime
Message #3 Posted by Damien on 4 Nov 2013, 6:27 a.m.,
in response to message #2 by cyrille de Brébisson

Hi everyone !

I enjoy very much this feature, it is very handy and it would be perfect for me it it was possible to add its own Help, and consult it via the HELP key.

Dam.

Edited: 4 Nov 2013, 10:18 a.m. after one or more responses were posted

                  
Re: Grouping programs on the HP Prime
Message #4 Posted by Tim Wessman on 4 Nov 2013, 9:46 a.m.,
in response to message #3 by Damien

Indeed. How would you envision this working best? We've had some ideas, but feedback is always nice.

A keyword in the source? (might be best for longer helps so you could place them at the end of the source for example)

HELP MyFunc() "Help Text here";
...

EXPORT MyFunc() begin ... end;

or else

EXPORT MyFunc() HELP "Help Text here"; begin ... end;

Adding text before the function name? (similar to the VIEW naming - might be best for shorter ones and strange for longer)

EXPORT "Help text here",MyFunc()
begin
..
end;

Other ideas?

TW

Edited: 4 Nov 2013, 9:54 a.m.

                        
Re: Grouping programs on the HP Prime
Message #5 Posted by Jonathan Cameron on 4 Nov 2013, 2:05 p.m.,
in response to message #4 by Tim Wessman

Hi Tim,

I like the format you proposed:

  EXPORT MyFunc()
  HELP "Help Text here";
  begin
  ...
  end;

I think it is clear, uncluttered, and keeps the help string with the function itself (makes it easier to keep updated).

You can also use the same syntax at the top level of your program for an extended "Readme" style documentation string for the program/library. I'm a bit fuzzy about where you would look for it in the "Help" key display -- maybe put it somewhere under the "Program Catalog"?

Thanks for your work on all this.

-Jonathan

                              
Re: Grouping programs on the HP Prime
Message #6 Posted by Tim Wessman on 4 Nov 2013, 2:32 p.m.,
in response to message #5 by Jonathan Cameron

My only concern with that format is that if your help goes on for quite a while (multiple paragraphs,lines,related commands,examples) it might make it hard to track down the EXPORT fnname() and the funciton code. Same for the "help",FnName() option.

As to where to put it, I would assume it would be placed under the user functions tree item. Of course, that would also be linked directly so pressing HELP on your function name would jump directly there.

TW

                                    
Re: Grouping programs on the HP Prime
Message #7 Posted by Charles Bennett on 6 Nov 2013, 11:40 a.m.,
in response to message #6 by Tim Wessman

elisp allows a docstring right after the lambda-list

python allows a docstring between the class or function declaration and the code body

The Help keyword would be silly. Why not just take any text between the EXPORT decl and the Begin as help text?

Which raises the other question - it's 2013 - why isn't this thing just programmable in Python?

                                          
Re: Grouping programs on the HP Prime
Message #8 Posted by debrouxl on 7 Nov 2013, 1:58 a.m.,
in response to message #7 by Charles Bennett

A possible explanation is that Python, at least with its default interpreter, is not known for great performance and very low footprint on resource-constrained embedded platforms. Lua is one of the better fits for those platforms (*). python-on-a-chip (p14p) is an option, being much smaller than standard Python, at the expense of functionality and compatibility.
Another possible explanation is that the syntax of Python is not universally appreciated. And I'm sure there are other possible explanations :)

Even if the Prime has the most powerful processor for a calculator on the marketplace (ARM9 @ 400 MHz), its processor is far behind even the weak processor of the Raspberry Pi (ARM11 @ 700-1000 MHz). What's more, the Prime has an order of magnitude less RAM than the RPi: therefore, using large amounts of RAM to compensate for the weak CPU, which would be possible in some algorithms, is not an option on the Prime.

*: the TI-Nspire provides some Lua programming capability out of the box, albeit with large two-way incompatibilities with standard Lua: no io.* and os.* functions (yes, no way to access arbitrary external files, which is severe crippling in my book), but a platform-specific proprietary API for graphics / event-driven programming. There are third party ports of Lua to the TI-68k and Casio Prizm series, among others.

                                                
Re: Grouping programs on the HP Prime
Message #9 Posted by Tim Wessman on 7 Nov 2013, 9:34 a.m.,
in response to message #8 by debrouxl

All good points.

The major one in my mind is that in order to fully allow the user to use the capabilities of the system or integrate in cleanly, you end up creating so many "non standard" functions, commands and so on that in the end you end up with something that claims to be something standard, yet is nearly totally incompatible apart from the basic syntax so any slightly advanced program will not run on any other system anyway.

The goal we took was to make a very simple programming language that anyone with any experience in programming would be able to use immediately, and would be very simple for someone who has never programmed to learn. In addition, moving from PPL on to other "standard" languages would not be so radically different that the user would feel like you've learned something completely alien (which kind of is the truth with any style of RPN/RPL I think).

TW

            
Re: Grouping programs on the HP Prime
Message #10 Posted by Tim Wessman on 4 Nov 2013, 9:51 a.m.,
in response to message #2 by cyrille de Brébisson

Yup. A "program" in Prime is really more akin to a library of the 48 series. The difference is that you can't do binary only, don't have an assigned number to control load order, and don't have the concept of ATTACH or DETATCH.

Edited: 4 Nov 2013, 9:55 a.m.

                  
Re: Grouping programs on the HP Prime
Message #11 Posted by Marcus von Cube, Germany on 4 Nov 2013, 12:20 p.m.,
in response to message #10 by Tim Wessman

If you can't control load order, what about duplicate EXPORTed program names? Is there an implicit PATH?. If one EXPORTed program existing more than once is called from another then the version residing in the same file should come first.

                  
Re: Grouping programs on the HP Prime
Message #12 Posted by Damien on 4 Nov 2013, 1:38 p.m.,
in response to message #10 by Tim Wessman

Something simple, like that:

EXPORT Func1(c,f)
BEGIN
...
END;
EXPORT Func2(a,v)
BEGIN
...
END;
EXPORT Func3(x,y)
BEGIN
...
END;
//---------------------------------------------------
HELP Func1(); "How to Func1"; END;
HELP Func2(); "How to Func2"; END;
HELP Func3(); "How to Func3"; END;

Dam.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall