json

ght back to regular expression syntax. It also has a much better syntax for doing advanced things, as it was completely redesigned from first principles. The following is an example of how to match at least one `A` followed by exactly that number of `B`s and exactly that number of `C`s. (Note that bare square brackets [] are for grouping, not for character classes.) my $string = 'AAABBBCCC'; say $string ~~ / ^ # match at least one A # store the result in a named sub-entry $<A> = [ A+ ] {} # update result object # create a lexical var named $repetition :my $repetition = $<A>.chars(); # <- embedded Raku syntax # match B and then C exactly $repetition times $<B> = [ B ** {$repetition} ] $<C> = [ C ** {$repetition} ] $ /; Result: ｢AAABBBCCC｣ A => ｢AAA｣ B => ｢BBB｣ C => ｢CCC｣ The result is actually a very extensive object that has many ways to interrogate it. What you see above is just a built-in human readable view of it. In most regular expression syntaxes to match equal amounts of `A`s and `B`s you would need to recurse in-between `A` and `B`. That of course wouldn't allow you to also do that for `C`. That also wouldn't be anywhere as easy to follow as the above. The above should run fairly fast because it never has to backtrack, or recurse. When you combine them into a grammar, you will get a full parse-tree. (Actually you can do that without a grammar, it is just easier with one.) To see an actual parser I often recommend people look at JSON::TINY::Grammar https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Gra... Frankly from my perspective much of the design of "actual parsers" are a byproduct of limited RAM on early computers. The reason there is a separate tokenization stage was to reduce the amount of RAM used for the source code so that further stages had enough RAM to do any of the semantic analysis, and eventual compiling of the code. It doesn't really do that much to simplify any of the further stages in my view. The JSON::Tiny module from above creates the native Raku data structure using an actions class, as the grammar is parsing. Meaning it is parsing and compiling as it goes.

to bootstrap it we of course need to actually have keywords and operators there to build upon.) Since modules can add new things, we would need to update the list of known tokens as we are parsing. Which means that even if Raku did the tokenization thing, it would have to happen at the same time as the other steps. Tokenization seems like an antiquated way to create compilers. It was needed as there wasn't enough memory to have all of the stages loaded at the same time. --- Here is an example parser for JSON files using regexes in a grammar to show the simplicity and power of parsing things this way. grammar JSON::Parser::Example { token TOP { \s* <value> \s* } rule object { '{' ~ '}' <pairlist> } rule pairlist { <pair> * % ',' } rule pair { <string> ':' <value> } rule array { '[' ~ ']' <arraylist> } rule arraylist { <value> * % ',' } proto token value {*} token value:sym<number> { '-'? # optional negation [ 0 | <[1..9]> <[0..9]>* ] # no leading 0 allowed [ '.' <[0..9]>+ ]? # optional decimal point [ <[eE]> <[+-]>? <[0..9]>+ ]? # optional exponent } token value:sym<true> { <sym> } token value:sym<false> { <sym> } token value:sym<null> { <sym> } token value:sym<object> { <object> } token value:sym<array> { <array> } token value:sym<string> { <string> } token string { ｢"｣ ~ ｢"｣ [ <str> | ｢\｣ <str=.str_escape> ]* } token str { <-["\\\t\x[0A]]>+ } token str_escape { <["\\/bfnrt]> } } A `token` is a `regex` with `:ratchet` mode enabled (no backtracking). A `rule` is a `token` with `:sigspace` also enabled (whitespace becomes the same as a call to `<.ws>`). The only one of those that really looks anything like traditional regexes is the `value:sym<number>` token. (Raku replaced non capturing grouping `(?:…)` with `[…]`, and character classes `[eE]` with `<[eE]>`) This code was copied from https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Gra... but some parts were simplified to be slightly easier to understand. Mainly I removed the Unicode handling capabilities. It will generate a tree based structure when you use it. my $json = Q:to/END/; { "foo": ["bar", "baz"], "ultimate-answer": 42 } END my $result = JSON::Parser::Example.parse($json); say $result; The above will display the resultant tree structure like this: ｢{ "foo": ["bar", "baz"], "ultimate-answer": 42 } ｣ value => ｢{ "foo": ["bar", "baz"], "ultimate-answer": 42 } ｣ object => ｢{ "foo": ["bar", "baz"], "ultimate-answer": 42 } ｣ pairlist => ｢"foo": ["bar", "baz"], "ultimate-answer": 42 ｣ pair => ｢"foo": ["bar", "baz"]｣ string => ｢"foo"｣ str => ｢foo｣ value => ｢["bar", "baz"]｣ array => ｢["bar", "baz"]｣ arraylist => ｢"bar", "baz"｣ value => ｢"bar"｣ string => ｢"bar"｣ str => ｢bar｣ value => ｢"baz"｣ string => ｢"baz"｣ str => ｢baz｣ pair => ｢"ultimate-answer": 42 ｣ string => ｢"ultimate-answer"｣ str => ｢ultimate-answer｣ value => ｢42｣ You can access parts of the data using array and hash accesses. my @pairs = $result<value><object><pairlist><pair>; my @keys = @pairs.map( *.<string>.substr(1,*-1) ); my @values = @pairs.map( *.<value> ); say @pairs.first( *.<string><str> eq 'ultimate-answer' )<value>; # ｢42｣ You can also pass in an actions class to do your processing at the same time. It is also a lot less fragile. See https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Act... for an example of an actions class. --- Note that things which you would historically talk about as a token such as `true`, `false`, and `null` are written using `token`. This is a useful association as it will naturally cause you to write shorter, more composable regexes. Since they are composable, we could do things like extend the grammar to add the ability to have non string keys. Or perhaps add `Inf`, `-Inf`, and `NaN` as values. grammar Extended::JSON::Example is JSON::Parser::Example { rule pair { <key=.value> ':' <value> } # replaces existing rule # adds to the existing set of value tokens. token value:sym<Inf> { <sym> } token value:sym<-Inf> { <sym> } token value:sym<NaN> { <sym> } } This is basically how Raku handles adding new keywords and operators under the hood.

