[Octave-bug-tracker] [bug #56809] Dots in script file names

[Michael Leitner]

URL:
  <https://savannah.gnu.org/bugs/?56809>

                 Summary: Dots in script file names
                 Project: GNU Octave
            Submitted by: mleitner
            Submitted on: Mon 26 Aug 2019 01:25:41 PM UTC
                Category: Interpreter
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Feature Request
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: Any

    _______________________________________________________

Details:

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.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?56809>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/