<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 22/01/2019 à 19:12, Samuel Gougeon a
écrit :<br>
</div>
<blockquote cite="mid:79005fcb-fa3d-2fd3-ad85-5540a1384d74@free.fr"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Le 15/01/2019 à 11:41, Samuel Gougeon
a écrit :<br>
</div>
<blockquote
cite="mid:631f51b7-d409-25f5-4fbe-326f88b58391@free.fr"
type="cite">Le 15/01/2019 à 10:47, Antoine ELIAS a écrit : <br>
<blockquote type="cite">Hello Samuel, <br>
<br>
You are right, there is no overload for these new operators. <br>
for || and &&, it seems to be OK, we can create new
overloads like %x_gg_x ( || ) and %_hh_x ( && ) for
example. <br>
<br>
but for {} it would be difficult, cell creation accepts ALL
types so how to detect and call overloads ? <br>
</blockquote>
<br>
You are right. This concatenator can't be overloaded. Let's
document it in its forthcoming page. <br>
<br>
Do you think that overloading for || and && could be
ready for Scilab 6.0.2, to make Scilab 6.0 regular? <br>
</blockquote>
<br>
Antoine,<br>
<br>
After our discussion in private mails continuing this thread, i
would like to go on about this topic.<br>
For the short term, that's to say Scilab 6.0.2, clarifying the
not-overloadable status of && and ||<br>
is a good thing. This is proposed here: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://codereview.scilab.org/20703">https://codereview.scilab.org/20703</a><br>
<br>
To abstract our private discussion:<br>
My initial public question was about making these symbols
overloadable as all other ones,<br>
without any specific meaning or processing.<br>
However, your were thinking about overloading them by keeping
their "shortcircuit" property.<br>
Finally, you told me that if this is not possible, and that just
adding && and || to the list of<br>
overloadable symbols is not interesting and should not be done.<br>
<br>
I don't really agree with this last point. Even if such a
regularization is rather not a high priority,<br>
it would be interesting anyway. Scilab 6.0 aimed to make Scilab
more regular than Scilab<6.<br>
I hope that this will hold as well for next 6.x releases, avoiding
exceptions.<br>
<br>
Keeping the "short-circuit" property for the overloads of
&& and || is not possible for two reasons:<br>
<ul>
<li>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.</li>
<li>The even stronger reason is that the criterion deciding if b
must be evaluated or not <i>is necessarily part of the
overload</i>. So <b>a</b> 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.<br>
</li>
</ul>
Not making the criterion about <b>a</b> part of the overload
would mean that <b>a</b> is necessarily boolean. Then, the
overload would stand only on b, and would be always named
%b_hh_<btype>(a,b).<br>
To me, this would be a too poor restricted implementation.<br>
<br>
<b>The intention to keep the "shortcircuit" property should be
abandoned</b>. <br>
However, the overloading of both operators could be implemented in
a special way, in order to diversify overloading possibilities.<br>
How?<br>
The overloading of all other binary operators is called according
to the type of <b>both</b> left and right operands.<br>
But for some custom operations, being able to call an overload for
<font size="+1">a op b</font> <u>only according to the type of <b>a</b></u>
would be interesting.<br>
When developing in Scilab language, it is possible to meet
situations where some very similar code is able to process <b>a
op b</b> for various types of <b>b</b>.<br>
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().<br>
This is not very smart.<br>
<br>
So, the special implementation that we could imagine would be to <b>call
%typea_hh(a,b) only according to a's type</b>.<br>
<br>
This would make && and || of fractional multiplicity 1.5.<br>
This would not be a shortcircuit, but this is currently the best
thing i may propose to you and users about this topic.<br>
</blockquote>
<br>
To illustrate on a case that many of us have likely already met:<br>
When a custom operator supports 5 distinct data types for both
operands,<br>
only 5 overloads/files would then have to be defined, instead of
5x5 = 25 files...<br>
The added value would be clear.<br>
<br>
<font color="#3333ff">By the way, this kind of implementation could
become generic, even for native operators:<br>
if %typea_op_typeb() is not defined => test whether
%typea_op(a,b) is defined, and call it if it's the case.<br>
</font><br>
Samuel<br>
<br>
</body>
</html>