Chapter 2 of 9

Only five borrowings escaped the Perl family, and only the heredoc rule shipped intact

AdoptionPerl 6 / Raku datesAdopter's datesWhat the record saysVerdict
Swift multi-line string literals (SE-0168)RFC 162 (27 Aug 2000); A2 (3 May 2001); Pugs 6.2.7 (13 Jun 2005); Rakudo 2012.11swift-evolution 25 Apr and 5 May 2016; accepted 19 Apr 2017; Swift 4.0Becca Royal-Gordon cites Perl 6's delimiter-indentation rule and lead author John Holdsworth adopts it; both are SE-0168 authors, but the proposal and the acceptance state the rule without credit (0157381; 0166462; SE-01683; Accepted4)Borrowed (documented in the design thread); shipped intact, uncredited
Ruby ->(x) { } lambdaRFC 173 multi-variable for (29 Aug 2000); A4 pointy blocks (15 Jan 2002); Pugs 6.0.7 (18 Feb 2005)Matz's diary 1 and 22 Jul 2005; commit 27 Jul 2005; ruby-dev:26650, 29 Jul 2005; Ruby 1.9.0, 25 Dec 2007Diary says the -> proposal comes from Perl 6; commit labels the new syntax a Perl6-style lambda; ruby-dev:26650 says the grammar is aligned with Perl 6; Matz confirms the origin in 2008 (diary 22 Jul5; commit 759a63b66; ruby-dev:266507; ruby-core:167348; Ruby 1.9.0)Borrowed (documented), syntax only
PHP string ++/--Raku's current string-increment semanticsRFC 21 Nov 2022; vote 25–0, 28 Jun–12 Jul 2023; implemented in PHP 8.3RFC compares PHP with Raku, calls Raku's result consistent, and says its proposal follows Raku's behaviour (PHP RFC9)Borrowed (documented)
Swift Regex / RegexBuilderA5 (4 Jun 2002): rules as grammar methods, /x by default; LTM ≤ Apr 2006; Rakudo NFA-driven LTM 2011.11Ilseman gist 10 Jan 2018; forum posts Sep–Oct 2021; SE-0350/0351/0354/0355 in Swift 5.7 (2022)Gist lists Perl 6 regex features Swift should take outright; 2021 post says the earlier literal design was heavily Raku-inspired; accepted proposals cite PEGs, PCRE2 and Perl 5 only (gist10; forum #4611; SE-035512)Borrowed at design stage (documented); shipped syntax is not Raku's
Joose (JavaScript) via MooseA12 (16 Apr 2004); Pugs-era Perl 6 meta-model (2005–06)Moose 0.01, 15 Mar 2006; Joose manual, © 2008–2009Moose says it is built on Stevan Little's Perl 6 meta-model prototypes; Joose says it is based largely on Moose (Moose 0.1813; Joose manual14)Borrowed via Perl 5 (documented, two hops)
What the sources say 14

  1. Becca (then Brent) Royal-Gordon, later an SE-0168 co-author swift-evolution mailing list, thread "multi-line string literals.", message 015738 source ↗

    Recalls that Perl 6's redesign took a heredoc's base indentation from the indentation of its delimiter, and asks whether Swift should treat multi-line literals the same way.

  2. John Holdsworth, later SE-0168's lead author swift-evolution mailing list, thread "multi-line string literals.", message 016646 source ↗

    Proposes that the lexer strip each line's margin by the whitespace that precedes the closing quote, explicitly as Perl 6 does.

  3. John Holdsworth, Becca Royal-Gordon and Tyler Cloutier, authors; Joe Groff, review manager Swift Evolution proposal SE-0168, Multi-Line String Literals source ↗

    Specifies triple-quoted multi-line strings whose lines all lose the indentation found ahead of the closing delimiter; the text never mentions Perl or Perl 6.

  4. Joe Groff, review manager, for the Swift core team Swift Forums, SE-0168 acceptance announcement source ↗

    Accepts the proposal with revisions: where the closing delimiter sits fixes the indentation for the whole literal, and under-indented or inconsistently indented lines are errors. Perl goes unmentioned.

  5. Yukihiro Matsumoto (Matz), Ruby's creator Matz's diary on rubyist.net, entry on the new lambda grammar (Japanese) source ↗

    Traces the original arrow-lambda proposal to Perl 6, explains Perl 6's pointy-block closures and loops, calls Perl 6 culturally close to Ruby, yet doubts when or whether it will be used.

  6. Yukihiro Matsumoto (Matz), Ruby's creator ruby/ruby commit 759a63b6 (parse.y and ChangeLog) source ↗

    Adds an arrow lambda expression to Ruby's parser and records it in the ChangeLog as a Perl6-style lambda, flagged as new and very experimental.

  7. Yukihiro Matsumoto (Matz), Ruby's creator ruby-dev mailing list, message 26650 (Japanese), thread on Ruby 2.0 block-parameter notation source ↗

    Replying to Shin-ichiro Hara, who wanted parameters listed within the braces, Matz says the present grammar follows Perl 6, sets the Perl6/Ruby2 arrow form beside Groovy's and Haskell's, and offers to reconsider.

  8. Yukihiro Matsumoto (Matz), Ruby's creator ruby-core mailing list, message 16734, thread "lambda, ->, haskell, and so on" source ↗

    Answering Evan Phoenix, Matz confirms Perl 6 has the arrow syntax and is its source, and says he once tried an arrow block form for method calls but dropped it as too radical.

  9. George Peter Banyard, the RFC's author PHP RFC: Path to Saner Increment/Decrement operators source ↗

    Sets PHP's string increment beside Raku's, describing Raku as a Perl successor whose result is consistent, and states that the proposed PHP behaviour follows Raku's.

  10. Michael Ilseman, Apple engineer leading Swift's String and standard-library work GitHub gist "State of String: ABI, Performance, Ergonomics, and You!" source ↗

    Sets Swift the aim of surpassing Perl at string processing, cites Apocalypse 5, and lists Perl 6 regex features Swift should take outright, from free-form syntax and named captures to interpolation, plus ratcheting and LTM.

  11. Michael Ilseman, lead designer of Swift's string processing Swift Forums, "Declarative String Processing Overview", post #46 source ↗

    Says the earlier literal design drew heavily on Raku, but familiar, conventional regex syntax mattered most for literals, so the team's novelty budget goes to Pattern, though he prefers Raku's syntax himself.

  12. Hamish Knight and Michael Ilseman, authors Swift Evolution proposal SE-0355, Regex Syntax and Run-time Construction source ↗

    Defines the regex syntax Swift accepts in literals and strings as a blend of PCRE 2, Oniguruma, ICU and .NET, compares behaviour with Perl in places, and never mentions Raku or Perl 6.

  13. Stevan Little, Moose's author Moose 0.18 documentation (Moose.pm POD) on CPAN source ↗

    States that Moose grew out of the experimental prototypes Little built for Perl 6's meta-model, while stressing that Moose itself is meant for real use rather than as an experiment.

  14. Nickolay Platonov, Joose author Joose.Manual, Joose 3.013 documentation on openjsan.org (Wayback copy of 8 Feb 2024; the live URL now serves an unrelated page) source ↗

    Presents Joose as a complete JavaScript object system modelled largely on Moose, which it credits with borrowing much from Perl 6's object model as well as from CLOS and Smalltalk.

Swift's multi-line strings are the one case in which a Perl 6 design decision shipped whole in a major language outside the Perl family. On 25 April 2016, in the swift-evolution thread on multi-line string literals, Becca Royal-Gordon (then posting as Brent, and earlier a perl6-language participant and Parrot pumpking) described Perl 6's choice to take a heredoc's base indentation from its delimiter and asked whether Swift should do the same; on 5 May John Holdsworth replied that the lexer could strip the margin by the whitespace before the closing quote "as per Perl6" (0157381; 0166462; forum #2115). Both became SE-0168's authors, with Tyler Cloutier. The proposal specifies that whitespace in front of the closing delimiter is removed from every line and never mentions Perl 6; in the April 2017 review Royal-Gordon summed up Perl 6's heredocs as Perl 5's plus de-indenting, and on 19 April Joe Groff accepted the proposal with the rule that the closing delimiter's position sets the indentation of the whole literal, making under-indentation an error where Raku only warns (SE-01683; review #1716; Accepted4). The credit lives where Swift regex's does, in the discussion rather than the proposal, but unlike the regex work the rule itself reached Swift 4.0 unchanged.

What the sources say 2

  1. Becca (then Brent) Royal-Gordon, later an SE-0168 co-author swift-evolution thread on multi-line string literals, imported to Swift Forums under the title "Optional dictionary subscripts", post #21 source ↗

    Arguing against copying Perl 5's quoting rules into Swift, Royal-Gordon recounts helping design Perl 6, serving as pumpking for a subsystem of Parrot, and contributing patches to Perl 5 itself.

  2. Becca (then Brent) Royal-Gordon, SE-0168 co-author Swift Forums, SE-0168 review thread, post #17 source ↗

    Surveying prior art during the review, Royal-Gordon describes Perl 6's quoting as Perl 5's arbitrary delimiters and heredocs with de-indentation and user-defined quoting added, noting that Perl 5 lacks de-indenting.

Ruby's arrow is the best-documented case and sets the pattern for the rest. The record is contemporaneous: Matz's diary listed a Perl6-style anonymous function among candidate lambda syntaxes on 1 July 2005 and on 22 July said the -> proposal came from Perl 6, weighing Perl 6's cultural closeness to Ruby against doubt over when, or whether, Perl 6 would be used (diary 1 Jul17; diary 22 Jul5). He committed it as new and very experimental on 27 July 2005 — five months after Pugs made pointy blocks runnable and three and a half years after A4 specified them — and two days later told ruby-dev that the grammar was aligned with Perl 6, in a comparison table that set Perl6/Ruby2 -> (x,y) {...} beside Groovy's and Haskell's forms (ruby-dev:266507). In May 2008, asked on ruby-core whether Perl 6 has the -> syntax, he answered "Yes. It's the origin." Evan Phoenix had asked after quoting Matz's earlier remark that a syntax Ruby shared with Perl 6 would gain mind-share quickly; in reply Matz also noted that Perl 6 goes further, with for obj -> var { }, and that a method(arg) -> x { } block form he had tried himself was dropped (ruby-core:1673318; ruby-core:167348; ruby-core:1676619). What crossed was only the token: Ruby's ->(x) { } builds a lambda object, whereas Raku's -> introduces a Block with a signature that for, given and with consume. PHP's increment RFC by George Peter Banyard is the only shipped mainstream feature whose design text says it follows Raku, and its framing is a survey: it treats Raku as a Perl successor whose string increment gives consistent results where PHP's does not (PHP RFC9). A 2013 internals thread on letter decrementing had already cited S03's decrement, which does not fully mirror increment, and changed nothing (6818420).

What the sources say 4

  1. Yukihiro Matsumoto (Matz), Ruby's creator Matz's diary on rubyist.net (Japanese) source ↗

    Listing candidate lambda notations, Matz sketches a Perl6-style anonymous function with the arrow before its parameters and judges Perl 6's arrow an acceptable shorter alternative to a lambda keyword, alongside Haskell's backslash.

  2. Evan Phoenix, Rubinius lead developer, quoting Matz ruby-core mailing list, message 16733, thread "lambda, ->, haskell, and so on" source ↗

    Evan Phoenix quotes Matz saying he is content with the current arrow and that sharing it with Perl 6 would quickly win mind-share, then asks whether Perl 6 actually has that syntax.

  3. Yukihiro Matsumoto (Matz), Ruby's creator ruby-core mailing list, message 16766, thread "lambda, ->, haskell, and so on" source ↗

    Rejecting David A. Black's objection that the mind-share argument would equally justify Perl's globals, Matz replies that Perl 6 has good ideas worth taking even though its bad parts are very bad.

  4. Peter Lind, PHP internals list participant PHP internals list, thread "Allow letter decrementing", message 68184 source ↗

    Citing Perl 6's Synopsis 3 in a thread on letter decrementing, Lind notes that Perl 6 can decrement strings, though not as a full mirror image of its increment.

Swift's regex work is the deepest engagement and the clearest case of attrition between design and ship. The interest started in the core team: Chris Lattner urged forum readers to study Perl 6's regexes from December 2015, wrote in January 2017 that Swift could learn a lot from Perl 6's grammars, and was still praising them in March 2020, while Joe Groff and Dave Abrahams pointed to Perl 6's approach and its recursive grammars in the same January 2017 thread (335/421; 876/922; 4939/13023; 34373/1024; 4939/6825; 4939/15326). Michael Ilseman's January 2018 "State of String" gist set Swift the goal of beating Perl at string processing, cited Apocalypse 5 as Perl's clean-up of its own regex mess, noted that Perl 6 has a PEG-like grammar system, and listed Perl 6 features Swift should take outright: whitespace-insignificant syntax, named captures, multi-line matching and regex interpolation. It also proposed ratcheting, frugal quantifiers and Raku's % separator quantifier, and asked whether alternation should use longest-token matching (gist10). By October 2021 Ilseman was explaining the retreat: familiarity with traditional syntax was decisive for a literal, so the team would spend its appetite for novelty on a separate Pattern type, even though he personally preferred Raku's syntax (forum #4611). In Hamish Knight's March 2022 regex-syntax pitch, Joe Groff's first reply again cited Raku for making /x the default (Swift Forums27), and SE-0354 split the difference, making extended syntax mandatory in multi-line #/…/# literals while rejecting non-semantic whitespace for single-line ones (SE-035428). A5's 2002 choices thus reached Swift 5.7 two decades later in altered form — composable, named sub-patterns in RegexBuilder (SE-035129), PEG-style ordered choice credited to PEGs (SE-035030), and mandatory extended syntax in multi-line literals — while the attribution survives only in a gist and forum posts. SE-0363 even defines a [raku] reference link that its body never uses (SE-036331). Joose is a genuine Perl 6 → other-language transmission, but it passed entirely through Moose and remained niche (Joose manual14).

What the sources say 11

  1. Chris Lattner, Swift's creator, core team Swift Forums (swift-evolution import), "Empower String type with regular expression", post #4 source ↗

    Lattner hopes Swift gains proper regex support and argues that first-class language support would allow inline captures, flexible syntax, compile-time checking and Perl 6-style extensions beyond the basic regex model.

  2. Chris Lattner, Swift's creator, core team Swift Forums (swift-evolution import), "Empower String type with regular expression", post #9 source ↗

    Lattner urges readers to study Perl 6's regexes, explaining that a community obsessed with regexes got to rebuild them from experience and produced something very powerful.

  3. Chris Lattner, Swift's creator, core team Swift Forums (swift-evolution import), "Strings in Swift 4", post #130 source ↗

    Agreeing with Joe Groff, Lattner says Swift has much to gain from Perl 6's grammars and should take its time on them, adding that by regex he means a general grammar system.

  4. Chris Lattner, Swift's creator, core team Swift Forums, "Regular expressions in Swift", post #10 source ↗

    Lattner says Perl 6 has excellent ideas for regex support after long community thought, and that although the language is not widely used, Swift should study and learn from its strengths.

  5. Joe Groff, Swift core team Swift Forums (swift-evolution import), "Strings in Swift 4", post #68 source ↗

    Groff warns against a narrow focus on regexes, says the Perl 6 designers grew regex support into arbitrary grammars, and recommends Swift begin from that level by examining their work.

  6. Dave Abrahams, Swift core team Swift Forums (swift-evolution import), "Strings in Swift 4", post #153 source ↗

    Abrahams explains that regexes cannot parse languages like Swift and that he has in mind parsers of the kind Perl 6's recursive grammars allow, linking examples.

  7. Joe Groff, Swift team, replying to Hamish Knight's pitch Swift Forums, Regex Syntax pitch thread, post #2 (the pitch itself is Hamish Knight's) source ↗

    Groff backs a PCRE baseline, singles out free-whitespace /x mode as the most valuable tweak, and notes that Raku made it the default for pattern literals, urging new languages to do likewise.

  8. Hamish Knight, Michael Ilseman and David Ewing, authors Swift Evolution proposal SE-0354, Regex Literals source ↗

    Enables extended (?x) syntax, with non-semantic whitespace and comments, in multi-line #/…/# literals, and rejects that default for single-line ones for familiarity and compatibility; it cites Perl, never Raku.

  9. Richard Wei, Michael Ilseman, Nate Cook and Alejandro Alonso, authors Swift Evolution proposal SE-0351, Regex builder DSL source ↗

    Introduces RegexBuilder, a result-builder DSL for assembling regexes from reusable components, including other regexes and custom patterns, without mentioning Perl or Raku.

  10. Michael Ilseman, author Swift Evolution proposal SE-0350, Regex Type and Overview source ↗

    Calls Parsing Expression Grammars the nearest formal analogue of Swift's regex design, which uses ordered-choice alternation, possessive quantification and recursive subpattern calls; it never mentions Perl or Raku.

  11. Nate Cook and Alejandro Alonso, authors Swift Evolution proposal SE-0363, Unicode for String Processing source ↗

    Compares Swift's grapheme-cluster regex matching with NSString, Java, Ruby and Perl, and lists a reference link to Raku's regex documentation that nothing in the proposal's text uses.

Two further transmissions sit below the language level, and neither counts as a language borrowing. Matthew Barnett, author of the third-party Python regex module, wrote in 2008 that his variable-length lookbehind, done by matching backwards, came from a page on how Perl 6 could implement it; he names no page, but S05 had described after as reversing the syntax tree since at least April 2006, and CPython never took the module into re (cpython#4807532; S0533; PyPI regex34). And the Rust Grammar Working Group's notation took Raku's % and %% separator modifiers, which eddyb, then on Rust's language and compiler teams, attributed to Perl 6 in 2018; the wg-grammar files use %% throughout, while the Rust Reference keeps its own notation (internals #835; expr.lyg36).

What the sources say 5

  1. Matthew Barnett, author of the third-party regex module python/cpython issue #48075 (migrated from bugs.python.org), comment source ↗

    Barnett reports that his re-engine rework adds backward matching so lookbehinds can be variable-width, and credits the idea to a page on implementing it in Perl 6, without naming the page.

  2. Synopsis 5 (Larry Wall, Damian Conway, Patrick Michaud and others), Perl 6 design document S05-regex.pod, Raku/old-design-docs repository source ↗

    States that the after assertion performs lookbehind by matching a reversed syntax tree leftward, and forbids lookbehind on any pattern that is not reversible.

  3. Matthew Barnett, the regex module's author PyPI project page for regex source ↗

    Describes regex, a separately installed package, as an alternative intended to replace Python's built-in re, compatible with it but adding features, among them lookbehinds able to match strings of varying length.

  4. eddyb (Eduard-Mihai Burtescu), Rust language and compiler team member Rust internals forum, "Proposal: Grammar Working Group", post #8 source ↗

    Describing the proposed grammar notation, eddyb lists separator forms for repeated items and says the % syntax comes from Perl 6, as he recalls, having been suggested by eternaleye.

  5. Rust Grammar Working Group (eddyb, Eric Huss, Mazdak Farrokhzad) rust-lang/wg-grammar repository, grammar/expr.lyg source ↗

    The working group's expression grammar writes comma-separated lists, among them array elements, tuple fields, call and method arguments and closure parameters, with the %% separator modifier.