Please see the PDF of our Release Brochure for all the details: marketing.perl6.org/id/1541379592/pdf_digital (print-friendly version is also available on marketing.perl6.org)
If you are unable to view PDF documents, most important details are also available as a plain text file in the repository github.com/perl6/roast/blob/master/docs/announce/6.d.md
Compiler releases with 6.d as their default language version will follow their standard release scheduling (for Rakudo compiler, release process will start on 2018-11-17)
Happy Diwali!
]]>Every year since 2009, the Perl 6 community publishes a Perl 6 advent calendar, in the form of blog posts on perl6advent.wordpress.com.
To keep up this great tradition, we need 24 blog posts, and volunteers who write them. If you want to contribute a blog post about anything related to Perl 6, please add your name (and potentially also a topic already) to the schedule, and if you don't yet have a login on the advent blog, please tell Zoffix or someone on #perl6 IRC chat your email address so that they can send you an invitation to Wordpress for the site.
Perl 6 advent blog posts should be finished the day before they are due, and published on midnight (UTC) of the due date as publishing date.
If you have any questions, or want to discuss blog post ideas, please join on the #perl6 IRC channel on irc.freenode.org.
]]>I (Zoffix Znet) am writing this document to Larry Wall to request the creation of a second name for the "Perl 6" language. This name is not a rename of the language, but is simply an alternative name, an alias. Similar to how TimToady is an alias for Larry Wall.
It's been a year and a half since the time when I first re-opened this issue with a blog post, and in this document, I compiled the argumentation for creation of the alias, the community suggestions for what that alias might look like, along with the observations of discussions on the topic that occured during that time period.
I ask that Larry Wall renders his decision on the alias by November 1, 2018, so we would have the time to create proper informational materials for the 6.d language release, during which time, the name alias would be officially announced, if one is chosen.
The original idea for the alias came in the form of creating a "marketing alias", for markets where Perl "is a swear word." However, I believe such an alias has a more immediate application closer to home, by improving the wellbeing of the existing community and the interactions of its members with other programming communities, including the Perl 5 community.
The idea of Perl 6 was birthed in the form of the community rewrite of the Perl language. This name alias, then, is the Community Alias for that language.
The current language name "Perl 6" comes with a set of built-in assumptions that do not apply either to the language or to currently-available compilers for it. The assumptions encoded in the name are:
In reality, what we have is an entirely brand new language. Different, and with all the caveats typical of brand new software.
Other than the "spirit" some claim the Perl 5 and Perl 6 languages share, they're dissimilar in many ways.
$ perl -e 'print "I am a Perl ", "0" && 6||5, " program\n"'
I am a Perl 5 program
$ perl6 -e 'print "I am a Perl ", "0" && 6||5, " program\n"'
I am a Perl 6 program
In Perl 5 you choose your own OO system, concurrency/parallelism system, your list processing utilities, etc; in Perl 6, many of these features are a large part of the standard language itself. In Perl 5, you're told to never use threads
; in Perl 6, even an empty program is multi-threaded (JIT runs on a separate thread). In Perl 5, lists autoflatten; In Perl 6, they don't and you have a choice of multiple core list types.
Thus, we lose on two fronts: those who love Perl 5 and come to Perl 6 get disappointed because they get a different language; and those who hate Perl 5 never bother trying out Perl 6, assuming it's the same language they hate.
The naming of "Perl 6" has a strong suggestion that "6" is the version number rather than a part of the name. Some suggested it's easy to explain this caveat of naming, but my personal experience was quite the opposite of that. First, it's hard to wedge this information during a real-time meatspace conversation:
— What are you working on?
— Writing an AI for a game in Python.
— You?
— Hacking on Rasperry Pi with C.
— You?
— Making a media center for my car in Perl 6. YES. YOU MAY HAVE HEARD OF PERL, BUT PERL 6 IS NOT PERL BUT A RELATED LANGUAGE.
— ...
Second, even after you make that clarification, people still continue to shorten the name to just Perl ("You're the Perl guy, right?"). Moreover, some media, such as banners and posters, often do not allow for adding a suitable clarification.
Lastly, similar shortening of the name occurs with some software, such as DuckDuckGo search engine producing results for Perl 5 instead of Perl 6 when searching for "perl6 argv".
The biggest issue here, however, is the relationship with the Perl 5 community. The mere existence of a "Perl 6" language paints Perl 5 as obsolete. While the Perl 6 community has to make clarifications to distance itself from Perl 5's negatives that don't apply to Perl 6, the Perl 5 community must make the same clarifications just to convince people they're not dead. This brews understandable animosity towards Perl 6.
The Perl 5 language is effectively blocked from releasing the next "major version", because Perl 6 is squatting on it. And were Perl 5 to release a "Perl 7", that would immediatelly paint Perl 6 as obsolete. The lack of any established alternate names leaves Perl 6 vulnerable to such a scenario.
Thus, we have three community issues: difficulty for community to explain what language they're using; difficulty for community to find information about the language; and difficulty of amicable existence beside the Perl 5 community.
The Christmas release of Perl 6 came with a caveat that it's the language spec that's stable now, and the compiler itself needed more work. That is exactly the sort of a caveat you'd expect to come with a brand new language.
However, our brand new language is not named that way. The current name suggests it's the next version of Perl and thus it should be slightly different, and faster and more stable. None of which is currently true. By using the name to associate ourselves so closely with Perl 5, we effectively set a performance target to surpass. Yet, due to how new our language is, there is still a lot of work needed to reach that target, and due to significant differences between the languages, some of these targets might not be met when comparing exactly the same constructs (e.g. Perl 6 regexes produce a much more complex data structure—a tree of Match
objects).
Thus, by mislabeling our brand new language with a next-version language, we suffer disproportionally when our compiler does not perform as well or is not as stable as a well-established language.
In summation, the name "Perl 6" is a misrepresentation. It's a wrong label on a can. It causes friction within the broad Perl community and confusion or difficulty when communicating with those outside the Perl community.
It sets incorrect expectations of performance, stability, and features of the language.
It is detrimental to our future.
While numerous members of the community would have liked to see a full language rename, there are also those who believe a full rename would be detrimental. The full rename at this point in time is also a lot more challenging due to the existence of books, websites, documentation, environmental variables, and dynamic variables in the language—all with the name "Perl" in them.
As such, we are creating an alias only. One that does not have any reference to Perl in it (i.e. no "Perl++"). If another name is truly as superior as the full-rename proponents claim it would be, I believe the alias can become a defacto name through its sheer amount of use. Thus, the creation of the alias can be seen as a means for the full-rename proponents to prove their claims.
What follows are references to real-world examples of confusion and problems due to the current name, additional community discussions on the naming along with suggestions for what that name can be, and other resources relevant to the topic.
The (parentheticals) indicate what issue was encountered in an item. The issues refer to issues examined in Reasoning for Alias section above.
With the 6.d release around the corner, we have approached the point where a direct request to Larry Wall is made with the matter of assuaging the problem of the naming of the language.
Through a year and a half worth of discussions, we came to a conclusion that a second name to the language should be created, as opposed to a full rename. This will let the proponents of a rename to prove their claims, without severely upsetting those who believe the current name is beneficial.
This document presented argumentation for why a second name is beneficial, as well as compiled the discussions and suggestions that occured during that year and a half.
It is now up to TimToady to reach the final decision on whether the official alias is to be created during the 6.d language release and what that alias is to be.
See you at the 6.d release party! Bring your own virtual beer.
]]>Today's is a milestone of sorts: it's 100 days before the first scheduled Rakudo Perl 6 compiler release that will occur after this year's festival of Diwali. As some know, Diwali is also the code name for the next major release of the Perl 6 language, version 6.d, which means there's a high chance that in about 100 days you'll be able to install and use that.
I figured, I'd write a update on the subject.
The oft-asked questions is when is 6.d going to be released. The plan is to have the 6.d specification good and ready to release on this year's Diwali, which is November 6–7.
About 10 days later the Rakudo compiler will be
released (compiler-only, not the Rakudo Star),
with 6.d language enabled by default. That is, you'll no longer
need to use use v6.d.PREVIEW
pragma to get 6.d features, and if you wish to
get old, 6.c behaviour you'll need to use an explicit use v6.c
pragma.
However, there's a ton of work to do and the work is largely done by volunteers, so we have no compunction about delaying the release of any of the deliverables indefinitely, if the need arises.
The 6.d major version of the Perl 6 programming language includes over 3,400 new commits in its specification. The vast majority of these are clarifications to 6.c spec. In other words, most of these define previously undefined behaviour, rather than specify entirely new features.
Many of the clarifications and new features do not conflict with the 6.c
specification. If you're using the Rakudo compiler, you are likely already
reaping some of the benefits of the 6.d language, as such things do not require
explicit use v6.d.PREVIEW
pragma.
Those who've seen the 6.d Teasers frequently ask for the full list of 6.d changes. That list does not yet exist, as the spec is still in the process of being reviewed. The changelog will be available some time in October. You may have seen the 6.d prep repo, but that just contains guiding info for coredevs and isn't descriptive of the actual 6.d content.
The aforementioned ton of work includes:
Going forward for future language releases, I foresee us doing a point release every 6 months, and 6.e being released 2 or 3 years after 6.d. The previously 6.d-blocking Issue R#1289 still blocks a number of language changes, and all the 6.d changes blocked by that Issue were pushed to later language versions. So, if that Issue is resolved, that will likely be a reason to cut a language release soon thereafter.
The prep work for next major release of the Perl 6 Programming Language version 6.d (Diwali) is in a high gear. There's lots of work to do. Will likely release spec on November 7th, with compiler release following step and being released about 2 weeks after that. The list of changes will be ready in October and does not currently exist in any user-consumable form.
Let the hype begin \o/
-Ofun
]]>As some of you already may have known from occasional tweets and mentions
in the Weekly, we have a
perl6/marketing
repo that contains
some flyers and brochures for Perl 6.
With one of the Perl 6 coredevs making a living as a Multi-Media Designer, the repo has seen a steady stream of new pieces designed, when inspiration strikes, or when someone makes a request. There are now several pieces available, but GitHub isn't the greatest interface for this sort of stuff.
To make it easier to see what we have available, we made a front-end for our marketing repo, that lets you browse all of the assets. It's hosted at marketing.perl6.org
Under the thumbnail of each asset, there are a few buttons that show you which formats are available for download. The last two buttons are the GitHub button and the pencil button. The former will lead you to GitHub to the folder that particular asset is at, where you can download any files that aren't shown on the front end (e.g. the source files). The latter will lead you to the New Issue page on the marketing repo, with title/ID of the piece pre-filled. This is in case you'd like to request different format, size, or some other changes for that piece.
Each piece has an ID number (a Unix timestamp, e.g 1516098660
).
If you want to refer to some piece, try to include its ID, as that's the easiest
way for the designer to know what piece you're talking about.
INB4, the Camelia logo variants are so numerous because the rules allow for her colours to be changed. Personally, I prefer transparent wings, as they're easier on my retinas than the default logo.
Keep in mind, you can request new pieces as well. Just file a new Issue in the marketing repo, describing the content that you want, including the sizes/colour restrictions, and our volunteers will hook you up.
While files themselves are easy to make for free, the same isn't the case for hard copies. We (the volunteers handling the marketing repo) can't print any hardcopies for you. Unless you are able to use a local printing company and pay out of your own pocket, your best bet would be to contact The Perl Foundation and ask them if they can sponsor the prints. I know they made prints of the Introducing Perl 6 brochure for a conference in the past.
The assets shown in the marketing web app are licensed under Creative Commons Attribution 4.0 International License. The Camelia logo is copyright by Larry Wall. Some of the pieces use purchased stock, which may have licenses that limit super-large print runs (50,000+ copies). Check the files in the repo or contact Zoffix if you have an unusual usecase for the materials and wish to clarify the licensing.
The source files (InDesign/PhotoShop/Adobe Illustrator) themselves can be modified freely, under the terms of Creative Commons Attribution 4.0 International License. Any images/fonts/other assets used by those source files might have additional licensing restrictions, which will usually be noted in the directory for that asset.
Going out for some tech meetup? Print out a few pieces from our marketing web app, hand them out, share the Perl 6 love!
-Ofun
]]>An important part of a project is to keep a steady flow of new volunteers coming on board to help you out (that's Hug 1: Gift a Shovel in the Hole Digging Metaphor). Starting out can be difficult: you barely know the people who you're working with and you're not familiar with the codebase or the build toolchain. A bug that will take a regular coredeveloper a minute to fix, test, and ship, might be insurmountable for someone who doesn't know where to start.
Perl 6 can especially benefit from newcomer help, as core development is very easy to get into: a lot of bugs involve pure Perl 6 code, mixed with some NQP subroutine calls that aren't much different than using subroutines from an ecosystem module.
For some time now, the Perl 6 devs labeled easy Issues with particular labels. However, that still leaves some challenges for new volunteers in place: knowing what the labels really mean, knowing how to build the project with the fix applied, and knowing how to run the tests.
To address those issues, I drafted a Newcomer Guide to Contributing to Core Perl 6 that will be linked to on specially labeled Issues. It's still an early version and will likely see several revisions based on the type of questions new volunteers ask.
It's meant to be a quick guide a programmer can read to get into contributing
to Rakudo Perl 6. It's not meant to be exhaustive, so for example things
like how to submit a Pull Request or make a commit with git
are outside of
its scope.
The Z-Script the guide uses haven't seen much battle testing by people without a commit bit to all the repos, so I suspect that will need some improvement as well, as people start to use it.
Be sure to label easy issues with the labels mentioned in the guide. Encourage people to fix bugs. The person reporting the bug can be given a few tips on how to fix the very problem they're reporting and asked whether they wish to submit a fix. You never know when a one-off contributor will become a regular core developer.
The Guide promises the core devs will answer questions and help walk the interested volunteers through the fixes of specially labeled Issues, so keep an eye open for such questions and help people out. Also, when filing the Issues for newcomers, add a few tips and suggestions on how the Issue can likely be fixed.
There isn't much else to say, other than check out the Guide itself and help make Perl 6 better! :)
]]>Last week I gave a "Intro Into Perl 6 Regexes and Grammars" talk at the Toronto Perl Mongers, whom I thank for letting me speak.
For google hangout that is usually set up, we got to use the fancy equipment provided by the company that was letting us use their space. Unfortunately, it's currently unclear if the hangout was recorded and if there would be a video of the talk.
So, I figured I'd make a screencast of the talk. You won't get some of the discussions that occurred during the meeting, but the content of the talk itself is pretty much identical.
You can view the slides at https://tpm-regex.perl6.party/ and the screencast of the talk is on YouTube:
]]>Last week I gave a "Faster Perl 6 Programs" talk at the Toronto Perl Mongers, whom I thank for letting me speak.
For google hangout that is usually set up, we got to use the fancy equipment provided by the company that was letting us use their space. Unfortunately, it's currently unclear if the hangout was recorded and if there would be a video of the talk.
So, I figured I'd make a screencast of the talk. You won't get some of the discussions that occurred during the meeting, but the content of the talk itself is pretty much identical.
You can view the slides at https://tpm-perf.perl6.party/ and the screencast of the talk is on YouTube:
]]>Since any further grant's work now differs significantly from what the TPF and community voted on, I prefer to cancel the grant and perform any of the remaining work on a volunteer basis, whenever I get a chance.
No payments will be made for any of the completed work to date and it is to be deemed to have been performed on a volunteer basis.
The originally promised MidRat
type is not going to be implemented. It was deemed to be likely a bad idea, as was described in my May Grant Report
The original proposal claimed Rats with larger-than-64-bit denominators resulted in precision loss in certain operations. Further investigation revealed that the actual cause of apparent precision loss were were bugs in Num
stringification precision (now-fixed by my Grisu3 algo work) and the implementation of Rational.Str
method (now largely fixed by another person).
Some of the originally hoped-for performance improvements due to nativization of denominator of Rat
might not be achieved. In MidRat
-less paradigm, the Rat type can have a denominator larger than 64-bits under some
conditions, making native types unsuitable to hold it. In addition, Rakudo currently boxes native types returned from methods, and until that is avoided, switching to native types would likely be detrimental to performance.
ZeroDenominatorRational
role was unimplementable. While the original grant proposal speculated that might be the case, it took me almost no time to hit a roadblock with this approach, making it a largely irrelevant item on the original proposal.
Normalization of Zero Denominator Rationals was promised on the proposal, but is blocked by 6.c language specification. Additionally, it's blocked from being changed in 6.d specification due to a rule that requires at least one working implementation of a feature, and it cannot be implemented in Rakudo yet, as we currently lack a mechanism to discern caller's language version.
Lastly, the bonus work that was promised would require me learning a bunch of new things about MoarVM. While that's doable, there are much more pressing matters that I could tend to instead—such as Rakudo's stability and spec compliance on Windows and preparation for 6.d language release.
In conclusion, I believe were this grant to be completed, the result would differ significantly from what was voted on during grant's proposal. For that reason, I wish to cancel it. The remaining work on the grant that is still doable will be performed by me on a volunteer basis, when the time allows.
]]>Today, I came across a reddit post from a couple months back, from a rather irate person claiming themselves to be possibly the only person to never receive any credit for their work on Perl 6.
I was aware that person committed at least one commit and knowing the contributors list is generated automagically with a script, I thought to myself "Well, that's clear and provable bullshit." And I went to prove it.
I looked up the commit I knew about, looked at the release announcement for the release it went into and… that person was indeed missing! It was the 2017.02 release, which I released. So what was going on? Did I have an alter-ego that shamelessly erased random people from the contrib list without my having any memory of it?!
First, a brief intro on how the contrib script works: it uses git
to look
up commits in checkouts of 5 repos: Rakudo, NQP, MoarVM, Docs, and Roast.
Until December 2016 the script just used the day of the
release as last release, which was later switched to using the timestamp
on the Rakudo's tag. The script gathers all the contributors from commits,
crunches the names through the names map in CREDITS files in the repos, and
it spits out the names ordered by the number of commits made, largest first.
I set out to figure out why a person was missing from the release announcement. After digging through commits, CREDITS files, and tracing the code in the contributor generating script, I found out that in September 2016, I introduced a bug into the contributors script. After some refactoring I accidentally left out MoarVM repository from the list of repos the script searches, so all the contributors to the MoarVM since September 2016 were missing! Since many of them also contribute to the other 4 repos, it was harder to spot that something was wrong.
I filed the problem as R#2024 and left it at that for the time being.
I started working on the problem and implemented a new feature in the contributors script that lets you look up contributors for past releases. Neat! So let's try it out for some release before my bug was made, shall we?
I ran the contrib script for 2016.08 relase and then ran another script that diffed the names from that output against what is on the release announcement. The output was:
Announcement has these extra names: David Warring
Contrib script has these extra names: Arne Skjærholt, Bart Wiegmans
The announcement had an extra name and was missing two. The way the contrib script figures out when one release ends and another starts is iffy, especially so in the past. There's a gap of about a day where contributors can slip through: e.g. release manager runs the release at 2PM, someone commits at 3PM, and that commit didn't make it into this release and will be included in the next, or might even be missed entirely.
So that was one problem I noticed. Is that where the difference for 2016.08 release names list comes from? Let's try the earliest post-The-Christmas release: 2016.01-RC1
Announcement has these extra names: Andy Weidenbaum, Lloyd Fournier, skids
Contrib script has these extra names: A. Sinan Unur, Aleks-Daniel Jakimenko-Aleksejev,
Brad Gilbert, Brian S. Julin, Brock Wilcox, Bruce Gray, Carl Masak,
Christian Bartolomäus, Christopher Bottoms, Claudio Ramirez, Dale Evans,
Dave Olszewski, David Brunton, Fritz Zaucker, Jake Russo, James ( Jeremy )
Carman, Jeffrey Goff, Jim Davis, John Gabriele, LLFourn, Marcel Timmerman,
Martin Dørum Nygaard, Neil Shadrach, Salvador Ortiz, Shlomi Fish, Siavash
Askari Nasr, Stéphane Payrard, Sylvain Colinet, Wenzel P. P. Peppmeyer,
Zoffix Znet, fireartist, sylvarant, vinc17fr
That's huge! One name stood out to me in that list—and it isn't my own—it was that same person from reddit who was complaining that they don't get credit. They got left out twice: in 2016.01 and again in 2017.02. No wonder they're pissed off, but I wish they would've said something in 2016.01, so we'd've fixed the Missing Persons issues back then instead of now.
The 2016.02 release has a bunch of missing names as well. I can surmise the cause of the issue is a previously fixed mis-implementation of the contributors script where it'd be quiet if some of the repo checkouts were missing. Neither I (until that point), nor earlier release managers had all of at the right locations the script was expecting, so it's possible that's how some repos were missed.
At the time, I assumed only the docs repo was missing and we credited missing Docs contributors in the 2016.08 announcement. However, now I realize that other release managers likely had different directory setups and thus missed different sets of people.
Thus, we have identified four issues with the way contributor's script is or has been generating the list of contributors:
I'm taking the lazy way out and leaving it to the current release managers to resolve these problems. I filed R#2028 with the list of issues and have full trust the solution that will be implemented will be suitable :)
And now, of course, the list of previously unsung heros who made Perl 6 better in the past two and a half years, in alphabetical order. I've also added them to our past release announcements.
It's possible this list includes the missing-found from 2016.08 announcement as well as people who were not logged in the CREDITS file in the past but are now, but I figure it's better to list them twice than none at all.
If you still believe we're missing someone, let us know so the problem can be fixed.
A. Sinan Unur, Aleks-Daniel Jakimenko-Aleksejev, Brad Gilbert, Brian S. Julin, Brock Wilcox, Bruce Gray, Carl Masak, Christian Bartolomäus, Christopher Bottoms, Claudio Ramirez, Dale Evans, Daniel Perrett, Dave Olszewski, David Brunton, Fritz Zaucker, Jake Russo, James ( Jeremy ) Carman, Jeffrey Goff, Jim Davis, John Gabriele, LLFourn, Marcel Timmerman, Martin Dørum Nygaard, Neil Shadrach, Salvador Ortiz, Shlomi Fish, Siavash Askari Nasr, Stéphane Payrard, Sylvain Colinet, Wenzel P. P. Peppmeyer, Zoffix Znet, fireartist, raiph, sylvarant, vinc17fr
Bart Wiegmans, Brian S. Julin, Brock Wilcox, Daniel Perrett, David Brunton, Eric de Hont, Fritz Zaucker, Marcel Timmerman, Nat, Pepe Schwarz, Robert Newbould, Shlomi Fish, Simon Ruderich, Steve Mynott, Wenzel P. P. Peppmeyer, gotoexit, raiph, sylvarant
Ahmad M. Zawawi, Aleks-Daniel Jakimenko-Aleksejev, Bahtiar kalkin-
Gadimov, Bart Wiegmans, Brian S. Julin, Brock Wilcox, Claudio Ramirez, Emeric54, Eric de Hont, Jake Russo, John Gabriele, LLFourn, Mathieu Gagnon, Paul Cochrane, Siavash Askari Nasr, Zoffix Znet, jjatria, okaoka, sylvarant
Brian S. Julin, Brock Wilcox, Christopher Bottoms, David H. Adler, Donald Hunter, Emeric54, Itsuki Toyota, Jan-Olof Hendig, John Gabriele, Mathieu Gagnon, Nick Logan, Simon Ruderich, Tom Browder, Wenzel P. P. Peppmeyer, Zoffix Znet
Aleks-Daniel Jakimenko-Aleksejev, Brian Duggan, Brian S. Julin, Brock Wilcox, Christopher Bottoms, Clifton Wood, Coleoid, Dabrien 'Dabe' Murphy, Itsuki Toyota, Jan-Olof Hendig, Jason Cole, John Gabriele, Mathieu Gagnon, Philippe Bruhat (BooK), Siavash Askari Nasr, Sterling Hanenkamp, Steve Mynott, Tadeusz “tadzik” Sośnierz, VZ, Wenzel P. P. Peppmeyer, Will Coleda
(contrib script missing repos issue is fixed around this point, so the number of missing persons drops. Remaining ones are likely the ones that fell into the gap between releases; particularly MoarVM and docs contributors)
Itsuki Toyota, Matthew Wilson, Will Coleda, parabolize
Bart Wiegmans, Brian S. Julin, Daniel Perrett, David Warring, Dominique Dumont, Itsuki Toyota, thundergnat
Arne Skjærholt, Bart Wiegmans
(missing MoarVM bug is introed at this point; we start to see the missing MoarVM devs who mostly work on MoarVM and not other repos. Also a bunch of docs people who likely fell into the gap between releases)
Alexey Melezhik, Bart Wiegmans, Paul Cochrane
Brent Laabs, Jimmy Zhuo, Steve Mynott
Bart Wiegmans, Itsuki Toyota, Jimmy Zhuo, Mark Rushing
Bart Wiegmans, Jimmy Zhuo, LemonBoy, Nic Q, Reini Urban, Tobias Leich, ab5tract
Antonio Quinonez, Jimmy Zhuo, M. Faiz Zakwan Zamzuri
A. Sinan Unur, Bart Wiegmans, Benny Siegert, Jeff Linahan, Jimmy Zhuo, Lucas Buchala, M. Faiz Zakwan Zamzuri
Jonathan Scott Duff, Lucas Buchala, Moritz Lenz
Bart Wiegmans, eater
Bart Wiegmans, Paweł Murias
Bart Wiegmans, Jimmy Zhuo, Oleksii Varianyk, Paweł Murias, Robert Lemmen, gerd
Bart Wiegmans, Douglas Schrag, Gerd Pokorra, Lucas Buchala, Paweł Murias, gerd
Bart Wiegmans, Dagfinn Ilmari Mannsåker, Douglas L. Schrag, Jimmy Zhuo, Mario, Mark Montague, Nadim Khemir, Paul Smith, Paweł Murias, Philippe Bruhat (BooK), Ronald Schmidt, Steve Mynott, Sylvain Colinet, rafaelschipiura, ven
Bart Wiegmans, Dan Zwell, Itsuki Toyota, Jan-Olof Hendig, Jimmy Zhuo, Mario, Paweł Murias, Rafael Schipiura, Skarsnik, Will Coleda, smls
Bart Wiegmans, Jimmy Zhuo, Joel, Julien Simonet, Justin DeVuyst, M, Mario, Martin Ryan, Moritz Lenz, Patrick Sebastian Zimmermann, Paweł Murias, bitrauser, coypoop, eater, mryan, smls
Bart Wiegmans, Jimmy Zhuo, Martin Barth, Patrick Zimmermann, Paweł Murias
Bart Wiegmans, Paweł Murias, Stefan Seifert, brian d foy
Bart Wiegmans, Daniel Dehennin, Paweł Murias, Stefan Seifert, Will Coleda
Bart Wiegmans, Daniel Green, Paweł Murias, cygx, wukgdu
Bart Wiegmans
Bart Wiegmans, Paweł Murias, cc, gerd
Antonio, Bart Wiegmans, elenamerelo
Bart Wiegmans, JJ Merelo
So this was quite a fun investigation and hopefully all the missing people have been found and this is the last missing-found persons list we compile.
The most important lesson, however, is: report problems as soon as you find them. We could've fixed this at the start of 2016, and those who knew they were left out could've saved two years of being upset about it.
-Ofun
]]>With what little Python I come across day-to-day, the Perl 6 version of the program often comes out shorter and clearer[^1][^2][^3].
Due to ubiquitous special-casing, Perl 5's syntax is more difficult to learn than Perl 6's, especially if you use it infrequently. Yet, I assume you both know the language well, given you're on this site, and managed to scale the learning curve without losing any limbs.
I feel like you are committing the same fallacy the "Perl is linenoise" crowd commits: you see a symbol you don't know the meaning of and you kneejerk into claiming it's unreadable or difficult to learn, yet the learning curve for a feature is the same whether it's written as "pass" or "{}".
[1] https://en.wikipedia.org/wiki/C3_linearization#Example_demonstrated_in_Python_3 vs. https://en.wikipedia.org/wiki/C3_linearization#Example_demonstrated_in_Perl_6
[2] https://twitter.com/zoffix/status/1009879112532492288
[3] https://rakudo.party/post/Python-is-The-New-Write-Only-Linenoise-Language
Yes, other than using `:batch` to mean `batch => 1` and perhaps abusing `:3rd` syntax for non-ordinals, it's fairly idiomatic Perl 6.
Perhaps, when the book comes out you should just give Perl 6 a go? In your comment above, you had no trouble writing both the full "this is" and shortcut form "that's", solely for the sake of omitting one character. Perl 6 is no different and you'll be using all variants of colonpairs in no time without even thinking about it.
]]>If I were to pick the most ubiquitous construct in the Perl 6 programming language, it'd most definitely be the colonpair. Hash constructors, named arguments and parameters, adverbs, and regex modifiers—all involve the colonpair. It's not surprising that with such breadth there would be many shortcuts when it comes to constructing colonpairs.
Today, we'll learn about all of those! Doing so will have us looking at the simplest as well as some of the more advanced language constructs, so if parts of this article make you scratch your head, don't worry—you don't have to learn all of it at once!
The colonpair gets its name from (usually) being a Pair
object constructor
and (usually) having a colon in it. Here are some examples of colonpairs:
:foo,
:$bar,
:meow<moo>,
heh => hah
The last one doesn't have a colon in it, but since it's basically the same thing as other colonpairs, I personally consider it a colonpair as well.
We can see the colonpairs make Pair
objects by dumping their
.^name
methodname):
say :foo.^name; # OUTPUT: «Pair»
However, when used in argument lists, the colonpairs are specially handled to represent named arguments. We'll get to that part later in the article.
Here's a mostly-complete list of available ways to write a colonpair you can glance over before we dive in. I know, it looks like a huge list, but that's why we're reading this article—to learn the general patterns that make up all of these permutations.
# Standard, take-any-type, non-shortcut form
:nd(2).say; # OUTPUT: «nd => 2»
:foo('foo', 'bar').say; # OUTPUT: «foo => (foo bar)»
:foo( %(:42a, :foo<a b c>) ).say;
# OUTPUT: «foo => {a => 42, foo => (a b c)}»
# Can use fat-arrow notation too:
# (parentheses around them are here just for the .say call)
(nd => 2).say; # OUTPUT: «nd => 2»
(foo => ('foo', 'bar') ).say; # OUTPUT: «foo => (foo bar)»
(foo => %(:42a, :foo<a b c>) ).say;
# OUTPUT: «foo => {a => 42, foo => (a b c)}»
# Booleans
:foo .say; # OUTPUT: «foo => True»
:!foo.say; # OUTPUT: «foo => False»
# Unsigned integers:
:2nd .say; # OUTPUT: «nd => 2»
:1000th.say; # OUTPUT: «th => 1000»
# Strings and Allomorphs (stings that look like numbers are Str + numeric type)
:foo<bar> .say; # OUTPUT: «foo => bar»
:bar<42.5> .say; # OUTPUT: «bar => 42.5»
:bar<42.5>.perl.say; # OUTPUT: «:bar(RatStr.new(42.5, "42.5"))»
# Positionals
:foo['foo', 42.5] .say; # A mutable Array: OUTPUT: «foo => [foo 42.5]»
:foo<foo bar 42.5>.say; # An immutable List: OUTPUT: «foo => (foo bar 42.5)»
# angled brackets give you allomorphs!
# Callables
:foo{ say "Hello, World!" }.say;
# OUTPUT: «foo => -> ;; $_? is raw { #`(Block|82978224) ... }»
# Hashes; keep 'em simple so it doesn't get parsed as a Callable
:foo{ :42a, :foo<a b c> }.say; # OUTPUT: «foo => {a => 42, foo => (a b c)}»
# Name and value from variable
:$foo; # same as :foo($foo)
:$*foo; # same as :foo($*foo)
:$?foo; # same as :foo($?foo)
:$.foo; # same as :foo($.foo)
:$!foo; # same as :foo($!foo)
:@foo; # same as :foo(@foo)
:@*foo; # same as :foo(@*foo)
:@?foo; # same as :foo(@?foo)
:@.foo; # same as :foo(@.foo)
:@!foo; # same as :foo(@!foo)
:%foo; # same as :foo(%foo)
:%*foo; # same as :foo(%*foo)
:%?foo; # same as :foo(%?foo)
:%.foo; # same as :foo(%.foo)
:%!foo; # same as :foo(%!foo)
:&foo; # same as :foo(&foo)
:&*foo; # same as :foo(&*foo)
:&?foo; # same as :foo(&?foo)
:&.foo; # same as :foo(&.foo)
:&!foo; # same as :foo(&!foo)
Let's break these up and take a closer look!
The "standard" form of the colonpair consists of a colon (:
), a valid term
that functions as the .key
of the created Pair
object, and then
a set of parentheses inside of which is the expression with the .value
for the Pair
:
:nd(2).say; # OUTPUT: «nd => 2»
:foo('foo', 'bar').say; # OUTPUT: «foo => (foo bar)»
:foo( %(:42a, :foo<a b c>) ).say;
# OUTPUT: «foo => {a => 42, foo => (a b c)}»
As long as the key is a valid identifier, all other forms of colonpairs can be
written using this way. And for non-valid identifiers, you can simply use
the .new
method—Pair.new('the key','value')
—or the "fat arrow" syntax.
If you ever used Perl 5, you need no introductions to this syntax: you write
the key—which will get auto-quoted if it's a valid identifier, so in those
cases you can omit the quotes—then you write =>
and then you write the value.
The quotes around the key are required if the key is not a valid identifier
and the fat arrow is the only operator-involved syntax that will let
you construct Pair
s with such keys:
# (outer parentheses are here just for the .say call)
(nd => 2).say; # OUTPUT: «nd => 2»
(foo => ('foo', 'bar') ).say; # OUTPUT: «foo => (foo bar)»
(foo => %(:42a, :foo<a b c>) ).say;
# OUTPUT: «foo => {a => 42, foo => (a b c)}»
("the key" => "the value").say; # OUTPUT: «the key => the value»
There are some extra rules with how this form behaves in argument lists as well as sigilless variables and constants, which we'll see later in the article.
Now we start getting into shortcuts! What would the most common use of named parameters be? Probably, to specify boolean flags.
It'd be pretty annoying to
always have to write those as :foo(True)
, so there's a shortcut: simply omit
the value entirely, and if you want :foo(False)
, omit the value and put the
negation operator)
right after the colon:
# Booleans
:foo .say; # OUTPUT: «foo => True»
:!foo.say; # OUTPUT: «foo => False»
# Equivalent calls:
some-sub :foo :!bar :ber;
some-sub foo => True, bar => False, ber => True;
The shortcut form is a lot shorter. This is also the form you may see
in adverbs and regex syntax, such as the :g
adverb on the m//
quoter
and :s
/:!s
significant whitespace modifier inside the regex:
say "a b c def g h i" ~~ m:g/:s \S \S [:!s \S \s+ \S]/;
# OUTPUT: «(「a b c d」 「f g h i」)»
Here's also another trick from my personal bag: since Bool
type is
an Int
, you can use boolean shortcuts to
specify Int
values 1
and 0
:
# set `batch` to `1`:
^4 .race(:batch).map: { sleep 1 };
say now - ENTER now; # OUTPUT: «1.144883»
However, for clarity you may wish to use unsigned integer colonpair shortcut instead, which isn't much longer.
The Perl 6 programming language lets you grab an nth match when you're matching stuff with a regex:
say "first second third" ~~ m:3rd/\S+/;
# OUTPUT: «「third」»
As you can probably surmise by now, the :3rd
after the m
in m//
quoter
is the adverb, written as a colonpair in unsigned integer shortcut. This
form consist of a colon and the name of the key with unquoted unsigned integer value placed
between them. No signs, no decimal dots, and not even underscore separators
between digits are permitted.
The primary use of this shortcut is for things with ordinal suffixes
like :1st
, :2nd
, :9th
, etc. It offers great readability there, but
personally I have no reservations about using this syntax for all unsigned
integer values, regardless of what the name of the key is. It feels slightly
offcolour when you first encounter such syntax, but it quickly grows on you:
some-sub :1st :2nd :3rd :42foo :100bar;
^4 .race(:1batch).map: { sleep 1 };
Using standard colonpair format you may notice some forms are too parentheses-heavy:
:foo(<42>) # value is an IntStr allomorph
:foo(<a b c>) # value is a List
:foo([<a b c>]) # value is an Array
:foo({:42foo, :100bar}) # value is a Hash
:foo({.contains: 'meows'}) # the value is a Callable
In these form, you can simply omit the outer parentheses and let the inner brackets and curlies do their job:
:foo<42> # value is an IntStr allomorph
:foo<a b c> # value is a List
:foo[<a b c>] # value is an Array
:foo{:42foo, :100bar} # value is a Hash
:foo{.contains: 'meows'} # the value is a Callable
It looks a lot cleaner and is simpler to write. Both the Hash
and
Callable
use the same set of curlies and the same simple rules as used by
the {…}
construct elsewhere in the language: if the content is empty,
or contains a single list that starts with a Pair
literal or %
-sigiled
variable, and the $_
variable or placeholder parameters are not used,
a Hash
is created; otherwise a Block
(Callable
) is created.
The angle bracket form (:foo<…>
) follows the same rules as the
angle bracket quoter used elsewhere in the language:
:foo< 42 >.value.^name.say; # OUTPUT: «IntStr»
:foo<meows>.value.^name.say; # OUTPUT: «Str»
:foo<a b c>.value.^name.say; # OUTPUT: «List»
And keep in mind that these two forms are not equivalent:
:42foo
:foo<42>
The first creates an Int
object, while the second one creates an
IntStr
object, which is an allomorph. This difference is important
for things that care about object identity, such as
set operators
The one thing I find a pain in the bit to write in other languages is constructs like this:
my $the-thing-with-a-thing = …
…
some-sub the-thing-with-a-thing => $the-thing-with-a-thing;
It's fairly common to name your variables the same as some named argument to which you wish to pass that variable as a value. The Perl 6 programming language offers a colonpair shortcut precisely for that case. Simply prepend a colon to the variable name to construct a colonpair with the key named the same as the variable (without including the sigil) and the value being the value of that variable. The only catch is the variable must have a sigil, so you can't use this shortcut with sigilless variables or constants.
my $the-thing-with-a-thing = …
…
some-sub :$the-thing-with-a-thing;
You'll notice that the syntax above looks exactly like how you'd declare a parameter that takes such a named argument—consistency is a good thing. All available sigils and twigils are supported, which makes the full list of variants for this shortcut look something like this:
# Name and value from variable
:$foo; # same as :foo($foo)
:$*foo; # same as :foo($*foo)
:$?foo; # same as :foo($?foo)
:$.foo; # same as :foo($.foo)
:$!foo; # same as :foo($!foo)
:@foo; # same as :foo(@foo)
:@*foo; # same as :foo(@*foo)
:@?foo; # same as :foo(@?foo)
:@.foo; # same as :foo(@.foo)
:@!foo; # same as :foo(@!foo)
:%foo; # same as :foo(%foo)
:%*foo; # same as :foo(%*foo)
:%?foo; # same as :foo(%?foo)
:%.foo; # same as :foo(%.foo)
:%!foo; # same as :foo(%!foo)
:&foo; # same as :foo(&foo)
:&*foo; # same as :foo(&*foo)
:&?foo; # same as :foo(&?foo)
:&.foo; # same as :foo(&.foo)
:&!foo; # same as :foo(&!foo)
This about wraps up the list of currently available colonpair shortcuts. As you can see, the huge list of shortcuts was reduced to a few simple patterns to follow. However, this might not be all the shortcuts that will exist for all the time…
While currently aren't available, the following two shortcuts might become part of the language in future language versions.
The first one is the indirect lookup shortcut. If you have a named variable and the name of that variable in another variable, you can access the value of the first variable using the indirect lookup construct:
my $foo = "bar";
my %bar = :42foo, :70bar;
say %::($foo); # OUTPUT: «{bar => 70, foo => 42}»
If you squint, the indirect lookup is sort'f like a sigilled variable and colonpair shortcuts
for sigilled variables exist, so it makes sense for the language to be
consistent and support indirect lookup colonpair shortcut, which would look
something like this, where the value of $foo
contains the name of
the key for the colonpair.
:%::($foo)
This form is currently listed as simply unimplemented feature in R#1532, so it'll likely see life some day.
The second possible future construct is the :.foo
form, which was proposed
in RFC R#1462.
This form calls method .foo
on the $_
topical variable and uses the return
value as the value for the created Pair
, with the name of the method being
the name of the key.
This form comes up semi-frequently when you're passing values of attributes of one object to another with similarly-named attributes, so something like this:
Some::Other.new: :foo(.foo) :bar(.bar) :ber(.ber) with $obj
Would in shortcut form be written like this:
Some::Other.new: :.foo :.bar :.ber with $obj
At the time of this writing, this RFC has been self-rejected, but you never know if there'd be more calls for introduction of this syntax.
Now that we're familiar with how to write all the forms of colonpairs, let's take a look at some of their available uses, especially those with special rules.
To specify that a parameter should be a named rather than a positional parameter, simply use the sigilled variable colonpair shortcut:
sub meow($foo, :$bar) {
say "$foo is positional and $bar is named";
}
meow 42, :100bar; # 42 is positional and 100 is named
meow :100bar, 42; # 42 is positional and 100 is named
Since parameters need some sort of a variable to bind their stuff to, pretty
much all other forms of colonpairs are not available for use in parameters.
This means that you can't, for example, declare sigilless named parameters
and must instead explicitly use the is raw
trait to get the rawness:
sub meow (\foo, :$bar is raw) {
(foo, $bar) = ($bar, foo)
}
my $foo = 42;
my $bar = 100;
meow $foo, :$bar;
say [$foo, $bar]; # OUTPUT: «[100 42]»
The one other colonpair form available in parameters is the standard form that is used for aliasing multiple named params to the same name and parameter descructuring:
sub meow (:st(:nd(:rd(:$nth))), Positional :list(($, $second, |))) {
say [$nth, $second];
}
meow :3rd, :list<a b c>; # OUTPUT: «[3 b]»
Pro-tip: if you're using the Rakudo compiler you may wish to take it easy with aliasing. Using aliases more than 1 level deep will cause the compiler to switch to the slow-path binder, which, as the name suggests, is about 10x slower.
A trick you can use is to use more than one parameter, each with aliases at most 1 level deep, and then merge them in the body:
sub meow (:st(:$nd is copy), :rd(:$nth)) {
$nd //= $nth;
}
Use of colonpairs in argument lists deserves a separate section due to a rule
that's subtle enough to earn a spot in language's traps section. The rule involves the problem
that a programmer may wish to pass Pair
objects in argument lists as
either a named or a positional argument.
In majority of cases, the colonpairs will be passed as named arguments:
sub args {
say "Positional args are: @_.perl()";
say "Named args are: %_.perl()";
}
args :foo, :50bar, e => 42;
# OUTPUT:
# Positional args are: []
# Named args are: {:bar(50), :e(42), :foo}
To pass a Pair
object as a positional argument, you can do any of the
following:
.self
or .Pair
; weird stuff like using R
meta op on the =>
operator applies as wellfoo => bar
syntaxfoo => bar
syntax, use a key that is not a valid identifierPair
s in a list and slip it in with the |
"operator"Here's that list of options in code form:
my @pairs := :42foo, :70meow;
args :foo.Pair, (:50bar), "baz" => "ber", e R=> 42, 42 => 42, |@pairs;
# OUTPUT:
# Positional args are: [:foo, :bar(50), :baz("ber"),
# 42 => 2.718281828459045e0, 42 => 42, :foo(42), :meow(70)]
# Named args are: {}
Number (3) is especially worth keeping in mind if you're coming from other
languages, like Perl 5, that use the fat arrow (=>
) for key/value separation.
This construct gets passed as a named argument only if the key is unquoted and
only if it's a valid identifier.
Should it happen that you have to use one of these constructs, yet wish
to pass them as named arguments instead of positionals, simply wrap them in
parentheses and use the |
prefix to "slip" them in. For the list of Pair
s
we were already slipping in in previous example, you'll need to coerce it into a Capture
object first, as Pair
s stuffed into a Capture
—unlike a list—end up being named parameters, when the Capture
is slipped into the
argument list:
my @pairs := :42foo, :70meow;
args |(:foo.Pair), |(:50bar), |("baz" => "ber"),
|(e R=> 42), |(42 => 42), |@pairs.Capture;
# OUTPUT:
# Positional args are: []
# Named args are: {"42" => 42, :bar(50),
# :baz("ber"), :foo(42), :meow(70)}
The same slipping trick can be used to provide named arguments conditionally:
sub foo (:$bar = 'the default') { say $bar }
my $bar;
foo |(:bar($_) with $bar); # OUTPUT: «the default»
$bar = 42;
foo |(:bar($_) with $bar); # OUTPUT: «42»
If $bar
is not defined
, the with
statement modifier will return Empty
, which when slipped with |
will end up being empty, allowing the parameter to attain its default value.
Since |(:)
looks like a sideways ninja, I call this technique
"ninja-ing the arg".
=>
FormThe sharp-eyed in the audience might have noticed the e => 42
colonpair
in the previous section used letter e
as a key, yet in reversed form
e R=> 42
, the e
became 2.718281828459045e0
, because the core language
has e
defined as Euler's number.
The reason it remained a plain string e
in the e => 42
form is because
this construct auto-quotes keys that are valid identifiers and so they will
always end up as strings, even if a constant, a sigilless variable, or
a routine with the same name exists:
my \meows = '🐱';
sub ehh { rand }
say %(
meows => 'moo',
ehh => 42,
τ => 'meow',
); # OUTPUT: «{ehh => 42, meows => moo, τ => meow}»
A multitude of ways exist to avoid this autoquoting behaviour, but I'll show you just one that's good enough: slap a pair of parentheses around the key:
my \meows = '🐱';
sub ehh { rand }
say %(
(meows) => 'moo',
(ehh) => 42,
(τ) => 'meow',
);
# OUTPUT: «{0.58437052771857 => 42, 6.283185307179586 => meow,
# 🐱 => moo}»
Simple!
That's pretty much all there is to know about colonpairs. We learned
they can be used to construct Pair
objects, used as adverbs, and used
to specify named arguments and parameters.
We learned about various shortcuts, such as using key only for boolean
True
, sticking the negation operator or an unsigned integer between the
colon and the key to specify boolean False
or an Int
value. We also learned
that parentheses can be omited on colonpair values if there's already a set
of curly, square, or angle brackets around the value and that prepending
a colon to a sigilled variable name will create a colonpair that will use the
name of that variable as the key.
In the second half of the article, we went over available colonpair syntaxes when specifying named paramaters, the pecularities in passing colonpairs as either named or positional arguments, as well as how to avoid auto-quoting of the key by wrapping it in parentheses.
I hope you found this informative.
-Ofun
]]>The bonus deliverable "Perl 6 Numerics" Language documentation page was merged to master. It describes all of the available Perl 6 numerics, their interactions, suitability, and hierarchy.
The bulk of work on constants also has been merged to post-release-2018.06
branch, which will be merged to master
after this month's release. I wrote 200 spec tests, available in S04-declarations/constant-6.d.t
spec file, and about 500 words of documentation to cover this work.
Since my last report, I first continued working on Rationals, focusing on three
pieces of work that currently reside in
car-grant-unreduce
branch
The (1) was successful and I already was able to optimized some
ops due to Rationals being always reduced now: ==
was made 28% faster and ===
was made 52% faster. I also made
creation of Rational
s 19% faster and argless Rational.round
4.7x faster
(used by .Str
and .base
).
The plan for (2) was to try normalization to <1/0>
, <0/0>
, <-1/0>
and
the hope was that alone would fix all math problems. However, after that change some issues still remained.
Also, doing this normalization created a new problem where code like
say 42 / 0
would throw an Exception with message "division of 1 by 0 attempted"
which is quite confusing for users who did not internalize that
/
op with Int
objects is really just a Rat
constructor. The 6.c spec
actually covers this exact scenario and expects the thrown Exception
to
report value 42
for numerator, thus blocking this change.
The first attempt at (3) ended with a dead-end.
Marking ZDRs with a role created an extra dispatch ambiguity with some
operators like cmp
. We already had to disambiguate that op
with is default
marker to disambiguate between Rational
and Real
candidates, so now we'd need an is default of defaults
trait :). I gave up
on this for now, but will likely revisit and try again.
As you can see, the Rational
s work was a mixed bag, so to experiment with the
problem space a bit I decided to implement my own rationals outside of core
from scratch. The work is available in zoffixznet/perl6-Rashnl
repo, which might become
an ecosystem module if it offers significantly better rationals.
I doubt the entirety of Rashnl
could be made core, as my current approach
does not involve separate roles at all and just has a single class with a flag
for fattiness that marks what in core is a FatRat
type. The primary purpose
of that work is to experiment with code and learn some lessons that could
be applicable for core Rational
s and achieve the goals of this Grant.
Due to that detour for the Rational
s work and more time to think required, I
switched to the work on constants for the time being…
The bulk of the work on constants is now completed and has been merged to
post-release-2018.06
branch, which will be merged to master
after this
month's release.
I wrote 200 spec tests, available in S04-declarations/constant-6.d.t
spec file, about 500 words of documentation, and 8 commits of the implementation.
Except for native types, the type constraints are now enforced on constants.
The auto-coercive behaviour for %-
sigilled constants was blocked by
one test in 6.c specification and so that behavior has been added to 6.d
language and currently requires the use of use v6.d.PREVIEW
pragma to enable
(6.c behavior is to simply throw without any attempts to coerce, making
constant %foo = :42foo, :70bar
fail, because it's a List
).
One of the remaining things for constants is improving error reporting for unsupported constructs. Most likely I will implement support for coercers—even though they're currently not available on variables, there should be no problem with executing them during constant creation.
The other remaining item is natively-typed constants. Currently, my int const foo = 42
actually does not create a natively-typed constant at all. I hope the knowledge I'll gain while implementing the Grant's bonus work for support of native-typed unsigned attributes will help me in implementing the natively-typed constants as well.
As has been discussed with and approved by my grant manager, I plan to now take a month off working on this grant, so there will be no report in mid-July, and the next report will be in mid-August. I plan to take this time to work on resolving Rakudo's outstanding spectest issues on Windows and possibly resolving some of the open Issues with our community websites.
After that period, I will resume working on the grant, finishing the remaining work on constants, and then going back to Rationals, and finally finishing the bonus work with the natively-typed entities.
]]>If you follow the updates on KickStarter, you may know the Learning Perl 6 book is nearing completion, with the author planning to submit final manuscript to O'Reilly on June 18th.
What this means is the July's Rakudo Star release will possibly be the release the first crop of readers of that book will be using (the next release after that is in October). I've seen several people say they're waiting for this book to get published before they give Perl 6 a try. Coupled with the marketing the author and O'Reilly will be doing for the book, I expect to see an influx of new users.
For that reason, I'm making a call to action, for everyone to polish the experience of the first steps those users will make in Perl 6.
There are several things you can help with, depending on your skillset. And before anyone protests, don't worry, there's one thing everyone is able to do…
The easiest thing you can do is grab a clean box and try to install Perl 6 to it. This is especially useful if you've never done it before and have no idea what you're doing, as it'll be very easy for you to see things that need to be improved.
Are you having trouble finding or choosing what to install? Getting installation errors? Having trouble finding support channels? Report it!
Unless you can think of a better place, you can always report these things in our User Experience repo by filing a new Issue.
This, again, is the area where the less experience with Perl 6 you have, the better. Is there something you find difficult to use or hard to find? Let us know.
Code editors, books, documentation, modules, tutorials, excercises, contests, language news, support channels. If you were looking for any of those things and had a hard time finding them, the process will likely need to be addressed.
This is the area where I hope we'll make a lot of progress before the next Rakudo Star release (it'll be in July, based on Rakudo compiler release scheduled for July 21st). Few, if any of the core devs use Windows as their development environment, so the state of Rakudo on Windows is slightly lagging behind.
While 6.d-proposals roast stresstest
is clean on Linux and MacOS, on Windows,
there's a bunch of test failures. Several of them are likely problematic tests themselves (e.g. those that shell out and expect
cmd.exe
to handle Unicode out of the box). When I last looked at the failing tests, some of them were failing due to how
&run
escapes arguments; since perl6
is launched with a batch file on
windows, using $*EXECUTABLE
with &run
would require using cmd.exe
-style
escapes of command line arguments, which &run
doesn't use. There's some discussion for this issue on R#1325, RT#132258, and self-rejected RFC R#1306.
If you'd like to look into these problems, you can install Rakudo from source on Windows and then run gmake stresstest
(or whatever make
equivalent you have) to clone all the spectests into t/spec
directory and run them, so you'll be able to see what's failing. You can run individual tests with t/fudgeandrun t/spec/42-foobar/the-test-file.t
There's also a second item of lesser importance: Rakudo Star build on 32-bit Windows. The latest build we have for that system is 2016.01, which is quite outdated. On occasion people do ask for 32-bit builds and currently we can only suggests to build from source.
It'd be nice to have a more recent build created. I'm unfamiliar with what's
involved. If you're interested in helping. Join our IRC chat and try to speak to stmuk
or FROGGS
Help us resolve open Issues. In the context of this call to action, the most pertinent repos would likely be User Experience, Perl6.org website, Modules.Perl6.org website, as well as Docs, Rakudo Star, Rakudo itself, and Roast Test Suite.
For core hacking resources, there are some tutorials with "Core Hacking" in their titles on Rakudo.Party website and the NQP/Rakudo Internals Course and 6guts blog. I also like to use Z-Script rakudo dev helper script.
The LP6 book is about to hit the shelves and will likely bring a crop of new Perl 6 users. We can improve the perception of the language by polishing the experience of those users. Let's see if there are any problems with obtaining the compiler or any resources a begginer would need to get started with the language.
There are also some issues on Windows that need to be addressed, such as failing stresstests and 32-bit Rakudo Star builds.
If you can give a hand with any of that, it'd be greatly appreciated. File a new Issue in our User Experience repo or just chat with us on IRC.
-Ofun
]]>