I think I've made my point. In response to your latest,

> the concept of script files is recognized at an unnecessarily deep level in the present implementation

I don't think that's accurate. A script file is recognized at the evaluator level, after a parse tree has already been built from the input text.

I think that invalidates your last point, that a script name is known early enough that a decision could be made to parse the complete input line according to two different sets of rules.

I agree with Mike.  I don't think we want to go down this path.

Script file resolution only happens at execution time, not when the code is parsed.

AFAIK, the only time we care about whether a symbol is defined as a variable is to determine whether to parse something like

ls -1

as a command, equivalent to the expression "ls ('-1')", or as a subtraction.  And that only happens at the command line, not inside scripts or functions.  And it happens when the expression is parsed, not when it is executed.

Even if you limit your proposal to the command line, you will have some trouble if you expect it to work for spaces.  Currently, the expression

foo bar

is equivalent to "foo ('bar')" if foo is not defined as a variable (again, only at the command line).  Now we would attempt to execute the script "foo bar.m" if the evaluation failed to find a function "foo"?

You are free to experiment with this idea and it may be possible to implement in some limited way but I don't think it is a good feature to add to Octave.

If I'm understanding you correctly, you are suggesting that scripts could be treated specially, since they can only be called by name with no arguments and cannot be part of larger expressions anyway. So essentially you are suggesting that if the normal grammar rules results in an expression that fails to evaluate, for some error or set of errors, and the expression contains no spaces, then a secondary grammar should be used instead, where the entire string is searched for a script file with a .m file extension. Is that about right?

I don't think that's a good idea.

I'm not sure how this would work with the Octave syntax.

If the Octave parser sees an expression "script.a", that is first parsed as an identifier "script" followed by a subscript expression referencing a field named "a". That is before Octave knows whether "script" is a variable, function, script, class, etc.

I think it would be nice if Octave allowed functions and scripts to use hyphens, but unfortunately a script named "do-something" is parsed as a binary minus operation. These seem like the same to me. The names of script files must be valid identifiers. I'm not sure there's any way around that without making parsing dependent on context and evaluation, and in turn more complex and error prone.

If you have a script file called script.a.m, it is impossible to execute it in the normal way by just entering its name excluding the trailing .m (of course the syntax source("script.a.m") still works). Octave will complain that 'script' is undefined, obviously because it parses the command as a structure 'script', of which the field 'a' is requested. Interestingly, for a file script.1.m it doesn't even get so far, seemingly because field names cannot start with a digit, thus giving you a parsing error.

So the dot character has a special meaning in the syntax. Obviously Octave can now go the easy way and just forbid using it more than exactly once (before the suffix "m") in script file names. In this case, this at least borders onto a documentation bug, because in the documentation the only thing I find about script file names is under 11.10 Script Files "Octave uses the same rules to search for script files as it does to search for function files.", while 11.9 Function Files does not say anything, and only 11.2 Defining Functions says "A valid function name is like a valid variable name: a sequence of letters, digits and underscores, not starting with a digit."

However, I would argue that this restriction is unnecessary: if parsing errors out because the dot is followed by a digit, you can still try to interpret this as a script file name, the same applies if you find the leading string undefined. This does not hurt performance, as it on the one hand happens after parsing has been tried, and on the other hand also such script file names won't be much slower than those without dot, as I am quite sure that searching for a script file in the load path is already much slower than trying to parse an expression. Further, I would find it beneficial to be able to naturally name scripts for instance "integrate_sin_step0.1_midpoint.m", which comes natural if you use Octave as numerical environment for doing simulations (a student just came to me with such an issue -- it was only five minutes for me, but she probably had invested more time before asking me). I see no potential regressions with such an approach. Of course, I cannot judge the effort such a change would entail, necessitating to catch the error before it is issued, try to interpret it as a script file name, and if that should fail, not issue the corresponding error, but the original one.