It is a curious example, but the availability of variables from the outer scope makes global variable declarations and multiple input arguments unnecessary in many cases. I think it deserves praise, in fact it is one of the best advantages of Scilab over certain software whose name starts with M. By the way, the pause - resume command pair is another Scilab's marvel, it should be fixed <https://bugzilla.scilab.org/buglist.cgi?quicksearch=pause%20resume>
El vie, 26 feb 2021 a las 9:02, Stéphane Mottelet (<stephane.motte...@utc.fr>) escribió: > Le 26/02/2021 à 14:50, Stéphane Mottelet a écrit : > > > Hi devs, > > > > Just after changing the rule in macro.cpp I see this at startup, and I > > am laughing out loud ;-) > > > > Scilab branch-6.1 (Feb 19 2021, 14:37:51) > > at line 44 of function mdelete ( > > > /Users/mottelet/git/scilab_6.1.orig/scilab/modules/fileio/macros/mdelete.sci > > > line 57 ) > > at line 26 of function atomsAUWriteAccess ( > > > /Users/mottelet/git/scilab_6.1.orig/scilab/modules/atoms/macros/atoms_internals/atomsAUWriteAccess.sci > > > line 42 ) > > at line 11 of function atomsSystemInit ( > > > /Users/mottelet/git/scilab_6.1.orig/scilab/modules/atoms/macros/atomsSystemInit.sci > > > line 27 ) > > > > Wrong number of input arguments. > > > > --> > > > > Does it mean that we use the "crappy shortcut" as a feature in Scilab > > internals ? > > of course nobody uses it, my patch waas a little bit rude. We have the > right to call macros with less arguments than the number of formal input > arguments, hence when inheriting the outer context then there is a > complete confusion between the formal parameter name and the same name > of a symbol in the outer context. Inheritance should be OK for all > symbols BUT formal input parameters. > > S. > > > > > S. > > > > 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... > >> > >> S. > >> > -- > Stéphane Mottelet > Ingénieur de recherche > EA 4297 Transformations Intégrées de la Matière Renouvelable > Département Génie des Procédés Industriels > Sorbonne Universités - Université de Technologie de Compiègne > CS 60319, 60203 Compiègne cedex > Tel : +33(0)344234688 > http://www.utc.fr/~mottelet > > _______________________________________________ > dev mailing list > dev@lists.scilab.org > http://lists.scilab.org/mailman/listinfo/dev > -- *Aviso legal:* El contenido de este mensaje y los archivos adjuntos son confidenciales y de uso exclusivo de la Universidad Nacional de Colombia. Se encuentran dirigidos sólo para el uso del destinatario al cual van enviados. La reproducción, lectura y/o copia se encuentran prohibidas a cualquier persona diferente a este y puede ser ilegal. Si usted lo ha recibido por error, infórmenos y elimínelo de su correo. Los Datos Personales serán tratados conforme a la Ley 1581 de 2012 y a nuestra Política de Datos Personales que podrá consultar en la página web www.unal.edu.co <http://www.unal.edu.co/>.* *Las opiniones, informaciones, conclusiones y cualquier otro tipo de dato contenido en este correo electrónico, no relacionados con la actividad de la Universidad Nacional de Colombia, se entenderá como personales y de ninguna manera son avaladas por la Universidad.
_______________________________________________ dev mailing list dev@lists.scilab.org http://lists.scilab.org/mailman/listinfo/dev