🦋 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.
02:29 nine left 02:30 nine joined 10:36 finanalyst joined 11:31 sena_kun joined 12:11 finanalyst left 14:03 sena_kun left 14:05 finanalyst joined, sena_kun joined 14:11 sena_kun left 14:12 sena_kun joined
timo m: class foo { method ACCEPTS(foo:D $self: $other) { } }; dd foo.^lookup("ACCEPTS").signature.params[0].type 15:22
camelia foo
timo m: class foo { method ACCEPTS(foo:D $first, foo:U $second) { } }; dd foo.^lookup("ACCEPTS").signature.params.map(*.type) 15:23
camelia (foo, foo, foo, Mu).Seq
timo where is the type that has .archetypes.definite on it stored? 15:25
got surprised by this while looking into github.com/rakudo/rakudo/issues/5762 15:30
looks like .modifier gets :U or :D in it as a string. that's odd 15:41
committable6: releases sub blorb(Any:D $x) { }; say &blorb.signature.params[0].modifier; say &blorb.signature.params[0].type.raku 15:44
committable6 timo, gist.github.com/3e3d57955444f00e2f...f9a37823be
timo committable6: releases sub blorb(Any:D $x) { }; say &blorb.signature.params[0].type 15:45
committable6 timo, gist.github.com/b677e1663e0e185c87...5599e1597b 15:46
timo it sounds like the code in IS-SETTING-ONLY-U and IS-SETTING-ONLY-D could never have worked? 15:47
committable6: releases class foo { method ACCEPTS(foo:D $self: $other) { } }; say foo.^lookup("ACCEPTS").signature.params[0].type 15:48
committable6 timo, gist.github.com/b4a0adadc2a85cf437...f7190a6408 15:49
timo i think lookup might be relatively new
no, it's always been there seems like 15:52
i'm not 100% sure what the logic of these IS-SETTING-ONLY-U and -D are meant to be, and the comment doesn't seem to be complete 15:56
"Return 1 if all candidates of the given proto have a :U invocant constraint" says nothing about setting or not-setting 15:57
so the loop skips over anything not a Method or Submethod. presumably this guards against something like ForeignCode? then it is meant to skip if the parameter has a definiteness constraint on it and if it doesn't match the one the method is for (ONLY*-U or ONLY*-D), and if anything that is left over is not in the setting, it returns "nope". otherwise, if we skipped everything, or everything left 16:00
over had the correct constraint, we return 1 16:01
right, so this effectively first filters by the constraint, so it only looks at methods with :U or :D constraints on it, and tells us if any of these are not from the setting 16:02
because we're using this to figure out for the smart-match dispatcher if the ACCEPTS method of a given type is "boring", and we know at the time we dispatch if we have an instance or a type object that we are smart-matching against 16:03
and we have to bail out if there are any "custom" (user-code, i.e. not-SETTING) candidates that take unconstrained selfs or that take the :U or :D that match the thing we're dispatching for right now 16:04
ok, actually, this is only for the case where we `$blah ~~ typeboj` 16:05
if there are no custom-code candidates that take :_ or :U, then we can just make the whole thing just a type check 16:06
but if there are any candidates, we have to do more
my head is still suffering from my cold, so i could be getting this wrong 16:11
is there already a decision to not include p5 regex support in rakudo's rakuast parser? 18:38
lizmat the regex parser lives in NQP both Raku and P5 18:45
and I seem to remember it wasn't worth the trouble of removing it well, about 2-3 years ago 18:46
ugexe i thought the hope was it would be possible to make it a module or something
lizmat so RakuAST has not touched that at all yet, apart from the actions
ugexe maybe im thinking of something else though
lizmat that is definitely an option, once the Raku grammar has solidified enough for 6.e 18:47
it's a bit of a moving target atm, I'd say
although there hasn't been much movement lately :-(
timo right now the first p5 regex i attempted to compile with RAKUDO_RAKUAST turned on, or with "blah".AST just turned into / <!> / 18:48
lizmat probably because there are no actions for it yet
timo so i thought we just make every p5 regex into matches-nothing
lizmat or maybe a single fallback action... nine might know 18:49
timo not too important. especially not for me
i'd kind of want an army of modules that let me write raku regexes and generate the equivalent in a bunch of different formats
lizmat the other way around I can see 18:50
but Raku grammars have some unique properties, that I'd would be hard to port ?
because Raku grammars are not state machines, but programs
timo when i have to deal with Go RE2 again ... >:(
yeah, some things are literally impossible to translate, and that's okay 18:51
lizmat I guess for a subset of Raku regexes, yes
timo i just want syntax that's less shit
especially when composing stuff together
if i didn't miss it, it doesn't even have the mode that allows you to put whitespace in the regex for clarity 18:52
lizmat yuck
timo plus, when i have to put them in a yaml document so they may also have to be escaped ... though i need to review if the | syntax helps there
lizmat fwiw, most of the regex stuff already builds a correct AST 18:53
timo you mean raku regexes in RakuAST?
lizmat yes
timo yeah, the other day i wrote the first few lines for the Regexplain idea
lizmat m: say Q|/ foo /|.AST.statements.head 18:54
camelia RakuAST::Statement::Expression.new(
expression => RakuAST::QuotedRegex.new(
body => RakuAST::Regex::Sequence.new(
RakuAST::Regex::WithWhitespace.new(
RakuAST::Regex::Literal.new("foo")
)
)
)
)
Geth rakudo: 1-1sam++ created pull request #5763:
Pod::To::Text: Sort enum pairs by value		 19:12
19:17 finanalyst left 20:48 bisectable6 left 20:57 bisectable6 joined
Geth rakudo/main: c7004109c8 | (Samuel Young)++ (committed using GitHub Web editor) | lib/Pod/To/Text.rakumod
Pod::To::Text: Sort enum pairs by value

Currently, Pod::To::Text renders enum pod declarators by passing the pair list returned by .pairs to signature2text. The issue with this is that the pairs will not be in any fixed order, meaning rendered output of enum pod declarators could be inconsistent between different renders, which I find to be undesirable behavior. This commit fixes that by sorting the pair list by value. I chose to sort by value because, in my personal experience, writing enums ordered by enum value seems to be fairly common in code.		 21:20
23:47 sena_kun left

Powered by Cro and the Raku® Programming Language.

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

Thank you!