--> 'Life, the Universe and Everything' ){ } } Roles were heavily influenced by Smalltalk traits. Rather than being limited to those uses, Roles were expanded to include all of those other use-cases as well. --- Really Roles are a better method of code-reuse than inheritance. role Animal { method species ( --> Str ){...} method produces-egg ( --> Bool ){...} } role Mammal does Animal { method produces-egg ( --> False ){ # most mammals do not produce eggs. } } role Can-Fly { method flap-wings ( --> 'flap flap' ){ } } class Bat does Mammal does Can-Fly { method species ( --> 'Bat' ){ } } class Bird does Animal does Can-Fly { method species ( --> 'Bird' ){ } method produces-egg ( --> True ) { } } class Platypus does Mammal { method species ( --> 'Platypus' ){ } method produces-egg ( --> True ) { # override Mammal.produces-egg() } } Of course a simple example doesn't do this ability justice. It really shines on large code-bases. For a better example see: “Curtis Poe (Ovid) - Roles versus Inheritance” https://www.youtube.com/watch?v=cjoWu4eq1Tw That is of course about roles in Perl, which doesn't have all the same features. All of the points do apply to Raku roles though. --- Raku has so many good ideas it would be a waste if other languages didn't copy at least some of them. I of course can understand if a single language doesn't want to copy all of them at the same time. It would definitely be a waste if no other language tries to combine regular expressions, parsers, and objects like Raku grammars have done. At the very least Raku regular expressions are easier to understand than Perl compatible regular expressions. (Note that I very much DO understand PCRE syntax, having used it heavily in Perl for many years.) Compare the Raku grammar for JSON https://modules.raku.org/dist/JSON::Tiny:cpan:MORITZ/lib/JSO... to the Perl version https://metacpan.org/release/JSON-Decode-Regexp/source/lib/J... I would like to point out that when JSON started allowing any value as a top-level result, it actually made the Raku code simpler. https://github.com/moritz/json/commit/9888329771730574967197...

he main exception I'm aware of is that subs and ops related to matching still default to operating on "it". The Perl 5 <> op is gone. > Or, perhaps the syntax for dealing with elements in a somewhat deep data structure, like: push(@{$TV{$family}{kids}},"anotherkid"); This would be something like this in Perl 6: my %TV; my $family = 'foo'; push %TV{$family}<kids>, 'another'; > Sometimes, people are just griping about regex syntax though, which seems disingenuous, since many languages use the exact same pcre expressions. This is talked of in Perl 6 circles as being ironic because regex syntax has been thoroughly cleaned up (and massively powered up too) in Perl 6.[1] > I like perl, but if it's been a while, there's definitely some back and forth with books to decipher something I wrote some time ago. One of the many downsides to Perl 6, imo, is that this back-to-the-book-oh-yeah aspect is still there -- but there's only incomplete doc and no books yet written by the likes of Larry. [1] See, for example, https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Gra...

ved characters]". [3] Is that still correct or out of date?) ---- > Perl suffers from having too many magical operators that makes it hard to reason about a snippet of code. I feel Python strikes the right balance. To quote Larry Wall, "Perl 6 ... has been rethought and rebalanced on every level".[4] It might be interesting for you to pick a couple Perl 5 operators that you consider too magical; then we could look at the merits and demerits of those ops in Perl 5 and their equivalents in Python and Perl 6. > It's very easy to express ideas I have in mind without worrying about the details [of Python, now, and Perl, back in the day] This, of course, has explicitly been a deliberate focus of all the Perls. Part of the point of Perl 6 was to remove the bits in Perl 5 that were problematic (including some "too cute/weird" stuff) and to introduce much nicer higher level abstractions (eg grammars instead of just regexes[5]). ---- I've long encountered vocal folk who underestimate or misunderstand Larry Wall and Perl to an absurd degree. Perl has been focused for over two decades on making it easy to get the right results when doing basic practical things (like integer division and counting characters) and, imo, that ought to be obvious to anyone who looks at the matter carefully. ---- [1] http://www.slideshare.net/Ovid/perl-6-for-mere-mortals and https://www.youtube.com/watch?v=lpu-3UF_b48 [2] http://www.reddit.com/r/perl/comments/2szv7m/beginner_progra... [3] http://unicode-programming.readthedocs.org/en/latest/count-c... [4] http://www.infoworld.com/article/2882300/perl/perl-creator-l... [5] https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Gra...

ing any change in code that uses regexes (unless an engine uses a different syntax of course). (But it takes a lot of effort to package a regex engine up for use with Perl 5.) A given regex engine can be extended using the overload module. Extending is relatively easy. = About Perl 6 regexes = A whole new ball game, two decades ahead of Perl 5 regexes. http://en.wikipedia.org/wiki/Perl_6_rules http://doc.perl6.org/language/grammars https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Gra... Generally matches Perl 5 regexes feature-for-feature but with a much cleaner syntax. More importantly, unifies regexes and grammars. Currently way slower than Python or Perl 5 regexes. Supposedly will eventually (5 years? 10?) incorporate all the key optimizations in the Perl 5 engine and become faster than Perl 5 regexes.

earn". ( I for one found it quite easy to learn, and can read it quickly. ) --- Really can you make all of the following examples clearer in any other single language? constant powers-of-two = 2,4,8 ... *; # an infinite deductive list # perhaps that would be more clear as: constant powers-of-two = 2, 4, 8, 16, 32, 64 ... *; # list of pairs using the zip meta-operator (Z) # combined with the pair constructor operator (=>) my @a = 'a'..'z' Z=> 0..*; # ( a => 0, b => 1, etc ) my $new-password = ('a'..'z','A'..'Z',0..9).roll(12).join; # 'ygHIHbi4XgUV' # the zero in the following is to prevent an off-by-one error # when accessing by index # * + * creates a code ref that takes two inputs and numerically adds them together constant fibonacci-list = 0, 1, 1, * + * ... *; # takes about a second the first time it's accessed currently say fibonacci-list[10000].chars == 2090; # if you wanted it to look more like haskell you could write it like this: constant fibonacci-list = 0, 1, 1, &[+] ... *; my @dice-rolls := ('⚀'..'⚅').roll(*); # infinite list of dice rolls # deck of cards using the cross meta-operator (X) # and the string concatenation operator (~) my @deck = 2..10,<J Q K A> X~ <♡ ♢ ♣ ♠>; my @shuffled = @deck.pick(*); # ( .say ) is short for ( $_.say ) # prints the first 6 numbers (0..5) each on it's own line for ^6 { .say } # prints the numbers 0..5 each on it's own line, # possibly randomized, # possibly each in it's own thread ( texas version ) (0..^6)>>.say; (^6)».say; # ditto ( french version ) # ( those were purposefully misusing an auto-threading list operator >> ) # says a random number (1..5), 5 times out of 6 if (0..5).pick -> $number { say $number } if (0..5).pick { say $^number } # ditto --- That was just a sampling of the bread-and-butter constructs (some of which were used in a way that most people wouldn't use them). There are also operators for dealing with Sets for example. ( ⋃ and (elem) being two of them ) see: http://doc.perl6.org/ You can even create new operators the same way you define a subroutine ( That's all they are in the Rakudo implementation, for most of them. ) # common factorial example sub postfix:<!> ( Int \n where * >= 0 ) is tighter(&infix:<*>) { [*] 1..n } say 5!; # 120