You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem is that the argument in the first case is not surrounded with parentheses.
A nice improvement would be that the REPL looks if the inserted expression is in operator notation (as it is the case for .*2, it contains only one argument). If this is the case, the REPL could replace the . with the previous result to get the real operator notation res0*2 instead of concatenating it, which results in the wrong res0.*2.
If it turns out that this rule is ambigous in a more complex expression, another option would be to introduce another character for this case, for example a ,.
The text was updated successfully, but these errors were encountered:
@som-snytt said:
The linked issue is about "split line healing", but the proposed solution suffers from re-evaluation of the previous line. If the previous result is inserted into the line instead, then it would be acceptable and cover this case.
Unless there is an {code}object * { def 2 = 2 }{code}. No, you'd still need to backquote the call.
Look at the following example:
The problem is that the argument in the first case is not surrounded with parentheses.
A nice improvement would be that the REPL looks if the inserted expression is in operator notation (as it is the case for
.*2
, it contains only one argument). If this is the case, the REPL could replace the.
with the previous result to get the real operator notationres0*2
instead of concatenating it, which results in the wrongres0.*2
.If it turns out that this rule is ambigous in a more complex expression, another option would be to introduce another character for this case, for example a
,
.The text was updated successfully, but these errors were encountered: