🦋 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: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
00:00 reportable6 left, reportable6 joined 01:59 linkable6 left, evalable6 left 02:00 linkable6 joined 02:01 evalable6 joined 04:57 squashable6 left, evalable6 left, linkable6 left, coverable6 left, sourceable6 left, statisfiable6 left, bloatable6 left, bisectable6 left, committable6 left, unicodable6 left, nativecallable6 left, statisfiable6 joined 04:58 committable6 joined, squashable6 joined, linkable6 joined, unicodable6 joined 04:59 sourceable6 joined, coverable6 joined, evalable6 joined, bisectable6 joined, nativecallable6 joined 05:00 bloatable6 joined 05:05 rba left 05:06 rba joined, nine left, nine joined 06:00 reportable6 left 06:02 reportable6 joined 06:12 kurahaupo left 06:17 kurahaupo joined 06:23 discord-raku-bot left, discord-raku-bot joined 07:24 sena_kun joined
lizmat So: are Captures supposed to be value types or not? 08:02
m: dd \().WHICH.^name 08:03
camelia "ValueObjAt"
lizmat currently they are
yet there are spectests mutating values in a Capture 08:04
m: my $c := \(my $); dd $c; $c[0]++; dd $c
camelia \(Any)
\(1)
lizmat so I think we either we must make Capture an object type again, or disallow mutation 08:05
nemokosch I definitely have written code some time in the early days that does depend on Captures being value types 08:16
what does it imply if somebody mutates a value type? will the new value of it have the same identity or not? 08:17
Geth rakudo/main: a2f71d800c | (Elizabeth Mattijsen)++ | src/core.c/Capture.pm6
Fix copy-pasto in Capture.Bool
 08:21
lizmat the way it's implemented now, the .WHICH will mutate as well 08:22
nemokosch that sounds like the better scenario 08:23
actually, what's so bad about allowing mutation of value types under these condition? it sounds just like how a record/data class would behave 08:24
lizmat if a class is a value type, it is assumed to be immutable for optimising purposes 08:46
so it may work now, but there is no guarantee it will work in the future 08:47
github.com/Raku/problem-solving/issues/372 08:48
10:21 MasterDuke left
Voldenet mutating Captures makes no sense logically, but mutating underlying data makes sense 10:33
m: my $c := \(my $v); dd $c; $v++; dd $c 10:35
camelia \(Any)
\(1)
Voldenet m: sub inc (|c) { for c { $_++ } }; my $x; inc $x; dd $x # should this be allowed? 10:51
camelia Int $x = 1
lizmat m: sub inc (|c) { for c { $_++ } }; my $x; inc :$x; dd $x 10:53
camelia Any $x = Any
lizmat hmmm... I'd expect that to work as well, actually
Voldenet for c doesn't iterate on pairs 10:54
m: sub inc (|c) { for c.pairs { $_.value++ } }; my $x; inc $x, :$x; dd $x
camelia Int $x = 2
Geth roast: c8af04f496 | (Elizabeth Mattijsen)++ | S03-operators/value_equivalence.t
Remove bogus tests for "reference types"

The tests in question, from *2008*, assumed that \ was syntax for taking a reference to something (like in Perl). In Raku, the \ syntax is used for creating Captures, which is a different beast altogether.
... (10 more lines)		 10:56
rakudo/lizmat-Capture: 170802bfc7 | (Elizabeth Mattijsen)++ | src/core.c/Capture.pm6
Make Capture an object type

Rather than a value type, which it is **not** as it can have mutable elements. See github.com/Raku/problem-solving/issues/372 for more information.
This causes: ... (5 more lines)		 10:59
rakudo: lizmat++ created pull request #5291:
Make Capture an object type		 11:00
12:00 reportable6 left
nemokosch this is quite a considerable breaking change, for what it's worth 12:00
12:01 reportable6 joined 12:26 guifa_ left 12:27 guifa joined 12:41 sena_kun left, sena_kun joined
lizmat that's why it's in a PR 13:07
13:49 jjatria left 13:50 jjatria joined 14:05 kurahaupo left 14:09 kurahaupo joined
Geth rakudo/main: ebe0e0b2c7 | (Elizabeth Mattijsen)++ | 4 files
Introduce the Format class in 6.e

This subclass of Str embeds a Callable created by the Formatter class for the given format string.
   my $f = Format.new("%10s");
   say "'$f("foo")'"; # ' foo'
As discussed with jnthn at the first RCS		 14:41
roast: 6ed4f3b331 | (Elizabeth Mattijsen)++ | 2 files
Add basic tests for Format / Formatter::Syntax
 14:58
15:29 squashable6 left
[Coke] Is format its own thing, or "exactly sprintf" or "sprintf when convenient" or... 15:29
15:30 squashable6 joined
japhb Oooh, that's an interesting performance feature. 15:49
jdv recent blin is good so we're go for a release monday, so far 17:04
[Coke] +1
18:00 reportable6 left 18:02 reportable6 joined 18:19 samebchase5 joined 18:21 samebchase left, |Tux| left, sivoais left, samebchase5 is now known as samebchase 18:22 sivoais joined, |Tux| joined
lizmat [Coke] japhb the intent is to have that serve sprintf in 6.e 20:22
not sure yet how we're going to make that happen for .fmt yet
I assume we could add a .fmt taking a Format object as a format 20:23
and make it opt-in that way
20:47 sena_kun left
japhb Seems like a decent way to do that, especially since it can be done right now. 20:48
Geth roast: bd49da7bc3 | (Elizabeth Mattijsen)++ | S32-str/format.t
Add basic test for Format.AST|CODE

To at least check for the existence of these methods		 20:57
lizmat Formatter, duh :-( 20:58
tonyo is 6.e the release of ast? 21:00
lizmat yes, 6.e would enable the final initial version of RakuAST and have RakuAST be the grammar used for parsing Raku code 21:01
21:47 kurahaupo left 21:49 kurahaupo 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!