[Scilab-users] Variable scope in Scilab

[Samuel Gougeon]

Hello,

Le 26/02/2021 à 14:38, Stéphane Mottelet a écrit :
> Hi all,
>
> In Scilab the scope of variables is quite permissive but even in Julia 
> (really strict rules) we can have the following behavior:
>
> function y=f(x)
>  y=x+a;
> end
>
> a=1;
> f(2)
> a=2;
> f(3)
>
> -> a=1;
>
> --> f(2)
>  ans  =
>
>    3.
>
> --> a=2;
>
> --> f(3)
>  ans  =
>
>    5.
>
> Yesterday afternoon I was my students for a Scilab beginners tutorial, 
> and by accident one of them had "x" defined before in the main 
> workspace and tried to call f without arguments. I reproduce the 
> experiment here by explicitely defining x before the call:
>
> x=1;
> f
>
> --> x=1;
>
> --> f
>  ans  =
>
>    3.
>
> Allowing the function inner scope to see variables of the outer scope 
> is one thing, you may or may not agree this is not the point here, but 
> allowing to call f without arguments just because the formal input 
> parameter has the same symbol as an outer scope symbol is another 
> thing. I knew this was possible even if i never used such a feature, 
> but my students were so puzzled by this, particularly those who 
> already learned other low-level languages, that I decided to propose 
> the suppression of this, that I consider as a serious potential source 
> of many bugs. Don't tell me that this would break some user code 
> because I frankly have no consideration for this kind of crappy 
> shortcut and, sorry if it may sound rude, for programmers who use it...


If low-level languages would be mandatory references imposing all their 
constrains, Scilab and other high level languages would not exist. Most 
often, the same people knowing "only" low level languages do not 
understand vectorized syntaxes and prefer to write as many explicit 
(nested) /for/ loops as needed. Very nice... :-/

About the topic: likely, i would not consider input and output arguments 
in the same way:
*
Input arguments*: As soon as external variables can be seen from the 
function, i do not see fundamental differences between an input argument 
-- that technically speaking can always be optional --, and any other 
internal variable. /It's the author's responsibility to properly test 
and initialize input arguments as is. We can't replace this 
responsability with an exception to a general scoping rule./
Accepting that the result can be built from external objects out of the 
list of input arguments.. already weakens the specific role of these 
ones (by the way as in object oriented programming, where operands are 
most often class attributes "in an external context" out of the list of 
input arguments). You propose to "reinforce" the strictness of their 
role, but without weakening the accessibility of external objects. 
Doesn't it look  a bit arbitrary, and vain? I don't think it would make 
programming neither easier nor really more "reliable".

*Output arguments*: they are more clearly expected to be products of the 
function, not of anything else.  Initializing them from outside looks 
more awkward and tricky.

My two cents..
Regards
Samuel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20210510/0da4ca9b/attachment.htm>