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

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

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

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.

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.

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.

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.

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

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

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?

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.

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