🦋 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 00:03 reportable6 joined
gfldex m: my @b := List; say +@b; 00:08
camelia Use of uninitialized value of type List in numeric context
0
in block <unit> at <tmp> line 1
gfldex I have the feeling this should .throw instead of .warn . 00:09
m: my @b := List; say @b.elems; 00:10
camelia 1
gfldex And that is outright wrong.
ugexe m: my @b := List, List, List; say @b.elems; 00:13
camelia 3
ugexe i dont see why its wrong
m: my @b := List, List, List; say +@b; 00:14
camelia 3
ugexe i guess that is a difference i didn't expect
01:32 Xliff joined 04:17 reportable6 left, sourceable6 left, coverable6 left, nativecallable6 left, greppable6 left, statisfiable6 left, shareable6 left, evalable6 left, squashable6 left, bisectable6 left, tellable6 left, releasable6 left 04:18 evalable6 joined, statisfiable6 joined, bisectable6 joined, greppable6 joined, releasable6 joined, squashable6 joined
[Coke] m: my @b := List,; say +@b; 04:19
camelia 1
04:19 reportable6 joined, coverable6 joined, shareable6 joined, nativecallable6 joined, sourceable6 joined 04:20 tellable6 joined 05:54 squashable6 left 05:56 squashable6 joined 06:00 reportable6 left 06:01 reportable6 joined 08:51 epony left
Geth rakudo/main: 7ca567b4d9 | (Stefan Seifert)++ | 5 files
RakuAST: detect illegal postdeclaration of dynamic variables

Makes `say $*a; my $*a` fail the way it should.		 08:58
Nemokosch no need to even bind for these examples... 09:05
m: List.elems.say; List.list.say;
Raku eval 1 ((List))
Nemokosch List is not a List - or if this sounds too bizarre, a List is not a List:D 09:08
therefore it doesn't have .elems, and consequently it also knows nothing about using .elems for Numeric coercion 09:09
This is not a bug I'm afraid... this is a design mistake, one that doesn't seem to be easy to mitigate 09:16
Geth rakudo/main: f8ac118c02 | (Elizabeth Mattijsen)++ | src/core.c/RakuAST/Raku.pm6
RakuAST:: Tweak .raku for "abbreviated" flag
 09:19
nine A List is not an object of type list. It's a type object. As with all other non-listy objects, .list will convert it to a list with itself as the single element. Hence .elems returns 1
Geth rakudo/main: 7a442c6d45 | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: throw proper error on trying to declare dynamic package variable

my $*foo::bar should fail		 09:20
rakudo/main: 9cd11f75bd | (Stefan Seifert)++ | src/Raku/ast/variable-access.rakumod
RakuAST: throw proper error on trying to use dynamic package variable

