HP 48 SYSEVAL

[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).