🦋 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.
jdv nightwish in berlin in 2015. good times. 02:10
nine jdv: wrong window? Anyway sounds fantastic indeed :) 09:57
m: ub foo(Int &bar:()) { } 09:58
camelia ===SORRY!=== Error while compiling <tmp>
You can't adverb :()
at <tmp>:1
------> ub foo(Int &bar:()<HERE>) { }
nine m: sub foo(Int &bar:()) { }
camelia ===SORRY!=== Error while compiling <tmp>
Redeclaration of return type for '&bar:()' (previous return type was
Int ).
at <tmp>:1
------> sub foo(Int &bar:()<HERE>) { }
nine thinks that syntax can't be in use very much... 09:59
lizmat so, some of the .assuming tests check the signature that is generated 10:35
for instance: sub a(::T $a, T $b).assuming(42) expects the generated signature to be :($b) 10:36
the code that I'm working on using RakuAST, generates a signature: :(Int $b) 10:37
do we agree that that new signature is more correct than the old one?
because currying with an Int as the first argument, forces ::T to become Int, and thus describes the constraint on the second argument ? 10:38
so I'm inclined to fix those tests 10:39
Geth rakudo/main: 6 commits pushed by (Stefan Seifert)++ 10:46
nine 1217
Geth rakudo/main: f5aa9fbcf4 | (Stefan Seifert)++ | 4 files
RakuAST: recognize more compile time values in return check

Fixes: sub foo(--> "foo") { }
12:10
rakudo/main: dc8dce7312 | (Stefan Seifert)++ | src/Raku/ast/call.rakumod
RakuAST: prohibit return with args when signature already has return value
nine 1218
Geth rakudo/main: ca3c621a25 | (Stefan Seifert)++ | src/Raku/ast/call.rakumod
RakuAST: fix explicit return to return value from signature