say $*foo::bar should fail
gfldex So basically, the binding actually works but List is Any. 09:30
lizmat No, List is List ?
gfldex m: say List.^mro;
camelia ((List) (Cool) (Any) (Mu))
lizmat or do you mean inheritance wise
gfldex aye
lizmat ok, gotcha
Nemokosch List is not List:D and apparently .elems comes from List:D 09:31
so it falls back to Any, invokes .list, builds the list from that one element, and reports the size
gfldex m: my Int:D $a := Int;
camelia Type check failed in binding; expected Int:D but got Int (Int)
in block <unit> at <tmp> line 1
lizmat multi method elems(Any:U: --> 1) { } # line 87 in src/core.c/Any.pm6
gfldex m: my List:D @a := List; 09:32
camelia Type check failed in binding; expected Positional[List:D] but got List (List)
in block <unit> at <tmp> line 1
Nemokosch github.com/rakudo/rakudo/blob/2022...t.pm6#L460
gfldex We don't really have a nothing of an @-sigiled containter that can't be bound to undefined values.
*notion* 09:33
lizmat fwiw, binding a type object to a @-sigilled or %-sigilled entity feels meh
and I guess a case could be made to make that an error
gfldex m: sub foo(@a) { dd @a }; foo(List); 09:34
camelia List
Nemokosch It does feel that nobody really likes this discrepancy between @vars/%vars and $vars that the former cannot be meaningfully undefined while that's the default for the latter
gfldex That is the case that made me trip.
nine lizmat: List is of type List, but it doesn't represent a list
Nemokosch and yet we are pushing further and further from simply making it the case that the default value for the former is, well, consistent with the latter 09:35
gfldex I like to think about undefined Positionals as a place where a box could be but it's right now. However, that is not what Rakudo does with type objects. So Rakudo can answer the question: "How many things are in the box that isn't there.", just fine. 09:36
The more complex we make computer systems the easier it becomes to confuse ourselves. :) 09:37
nine my $a = List.new # $a now holds an object of type List - representing an ordered collection of elements.
my $a = List # $a now holds an object of type Perl6::Metamodel::ClassHOW (approximately) - representing a type object. 09:38
These are vastly different things.
Nemokosch my List $a # $a now holds the latter, simply as a default undefined value 09:39
a "nullable" List, doesn't sound awkward at all
nine Yes, because in that case $a again is specified to be an object of type List
Nemokosch the problem is that the concept of a "nullable List/Array/Hash/whatever" is perfectly legitimate and Raku does hint that the way to go is to use the type object 09:41
gfldex I'm totally fine with assignment. What I don't like is the binding case. And that is relevant for Routine calls, because we default to binding.
Nemokosch and then breaks it down by proliferating the .list/.hash way of doing business where you cannot have a representation of an undefined value at all
gfldex For scalars we got :D to guard against it. That doesn't work for @-sigiled containers. 09:42
I can use a where-clause ofc.
lizmat m: my @a := List # I wouldn't be against making this an error
camelia ( no output )
lizmat m: my @a := Int 09:43
camelia Type check failed in binding; expected Positional but got Int (Int)
in block <unit> at <tmp> line 1
Nemokosch I don't think using the @ and % sigils is even advisable at this point...
gfldex I believe the binding part is fine. But the question `.elems` doesn't make sense in that case. 09:44
Nemokosch what do you think about restricting .elems to Any:D? 09:45
If List's .elems itself is restricted to List:D 09:46
lizmat that would be a breaking change
gfldex indeed
Nemokosch well, if there exists an immune system of the language, breaking changes like this will have to happen at some point 09:47
or else we might as well say that the language is only allowed to get worse, never improve
Maybe you will say "get behind me Satan" but I'm gonna say it nevertheless... 09:52
lizmat fwiw, I think that allowing my @a := List is a WAT because one might think that would make @a an empty List, but it does not: it semantically makes that a List with a List type object as its only element 09:54
Nemokosch it's not the 2000's anymore when Perl was still quite big and people cared about keeping their decade(s) old code working. When that was the aim, Perl 6 couldn't live up to the expectations, despite all the design decisions in favor of the old Perl 5 way of things, one of which is this whole list context business
lizmat Nemokosch that may be true, but there *is* Raku production code out there that could break 09:55
Nemokosch To be frank, it would be better to admit that if somebody runs Raku in production in 2023, they aren't that serious about it. 09:56
09:56 squashable6 left
lizmat Nemokosch you'd be surprised how serious people are about thta 09:56
*that
09:57 squashable6 joined
Nemokosch It's hard to make estimations but I feel quite confident that there are more so-called core developers/community members than actual users 09:57
Everybody would like to think that the vast majority of Raku code is yet to be written and one serious question is if it ever will be or not 09:58
nine Nemokosch, you are simply wrong on that.
Nemokosch I might as well be right on that
nine No, you are not. I alone know more people using Raku in important production code bases than I know core developers. And I am not even particularly active in the community. 09:59
Nemokosch If you don't know more core developers, that doesn't mean I also don't. 10:01
nine So how many core developers are there?
lizmat Nemokosch nine this discussion is not productive
Nemokosch And one needs to seriously doubt the decision of people using Raku "in important production code bases"
nine Ah, the good old No True Scottsman 10:02
Nemokosch I mean duh, memory leaks are real, core dumps are real, performance issues are real
lizmat Nemokosch yet, for some people, that is not a reason not to use Raku 10:03
even in production
Nemokosch and this is where that leads
a handful of users and total ignorance for the rest 10:04
lizmat Nemokosch and you're not helping.
Nemokosch and endless arguments about sticking to well-understood design mistakes
THAT is not helping
it's not that we couldn't fix a lot of mistakes
nine Memory leaks, check. Core dumps, check. Performance issues, check. According to your definition C++ is not suitable for production. I'll tell my customer right away that they should take their database out of production ASAP
Nemokosch it's that we are gonna cling to this myth that Raku was released in 2015 and therefore it is a finished product 10:05
lizmat Nemokosch stop
Nemokosch first warning
nine Not sure what I should recommend as language they should write their database in. Maybe bash? 10:06
Nemokosch that's just being dishonest
Breaking. Changes. Have. To. Be. Made. Simple as that.
nine Because you say so. 10:07
lizmat Nemokosch then make a PR to make it so
and maybe, just maybe it will get accepted
but so far, this is just talk
and you are big on talk, we know
Nemokosch Any work only makes sense if you at least step out of this fixation of nothing can be changed 10:09
lizmat Not true: *you* at least would have learned something from it 10:10
nine A fixation that does not exist in reality. If you disagree, kindly have a look at the -errata branches and compare them to the original language releases. You will be surprised.
Nemokosch Surprised in what regard? 10:12
nine By how many backwards incompatible changes we've made over the years. 10:13
Nemokosch Honestly, I can imagine that. What I can't imagine, and also can't see, is a systematic review of Roast a) when the language was announced as stable b) whenever it became apparent that the aims of the project changed significantly from the original "next version of Perl" vision 10:17
nine Interesting. You can imagine that, but just a few minutes ago you accused us of being fixated no nothing can be changed. You know, this would ordinarily the point where an appology would be appropriate. 10:19
Nemokosch Are we gonna split hairs whether there exist changes to the test suite or not, or did you understand my point? 10:21
lizmat Nemokosch stop 10:23
nine You accused us of being fixated. I told you where to find evidence to the contrary. You refuse to apologize. And that's the end of the discussion. Basic human decency is just that: basic. If that's not present, there's no point in continuing. 10:24
Nemokosch It wasn't "evidence to the contrary" 10:25
lizmat Nemokosch second warning
Nemokosch warn someone else as well for once
10:25 ChanServ sets mode: +o lizmat
lizmat Nemokosch nobody else is sealioning like you are 10:26
so you're the only one who needs a warning
nine Anyone have any idea how the old frontend actually processes &infix:<!eqv>?
lizmat it's a metaop for <eqv> ?
METAOP_NEGATE 10:27
?
Nemokosch it's not sealioning and we have seen the narrative before
lizmat indeed we have
10:28 discord-raku-bot was kicked by lizmat (Your behavior is not conducive to the desired environment.)), discord-raku-bot joined
nine It is. Apparently the compiler is calling that sub at compile time to get the actual routine for &infix:<!eqv> 10:28
Question is, how do we get from method infixish in Actions to that. The way seems a bit obscure 10:29
Nemokosch METAOP_NEGATE makes it to the QAST at least
Zephyr late to the party, @Nemokosch it'd be preferable if you could try being a little more friendly... since currently the tone of many of your complaints certainly doesn't seem welcomed 10:32
lizmat nine: wouldn't it be an idea to create an actual infix:<!eqv> in RakuAST ? having to go through METAOP_NEGATE feels like a lot of overhead
nine lizmat: possible. First I'd like to make it work at all though :) 10:35
lizmat nine: understood :-)
Nemokosch m: sub infix:<bzt>($a, $b) { $a ** $b }; say &infix:<Zbzt>;
Raku eval -> +lol { #`(Block|4375574438352) ... }
nine m: say &infix:<!eqv>() # This might make it somewhat complicated though 10:36
camelia True
lizmat m: say &infix:<eqv>() 10:37
camelia True
lizmat heh
m: say &infix:<eqv>(42)
camelia True
lizmat m: say &infix:<!eqv>(42)
camelia True
nine Mu.pm6: multi sub infix:<eqv>($?) { Bool::True }
lizmat so why isn't that negated? 10:38
-> |c { c.elems > 1 ?? !op.(|c) !! True # aha! 10:39
nine I amend my question: how do we even get to method infixish in Actions when &infix:<!eqv> is really just a name? 10:41
lizmat 6abf2bf624ba12ea3c86f set that behaviour
sadly low on comment
nine And infixish is the only place that calls &METAOP_NEGATE
lizmat wonder why that isn't: !try(op.(|c) 10:42
)
Nemokosch - EXPR: &infix:<!eqv> - variable: &infix:<!eqv> - sigil: & - desigilname: infix:<!eqv> - longname: infix:<!eqv> - colonpair: 1 matches - coloncircumfix: <!eqv> - circumfix: <!eqv> - nibble: !eqv - name: infix - identifier: infix - morename: isa NQPArray
nine Well actually that commit does answer my question :) That code in add_mystery seems to do it 10:43
So... we cannot find that routine and it's the error reporting code that does a last ditch effort to resolve it by looking at whether it may be a metaop 10:44
lizmat glad to have been of help :-) 10:46
[Tux] Rakudo v2023.04-5-g9cd11f75b (v6.d) on MoarVM 2023.04-1-g965be0af5
csv-ip5xs0.835 - 0.850
csv-ip5xs-205.144 - 5.192
csv-parser3.506 - 3.675
csv-test-xs-200.404 - 0.449
test6.520 - 6.582
test-t1.399 - 1.430
test-t --race0.805 - 0.818
test-t-2019.961 - 21.751
test-t-20 --race6.537 - 7.067
 10:56
