HP 48 SYSEVAL

[MNH]

I've been perusing https://www.hpcalc.org recently, and I would like to refer to https://www.hpcalc.org/hp48/docs/program...dnames.txt. Rick Grevelle discusses creating unallowed variable names using # 05B15h SYSEVAL. What allows this to break the rules?

[Giuseppe Donnini]

The fact that the built-in command-line parser is bypassed.

The operating system itself is able to accept any character within an identifier object: a space, a newline, a null character, whatever. It can also handle names that are identical to built-in command names, like DUP or SIN. The "rules" you refer to are a set of restrictions implemented at the end-user level in order to protect said user from himself, with the command-line parser being one mesh of the safety net.

[Allen]

According to Donnelly's "introduction to System RPL" page 81 SYSEVAL #05B15h ($>ID) converts a string object into a name object. ( I suppose bypassing any check on the ID validity?)

[MNH]

(12-27-2020 01:28 PM)Giuseppe Donnini Wrote:  The fact that the built-in command-line parser is bypassed.

If I understand you correctly, the command-line parser validates the object (global name) type. Using # 05B15h SYSEVAL, I stored \<< 2 * \>> in a variable named 880. Usually I'm able to open up single quotes, press the soft key below a variable, and [ENTER] it on the stack. When I do this with 880, the single quotes disappear. It is not object type 6, but type 0. Is the HP 48's inability to store (using the built-in command set) a variable beginning with a number, a throwback to the days of a computer's inability to store a file that began with a number?

[Giuseppe Donnini]

(12-27-2020 05:13 PM)MNH Wrote:  If I understand you correctly, the command-line parser validates the object (global name) type.

Not quite. The command-line parser validates the source text. As long as the command-line is not terminated, there is no object yet, everything is just text. It is at this stage that the safety net comes into effect and where the difference to $>ID lies. $>ID directly creates a binary object of the appropriate type, without first having to parse, that is, analyze, tokenize, and error check, a given text string, which only then is compiled into the corresponding object(s). In other words, if you create an object directly in compiled form, there can be no ambiguity as to how to interpret it, because the prologue address, which introduces each and every object, is a unique type identifier.

(12-27-2020 05:13 PM)MNH Wrote:  Is the HP 48's inability to store (using the built-in command set) a variable beginning with a number, a throwback to the days of a computer's inability to store a file that began with a number?

I think we should for a moment make a distinction between file names and variable names. Almost all operating systems allow file names that start with a digit, even as brain-dead a system as MS-DOS. On the other hand, even the most recent revision of C (2017/18) or the latest craze in programming languages, like Python or R, all prohibit variable names that start with a digit. The difference, again, has to do with parsing.

The less work it takes the parser to interpret the source text, the fewer the restrictions. Now, if you compare the contexts in which file names and variable names usually appear, you will find that the room for ambiguity is considerably higher, and hence more restrictions are needed, in the case of variable names.

Indeed, the command-line parser of an operating system shell usually has only to distinguish between commands, options, and arguments, where the latter consist almost exclusively of file or directory names, and where the elements' relative positions play a major role in their identification.

In contrast, the parser of a full-blown programming language has to deal with all kinds of different tokens: keywords, delimiters, operators, identifiers, variable names, function names, string literals, integer literals, long integer literals, floating-point literals, etc. etc.

Now, if we examine the HP-48 in that light, it becomes quite clear that it has a number of atypical features:

1. A global name is able to identify any object type, so that a global variable, that is, the association of a global name with its corresponding object, can also play the role of a file or sub-directory as known from other operating systems.
    
2. Due to the nature of RPL as a threaded interpretive language, the command-line of the HP-48 serves a double purpose. Not only does it constitute the shell, or main user interface, of the system, it also incorporates the parser for the programming language (as part of RPL's read-eval loop)! You can indeed enter the source text of an arbitrarily large program directly into the command-line, and it will be parsed, compiled, and executed on-the-fly.
    
3. In addition to programs, the HP-48 can handle no less than 27 other object types, most of which can also be entered in source-text form.
   

Given the complexity of these tasks, it comes as no surprise that the naming conventions for global variables in the HP-48 are at least as restrictive as those for variable names in most high-level programming languages.

I even think that the designers went to great lengths to ensure a maximum of user-friendliness. Consider, for instance, the token ABC, without any special delimiters, and observe how the current implementation lets you concentrate on its mathematical or logical meaning, while the parser figures out if it refers to a variable in the current directory, a variable in the parent directory, a variable in the HOME directory, an undefined formal variable, a local variable in a running program, a built-in function, a function from a plug-in library, a user-defined function, etc. etc. And the same holds true for identifiers within algebraic expressions!

Just imagine the alternatives:

 
• You could introduce a special delimiter for global names, for example $. It would then indeed be possible to have variable names with leading digits, but you would not be able to write something as simple and common as 'A+B'; instead you would have to write '$ A+$ B'.
  
  This is, by the way, exactly what you have in System RPL, where each object type has its own unique delimiter, so that you are free to use almost any character you like for naming purposes. However, who would want to force the following syntax upon the general user for something as straightforward as 'A+B'?
  
  SYMBOL
    ID A
    ID B
    x+
  ;
  
   
• You could also use a different editor for each object type, so that the interpretation context is fixed before you even enter the source text. This might be an excellent solution for a specific application, but it would be far from ideal for general use, because it rules out the implementation of a flexible, free-format command-line with all its major benefits, like handling multiple different object types at the same time, writing quick, one-time, on-the-fly programs, etc.
  
  Judging from your avatar, you seem to be a surveyor and might therefore be familiar with SMI's software, which was very powerful and very elegantly written (one of its main programmers was by the way the same Rick Grevelle you mention in your post). Well, SMI uses this second method for handling job files, whose names can therefore begin with, or even consist entirely of, digits (at least in the software I tested, which is version 6 of the Construction V package).
  

[MNH]

(01-07-2021 03:06 AM)Giuseppe Donnini Wrote:  Judging from your avatar, you seem to be a surveyor and might therefore be familiar with SMI's software, which was very powerful and very elegantly written (one of its main programmers was by the way the same Rick Grevelle you mention in your post). Well, SMI uses this second method for handling job files, whose names can therefore begin with, or even consist entirely of, digits (at least in the software I tested, which is version 6 of the Construction V package).

Yes, I'm a surveyor, and I did use SMI's software for years. I do know that Rick rewrote the version 6 software in assembly language, which then became version 7. It was so fast that sometimes the screen pixels appeared smeared, like they couldn't keep up with the program output. I never named any job files that began with a digit. It was wondeful how SMI, unlike TDS, kept improving their data storage. It went from "PACKING AND SAVING" data to instantaneous storage. SMI used to call it SMI Smart Memory. Memory management is absolutely critical when choosing a good data collector. Although I never learned SYSRPL, I used to like looking at SMI's program variables like BANKNIBS and FLUSHBUFF. It's a shame that SMI software is no longer sold, however a number of dedicated users are still using it on HP 48's. Thank you for your excellent explanation of parsing! I may want to get involved in SYSRPL programming and resurrect SMI's version 7, I'd write it for the Emu48, just for my own gratification.