<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hello Samuel,<br>
<br>
You know my point of view: <br>
> <b>The intention to keep the "shortcircuit" property should be
abandoned</b>.<br>
Sorry I cannot be agree with that. <b>b</b> can be a non-idempotent
code/function or a failing code ( <tt>isfield(st, "foo") &&
st.foo == x</tt> )<br>
&& is often used to evaluate/execute or not "b".<br>
<br>
<b>"b" should not be evaluated until we know the result of "a".<br>
</b>If you don't care about short-circuit, use & or | instead of
&& or ||.<br>
<br>
<br>
About generic version of overload %x_op(a, b), I guess that can be a
good idea (in 6.1.0 ^^ ) but full version %t_op_t(a,b) must stay
priority if exists.<br>
That could reduce number of overloads that only reroute to
%t_op_generic(a, b) for example.<br>
<br>
Hoping to read other contributions too,<br>
Antoine<br>
<div class="moz-cite-prefix">Le 22/01/2019 à 19:12, Samuel Gougeon a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:79005fcb-fa3d-2fd3-ad85-5540a1384d74@free.fr">
<meta content="text/html; charset=UTF-8" 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
class="moz-txt-link-freetext"
href="https://codereview.scilab.org/20703"
moz-do-not-send="true">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>
; -)<br>
<br>
Hoping to read other contributions,<br>
<br>
Regards<br>
Samuel<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.scilab.org">dev@lists.scilab.org</a>
<a class="moz-txt-link-freetext" href="http://lists.scilab.org/mailman/listinfo/dev">http://lists.scilab.org/mailman/listinfo/dev</a>
</pre>
</blockquote>
<br>
</body>
</html>