Márton Polgár

> Indeed, because RakuAST as a tool to build code programmatically, is mature enough to allow modules in the ecosystem, such as [Polyglot::Regexen](https://raku.land/zef:guifa/Polyglot::Regexen). And to be used internally for processing...

I think this is kind of a catch-22 situation. If everything is done by a couple of people who (hopefully) know it well enough to make it work with little...

I think the content could live in another github repository. I don't feel strongly about the format; I'd think of a textual data serialization format, could be JSON, could even...

I would like to refer to the concrete situation that triggered the topic. [Standalone Rakudo support](https://github.com/Raku/problem-solving/issues/253) comes to mind, again. This particular emptiness problem has been proliferating the Rakudo sources...

Agreed. It's mainly the same argument as with the absence of a `use version` statement: somebody who wrote code in accordance with `v6.d` or whatever version, can have no guarantees...

@codesections all the more reason I'd like to get feedback on #381 (which is really just a reiteration of ages-old issues). Breaking somebody's 6.d code in a more recent runtime...

Could somebody elaborate a bit on what this work covers? From what I can tell, this sort of activity was very much hidden from our eyes for the most part,...

My proposal would be to keep control exceptions like the ones `next` and `last` create, inside `Sub`s, hence throwing a similar exception to a legitimately missing loop to iterate. If...

> > The [synopses actually do mention](https://design.raku.org/S04.html#The_Relationship_of_Lexical_and_Dynamic_Scopes) the dynamic nature of a bare `next` (as opposed to a labelled `next`, for example) - however, this doesn't appear anywhere in [the...

> Even the .map({...}) form is a good demonstration because the code block just cannot be in the same lexical scope where the iteration logic is located. The `.map({...})` form...