🦋 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.
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
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
nemokosch this is quite a considerable breaking change, for what it's worth 12:00
lizmat that's why it's in a PR 13:07
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
[Coke] Is format its own thing, or "exactly sprintf" or "sprintf when convenient" or... 15:29
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
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!