[Scilab-Dev] &&, ||, {} as cell-builder not overloadable: official?

[Samuel Gougeon]

Le 22/01/2019 à 19:12, Samuel Gougeon a écrit :
> Le 15/01/2019 à 11:41, Samuel Gougeon a écrit :
>> Le 15/01/2019 à 10:47, Antoine ELIAS a écrit :
>>> Hello Samuel,
>>>
>>> You are right, there is no overload for these new operators.
>>> for || and &&, it seems to be OK, we can create new overloads like 
>>> %x_gg_x ( || ) and %_hh_x ( && ) for example.
>>>
>>> but for {} it would be difficult, cell creation accepts ALL types so 
>>> how to detect and call overloads ?
>>
>> You are right. This concatenator can't be overloaded. Let's document 
>> it in its forthcoming page.
>>
>> Do you think that overloading for || and && could be ready for Scilab 
>> 6.0.2, to make Scilab 6.0 regular?
>
> Antoine,
>
> After our discussion in private mails continuing this thread, i would 
> like to go on about this topic.
> For the short term, that's to say Scilab 6.0.2,  clarifying the 
> not-overloadable status of && and ||
> is a good thing. This is proposed here: 
> https://codereview.scilab.org/20703
>
> To abstract our private discussion:
> My initial public question was about making these symbols overloadable 
> as all other ones,
> without any specific meaning or processing.
> However, your were thinking about overloading them by keeping their 
> "shortcircuit" property.
> Finally, you told me that if this is not possible, and that just 
> adding && and || to the list of
> overloadable symbols is not interesting and should not be done.
>
> I don't really agree with this last point. Even if such a 
> regularization is rather not a high priority,
> it would be interesting anyway. Scilab 6.0 aimed to make Scilab more 
> regular than Scilab<6.
> I hope that this will hold as well for next 6.x releases, avoiding 
> exceptions.
>
> Keeping the "short-circuit" property for the overloads of && and || is 
> not possible for two reasons:
>
>   * As you noted, after a && b, the overload will need to receive b
>     anyway. This requires that b is evaluated anyway before calling
>     the overload.
>   * The even stronger reason is that the criterion deciding if b must
>     be evaluated  or not /is necessarily part of the overload/. So *a*
>     must be sent to the overload, and since the overload won't be
>     called another time to send b, b must be sent -- and so evaluated
>     -- from the beginning, at the first call, even before deciding
>     whether b is useful.
>
> Not making the criterion about *a* part of the overload would mean 
> that *a* is necessarily boolean. Then, the overload would stand only 
> on b, and would be always named %b_hh_<btype>(a,b).
> To me, this would be a too poor restricted implementation.
>
> *The intention to keep the "shortcircuit" property should be abandoned*.
> However, the overloading of both operators could be implemented in a 
> special way, in order to diversify overloading possibilities.
> How?
> The overloading of all other binary operators is called according to 
> the type of *both* left and right operands.
> But for some custom operations, being able to call an overload for a 
> op b _only according to the type of *a*_ would be interesting.
> When developing in Scilab language, it is possible to meet situations 
> where some very similar code is able to process *a op b* for various 
> types of *b*.
> Presently, the only way to do so is to replicate the code of say 
> %ta_op_s in %ta_op_i, %ta_op_sp, %ta_op_i,  etc, or at least define 
> them and route to the same %ta_op_s().
> This is not very smart.
>
> So, the special implementation that we could imagine would be to *call 
> %typea_hh(a,b) only according to a's type*.
>
> This would make && and || of fractional multiplicity 1.5.
> This would not be a shortcircuit, but this is currently the best thing 
> i may propose to you and users about this topic.

To illustrate on a case that many of us have likely already met:
When a custom operator supports 5 distinct data types for both operands,
only 5 overloads/files would then have to be defined, instead of 5x5  = 
25 files...
The added value would be clear.

By the way, this kind of implementation could become generic, even for 
native operators:
if %typea_op_typeb() is not defined => test whether %typea_op(a,b) is 
defined, and call it if it's the case.

Samuel

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