HP-71B BASIC Question

[Valentin Albillo]

.
Hi again, Sylvain:

(03-17-2021 02:28 PM)Sylvain Cote Wrote:  Valentin, criticize or nitpick at will, you are welcome.

No, no, not at alll, I only tried to point out that you were actually using subprograms, not subroutines as you called them.

Quote:Valentin, Tom & Jean-François, you made me realize that I was asking too much from the BASIC language.

That's patronizing in the extreme.

The HP-71B BASIC dialect is not "the BASIC language" but a 40-year old dialect which was very advanced for a handheld device in its time but 40 years later is nothing but a relic. "The BASIC language" nowadays would be something like MS Visual BASIC in its latest team-oriented incarnations, and you can ask very very much from it and it will deliver, in spades. I've participated in very large commercial projects using it and it worked flawlessly, minimizing the development time and being a pleasure to use.

Quote:I have been spoiled from all the languages/paradigms that I have used since the 1980's and I have difficulty going back to a world that does not even have functional decomposition.

May I remind you that all those "functional decompositions" and other such niceties in the end are converted behind the scenes to a bunch of low-level assembly language operations full of goto's and whatnot. Also, the HP-71B BASIC implementation takes much less than 64 Kb, and I wonder about the size of those advanced languages that even have "functional decomposition". Megabytes ? Gigabytes ?

Last but not least, the possibility of sharing variables and other objects among the main program and subprograms already existed in HP's BASIC in the Series 80 and other models using so-called RMB BASIC, by using the COMMON statement to define a list of elements (don't remember right now if that included UDFs) to share among them. The 71B BASIC dialect does not implement that statement but that doesn't imply that "BASIC" in general doesn't.

Quote:I will refactor the code to remove all the CALL/SUB and replace them with GOSUB/LABEL.
I will also need to seriously manage variables names/usage because they becomes global.

Your decision, but it seems to me that this is the hardest way of the three I suggested. If your user-defined functions are single-line (as opposed to multi-line) no matter how long, it would be most convenient to use the S$ approach. Which is more, even if the definition takes 1,000 characters, you can dimension a 1,000-char string and VAL will evaluate it without complaining, which a single-line UDF can't do, being limited to ~90 chars or less.

On the other hand, replacing your subprograms with subroutines will force you to redesign your variable names so there's no conflicts among them and might also incur in unforeseen side effects (OPTION BASE, for instance) as you're merging a number of different local environments into a single one. I think this goes against maintanability and dismisses the many good points inherent in using subprograms in the first place.

Best regards.
V.