Re: Announce: Rakudo Star Release 2017.07
TL;DR Imo, one of Perl 6's notable strengths is its approach to its specification. Imo companies will love it. I can see it becoming a primary tool for driving P6 forward in just the right way. Steve has already answered with the short version of some of what I say below, and I agree with what you (Darren) said in your reply to him. So perhaps this is more for ToddAndMargo or other readers. >From the start in 2000, Larry intended that the P6 project would distinguish between various distinct notions of "specification": * An evolving set of English documents that would be used to guide compiler developers attempting to write a compiler that implements that "specification". For the last few years P6 project leaders have been calling these "Design Documents". The latest/last versions of these are stored at design.perl6.org. They are now largely an historical footnote -- calling these or any other English language documents a "specification" was explicitly deprecated some years ago. * An evolving set of English documents that would be used to guide end users attempting to understand or write P6 code. Aka end user documentation. The latest version of this is stored at doc.perl6.org. Contributors can draw insight from the design documents (as per previous bullet point) but are supposed to focus on the only remaining specification (as per the next bullet point). * An evolving Executable specification that emerges from that effort. A compiler **must** match **100%** of this executable specification if the compiler is to be officially allowed to claim it implements that specification. This is what the 6.c specification is and what the 6.d specification will be. * The 6.c specification is stored at https://github.com/perl6/roast/tree/6.c (Maybe we should change the description from "Perl 6 test suite" to "Perl 6 language specification".) There's also a 6.c errata at https://github.com/perl6/roast/tree/6.c-errata which, aiui, is what the monthly Rakudo releases target. So, anything you read in English, like "doesn't yet implement macros" is... written in English and is not part of a Perl 6 language specification, per contemporary P6 usage of the word "specification". > So I think it is reasonable for Rakudo to actually implement ALL of 6.c > before too long, that it would catch up, and otherwise the intent is that > Rakudo would be leading on things that eventually become 6.d etc later. Aiui Rakudo's HEAD implemented all of 6.c (on at least one platform) as of December 25th 2015 and each subsequent monthly release has as well. (Well, actually, all of 6.c.errata.) In principle this is an excellent foundation for manageable (in tech and business senses), systematic, community driven, compiler dev mediated, language stability, backwards compatibility, and evolution. If someone (or some company) wants to drive the language forward, then they work with the community to propose changes to the test suite for 6.d or some later 6.* version. These changes test that the particular features they want are working. Community members can do things like attaching a time-limited incentive for compiler devs to alter the compiler to pass some particular set of new tests. Indeed, I imagine it would be fairly easy to set up a flow of direct micro-funding of whatever a given community participant considers more important to them. If it's backwards compatibility, then write tests that ensure that backwards compatibility if they haven't already been written and/or add incentives to currently failing/skipped tests. A similar approach applies for those wanting more test coverage of existing features, or new features. -- raiph On Tue, Jul 25, 2017 at 11:23 AM, Darren Duncan wrote: > There's a key difference however. > > While programming languages continue to evolve, the expectation is that a > production-complete Rakudo would always be a functional superset (or equal > to) the Perl 6 language specification which is current at the time. > > So I think it is reasonable for Rakudo to actually implement ALL of 6.c > before too long, that it would catch up, and otherwise the intent is that > Rakudo would be leading on things that eventually become 6.d etc later. > > The original question would be more accurately phrased, "Any idea when > Rakudo will release implementing the full Perl 6.c?" > > -- Darren Duncan > > On 2017-07-25 1:02 AM, Elizabeth Mattijsen wrote: >> >> If that is the question, the answer is: the junction of “never" and “now". >> Which would also be the answer for Pumpking Perl 5, or any other programming >> language like ever. Because as long as people are using it, a programming >> language will evolve. Much like any human endeavour I would say. >> >>> On 25 Jul 2017, at 09:42, Andrew Kirkpatrick wrote: >>> >>> I assume the meaning is, roughly when is the implementation expected >>> to cover the entire spec? >>> >>> Answering this is probably an exercise in futility, because its up to >>> the community
Re: chaining substitutions?
You want to do two things: 1. match/replace something 2. match/replace something else To do this in one command you need: * `:g` to tell P6 to keep going after the first match * `||` to tell P6 to match what's on the left first, or if that fails, what's on the right Which yields: my $x="State : abc "; $x ~~ s:g/.*?" : "||" ".*//; say "<$x>"; # On Sat, Sep 23, 2017 at 1:29 AM, ToddAndMargo wrote: > Hi All, > > Question. Can I chain these two substitutions together? > > $ perl6 -e 'my $x="State : abc "; $x ~~ s/.*?" : "//; $x ~~ s/" > ".*//; say "<$x>";' > > > > Many thanks, > -T -- raiph
Re: Naming debate- what's the location for it?
Another 2 or 3 pennies^1 worth of strawman proposing / bikeshedding / flight of marketing fancy about naming etc: Perl's Rapture === Imagine we officially embarked on a year+ long communal process in which we (TPF and Perl community) sort out branding and marketing of Perlish languages. A key goal is to have everything as clear as we can manage before Python 2.x official EOL. We not only make it clear how P5 and P6 are different and how they are related but also how they sit in contrast to Python, C/C++, Java, JS and other langs trying to evolve. I think "Perl's Rapture" would be a fun and helpful name for this process. I'm an atheist, or nearly so, but I can't think of something that beats the several fun and interesting elements/parallels I see in the Wikipedia intro in its Rapture page.^2 Perl Raptor = This is my proposal for Perl 5.30 and beyond. It's an existing semi-official alternate name for P5, with a logo hosted at TPF's website.^3 The 'Perl' could generally / increasingly be dropped from propaganda, calling the language just Raptor instead, when that's helpful for reinforcing that it's officially for refering to 5.30 and beyond. I'm thinking there would be a switch from use of the Velociraptor to a raptor bird logo, with a new logo competition, emphasizing smallness, evolutionary fitness, speed etc, but perhaps I'm now weighing in with 3p instead of 2p and that might be a tad too rich. (Perl) Rakudo === If jnthn and pmichaud and larry can warm to this idea, then: This is my proposal for 6e+ (My sense is we'd be better off letting P6 mature for another couple years, avoid unduly undercutting the wave of books with Perl 6 in their title, and wait till after we get a round of Perl Raptor branding impact / marketing, and instead hold the noisy push till 6e around the time Python folk EOL Python 2.x.) The 'Perl' could be dropped from Rakudo specific propaganda, calling the language just Rakudo instead, to reinforce that it refers to 6e and beyond. But the Perl could be retained in any material covering both Raptor and Rakudo as a reunified tech / community. - ^1 I've just arrived back in Britain after 25 years in the US. ^2 Excerpts from https://en.wikipedia.org/wiki/Rapture intro: The Rapture is an eschatological term used by certain Christians ... ... meaning to snatch away or seize [from what?] ... used by certain believers ... viewing it as preceding the Second Coming and followed by a thousand year millennial kingdom [cf 100 year language] ... there are differing viewpoints about the exact timing of the purported event [at official Python 2.x EOL?] ... There are differing views ... whether it will occur in one event or two [Raptor relaunch of P5... Rakudo relaunch of P6...] ... the term "rapture" is derived from the text of the Latin ... —"we will be caught up" [It's going to be fascinating to see what happens in 2020s re Python vs Perl in particular and Hindley Milner static typing vs nominal static/dynamic typing] ^3 http://news.perlfoundation.org/2012/12/the-first-twenty-five-years.html love to all, raiph
Re: Problem using a module containing a grammar
On Mon, Mar 25, 2013 at 11:01 AM, wrote:
> I have created a file called SalesReport.mp6, which contains a grammar
>
> module SalesReport;
> grammar SalesExportGram is export {
Aiui you can now use this module to introduce SalesReport as
a module name and SalesExportGram as a grammar name.
> which I would like to use in the following PERL 6 script:
>
> use SalesReport;
> my $parsed = SalesReportGram.parsefile('sales_report.txt');
As Brandon noted, SalesReportGram is misspelled in this case.
Aiui SalesExportGram ought to work.
> If I give the module (SalesReport.pm6) and the grammar
> declared in it (grammar SalesReport) the same name, I get
> "no such method 'parsefile' for invocant of type 'SalesReport'":
>
> my $parsed = SalesReport.parsefile('sales_report.txt');
Is SalesReport resolving to the module (which does not have
a method 'parsefile')? To see if this is so, try:
say SalesReport.HOW # how is SalesReport handled?
What version of Perl 6 are you using? If I correctly understand
what I just checked, SalesReport.parsefile() should work.
> Any suggestions?
The best place to get answers to these sorts of questions is
the freenode IRC channel #perl6. Feel free to email me if you
would like help getting going with IRC.
If you really want/need to use a mailing list, consider posting
to the perl6-users list. This perl6-language list is intended for
posts related to language design. (Which is why just about
the only traffic is the slow trickle of updates to the language
specification, which is relatively stable, and a very occasional
burst of discussion about some topic. It may get noisier in the
second half of this year when concurrency starts to get a work
through, but I think most of that will be on #perl6 too.)
Hth,
--
raiph
Re: Licensing: Perl 6 specification and test suite
Perhaps these help? http://pugs.blogs.com/pugs/2005/02/day_28_609.html https://www.google.com/#q=site:http%3A%2F%2Fpugs.blogs.com%2F+licensing -- raiph On Tue, Nov 5, 2013 at 9:36 AM, Moritz Lenz wrote: > Hi, > > > On 11/05/2013 03:16 PM, Jan Ingvoldstad wrote: > >> On Tue, Nov 5, 2013 at 3:09 PM, Kalinni Gorzkis >> mailto:musicdenotat...@gmail.com>> wrote: >> >> Can I distribute and modify the Perl 6 specification documents and >> test suite under which conditions? If not, I propose that they >> should be distributed under the Artistic License 2.0. >> >> >> That is an excellent question. >> >> I've checked the git sources, and from what I can see, the examples >> repository is under AL 2.0, as is STD.pm, but the synopses are not. >> >> I'm unsure as to whether this is an artifact of how things got added to >> the git repository or not, perhaps someone else can clarify. >> > > historically the test suite comes from the 'Pugs' SVN repository, which I > later migrated to git (when the SVN server failed, and nobody wanted to > maintain it), and split it up into multiple repositorys. At that time, I > didn't consider license questions, just getting the technical details > worked out. > > The remainder of the Pugs SVN, which hasn't been split out into different > repositories, now lives on github as perl6/mu, and it doesn't seem to have > a catch-all license. > > Somehow I have always worked under the assumption that it is under the > Artistic License 2, just as Rakudo and NQP, and community concensus seem to > agree with me. Therefor I've added an AL2 LICENSE file to the perl6/roast > repository, and I hope that any former or current contributor that > disagrees with the choice of license speaks up soon. > > I have no idea if the AL2 is well suited for sets of documents, as the > specification is. I'll leave that decision to Larry. > > Cheers, > Moritz > -- raiph
Re: question - languages with set/foo as only base data type
On Sun, Nov 17, 2013 at 5:43 PM, Andrew Suffield wrote: > While mathematics as a field has mostly settled on set theory as its > basis, type theory is equally expressive and is usually preferred in language > design. Aiui there is now optimism in some circles that the set theory foundation will be replaced by a "homotopical interpretation of type theory". I have about zero understanding of what this stuff is or if it will have any impact on programming language type systems, but thought I'd speak up. :) -- raiph
Re: [perl6/specs] 89cc32: Spec Bag.kxxv
Hi Damian, The .kxxv method name is a placeholder. The brief discussion that motivated introducing it is at: http://irclog.perlgeek.de/perl6/2014-04-13#i_8582049 Larry has chimed in at: http://irclog.perlgeek.de/perl6/2014-04-14#i_8582684 --- Another discussion that's unfolding right now and could do with your attention imo is: https://github.com/perl6/specs/commit/9213b1382078fee890ab9d74223f3c7e95942837 --- All of the above illustrates an issue that we ought to address, namely where we best discuss this stuff to make the best use of your time: 1. For the last few years almost all discussion is entirely on #perl6. There's a real time log of this #perl6 discussion (as per the irclog links above). (There's also a representative subset of lines I hand select after the fact, often days later, at eg http://irclog.perlgeek.de/perl6/2014-04-13/summary ) Sometimes there's discussion on #perl6 that involves Larry, followed by commits that generally stick. Or there's discussion without Larry followed by commits which are reverted if he doesn't like it. Or there's discussion followed by a message asking for Larry's input. This is done either by just saying so in the log or, more reliably, by leaving a message with an IRC bot. He will see the message by A) reading it in the log and/or B) receiving a message from the bot the next time he says something on #perl6. Or there's discussion that leads to nothing being decided (but which can be read later via the logs). Larry is on #perl6 for at least a while most days including weekends. Also, he catches up on what has been said by reading the entire backlog each time he returns. (Almost no regulars use the "summary" I create; for one thing it's often hours or days behind.) The above arrangement works for us and $Larry. But I'm thinking we might want to go back to @Larry with both you and him and figure out how we make that work for you. 2. Sometimes a discussion arises on github in response to a commit (eg the discussion that I said above could do with your attention). Anyone can follow whatever P6 repos they want. They'll then get emails alerting them to such discussions with a link back to github comments. We could add you to the github/perl6 org, and maybe others. 3. And then there's these mailing lists. Almost no discussion occurs on these lists these days. That said, we do respond if someone posts. It's great to see you back. Did you see that lizmat has taken a stab at implementing 'is cached' -- because she saw that that's the one unimplemented thing in some code you recently published? How confident are you that your all-in-one CS teaching platform concept will be taken up by some educational institutions? What timeframe are you thinking is involved here? Are you thinking P6 is already ready for it? I don't think we're there yet but it seems like the perfect initial goal for P6-as-a-product. -- raiph On Mon, Apr 14, 2014 at 1:03 AM, Damian Conway wrote: > > Spec Bag.kxxv > > It's a clever name...but maybe too clever? > > I find it unfortunate that a method that only returns keys has a 'v' > in its name. > Up to now, we've had a more predictable pattern to naming these accessors. > > How about one of: > > .weighted-keys > .distribution > > instead??? > > And what is the use-case for this? > I can see that I might want: > > $bag.kxxv.pick; > > but: > > $bag.pick > > already does that. > > I guess you might want to separate out the steps for some reason: > > my $selection = median_value_from( $bag.kxxv ); > > but that would be far more readable/maintainable as: > > my $selection = median_value_from( $bag.distribution ); > > > Damian > -- raiph
Re: Rukudo-Star => Rakudo-lite?
> Rakudo Zengi would be the most (in)appropriate, I think. Why do I get the sense that some in the community are suffering siege mentality? ;) I had thought of things like Zen, Zero, Catalyst, etc. But I love * | Star | Whatever. I love: o The word Star, regardless of its connection with Perl 6. o Insider reference to a cool feature of Perl 6. o Rakudo* as an alternate that invites footnote-fu. o Evoking "whatever works" instead of all of Perl 6.0.0. o Evoking "whatever" to invite ongoing definition of what it is. This latter point is the most exciting for me. "What is Rakudo Star? Well, it's..." I would love to see this meme encouraged, the notion that we all get to continuously (re)define just what Rakudo Star is. -- love, raiph
Re: Embedded comments: two proposed solutions to the comment-whole-lines problem
> for the latest spec changes regarding this item, see > http://perlcabal.org/svn/pugs/revision/?rev=27959. > > is everyone equally miserable now? ;) > ~jerry Ha! :) I do indeed feel underwhelmed. I'll surely get over it but I may as well post why, even though Larry's presumably trying to stop the discussion. Sorry Larry. First, I had liked some of the ideas that had been posted in this thread. Quite a lot more than Larry's pick. Of course, I may well be missing complications he can see. Second, I had been mulling backtick, but was thinking on more radical lines than the one Larry's gone for. Again, perhaps he's got more up his sleeve that builds on what he's just committed. For a quick backgrounder, Larry had talked of reserving backtick for use as a user defined operator [1], Mark had suggested its use as a (tightly bound) comment [2], and James et al had suggested using it to declare units [3]. I've long been in Mark's camp about a lightweight and attractive docstring syntax being likely to be helpful for encouraging habits that would likely contribute to improved long term maintainability of code with comments, and was mulling that. -- love, raiph [1] http://markmail.org/message/zvn2hul6irggtrde [2] http://groups.google.com/group/perl.perl6.language/msg/7d10c6bc5d66288e?hl=en [3] http://www.mail-archive.com/perl6-langu...@perl.org/msg20819.html -- love, raiph
Re: comments as preserved meta-data (was Re: Embedded comments ...)
On Thu, Aug 13, 2009 at 1:00 AM, Darren Duncan wrote: > Timothy, you raise a good point... > [discussion] > I think this can be made to work without much fuss I'm curious about these sorts of conversations, and the way the community works in relation to them. I'm also curious about this specific conversation, and the ability (or otherwise) to get a facsimile of what we want by using existing P6 specc'd features, especially morphing the grammar, and macros. First, about this conversation and the way the community works... We just had a bunch of threads touching on this stuff. Larry++ then made a change to the spec. Notably, @/Larry didn't post within the discussions I read and made the spec change while discussions were still going strong, with ingenious, fresh, thinking. (That suggests to me that he/they were trying to shut down debate, presumably due to viewing it as bike shedding, at a time when such could be considered ever more dangerous, perception- and productivity- wise. Leadership in an anarchist context is a tough role!) Despite @/Larry's move, you have continued, and I appreciate that, and hope @Larry are still paying some attention. Second, I'm hoping that @Larry are confident we'll get more or less what we want in the end, due to POD power and/or grammar morphing and/or macros and/or some other features we haven't thought about. I'm hoping that, rather than that what's happening is that @Larry are running out of time and patience (although that would be quite understandable!). There have been many of these comments discussions over the years. In particular, a notable multi year long exchange, best represented by Mark Overmeer and Damian Conway, about how best to weave documentation and code. Indeed, this issue goes way back and way deep; I recall Ward Cunningham's promotion of 'literate programming' in the mid 90s, in which, iirc, he talked of Donald Knuth's promotion in the 70s of the idea of code and comments being woven extremely closely together such that neither is dominant, and one can actually turn things inside out and have code embedded in commentary rather than the other way around. A radical paradigm indeed! Anyhoo, I'd love to see a session of brainstorming, with nitty gritty detail, about possible ways to get what you guys and Mark and I and perhaps others think we would like to see in the way of super tightly woven together comments and code, where said brainstorming initially works within the creative constraint of leveraging the P6 spec as is, plus reasonable extrapolation of unspecced bits. Think grammar morphing, aspects of macros, the existing unfinished POD6 spec, and any other relevant existing bits I'm forgetting. Did that make sense? Anyone interested? ;) -- love, raiph
Re: comments as preserved meta-data (was Re: Embedded comments ...)
> Excellent idea. But may I suggest you perhaps might like to hold off > that discussion until next week? > > @Larry had some very fruitful discussions about the long-overdue Pod > spec during YAPC::EU last week and, as a result, I plan to (finally!!!) > release a new version of S26 this week-end. I very much hope that this > new revision will satisfy The Overmeer Desiderata [1] too. > > Damian > > > [1] Sounds like a Robert Ludlum novel, eh? With this whiny man exchange ultimately having bourne supreme fruit, the apocalypse watch for the post damian weekend begins... -- love, raiph
Re: S26 - The Next Generation
On Sun, Aug 16, 2009 at 3:26 PM, Damian Conway wrote: > It's Sunday evening and, as promised, here's the new draft of S26. Thanks! After an initial read thru the summary and spec my overall reaction to the new pod is "whirled peas!". :) > * Hence it must always parsed using full Perl 6 grammar: perl6 -doc Couldn't the pod processing be encapsulated, perhaps in PGE/NQP, so that it could be reused in a different Parrot language, provided that said language supports declarators and comments, or even just comments (if one downgrades the impact of encountering an "attached" comment that has no declarator to a warning). The latter would fully restore the generic applicability of the POD 5 parser, right? > Hopefully this is something close to the final draft...and something that > every > stakeholder and faction in this long discussion can dislike equally. ;-) While I like the design, and I think it's near enough complete, and I think a reader who knows perl and pod well could understand your current description of that design, I think it could do with a major rewrite to make it less confusing to work out what you really mean as against what's currently written. ;) However, I think it's too early to attempt such a rewrite, or even to comment on specific problems; I plan to wait another couple weeks for some list back-and-forth before commenting further about clarity and/or proposing edits and/or providing patches. The two design questions/comments I have for now are: You don't say whether attached pod allows for configuration info or formatting codes. I'm guessing your intent is no on both accounts. However, presumably the pod parser could process config at the start of attached pod and attach just the text after the config to the .WHY. (Incidentally, .WHY seems a bit too cute; what about .DOC or .POD? Same with .WHEREFORE; my boring suggestion is .CODE.) And formatting codes could presumably be interpreted by renderers that chose to do so. Declarator aliases, as specced, seem to me the weakest part of the design. Declarator aliases seem to only allow one my, one has, etc. in a given context. Having to use non-attached pod syntax to do an attached thing seems very weird. Having to use aliases at all to refer to things that the Perl 6 compiler already has a name for seems like an ugly/heavyweight/suboptimal approach. Anyhoo, thanks for the time spent and great design skills that are so evident in this new spec. :) -- love, raiph
Re: S26 - The Next Generation
> However it seems we have to pay a price: each act of rendering a Pod > file actually means executing the program that's being documented (at > least the BEGIN blocks and other stuff that happens at compile time), > with all the security risks implied. So we'll need a *very* good > sandbox. Is that worth it? >From the spec: However, during parsing and initialization under K<-doc>, the interpreter only executes those C, C, and C blocks (and equivalents, such as C statements and subroutine declarations) that are preceded by the special prefix: C -- love, raiph
Re: S26 - The Next Generation
> Nonetheless, DOC INIT { system "rm -rf ." } (or etc.) would be unfortunate.
Gotcha. Perhaps something like perl6 -DOC is needed to execute DOC
blocks in the file passed on the command line and files it use's,
whereas perl6 -doc only processes DOC blocks in the Setting or its
use'd files, and merely parses but does not execute DOC blocks in the
file passed on the command line and files it use's.
--
love, raiph
Re: S26 - The Next Generation
Damian: > While I'm all in favour of other languages using Pod as a documentation > format, > I think that's unlikely. Pod says that anything of the form: > > =identfiier > > *anywhere* as the first non-whitespace of a line, is considered a Pod > directive. > I can't see many other language designers being willing to limit their > assignment statements that way. Hmm. I was thinking Pod would be parsed by a P6/PGE grammar, one that could be relatively easily edited/extended to suit another context, because, I thought, it could then be made available as a stock --doc subsystem that all PCT based languages get more or less for free. >> Having to use aliases at all to refer >> to things that the Perl 6 compiler already has a name for seems like >> an ugly/heavyweight/suboptimal approach. > > I think aliases are essential. Ok. > We need a way of referring to ambient code within Pod, without the > Podder having to write more code to get it. I was thinking it would be possible to reference (compiler) variables representing eg. the name and sig of a block being parsed, or a block or declaration which has just been parsed, or which is just about to be parsed, and that simply referencing these variables would be ok and would save the need to create explicit named anchors. -- love, raiph
