🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:27 MasterDuke left 01:02 Util_ left 02:16 frost joined
releasable6 Next release in ≈1 day and ≈15 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
03:59 Util joined 05:37 frost left 06:04 reportable6 joined
gfldex multi sub infix:<^^>(+@a) can return Nil. I consider this False because Nil can result in undefined values. In my eyes, any boolean operation should either return True of False. Any objections? 06:26
06:38 frost joined
moon-child what do you mean by 'any boolean operation should either return True or False'? 06:51
e.g.
m: say (False || 7) 06:52
camelia 7
06:52 patrickb joined 06:53 squashable6 left 06:55 squashable6 joined 07:00 MasterDuke joined 07:45 frost left
japhb m: say (False ?| 7) 08:02
camelia True
japhb ^ Is that what you were thinking of, gfldex? 08:03
(Meaning, there's a difference between short-circuiting operators and true boolean logic operators) 08:04
Razetime interesting
raydiak I agree, our infix *boolean* operators are only ?|, ?& and ?^. &&/||/^^ all short-circuit returning one of their operands, not a Bool. an Nil means some approximation of "there is no appropriate value to put here", which seems right if the values on both sides of the ^^ boolify to True 08:24
and ?^ does return False in that case. the only argument against Nil I can see is that it is somewhat overworked, so for example if you wanted to store the result in a variable, you'd get the container's default instead of an actual Nil, making it impossible to disambiguate between the case where both operands were e.g. Any and the case where both operands boolified to True 08:35
moon-child here's something disconcerting, though 09:02
m: say &[!=]() 09:03
camelia True
moon-child that should be false
m: say &[||](); say &[!||](); say &[==](); say &[!==]() 09:04
camelia False
True
True
True
moon-child aside the fact that false is the identity element for !=, why is &[!||]() !&[||](), but &[!==]() isn't !&[==]()? 09:05
aside the fact that false is the identity element for !=, why is &[!||]() !&[||](), but &[!==]() isn't !&[==]()? 09:06
Geth rakudo: 22f78f4e6c | MasterDuke17++ (committed using GitHub Web editor) | 3 files
Use 'inlinable' instead of 'inlineable' (#4474)
 09:08
09:10 Kaipi left 09:12 Kaiepi joined
Geth rakudo: 9bf1e1c2e4 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.pm6
Clean up the Any namespace a bit
 09:21
09:22 linkable6 joined
Geth rakudo: b4d33982ac | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/IO/Path.pm6
Allow IO::Path.add to take multiple values (#4472)

So that "foo".IO.add(<bar baz>) yields an "foo/bar/baz" path.		 09:22
09:23 linkable6 left 09:37 frost joined
moon-child hmm, another surprising bit of behaviour: 09:38
m: say 5 !== 6 !== 5
camelia True
moon-child perhaps != should be slurpy
lizmat huh? that feels correct to me? 5 !== 6 && 6 !== 5 ? 09:39
moon-child right, but in a mathematical sense you would expect that to mean that 5, 6, and 5 are all distinct 09:40
just as 5 == 5 == 5 means that 5, 5, and 5 are all the same; and 5 < 6 < 7 means that 5, 6, and 7 are ordered
lizmat yeah, but 5 < 6 < 7 is just syntactic sugar for 5 < 6 && 6 < 7 09:41
in Raku, it's just to allow you to write DRYer code 09:42
MasterDuke m: say [!==] 5, 6, 5 09:45
camelia True
Geth ¦ tap-harness6: Leont self-assigned deprecation message github.com/Raku/tap-harness6/issues/42
moon-child damn, it looks like &[!=]() being True is part of roast. No going back on that now 09:48
raydiak I would bet the == and !== thing is because they are chaining infix operators, so as lizmat said, `$a !== $b !== $c` is equivalent to `($a !== $b) && ($b !== $c)`. the key point here being that the identitiy value of the && which forms the chain is True 10:34
whereas && and || and friends are list-associative instead of chaining
10:37 evalable6 left 10:40 evalable6 joined
raydiak I just checked, and all chain-associative operators in the operators doc either give True as their identity value, or complain about requiring two arguments. no False identities 10:57
on a side note, these 3 have funny-looking names: 11:00
m: .say for &[!eqv], &[⊃], &[⊇]
camelia -> |c { #`(Block|74179616) ... }
Sub+{is-pure}.new
Sub+{is-pure}.new
raydiak vs the rest of them which look like
m: &[==].say
camelia &infix:<==>
MasterDuke probably another case of github.com/rakudo/rakudo/issues/4207 11:01
raydiak oh you're right, I forgot the .name 11:03
interesting that only those three are special...!eqv but not eqv, ⊃ but not ⊂, and only 3 out of 48 chaining operators. just looked funny in the output 11:07
also interesting that the others also have roles mixed in, but they .gist to their names instead. and !eqv is apparently a pointy block instead of a sub :) 11:12
anyway, I just couldn't sleep. gonna go try again since I have to get up in less than 3 hours 11:13
MasterDuke i've been investigating why the name sometimes is just type+role(s) the past day or toe, but haven't found the solution yet 11:16
11:37 patrickb left, patrickb joined 11:39 patrickb left, patrickb joined 11:41 patrickb left, patrickb joined 11:43 patrickb left, patrickb joined 11:45 patrickb left, patrickb joined 11:49 patrickb left, patrickb joined 11:51 patrickb left 11:52 patrickb joined 11:53 patrickb left 11:54 patrickb joined 11:55 patrickb left 11:56 patrickb joined 11:57 patrickb left 11:58 patrickb joined, patrickb left 12:02 reportable6 left 12:39 Altai-man left, Altai-man joined 12:47 linkable6 joined
Geth rakudo/new-disp: 41984bc981 | (Jonathan Worthington)++ | src/Perl6/Actions.nqp
Correct an inverted condition
 12:47
rakudo/new-disp: 0b85faf0b7 | (Jonathan Worthington)++ | 3 files
Eliminate two lexical capture extops

These go away in favor of a dispatcher and MoarVM syscalls. Both of the C implementations depend on the legacy invocation protocol, which is going away.		 13:01
13:18 discord-raku-bot left, [Tux] left 13:20 [Tux] joined 14:48 frost left 15:40 melezhik joined
melezhik . 15:43
16:23 melezhik left
Altai-man releasable6, status 17:35
releasable6 Altai-man, Next release in ≈1 day and ≈1 hour. There are no known blockers. 43 out of 99 commits logged (⚠ 1 warnings)
Altai-man, Details: gist.github.com/5fddc82dbb9b4f9869...661f767fa7
gfldex m: say &infix:<^^>(True, False, True); 17:37
camelia Nil
gfldex japhb: that's what I mean. ^^^
infix:<^^> with 2 arguments will call another candidate or never been called at all. Some boolean stuff is handled directly Actions.nqp . (As I understand it.) 17:38
Geth tap-harness6/proc-nowait: 83e099c7ee | (Leon Timmermans)++ | lib/TAP.pm
Avoid using Proc.status

This method has been deprecated. Instead we now use Proc.exitcode and Proc.signal to recreate the value.		 17:40
gfldex m: my $programmer-thinks-this-be-true = Any // &infix:<^^>(True, False, True); dd $programmer-thinks-this-be-true;
camelia Any $programmer-thinks-this-be-true = Any
tap-harness6: Leont++ created pull request #43:
Avoid using Proc.status		 17:42
tap-harness6: 83e099c7ee | (Leon Timmermans)++ | lib/TAP.pm
Avoid using Proc.status

This method has been deprecated. Instead we now use Proc.exitcode and Proc.signal to recreate the value.		 17:43
tap-harness6: e28b63aa0e | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | lib/TAP.pm
Merge pull request #43 from Raku/proc-nowait

Avoid using Proc.status
gfldex m: say (Any && Any && 42); 17:52
camelia (Any)
gfldex should (Any, Any, 42).reduce(&[&&]) return Any (and thus mimic chaining &&) or False in this case?
18:04 reportable6 joined
Altai-man releasable6, status 18:56
releasable6 Altai-man, Next release in ≈1 day and ≈0 hours. There are no known blockers. 61 out of 99 commits logged
Altai-man, Details: gist.github.com/9c3dc63b810857241a...73ec41683f
19:04 linkable6 left, evalable6 left, evalable6 joined 19:07 linkable6 joined
Altai-man releasable6, status 19:46
releasable6 Altai-man, Next release in ≈23 hours. There are no known blockers. 85 out of 99 commits logged
Altai-man, Details: gist.github.com/4449e87063ed99acb3...2c01934951
[Tux] Rakudo v2021.06-99-gb4d33982a (v6.d) on MoarVM 2021.06-27-g3a3eb7f9d
csv-ip5xs0.888 - 0.910
csv-ip5xs-209.169 - 9.331
csv-parser28.643 - 30.204
csv-test-xs-200.394 - 0.397
test7.759 - 8.258
test-t2.078 - 2.101
test-t --race0.931 - 1.176
test-t-2034.554 - 36.550
test-t-20 --race10.545 - 11.098
 20:39
20:57 Kaiepi left 20:59 melezhik joined 21:00 Kaiepi joined 21:12 Kaiepi left
raydiak gfldex: imo, the things we discussed 10-15 hours ago still apply to these cases. &&/||/^^ are not boolean operators and should not be boolifying their results. whether 2 args or more than 2, .reduce() or some other syntactic construct, as I see it the point stands that these are not actually boolean but instead short-circuiting operators. if you want the results to be boolified, that's what ?&/?|/?^ are for 21:28
on another side note, this is broken:
m: say (Any, Any, 42).reduce(&[&&])
camelia Too many positionals passed; expected 0 to 2 arguments but got 3
in block <unit> at <tmp> line 1
21:41 Kaiepi joined 22:41 evalable6 left, linkable6 left
releasable6 Next release in ≈19 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00
23:30 squashable6 left 23:31 squashable6 joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!