Fixes: sub foo(--> 1) { return }
lizmat m: sub a(**@a is raw is copy) { dd @a.shift }; a 42 # meh 12:41
camelia Cannot call 'shift' on an immutable 'List'
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat either this should work, or should be an error ?
ah, fixed in RakuAST
m: sub a(**@a is raw) { dd @a.shift }; a 42 # meh 12:44
camelia Cannot call 'shift' on an immutable 'List'
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat m: say Q|sub a(**@a is raw) { dd @a.shift }; a 42|.AST.EVAL
camelia 42
Nil
Geth rakudo/main: 5b7650c006 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: throw appropriate errors on twigiled arguments
12:51
rakudo/main: 78d9bf5d24 | (Stefan Seifert)++ | src/Raku/ast/call.rakumod
RakuAST: include non-matching signature(s) in "will never match" error
timo do we already have an idea how we should be handling what the Optimizer used to do in the new era of the RakuAST? 12:54
lizmat walk the tree like before, but with more information ? 12:55
timo does it go after the stage where we create QAST from RakuAST? so would it be a QAST -> QAST transformation like the optimizer has been so far? 12:56
lizmat no, it would be RakuAST -> RakuAST transformation, I would think? 12:58
it would be in the CHECK phaser stage
nine: that's the current thought, no ?
timo thing is, i'm not sure RakuAST covers the entirety of stuff that we may want to spit out of the optimizer 13:01
nine 1219
Definitely RakuAST -> RakuAST after CHECK. After all half the point of RakuAST is to retain more semantics for the optimizer. 13:03
lizmat m: use nqp; my @a = 1,2,3; dd nqp::iscont(@a.shift) # is this expected ? 13:05
camelia 0
lizmat m: use nqp; my @a = 1,2,3; dd nqp::iscont(@a.head) 13:06
camelia 1
Geth rakudo/main: 324fd3828f | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: set default_value on Parameter meta objects
13:07
nine 1221!
timo m: my @a = 1,2,3; @a.unshift(my $) = 99; say @a 13:20
camelia [99]
timo unshift returns self rather than the thing just added i assume?
lizmat yes
timo ok, that's probably specced and designed
lizmat it's most definitely spectested 13:21
timo that would be an odd ommisson to not spec test, yeah
just a random thought i had, don't mind me
lizmat m: my @a = 1,2,3; my $b := @a.pop = 42; say $b # that feels it should be legal? 13:22
camelia Cannot modify an immutable Int (3)
in block <unit> at <tmp> line 1
lizmat there are actually spectests for this behaviour
timo for pop to not return a container? 13:23
lizmat yes
actually, the speculation says:
Remove the first element from C<@array> and return it.
If C<@array> is empty returns a failure.
nothing about containerness there 13:24
nine Sometimes I really hate Raku
Why on earth do we need Array of Int AND Array[Int] syntaxes? Not a single other language needs more than one way to do this, much less 3 (!) 13:25
lizmat yeah.. maybe we could deprecate the "of Int" syntax 13:26
lizmat and the "returns Fpp" syntax as well :-) 13:27
nine How successful could we have been if we had concentrated on the features that are useful rather than shoving yet one more way to spell the exact same thing into the language just because it looks cute/
lizmat well, I think parts of these "warts" are because of a design process of 10+ years 13:28
nine No, more because of a lack of people with the will to say "no"
lizmat well, I have tried to say no to a lot of things over the years :-( 13:29
JimmyZ I +1 to say no to some 'more than way to do it' syntax :) 13:37
lizmat anyways, looks like making .shift / .pop raw cannot be made to work for native arrays 13:41
as we lack a nqp::shift_ref / nqp::pop_ref op
and faking it with first binding an atposref, and then shifting and then returning that was bound, feels meh 13:42
timo oh, it took me a moment to see what you mean 13:43
but how is that supposed to even work 13:44
after you have popped something out of the native array, you can't have a nativeref to it any more, since a nativeref is essentially a reference to the array + the index the element is at 13:45
so after the element was kicked out of the array, what's the ref supposed to reference?
lizmat aha... TIL 13:46
timo you can make a fresh container if you want 13:47
nine Why would you even want that in the first place?
timo now that i read the very first message about this again, i'm also not sure what it should do in the non-native array case 13:48
lizmat I ran into it while working on .assuming: I get an array with the curries, and they can be containers
I thought I could just handle that array of curries one by one by shifting off of it 13:49
and then found it deconts
I was just surprised by it 13:50
afk& 13:56
timo OK 13:59
Geth rakudo/main: b5ea8bd310 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: always mark capture parameters as raw
rakudo/main: 5c43bc69c1 | (Stefan Seifert)++ | src/Raku/Actions.nqp
RakuAST: implement parameterization with Foo of Bar syntax
nine 1223 14:00
1224 14:13
Geth rakudo/main: bfb070a7bb | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: set twigil on Parameter meta objects
14:14
rakudo/main: e0aaadf192 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: support PositionalBindFailover on Positional $p
14:32
nine 1225
Geth rakudo/main: 2493f33348 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: cope with where blocks returning strings
16:09
rakudo/main: b8ae70efba | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: prohibit clashing of parameter names
nine 1226
Encountering lots and lots of missing checks for user errors
Geth rakudo/main: 6539e984e6 | (Stefan Seifert)++ | 3 files
RakuAST: check shape of shaped array arguments
17:28
nine 1227
Geth rakudo/main: ad746c66d7 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: check for redeclarations of type captures
17:42
nine And 1228
nine Riddle of the day: find the no less than 2 errors in this spectest from t/spec/S06-signature/unpack-array.t that make its result bogus: for [1,2],[3,4] -> $a [$x, $y] { isa-ok $a.VAR, Scalar, "[...] doesn't lose containerization"; } 17:50
timo i would assume $a always gets a container just by virtue of being a $ variable? 18:09
lizmat $a is a read-only container ? 18:11
nine Well for one, considering that it's a test about array unpacking, shoulnd't it test the unpackad variables instead of the packed one? 18:19
But that doesn't actually matter, since the test would still always succeed 18:21
timo because the [ ] also makes fresh containers in any case? 18:22
nine nope
nine It's because isa-ok's first argument will always be wrapped in a Scalar 18:31
lizmat heh 18:35
that could be fixed
Geth rakudo/main: 47f8008fe3 | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: wrap arguments in Scalars unless we know they cannot flatten
nine 1231!! 18:36
lizmat fixing isa-ok is not an option 18:42
lizmat wishes Ukraine well, and the USA as well, as they both need to deal with Comrade Krasnov 18:49
lizmat feels sick and goes afk& 18:50
nine right you are 19:08
Geth rakudo/main: 9354366ca2 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: instantiate generic types in variable declarations

Fixes: sub foo(::T) { my T $a }
19:27
nine 1232
We are now at 90.44 % passing spec test files 19:36
class RT102478_1 { BEGIN EVAL q[has $.x] }; is RT102478_1.new(x => 3).x, 3, 'can declare attribute inside of a BEGIN EVAL in class'; 19:42
Why on earth is that important? Is the language really that unusable without making stunts like this easy? 19:43
Geth rakudo/main: 507172d663 | (Stefan Seifert)++ | src/Raku/ast/resolver.rakumod
RakuAST: find outer attach targets from BEGIN time EVAL
20:07
jdv oops. wrong chan. it was fantastic:) 20:52
lizmat nine: I guess it tries to do things that we want to do with RakuAST 23:36