problem-solving VS Fluent

Supply blocks may reorder flow of execution #364: solved Deadlock in supply / whenever chain #5141: fixed Simplify Supply / whenever processing order #5158: superseeded Fix rare deadlocks during supply setup #5202: merged 2023-11-24 Switch Supply.zip to a watermark approach (https://github.com/rakudo/rakudo/pull/5211rework) #5211: merged 2023-03-09 Test supply setup with a blocking recursion #833: merged 2023-11-24

I'm more leaning towards the former. you could open an issue at https://github.com/Raku/problem-solving/issues so that it won't get forgotten.

A bunch of people really good at bikeshedding took over the conversation and by the time they were done, the language looked nothing like Perl and they decided to rename it after the butterfly.

Now, there are security issues with the "p6c" ecosystem, as one can change the contents of a module without a version bump (aka without anybody noticing). So the plan is that the "p6c" ecosystem will be disabled by default.

Either way, I posted the other day a problem solving issue on the topic. I think we should start looking into ways to properly supporting the mixed grammars, be it a trait-like thing (you've basically made a trait without being a trait), a token (like mine) or some other specialized regex syntax.

There was no admitting to themselves.

There was the personal realization that the two factions in what was then the Perl community, would never see eye to eye on what the language called "Perl 6" was. And that all of my efforts of reconciliation, such as the Perl Reunification Summit http://blogs.perl.org/users/gabor_szabo/2013/02/perl-reunifi... had been in vain.

Which lead me to open an issue https://github.com/Raku/problem-solving/issues/81 which in the end resulted in the rename to the Raku Programming Language https://raku.org .

The CALLER:: initiates a symbol lookup in the caller. The MY:: limits that lookup to just the caller's lexpad. This is confusing. cf Particular scopes of PseudoStash'es are not clear #294.

Over time, most of the features that were a selling point for Data::Record have been rendered silly. Namely, the idea of a Tuple and Dict in core has been tossed about since writing, and the introduction of type inference for lists into core leaves most of the collections as which Data::Record is defined (Data::Record::Tuple, Data::Record::List, Data::Record::Map) with the odd edge case to cover, of which I don't feel it does a very good job of in its current release's state.

On my patrol of the wrongly named Discord channel #raku-beginners (I'm a Raku beginner since 2008, so this name is redundant), I spotted once again the question of iteration on nested Hashes and Arrays. Since the HyperWhatever wasn't taken yet (not everyone wants the colon) I wrote a proposal. I'm not sure if my nqp-foo is sufficient but I might give it a shot anyway. Unless lizmat wants to micro-optimise code that has not been written yet.

Beware: my old code is ugly as sin and painfully unoptimized (both things I'm much better at these days, which is why even if I start with my old code, it'll be unrecognizable when I'm done — that's actually the case with LanguageTag right now haha). Here's the link: https://github.com/alabamenhu/Fluent