nine lizmat: if it was just the negate thing, I'd be tempted to generate the appropriate op directly. But the other meta operators are a lot more complicated and being able to just re-use the existing infrastructure is too tempting. 11:21
lizmat yeah, understood
there's always later :-)
Geth rakudo/main: 7ac661126d | (Elizabeth Mattijsen)++ | 4 files
RakuAST: simplify Doc::Block hierarchy

While prototyping the Rakudoc slang, it occurred to me that the RakuAST::Doc::Block hierarchy was already too refined, and that the eventual creation of Pod::xxx objects could be done from one type of RakuAST::Doc::Block class. This effectively renames the RakuAST::Doc::Formatted class to RakuAST::Doc::Block, and removes the RakuAST::Doc::Verbatim and RakuAST::Doc::Table classes.
This will allow more of the pod parsing and processing to be done in Raku, rather than in NQP.		 11:22
11:24 ab5tract joined
nine The whole thing's gonna be horrible anyway. In the old frontend it's deeply integrated into the parser. In that error reporting code, we pre-parse the name to get the category and op. Then we use the category to determine the name of the method in the grammar that we then call to parse the op. Then we dynamically compile that AST and install the resulting routine as a new lexical symbol we then resolve to. 11:29
[Tux] For Issue 32 in Text::CSV I was composing an answer and wanted to check my answer by testing it only to discover I never implemented that in Raku
BAD Tux!
nine How on earth could that even work with a synthetic AST?
lizmat so maybe my suggestion is the way forward anyway ? 11:30
In the old grammar, pod parsing is deeply integrated in the grammar and NQP as well 11:31
nine Well for parsing it makes sense to be integrated into a grammar :)
gfldex lizmat: I'm very happy with your work on Pod::* because in Pod:To:BigPage I had to use where-claues everywhere, just to figure out what node I'm looking at. 11:32
lizmat gfldex: well, I'm not sure that will change for now, as the generated Pod:: objects will need to be compatible with the current state 11:33
but it will become *way* easier to generate another set of objects 11:35
gfldex Will Pod::Block::Ambient become possible?
nine I wonder if I should change RakuAST::Var::Lexical to take sigil, twigil and a fully blown RakuAST::Name, too, just like I did with VarDeclaration::Simple. That'd safe us the pre-parsing. 11:36
lizmat nine: as long as there's also a :name argument ? 11:37
gfldex: yes
gfldex: the idea is that there will be a Doc::Grammar slang 11:38
and another grammar could use that slang to create Pod::Block::Ambient blocks for anything that Doc::Grammar didn'tparse
well, that's the theory I'm working on atm 11:39
11:39 Xliff left, ChanServ sets mode: -o lizmat 12:00 reportable6 left 12:01 reportable6 joined
nine Ok, that change to RakuAST::Var::Lexical was not the 5 minute distraction I'd hoped it to be. But anyway, now back again to that meta op thing :D 12:57
lizmat nine: did you take care of tests and deparsing and .raku and all already? if not, I can do that 12:58
nine Currently it has a method new(str $name?, Str :$sigil, Str :$twigil, RakuAST::Name :$desigilname)
lizmat ah, ok, so it won't need any changes
nine Don't know if it will stay this way. Don't even know if I will keep this approach or throw it away :)
lizmat right
13:03 linkable6 left, evalable6 left 13:06 evalable6 joined, linkable6 joined
nine m: say &infix:<<!eqv>>(1, 2) 13:19
camelia True
nine m: my constant $eqv = "eqv"; say &infix:<<!$eqv>>(1, 2)
camelia ===SORRY!=== Error while compiling <tmp>
Undeclared routine:
infix:<! eqv> used at line 1. Did you mean 'infix:<eqv>', 'infix:<le>', 'infix:<leg>'?
nine I wonder if the second example shouldn't also work
lizmat feels to me it should
nine I think so, too. It just doesn't because of that ad-hoc parsing in the old frontend. 13:20
my $categorical := $name ~~ /^((\w+?fix) [ ':<'\s*(\S+?)\s*'>' | ':«'\s*(\S+?)\s*'»' ])$/; if $categorical { my $cat := ~$categorical[0][0]; my $op := ~$categorical[0][1]; 13:21
Much more precise: if ($!sigil eq '&' || $!sigil eq '') && nqp::elems($!desigilname.colonpairs) == 1 && nqp::istype($!desigilname.colonpairs[0], RakuAST::QuotedString) { my $category := $!desigilname.canonicalize(:colonpairs(0)); my $op := $!desigilname.colonpairs[0].literal-value; 13:23
14:06 evalable6 left, linkable6 left 14:07 linkable6 joined, evalable6 joined 14:24 epony joined
nine Darn.... dd :($a) currently declares $a as lexical variable in the surrounding scope because it's a parameter with a ParameterTarget::Var which is a RakuAST::Declaration 14:52
We need those targets, because without them the args wouldn't have any names and we need those for the generated meta object 14:53
lizmat I assume that's not an issue limited to dd is it ? 14:56
nine I wonder if I should just create a RakuAST::FakeSignature is RakuAST::LexicalScope which doesn't actually generate that code and will just forward calls to .meta-object or .compile-time-value
No, that was just an example 14:57
lizmat right
m: dd :($a)
camelia :($a)
nine I mean, with "Fake" already in the name, it'd be fair game to do a bit of fakery, wouldn't it?
lizmat m: dd :($a); say $a
camelia ===SORRY!=== Error while compiling <tmp>
Variable '$a' is not declared. Perhaps you forgot a 'sub' if this was
intended to be part of a signature?
at <tmp>:1
------> dd :($a); say ⏏$a
lizmat I'd say: go for it !
Geth rakudo/main: 2d656cd2c3 | (Stefan Seifert)++ | 3 files
RakuAST: fix fake signatures accidentally declaring names in outer scope

This is similar to the situation with role signatures fixed in commit 159cd628e7b3ace5a4487eff19a534b5380c1da0. In this case however we don't want those names to be declared at all.
Fixes `dd :($a); my $a`		 15:42
rakudo/main: f12c8598f4 | (Stefan Seifert)++ | 4 files
RakuAST: give RakuAST::Var::Lexical access to the fully parsed name
rakudo/main: 7267e7f1b3 | (Stefan Seifert)++ | 3 files
RakuAST: support metaops in categoricals (e.g. &infix:<!eqv>)
15:45 Geth left, Geth joined 15:48 Xliff joined 16:48 evalable6 left, linkable6 left 16:49 evalable6 joined 16:51 linkable6 joined 18:00 reportable6 left 18:02 reportable6 joined, sena_kun joined
gfldex m: List.AT-POS(0).say; 18:48
camelia (Any)
lizmat that's weird 18:54
hmm not 18:55
m: dd List.AT-POS(0) = 42 18:56
camelia assign requires a concrete object (got a List type object instead)
in block <unit> at <tmp> line 1
lizmat I guess we need to make sure that it's a writable containe
r
m: dd (my $a).AT-POS(0) = 42 18:57
camelia 42
lizmat m: dd (my $a).AT-POS(0) = 42; dd $a
camelia 42
Array $a = $[42]
gfldex That's related to my earlier issue because the @-sigil is the promise of Positinal semantics. However, a type-object can implement that interface but will be hard pressed to return anything useful. 18:58
Nemokosch m: my @foo is Callable; dd @foo; 19:07
Raku eval Callable.new
Geth rakudo/lizmat-Any-AT-POS: 9356a0e1a3 | (Elizabeth Mattijsen)++ | src/core.c/Any.pm6
Handle uncontainerized type objects as invocant to AT-POS better

If the invocant is a container, nothing changes. If the invocant is a type object, then look at the index. If the index is greater than 0, then Failure. Else consider the type object as a single element list, so return the invocant.		 19:11
rakudo: lizmat++ created pull request #5255:
Handle uncontainerized type objects as invocant to AT-POS better
lizmat gfldex ^^ 19:12
gfldex That will at least retain the type of the unreasonable value and thus may make debugging easier. 19:14
lizmat also: Int.AT-POS(0) = 42 will give a better error message 19:15
gfldex Can @a := List be fixed in v6.e? 19:23
19:27 linkable6 left, evalable6 left 19:28 evalable6 joined, linkable6 joined
lizmat fwiw I'd rather see this fixed in 6.c 19:37
PR #5255 is spectest clean
Nemokosch fixed as in shouldn't pass the type constraint? 19:45
gfldex That @a := TypeObject is an obvious bug doesn't mean nobody ever did that in production code. So we go from silent fail to runtime error with termination of the program. 19:46
lizmat incorrect: only of the type object is a Positional
any other type object is already an execution error
m: my @a := Int
camelia Type check failed in binding; expected Positional but got Int (Int)
in block <unit> at <tmp> line 1
lizmat m: sub a(@a) { }; a Int 19:47
camelia ===SORRY!=== Error while compiling <tmp>
Calling a(Int) will never work with declared signature (@a)
at <tmp>:1
------> sub a(@a) { }; ⏏a Int
lizmat m: sub a(@a) { }; my $a := Int; a $a
camelia Type check failed in binding to parameter '@a'; expected Positional but got Int (Int)
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
gfldex Right, that makes it much less likely to regress ofc.
Nemokosch is it even specified what should happen for @a := List ? 19:52
lizmat my PR didn't break any spectests. so I would assume no 19:53
Nemokosch ha, so there was nothing to break 😄 20:18
20:28 linkable6 left, evalable6 left 20:29 evalable6 joined, linkable6 joined 20:59 squashable6 left 21:00 squashable6 joined 21:17 sena_kun left 22:17 evalable6 left, linkable6 left 22:19 linkable6 joined 22:20 evalable6 joined
lizmat [00:33:03] <discord-raku-bot><Anton Antonov> It seems that the newest update at raku.land is from 3 days ago. 22:34
23:20 evalable6 left, linkable6 left, evalable6 joined 23:21 linkable6 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!