<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hello,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Le 26/02/2021 à 14:38, Stéphane
Mottelet a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:f7f76f97-11be-d4e3-06f6-53548cee9d8b@utc.fr">Hi all,
<br>
<br>
In Scilab the scope of variables is quite permissive but even in
Julia (really strict rules) we can have the following behavior:
<br>
<br>
function y=f(x)
<br>
y=x+a;
<br>
end
<br>
<br>
a=1;
<br>
f(2)
<br>
a=2;
<br>
f(3)
<br>
<br>
-> a=1;
<br>
<br>
--> f(2)
<br>
ans =
<br>
<br>
3.
<br>
<br>
--> a=2;
<br>
<br>
--> f(3)
<br>
ans =
<br>
<br>
5.
<br>
<br>
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:
<br>
<br>
x=1;
<br>
f
<br>
<br>
--> x=1;
<br>
<br>
--> f
<br>
ans =
<br>
<br>
3.
<br>
<br>
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...
<br>
</blockquote>
<p><br>
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) <i>for</i> loops as needed. Very
nice... :-/ <br>
<br>
About the topic: likely, i would not consider input and output
arguments in the same way:<br>
<b><br>
Input arguments</b>: 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. <i>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.</i><br>
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".<br>
<br>
<b>Output arguments</b>: they are more clearly expected to be
products of the function, not of anything else. Initializing them
from outside looks more awkward and tricky.</p>
<p>My two cents..<br>
Regards<br>
Samuel</p>
<br>
</body>
</html>