🦋 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.
Geth rakudo/main: 26d9a2ef9b | (Elizabeth Mattijsen)++ | 4 files
RakuAST: add pod declarator support for parameters

Implemented at the RakuAST class level (deparsing, .raku + tests). This was rather more involved due to Raku's syntax, so this had to be hacked into the Signature deparsing.		 09:41
lizmat I think I got all of the pod declarator cases covered now
nine nqp::istype($!type.IMPL-TARGET-TYPE, RakuAST::Type::Definedness) 10:02
There's a lot about types in a compiler...
lizmat nine: you're saying I should check all classes doing RakuAST::Type::Definedness for declarator pod ? 10:08
nine No, no, no, that's from my work on parameter checks 10:09
I just found it funny how often the word "type" can fit into such little code :)
lizmat typical :-) 10:16
timo1 type, type, type, type, eggs, bacon, and type 10:35
Geth rakudo/main: cecba5a4c5 | (Elizabeth Mattijsen)++ | 5 files
RakuAST: allow doc blocks in statement lists

It is now possible to put RakuAST::Doc::Blocks in statement lists, and still have them EVAL correctly, as if they're not there. This is achieved by checking all of the statement list logic for doc blocks and omitting them for further handling.
... (10 more lines)		 12:45
Geth rakudo/main: e42ecff09f | (Elizabeth Mattijsen)++ | 5 files
RakuAST: some class renaming

RakuAST::Doc::Block -> RakuAST::Doc::Formatted RakuAST::Doc::Basic -> RakuAST::Doc::Block
This makes more sense semantically.		 16:38
rakudo/main: 349050372f | (Elizabeth Mattijsen)++ | 6 files
RakuAST: remove some trailing whitespace
 16:51
nine lizmat: main build seems broken: Could not build C3 linearization: ambiguous hierarchy 16:56
lizmat run configure ?
nine Ah, indeed! 16:58
lizmat *phew*
Geth rakudo/main: 4 commits pushed by (Stefan Seifert)++ 17:01
lizmat 748! :-) 17:11
Geth rakudo/main: 83f2cb8f2b | (Elizabeth Mattijsen)++ | src/Raku/ast/statements.rakumod
RakuAST: make setting up $!labels a bit more sane

Before, $!labels could be uninitialized, but then that would need to be checked in a lot of places. Now, just put an nqp::list in there if nothing was specified yet. In the end this should be at least neutral on number of allocations.		 17:34
nine nine@sphinx:~/rakudo (main =)> rakudo -e 'multi rt107638(int $a) { "ok" }; multi rt107638(Str $a where 1) { }; rt107638(1)' 18:05
nine@sphinx:~/rakudo (main =)> rakudo --optimize=0 -e 'multi rt107638(int $a) { "ok" }; multi rt107638(Str $a where 1) { }; rt107638(1)'
Cannot resolve caller rt107638(1); none of these signatures matches:
I think I've looked at this before... was there a verdict on whether that test is actually correct? I thought multis are a lot stricter about native vs. boxed types. Apparently the optimizer makes them more lenient if the value is a literal. 18:06
lizmat I would expect an ambiguous dispatch for that case, actually ? 18:09
nine m: class Foo { multi method rt107638(int $a) { "ok" }; multi method rt107638(Str $a where 1) { } }; Foo.rt107638(1) 18:13
camelia Cannot resolve caller rt107638((Foo): 1); none of these signatures matches:
(Foo: int $a, *%_)
(Foo: Str $a where { ... }, *%_)
in block <unit> at <tmp> line 1
nine It only works for multi subs because for those the optimizer tries to find a matching multi candidate and dispatch to that directly. And it's more lenient than the real binder. 18:14
But roast commit f8c706da4a7f594c58ddfd697bd0bf79cdcc704d indicates that this is indeed the desired behavior. 18:17
nine And rakudo commit 1c0ed61a44420bba728b3da6567e830637c09613 confirms that 18:19
Now I wonder if this is something, that should be handled by the AST classes directly, or if it will make a comeback as "optimization". The work itself would look like something you'd find in an optimizer, but the goal is certainly not just an optimization. 18:23
lizmat well, there are more cases like that. Like doing a QuotedRegex.new with only str literals. Maybe it should return a StrLiteral instead immediately ? 18:25
but I guess that would make manipulation harder :-(
nine But that _is_ just an optimization, isn't it?
lizmat yeah, but suppose the QuotedRegex is from an .AST call, and you'd like to change it before it is getting codegenned 18:26
nine So that is definitely something for a separate optimization pass.
lizmat m: say Q|"foo"|.AST.statements.head.expression 18:27
camelia RakuAST::QuotedString.new(
segments => (
RakuAST::StrLiteral.new("foo"),
)
)
nine What I don't like is that currently we require that optimization to correctly compile a Raku program.
lizmat yeah, that is something that shouldn't be necessary
Geth rakudo/main: d3b58a3487 | (Elizabeth Mattijsen)++ | 3 files
RakuAST: renamed StatementList.push -> add-statement

The .push is way too general, and in similar cases in other classes, the method to add stuff is always named "add-foo". So it seemed appropriate to do that for this case as well.		 18:35
lizmat m: sub a() { 42; LEAVE say "hi" }; say a # should really be 42 18:37
camelia WARNINGS for <tmp>:
hi
Nil
Useless use of constant integer 42 in sink context (line 1)
nine What's the syntax for calling a method of the base class in NQP?
lizmat "the base class" ??
nine Or rather a base class' method
RakuAST::PointyBlock::PRODUCE-META-OBJECT wants to call RakuAST::Block::PRODUCE-META-OBJECT 18:38
lizmat nine: I think you're out of luck there :-( 18:40
nextsame and friends are HLL constructs, aren't they? 18:41
nine yes
nine self.IMPL-PRODUCE-META-OBJECT it is then 18:46
lizmat explain?
nine A second name for that method 18:47
ugexe can it be called by its full name? like self.ParentClass::method-name(...)? I 21:51
lizmat afaik, that's also a HLL construct 21:59
it's not called NQP for nothing :-)
sleep& 22:11

Powered by Cro and the Raku® Programming Language.

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

Thank you!