octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: more import tests


From: Rik
Subject: Re: more import tests
Date: Thu, 10 Aug 2017 08:59:47 -0700

On 08/10/2017 06:20 AM, address@hidden wrote:
Subject:
more import tests
From:
"John W. Eaton" <address@hidden>
Date:
08/10/2017 06:19 AM
To:
Octave Maintainers List <address@hidden>
CC:
address@hidden
List-Post:
<mailto:address@hidden>
Precedence:
list
MIME-Version:
1.0
Message-ID:
<address@hidden>
Content-Type:
multipart/mixed; boundary="------------2AFEE2CD8E5ED8D8CE023953"
Message:
5

I'm attaching a tar file with some more tests.  Unpack it, cd to the resulting import-test directory and run each of the s*.m scripts in a separate matlab session.  There is a doit.sh script that attempts to do that.

The things I'm looking for are

  * does import affect all function calls, or just the ones that follow the import statement?

On this point, it seems that the order of the import statement and code which uses the imported name is immaterial.  Having the import statement after the first use of an imported name, or having an import statement protected by a conditional which is not executed, made no difference in the tests I asked for.  I can't be certain of course, but this suggests at least a 2-pass compilation step for each function where the first step is to expand out import statements.  The expansion would appear to occur before detailed parsing because otherwise the parser could recognize the fact that the import is inside a conditional and issue a warning or error.

According to the documentation, import is localized to function scope.  The documentation mentions that if the definition is needed in several subfunctions then the import statement must be repeated for each function.  On the other hand, nested functions automatically have access to the imported names.  This suggests, again, that the parsing unit is one function and that an expansion step of imported names occurs throughout the function which necessarily applies to the nested function text.


  * is there a difference in behavior for command-style vs. function-style calls to import?

  * is there a difference when the import item is stored in a variable instead of a literal string?

  * what happens if the import statement is hidden inside an eval statement?

  * what happens if there is a user-defined import function in the load path?

Since one can re-define import to be a variable, I don't see why one couldn't write an import function which supplants the Matlab-provided one.  It's bad language design, however, because programmers will write code assuming import works the way it does in the documentation, but a particular installation may have an import function available and then all the code breaks.

In Octave, re-defining a built-in function at least produces a warning.  For the following file, sin.m,

function retval = sin (x)
  retval = cos (x);
endfunction

I get "warning: function ./sin.m shadows a built-in function".  But I get no such warning if I create a new m-file import.m which shadows the current one in scripts/path/import.m.  Maybe that suggests implementing import as a C++ function.

--Rik

It would be nice to see the results for the latest version of Matlab.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]