[Scilab-Dev] Private functions in a .sci file <= Re: Multiple Functions in a sci file

[Samuel Gougeon]

Hello Antoine,

I am answering in the thread:

Le 22/02/2017 à 14:28, antoine.elias at scilab-enterprises.com a écrit :
> Hello,
>
> After some tests, it seems that Scilab 5 loads in local context "sub 
> functions" only when you call the main function.

yes, the first time that the registered function is used.
>
> with your sample, test1 and testa in the same test1.sci file
> genlib -> load -> testa -> KO
>                -> test1 -> testa -> OK
and then, next calls
-> testa -> OK

>
> In Scilab 6, we load "sub functions" as nested functions of the main 
> function.
> So they can be called in main function but after the call, they are 
> "cleared".
>
> It is a regression, 

Really?! I am very surprised by this assertion. Some (may be many) 
former native Scilab .sci files have been split to work in this new way 
-- for instance ged.sci embedded many subfunctions that have been 
transfered in as many separated files (and moved to the TCL module...). 
And AFAIRemember, this feature was already discussed in 2015 on users@ 
or devs at . So, i believed, and still believe that this change is 
/intentional/.
By the way, this new behavior has some advantages. Without it, making 
private functions compels to define them a) inside the calling one, and 
b) at its beginning. This was not very smart programming.
The only way to avoid explicitly defining them at the beginning was to 
exec them (still at the beginning).
I never run any benchmarks to compare timing of exec()uting an external 
definition file at run time:

function test()
   exec("mysubfunction.sci")
endfunction

versus compiling an embedded function/endfunction as well at run time:

function test()
      function mysubfunction(..)
          // Its code
     endfunction
endfunction

A priori, i would say that using an external file laying on the disk is 
slower than compiling things in RAM.
So, imo, this change was not really expected, but it leads to a smarter 
programming, and likely processes subfunctions in a faster way.
So, why do you say that it is a regression ?

BR
Samuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20170223/bf67fd5d/attachment.htm>