user-experience
user-experience copied to clipboard
Raku
Talking about Perl 6
Referring to Zoffix's blog post, I think it would be good to split out the concepts & terminology part of "Getting Perl 6" into a section of its own, which comes before. Something like "Talking about Perl 6".
Even though I've downloaded and played with Perl 6, I'm still not sure what all the different bits are and how to talk about them. This page made things a bit clearer. Here's my current mental model, which may or may not be accurate :-)
- When you say Perl 6 you're talking about a language definition. There isn't a single document that defines Perl 6, the official definition is a test suite (called roast). If you have a thing that passes a given version of roast, then you have an implementation of Perl 6.
- Hmm, when "Perl 6.c" was announced, does that mean the version of roast is 6c? I couldn't find a version in that repo (though I didn't look very hard).
- The vision of what Perl 6 will be (or is it more "the direction we're going"?) is captured in the Synopses. Perl 6.c is a subset of what's described there. Is there an official document anywhere which captures what's missing? I remember this list from Jonathan.
- Perl 6 is compiled to bytecode which runs on a VM. There are currently two VMs targetted: MoarVM and JVM, though I think that the JVM can't do everything in Perl 6 that MoarVM can. I assume everyone is using MoarVM right now. Dunno whether JVM is waiting for someone to step up, coming later, or ?
- Rakudo is a compiler for Perl 6. I think it compiles stuff only for MoarVM. Rakudo has it's own version number, based on calendar. Any reason why it doesn't have a 6.c.* based numbering, given I assume that the latest rakudo supports 6c?
- MoarVM has its own lifeline, but its prime customer is Rakudo perl. So I don't know if it makes sense to talking about MoarVM 6.c.*, but that would seem to be at least one way to talk about it.
- Rakudo star is a distribution that comes with everything you need to get started with Perl 6 programming: rakudo the compiler, MoarVM, and some modules. I assume it ships with the 6.c version of roast as well, or maybe not?
Thanks a lot! Seems like indeed there's a lot of clarifying we need to do. I'm going to drop a link to this Issue in #perl6-release (on Freenode), as I think several of these items are actually currently being decided on on how to proceed.
Thanks.
Some quick clarifications, from my perspective:
On Fri, Jan 15, 2016 at 01:30:22AM -0800, Neil Bowers wrote:
- Perl 6 is compiled to bytecode which runs on a VM. There are currently two VMs targetted: MoarVM and JVM, though I think that the JVM can't do everything in Perl 6 that MoarVM can. I assume everyone is using MoarVM right now. Dunno whether JVM is waiting for someone to step up, coming later, or ?
Although Rakudo compiles to bytecode, there's nothing in the language ("Perl 6") that requires compiling to bytecode. Something could be a valid implementation of Perl 6 without requiring the bytecode step.
Rakudo-on-JVM is simply lagging behind Rakudo-on-MoarVM in terms of how much support it has for Perl 6.
- Rakudo is a compiler for Perl 6. I think it compiles stuff only for MoarVM. Rakudo has it's own version number, based on calendar. Any reason why it doesn't have a 6.c.* based numbering, given I assume that the latest rakudo supports 6c?
It doesn't have a 6.c.* based number because compilers have different release cadences than language specifications. Also, a feature will generally appear in an implementation (Rakudo) prior to its inclusion in a language spec (Perl 6), perhaps for a very long time.
Historically, language specification works best when it takes a backward-looking view; that is, a language spec describes what has been implemented and agreed to by users, rather than what ought to be and isn't proven yet.
Pm
Perl 6.c is currently a branch (called "6.c") in the roast repository. However we are discussing making it a directory in that repository for practicality reasons.
We have been de-emphasising the synopsis' importance, e.g. by calling them speculations (as an alternative expansion of "spec") and I think we should continue to do so. Because now that a stable release of the language is out, we don't have to speculate as much. We now start to get more real life feedback. Of course that could just be me not liking to write docs :) I'm not aware of any list of written down differences between the speculations and roast.
The JVM has been set aside a little to focus on making at least one VM ready for christmas. We're now starting to bring it back and ensure that it stays up to date. Of course, we could always use an extra pair of hands (or 10).
Rakudo's and MoarVM's versioning is date based which works well with the monthly releases. Both are released much more often (monthly) than versions of the language specification (once every 15 years it seems ;) While having a compiler version of "6.c.1" might be ok right now, it will be very confusing once there's a "6.c.1" version of the language.
And yes, Rakudo 2015.12 and the upcoming 2016.01 support Perl 6.c
Historically, language specification works best when it takes a backward-looking view; that is, a language spec describes what has been implemented and agreed to by users, rather than what ought to be and isn't proven yet.
I think it will really help folks outside of the bubble if parallels are drawn to something nearly everyone knows. It would be great if @pmichaud's and @niner's answers were to be reframed in the context of C89 / C99 / C11 and gcc / llvm / msvc / icc / whathaveyou
I think pmichaud++ already used the great example of HTML and/or CSS. XHTML 2.0 is a dead specification with no implementation in a mainline browser and no uptake whatsoever while HTML 5 standardized what was already implemented and continues to require two implementations for something to be added to the standard. Same for CSS.
@niner what I meant is for someone to put together a definitive X is like gcc, Y is like clang, Z is like C89, and we expect a C99 thing in the next N months/years or so. I myself (being close to the bubble) do not have answers to what X Y and Z are exactly today.
Could we optimize all this for the default case?
In the minds of new perl6ers, Rakudo/Moar is the default (and only viable) distribution of Perl6, and is synonymous with the language itself. We should make it super easy to get started with Perl6, rather than trying to explain to the newcomer the differences between a language, a spec, a compiler, a distribution, a ... before they even get to write a hello-world.
Nobody needs to know all that when they're just curious about Perl6 and wanting to play around with it.
Nobody needs to know all that when they're just curious about Perl6 and wanting to play around with it.
That'll be the "default" option for the GetPerl6.com website, where the goal is to get people to "install Perl 6" without having to learn all the names of all the bits and pieces.
However, those who do want to learn all the names of all the bits and pieces and how those pieces fit in together should have some easy-to-use guide/diagram that explains those things.
Will users be directed from perl6.org to getperl6.com?
If not then how will they find it?
Will we spend the next ten years explaining "oh, no, you're supposed to use this link instead"?
Why do we need another domain to host a download link?
'cause it's short and looks cool and trendy!!
Will users be directed from perl6.org to getperl6.com?
The Firefox's model is a good example of what I'm aiming for, where GetFirefox.com is really just a redirect to the download page on mozilla.org. That page is nice and simple and has just one purpose. It's also linked to from the main Mozilla's page, which has more links and info, just like the current perl6.org page and its download link.
@ribasushi maybe a table like the following would be useful to folks trying to get an overview of how the pieces fit:
| Language | Compiler | Platform |
|---|---|---|
| C | gcc |
x86 |
| Java | javac |
JVM |
| Clojure | Clojure | JVM |
| Perl 6.c | Rakudo | x86 |
Not sure how correct those are, or how other langs like Rust, Julia, Go, etc. would fit.
Maybe have a 2nd table to illustrate further:
| Language | How to Run | Shebang |
|---|---|---|
| C | $ foo |
n/a |
| Java | $ java -jar foo.jar |
n/a |
| Perl 6 | $ foo.pl6 |
#/usr/bin/env perl6 |
| Python | $ foo.py |
#/usr/bin/env python3 |
Per isn't commercial so it shouldn't be .com. It's also more to type. I don't see advantages here, sorry!
I don't see advantages here, sorry!
No one's stopping you from typing ~~perl6.org/download/~~ oh, it's actually perl6.org/downloads/
Responding to @pmichaud's comments on version numbers. When most people (in particular I mean the set of people who aren't currently working on or using Perl 6) say "perl 6", they effectively mean rakudo perl 6, since that's all there is.
When Perl 6.c was released at Christmas, I took that to mean that the release of rakudo at that time implemented the the version of roast at that time. Is that not right?
Perl 5 comes with a testsuite, and a public release isn't made without the expectation that the all of the testsuite will pass. Is that not the case for rakudo perl and roast? So at some times rakudo might be behind roast in terms of compliance, and at other times ahead, so that sometimes a release of rakudo might not pass the current release of roast?
@abraxxa click on the little pencil icon in the top right hand corner to edit a comment of yours.
In theory rakudo could be far behind roast at a given point in time. It cannot be ahead in terms of compliance per se, but it can and does contain features that make it later into the language specification (i.e. roast). Just like modern web browsers or C compilers contain experimental features that may or may not be standardized and may well lag in support for other features.
In practice, there won't be much difference, at least in the foreseeable future because "passing all spec tests" is a criterium for a release to be cut. Note that this will mean that it has to pass all spec tests, even the ones testing earlier language versions. So as long as rakudo is the primary vehicle for developing Perl 6, we will see a somewhat tight coupling.