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

[Samuel Gougeon]

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.
; -)

Hoping to read other contributions,

Regards
Samuel

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