🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
01:06 xinming left 01:08 xinming joined 03:01 derpydoo left 04:01 jpn left 04:15 [Coke] joined
xinming Just for confirmation, I read there is &? op and && in doc, The only diff between them is, &? will eval values on both sides, but && won't, Am I right? 04:53
kjp xinmin: Do you mean the ?& operator? If so, they are quite different. ?& performs a bit-wise and of the two numeric operands. && evaluates the truthiness of the left side. If it's false it will return false, otherwise return the right side. 05:33
xinming: ^ (sorry for the misspelling) 05:34
05:44 chmod222 left 05:46 chmod222 joined
Voldenet but +& is a bitwise and 05:53
m: say so 2 +& 4 05:54
camelia False
Voldenet m: say so 2 ?& 4
camelia True
Voldenet && as short-circuiting behaviour is useful when operands have side effects
m: sub n { "n".say; False }; say n() && n(); 05:56
camelia n
False
Voldenet m: sub n { "n".say; False }; say n() ?& n();
camelia n
n
False
Voldenet additionally && is not evaluating the expression on the right, so avoids memory accesses 05:57
kjp Yes, sorry -- my mistake. +& always returns true or false. && doesn't. Unless I've made another mistake :-(
Voldenet tbh. there's no situation in which I'd use ?& 05:58
kjp If the left expression is false, the value of the right expression is returned, not true/false.
I can't say I've ever used it. Thus my confuxion perhaps. 05:59
Voldenet I do wonder what happens if…
m: say True +& 255;
camelia 1
kjp Nope -- I'm wrong again. If the left expression is truthy, the value of the right expression is returned!
m: say True && 255 06:00
camelia 255
Voldenet it's a neat trick, but may be a bit surprising 06:03
07:53 abraxxa joined 08:08 abraxxa left 08:10 dakkar joined 08:13 jpn joined 08:19 jpn left 08:45 sena_kun joined 09:02 Sgeo left
nemokosch for what it's worth, the subroutine form of && also doesn't short-circuit 09:33
simply because it cannot
"short-circuiting" requires a syntactic transformation, akin to a macro. It's known as the "thunkiness" of an operator in Rakudo terminology 09:35
some other thunky operators: the smartmatch (~~), andthen, the various flipflop operators (ff), other forms of "and" and "or" (||, and, or) 09:37
09:39 lichtkind__ joined
Geth ecosystem: 2colours++ created pull request #622:
Remove LibraryMake		 09:40
09:44 sena_kun left 09:50 jpn joined
Geth ecosystem/main: a1997ff9e8 | (Márton Polgár)++ (committed using GitHub Web editor) | META.list
Remove LibraryMake (#622)

Now it lives on the zef ecosystem JJ++		 09:53
09:54 jpn left 09:55 jpn joined, lucerne joined 10:56 ProperNoun left 10:59 ProperNoun joined 11:06 ProperNoun left 11:38 ilogger2 joined 11:40 teatwo joined, teatwo left 11:41 teatwo joined
ugexe yeah that is weird 12:17
m: my Bool $is-foo = 123 && 456
camelia Type check failed in assignment to $is-foo; expected Bool but got Int (456)
in block <unit> at <tmp> line 1
ugexe I don't like that :P
lizmat m: my Bool(Int) $is-foo = 123 && 456; say $is-foo 12:20
camelia True
nemokosch It's like JS 12:21
lizmat m: my Bool $a = 123 && ?456 12:22
camelia ( no output )
nemokosch I don't know how python does it but it's not even prevalent style in Python anyway
lizmat m: my Bool $a = 123 ?&& 456 # meh 12:23
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> my Bool $a = 123 ?&&⏏ 456 # meh
expecting any of:
infix
infix stopper
postfix
statement end
s…
codesections m: class T { method Bool { note; True}}; ?T && ?T 12:45
camelia Noted
Noted
WARNINGS for <tmp>:
Useless use of "?" in expression "?T" in sink context (line 1)
tellable6 2022-05-28T22:12:12Z #raku <[Coke]> codesections - you still working on github.com/Raku/doc/issues/3563 or should I unassign you?
2022-06-24T19:52:56Z #raku <[Coke]> codesections - Please let me know what happened at the raku documention session at the conference. I just heard about it from liz 5m ago.
2022-12-06T13:55:50Z #raku-dev <ggoebel> codesections are you the maintainer for the raku-advent.blog? If not, who is? We need to update the link for "Full list of 2021 Raku Advent Blog Posts" to 2022
2022-12-06T13:56:31Z #raku <ggoebel> codesections are you the maintainer for the raku-advent.blog? If not, who is? We need to update the link for "Full list of 2021 Raku Advent Blog Posts" to 2022
2023-02-20T12:32:54Z #raku <[Coke]> codesections can we get feedback on github.com/Raku/doc-website/issues/119
2023-05-29T22:40:48Z #raku <uzl[m]> codesections1 If your RA article (raku-advent.blog/2022/12/20/sigils/), there's this incomplete sentence:
2023-08-25T03:40:42Z #raku-dev <MasterDuke> codesections btw, i saw this a little while ago and thought it would be up your alley if you haven't already seen it news.ycombinator.com/item?id=36672957
hey codesections, you have a message: gist.github.com/c3991d232c997c3f2a...2c167e5cdf
nemokosch tellable tellable tellable
codesections ha
m: class T { method Bool { note; True}}; say ?T && ?T
camelia Noted
True
Noted
nemokosch anyway, whether it was the right choice to make the short-circuiting generic "and" symbolized with && 12:46
codesections ^^^^ odd that both `Noted`s print, given the short circuting nature of &&
nemokosch I think a short-circuiting boolish "and" would be pretty useless
there's already a pure boolish "and", that's ?& 12:47
codesections I guess that's a precedence thing, though
nemokosch and if you want a built-in boolish operator, frankly, by all means, stay pure at least
12:47 derpydoo joined
codesections: are you thinking of short-circuiting? 12:48
I can recall that you argued that defining short-circuiting operators was possible and nobody corrected it for a long while 12:49
but that example was wrong, I commented on it when I came across it
codesections Hm, I don't recall that
Not saying it didn't happen, just that it's not comming to mind
(A problem-solving thread just linked to a blog post of mine about Unicode in Raku that I barely remember writing – I learned something by reading it!) 12:50
El_Che building rakudo-pkg for the ubuntu released today 12:51
codesections \ö/
nemokosch there wouldn't be much point in saying that it didn't happen anyway 😛
it was jubilatious, wasn't it 12:52
oh right, it was this issue, by the way: github.com/Raku/doc/issues/3914 13:00
google does wonders
I couldn't for the life of me guess this was only 2 months ago 💀 13:01
oh right, this was when I wanted to plan a redesign of the whole operators section and got no attention so I just casually moved on 😅 13:07
13:44 Nemokosch joined 13:50 Nemokosch left, Nemokosch joined 13:55 abraxxa joined 14:04 pierrot left
codesections @nemokosch Oh, thanks for that link – I'd very much forgotten that conversation. In fairness, some of it did go back to 2021 14:09
nemokosch by the way, as hinted for that "topicalized method calls" issue as well, I'd be more than happy if you checked out the operator rework discussion - quite a one-sided discussion, to be frank.. 14:11
14:12 Nemokosch left 14:18 wheaties joined
codesections Will do. I was just looking at that now, actually and my first impression is positive 14:21
Did we ever decide where to put independent routines? Your suggested operators list seems like it would naturally live along side independent routines 14:22
nemokosch what exactly are "independent routines"? what makes them "independent"? 14:26
never really understood this term
wheaties Responding to Coke:  I agree!  I think the path to a multinational investing in raku would likely be through modernization.  Many companies invested in Apache/mod_perl.  Today they are looking to migrate to cloud and concurrency.  How well does raku fit into that model?  How can we bring this knowledge to the public? 14:27
El_Che wheaties: I don't think the world is looking something to modernize the mod_* flow. People pick something different. 14:33
codesections @nemokosch yeah, maybe that isn't the best name. Maybe "core subroutines" ? AFAIK, it's supposed to be a list of any sub that's imported by default (e.g., &say, but not &is) 14:36
nemokosch yeah, core, or I find tempting to just say global, to be honest 14:38
they are available in all scopes (that aren't borderline internal)
14:59 pierrot joined
Nahita @codesections but you are returning True from .Bool, why would it short-circuit? 15:25
tellable6 2023-01-31T18:05:19Z #raku <Voldenet> nahita: I know that you can get hold on nqp:: things if you don't mind a few more allocations
2023-02-15T20:06:47Z #raku <tonyo> nahita: moving it to those sites is probably skipping precomp
Nahita unfortunately it notes twice even if False is returned
what's more, it notes once as expected when doing s/T/T.new/ 15:26
nemokosch If that notes twice even if False is returned then something is off 16:18
16:22 jpn joined 16:32 jpn left 16:34 jpn joined 16:40 jpn left 16:41 jpn joined
codesections @Nahita Yeah, I noticed that I'd goofed up the example I put in the chat. But it still prints the Noted from the RHS even if the LHS is false. But that's not really about short-circuiting; it's about the precedence of prefix:<?> being higher than infix:<&&> 16:49
tldr; I figured it out 😄
jdv lizmat: looks like the irc logs are unwell again 16:52
16:52 RakuIRCLogger joined
lizmat jdv thanks for the nudge 16:53
well reconcile logs tomorrow
jdv oh neat, thanks
lizmat for the record: there's a log file for each day starting at midnight UTC 16:54
only "completed" log files can be easily merged with IRC::Log modules
16:57 RakuIRCLogger left, RakuIRCLogger joined 16:58 Geth left, Geth joined
nemokosch No, the precedence shouldn't make a difference here, I don't think so 17:02
The precedence is normally higher - that's what it even means to have an expression on the right handside 17:03
A simple assignment already has higher precedence than && 17:04
.s/assignment/equality check 17:11
17:19 abraxxa left 17:29 Geth left, Geth joined
m: class T { method Bool { note; False}}; say T.so && T.so 18:16
evalable6 Noted
False
Raku eval False Noted
nemokosch this already shows that precedence shouldn't be an excuse... 18:17
18:17 bartolin left
m: class T { method Bool { note; False}}; say ?T && ?T 18:18
evalable6 Noted
False
Noted
Raku eval False Noted Noted
nemokosch um
18:18 jpn left
Two bots is a bit too much 18:19
Anyway, this definitely seems to be a bug
m: class T { method Bool { note; False}}; say Bool(T) && Bool(T)
evalable6 (Bool)
Raku eval (Bool)
nemokosch this is even worse 18:20
m: class T { method Bool { note; False}}; say T.Bool && T.Bool
evalable6 Noted
False
Raku eval False Noted
18:22 bartolin joined
Nahita > But that's not really about short-circuiting; it's about the precedence hmm, i don't think so because if you replace ?Ts with ?T.new for example, it notes once, i.e., shortcircuits as expected. ?T somehow gets evaluated eagerly 18:25
nemokosch m: class T { method Bool { note; False}}; say Bool(T.new) && Bool(T.new)
evalable6 Noted
False
Raku eval False Noted
nemokosch less of a nonsense suddenly
codesections @nemokosch @Nahita Yep, you're both right; the current behavior is a bug but it looks like it has already been fixed for RakuAST. 18:27
I opened (and immediately closed) github.com/rakudo/rakudo/issues/5410 to reflect the bug
nemokosch thunking is much better with RakuASTű 18:28
we could use the "fixed in RakuAST" for some other issues as well I think
iirc this is also fixed github.com/rakudo/rakudo/issues/5239 18:30
github.com/rakudo/rakudo/issues/5119 this as well 18:32
18:37 jpn joined 19:17 itaipu joined 19:18 jpn left 19:27 teatwo left 19:28 teatwo joined 19:35 jpn joined 19:41 jpn_ joined 19:43 jpn left 19:53 cleo left 20:10 cleo joined
codesections @nemokosch Yes for the second one (and now closed); no for the first, saddly 20:17
nemokosch oh right 20:19
sadly, I tend to remember my thought patterns... the outcome much less often
perhaps this was the case where it "worked" as long as $_ hasn't been set to anything
20:49 discoD joined 20:54 discoD left, discoD joined 21:06 xinming left 21:08 xinming joined 22:01 leah2 left 22:10 Sgeo joined 22:14 Geth left, Geth joined, leah2 joined 22:18 Geth left, Geth joined 22:22 lichtkind_ joined, lichtkind__ left 22:26 merp left 23:17 lichtkind_ left 23:33 merp joined 23:41 teatime joined 23:43 teatwo left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!