Talk:Raku (programming language)/Archive 1

This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

But can anyone answer the greatest question of them all - WHEN?--Amir E. Aharoni 16:10, 24 October 2005 (UTC)

When it's ready. There is deliberately no release date given. A beautiful mind 13:23, 10 March 2006 (UTC)

deliberately as opposed to ??? "when it's ready" as opposed to sometime afterwards? do we have a vaporware template somewhere? this has been "under construction" for six years now.

Perl 6 is expected to be released on Christmas. The year, however, is unknown. 195.240.42.199 19:04, 23 February 2006 (UTC)

Personally I'd add a Controversy heading at the bottom of the article that indicates, among other things, the discomfort that much of the community feels about the Perl 6 process taking so long and there being no realistic release date in sight (as of mid 2006). To many people this is probably the most important thing about Perl 6. The "Perl" and "Perl 6" communities don't communicate well on this topic, or on very many topics for that matter. Please note that I am not saying this article is a place for "Perl" and "Perl 6" people to bicker in public. However, if a different software or hardware project of great prominence were delayed by years, the delay would certainly receive some notice. Joseph N Hall 01:09, 31 August 2006 (UTC)

Wikipedia is not a message board, which – among other things – means that it's not the right place to air your concerns, wishes, etc. Since there is no delay (just the expectation of some people that a major rewrite of 15 years of history would, of course, happen in a year or two), there's nothing to note in the article other than the dates that were actually involved. We already have a fair amount of information about the timeline. -Harmil

01:44, 31 August 2006 (UTC)

Chained Comparisons

It's so fun to talk with yourself in the talk page :)

Now the real question: I didn't really understand what the example in "Chained Comparisons" paragraphs is supposed to do. Can someone please improve the example or at least explain what the current one does?--Amir E. Aharoni 15:35, 18 January 2006 (UTC)

In C

if (5 <= 10 <= 2) {...

returns 1 because it's equal to

if ((5 <= 10 ? 1 : 0) <= 2) { ...

and not

if (5 <= 10 && 10 <= 2)

as one might think at first.

In Perl 6 and Python the first example is ~equal to the third, not the second. —Ævar Arnfjörð Bjarmason

Actually, I don't think that's what the example is saying. Interestingly, the example given actually works just fine in Perl 5! It's chained relative comparitors that don't work in Perl 5. For example:

   $ perl -le 'print(1 < 2 == 1 < 3)'
   1

   $ perl -le 'print(1 < 2 < 3)'
   syntax error at -e line 1, near "2 <"

As you can see, the difference is the chaining of non-equality operators. -Harmil 21:41, 23 February 2006 (UTC)

Noone's saying that those statements don't compile, we're saying that they work as chained comparisons, a statement like:

$a <= $b == $c <= $d

Is not equivalent in Perl 5 and Perl 6, in Perl 5 it equals:

($a <= $b) == ($c <= $d)

And since in your case the boolean tests returns an integer and both of them will be true you'll end up with:

1 == 1

Which is true (1)

In Perl 5 however the statement is equal to:

$a <= $b && $b == $c && $c <= $d

With the exception that each term is only evaluated once, so that if $b was a function call the function wouldn't be called twice. --Ævar Arnfjörð Bjarmason 19:29, 16 March 2006 (UTC)

Is this one of those fuzzy areas, or can someone clarify this? Do variables make it informal because they could have an infinite number of names? I read formal language, and I'm still not sure understand what's not formal about Perl. Formal grammar is even worse. -Barry- 16:40, 16 March 2006 (UTC)

Lookbehind, for one, is a feature of Perl not part of the formal definition of

Regular expressions#In formal language theory may help. --TreyHarris

20:07, 16 March 2006 (UTC)

Regular expressions cannot have any sort of state by definition, so in the strictest sense no "regular expression" system that even stores a match is a true regular expression. However, when we talk about regular expressions in modern CS we generally allow for anything that doesn't require state in order to match. So, all of these would disqualify Perl's "regular expressions" along with many other modern regex-like sytems:

• \1 type backreferences within a match, e.g. (a|b)c\1
• Zero-length assertions that consume input. So, not \b, but certainly (?=...)
• Anything that looks behind, e.g. (?<=...)

Regular expressions are interesting in CS because they are as complex as a language can get and still allow for a solution to the halting problem. As a nifty side-effect you can "compile" a regular expression into an optimal form. Once you add Perl's goodies, you can no longer do that. Of course, I'm saying all of this as if I actually remember what I learned years ago, so feel free to correct me if I've gotten something backwards. -Harmil 23:58, 16 March 2006 (UTC)

I'm not a student of computer science or math or anything, but I have a feeling that the more accurately you try to explain this, the less certain it will seem that Perl's regexes aren't formal.

You could compile and optimize a regex that uses any of your three examples. You just do it in a manner that wouldn't break it given the way the regex works. I don't know how I'd optimize a look-behind assertion, but I don't know how I'd optimize a regular expressions that you would consider formal either, like /.{5}/. I'd have to know how it's processed in uncompiled form before I could say how to optimize it, then both regexes could probably be optimized.

I don't see how "anything that looks behind" would be seen as making a regex not formal. If the regex has to look back at a part of the term it's trying to match that it already looked at, or in the case of a substitution, if the regex has to know how some previous part of the string changed since the start of the regex, is that significantly different than updating pos, or whatever is done behind the scenes to keep track of the state of the processing? Is it different than simple multiplication, when you vertically align two multi-digit numbers on paper and iterate backwards over each digit of the top number again for each digit of the bottom number? That's not just looking back, but it's actually changing the state of top digits because of the carried numbers.

It's probably possible to create a definition of formal that's consistent with what you're saying, but I'm not sure how I'd word it, and I'd like to see such a definition if one exists. Currently, the best definition that explains why Perl's regexes aren't formal, at least to me, is your list of things that aren't formal, but that reminds me of the often ridiculed Web 2.0 by example list. It's like this, and this, and this, but there's no definition.

I just looked at Trey's link. The first sentence is "Regular expressions consist of constants and operators that denote sets of strings and operations over these sets, respectively." I'll mull that over, but it still seems to me that the ways in which parts of Perl regexes may be considered not constant involve the processing of the regex, as in my multiplication example, and not the string or operations comprising the regex. A string that's in the middle of being processed by a substitution regex and has been partially changed and has to be reviewed again by the regex (I'm assuming that's what you see as a violation of the "Regular expressions consist of constants..." rule) doesn't have to be considered changed. You can think of the pre-final version as you'd think of the top number in my multiplication example that's "changed" by a number being carried over. That doesn't make it a non-constant.

If you set up an interrupt, say at .01 milliseconds into the regex, that changes the string being processed based on some value outside of the regex, that would make the changed string a non-constant, and it would be justified to call it a rule or something other than a regular expression. Currently, saying that regular expressions in Perl 6 aren't regular expressions is like saying "it's not toilet paper, it's bathroom tissue." -Barry- 05:44, 17 March 2006 (UTC)

Barry, what's the article is saying is that Perl "regex" aren't really regular expression though they share some features. Regular expressions are a well formalized concept in CS and you can't redefine it as you wish. The simple facts are that Perl regex don't conform to the formal definition of regular expression in CS, this is evident by the fact that the class of languages that Perl regex can match isn't the regular languages one (which is formally defined as the closure of the set of individual letters and empty words by the union, concatenation and star operators) but rather the recursively enumerable one since Perl is Turing complete and you can include Perl code in a regex (though matching an arbitrary context-sensitive grammar would already be at best messy with the tools we have in Perl 5 and would probably run in one of the bugs of the most complex features of the regex engine that this would involve). Thus the Perl regex can't be formal regular expression... (even though they're defined formally in their own right). -Jedai 00:45, 12 July 2006

Regexes aren't called rules anymore. The following are quotes from #perl6 on Freenode (IRC).

http://colabti.de/irclogger/irclogger_log/perl6?date=2006-04-21,Fri

KingDillyDilly Anyone here check up on Wikipedia's Perl6 article at http://en.wikipedia.org/wiki/Perl6#Rules:_the_new_regexes? Will there be no regular expressions in Perl 6? They'll really be called rules? 21:04

PerlJam KingDillyDilly: well, they were. 21:04

TimToady we just change back to regex, actually rules are now more specialized critters 21:05

http://colabti.de/irclogger/irclogger_log/perl6?date=2006-04-22,Sat

TimToady After spending much time dithering about for a good name for non-backtracking rules, Damian hit upon the idea of just calling those "rules" and resurrecting "regex" to refer to the general regex {...} form. 02:39 -Barry- 04:57, 22 April 2006 (UTC)

No wone ever really responded to this, and while -Barry- isn't editing here any more, I want to respond to help others understand. "regex" is the name of the Perl 6 feature which is analogous to Perl 5 regular expressions. "rules" are the name of the superset of that feature which includes full grammar specification. There's no hard line between the two in Perl 6, but the keywords regex and rule are intended to present a conventional way to divide the two. -Harmil 16:20, 14 October 2006 (UTC)

CyberSkull recently added the {{future software}} template to the article, which renders as:

This article or section contains information about a program that is under development. It is likely to contain information of a speculative nature, and the content may change dramatically as the software release approaches and more information becomes available.

The language of this template doesn't make sense for this article (which seems to be more geared to a closed-source project where secrecy may reign until release). There's no speculation here—everything in the article comes from the design documents. They may be subject to change, but that would be as true of a current piece of software in continual development.

Does this template belong here? --TreyHarris 00:57, 28 March 2006 (UTC)

Since nobody's responded, I'm removing it. --TreyHarris 16:41, 28 March 2006 (UTC)

Damian Conway wrote in 2004 that "The syntax and semantics of Perl 6 is still being finalized and consequently is at any time subject to change." It's in the say documentation. It's a little old though. Has anyone seen a more recent similar warning from a reliable source?

BTW, say sounds sound-related. I'd suggest show, but it's supposed to work with things other than the monitor. Print is bad too; it's like you're using a printer. Output would sound like the opposite of saving to disk. I think a slightly more generic sounding name should be used, like send, and modifiers should make it more specific. Some modifiers would be optional, for clairity, so, for example, you could distinguish whether you intend to send to the monitor or whether stdout is presumably set to something else. Better for debugging. The optional send modifiers could be p or print for printing to a printer, and s or screen for the screen. Required modifiers would be used for send to function as send currently functions, and there should be a modifier that makes send function as write. These are all similar functions that arguably should be combined anyway, and the fact that the current function names don't properly describe the function makes it clear that a change is needed. It would especially help to have what's currently print and write on the same page of the documentation to make people aware of both options. There would be no need to rely on documentation writers to include an appropriate See also section.

Inspired suggestions for tomorrow's Perl. Listen to me, man. -Barry- 18:37, 28 March 2006 (UTC)

I suggest adding a link to my "Critique of where Perl 6 is Heading" essay. While I may have changed my mind about some of the points there, it still raised some concerns that people are having and expressed about Perl 6. There's also this comment by Michael G. Schwern that's worth linking to, as it is considered a good rebuttal of it.

There are similar discussions (pro and against Perl 6) all over the Net on Slashdot.org, etc. but this is the canonical "Perl 6 Critique". I'm not adding it myself due to Wikipedia self-promoting policies. —Preceding unsigned comment added by Shlomif (talk • contribs)

I was going to create a pro and con section for Perl 6, like Perl had, and add your link, so I agree. In fact, I sent you a couple of private IRC messages to see how you felt about me adding your link, but I never got a response. I agree that your critique is the canonical Perl 6 critique because I've searched for others. There are surprising few, even for Perl 5, and I think you should add it. I'm in arbitration and I may be blocked from editing Perl (for an unspecified reason, but it may be due to con links), so it might be more appropriate for you to add the links. It's not strictly against the rules. -Barry- 19:27, 9 July 2006 (UTC)

First off, as User:-Barry- is well aware, the Pro/Con section on Perl was removed for a reason. There's no particular need for Wikipedia to delve into the feelings of language users, and having a list of pros and cons for a language that isn't even finalized yet is beyond pointless.

That said, there are plenty of other valid reasons not to cite Shlomi Fish's article:

• It is horribly out of date
• It's factually flawed on many levels
• It makes very poor logical arguments

To be more specific:

• He asserts, "No one Understands Perl 6", and yet there are many involved in the design process that dispute this. He cites as reasoning the fact that the Exegesis take a long time to write, and yet ignores the fact that most of that time is spent creating useful examples, and pulling together the information presented, rather than "understanding" the material.
• He asserts, "Perl 6 is not Backwards-Compatible with Perl 5" (true in as far as it goes, but misleading). He's then makes a vague assertion that Perl 6 might have some sort of compatibility mode, but with even the most casual research he could have discovered that Perl 5 code will run under Perl 6 cleanly, using the original Perl 5 parser (either as a whole Perl 5 program or as lexically-scoped Perl 5 code... even the new-fangled Perl 6 regexes have a Perl 5 mode).
• Perl 6 is too Complex: This point isn't really worth going into. Either Perl 6 will be easy to use, but provide all of the tools that modern programmers want, or it will fail. Those of us actively working on Perl 6 think the former will happen, but either way, it's just speculation right now.

It's just not a well researched essay, and I've never seen it cited in any other context as a work of substantial merit, so I don't see why Wikipedia would give it that role. -Harmil 04:59, 10 July 2006 (UTC)

The links that the Perl 6 editors didn't want were from authors, teachers, lecturers, and the like, not just the feelings of any old language users. One may not have been, but that one was one of the few critiques of its kind because of how detailed it was and the number of replies, and it wasn't part of Slashdot, which is a well known repository for such critiques, so it wasn't so easy to find. It was a good find and worthy of the article, but the other links, including Shlomi's, were even more clearly good additions.

Shlomi is one of those who's been involved in the design process of Perl 6, and he's the author of the page he and I want to link to. A critique from someone who's helped develop Perl 6 and who has the background Shlomi has should be included, and if you find faults with what's in the critique, find good sources and put those in the article too. Shlomi already found an appropriate rebuttal though.

Even if I had no opinion about the content (if I were an arbitrator, for example), I'd still be on Shlomi's side because of your lies, bad faith, etc., which I partially describe here. And I'm the one who may get banned from editing Perl! With the arbitrators not even judging the content I want to add! What a freaking joke. -Barry- 05:38, 10 July 2006 (UTC)

Please watch the

Steve p

16:43, 10 July 2006 (UTC)

See Perl 6 Myths, Juerd slides for speech on German Perl Workshop, 2006. "Don't believe in myths... . Instead, believe in Perl 6, and the many people who spend lots of time on making it happen." --mj41 10:36, 10 July 2006 (UTC)

I tried quoting brian d foy's slides in Perl. That quote didn't last long. But in your defense, my quotes were anti-Perl and yours are Pro-Perl. I realize that makes a big difference to the editors.

Seems to be a lot of weaseling when Perl 6 proponents discuss backward compatibility. Harmil says it's misleading to say that Perl isn't backward compatible. In Fears, Uncertainties and Doubts about Perl 6, under My Perl knowledge will be useless! it says "...the way you programmed in Perl 5 is still possible in Perl 6. Just the spelling changed a little. Besides that, your Perl 5 knowledge will come in handy the many times that you encounter legacy Perl 5 code." Oh, but Juerd doesn't weasel around. He just flat out lies by saying "No" to "Backward compatibility is broken."

I wouldn't complain about linking to it though. -Barry- 11:44, 10 July 2006 (UTC)

Barry, I don't want to fight, here, it's a worthless essay. If you find a well-informed, well-written essay about how Perl 6 is the worst thing since toast landing butter-side down, then by all means add an external link. If I weren't writing Synopsys 26, I'd probably be writing a rant of my own (I think everyone involved would, as it's such an ambitious project that everyone gets cranky from time to time), but we can't just link to random cruft because we think we need an "opposing view" for a programming language. First off, that's the domain of bad TV news shows. Second, it's not encyclopedic.

As for backward compatibility, it's misleading to say that Perl 6 is not backward compatible in a vacuum. Perl 6 breaks backward compatibility in a very conscious and well-planned way, by throwing out the syntax-level compatibility, and providing language neutrality as an alternative. Your old Perl 5 code will work, and you will be able to write things like:

# Perl 6 regex
rule foo { <bar>* }
# Perl 5 regex
rule bar :p5 { a[bcd](?:ef) }
# Perl 6 loop
for @array -> {
  # Lexically scoped Perl 5 parser invocation
  use Lang :perl5;
  # Perl 5 string manip
  print $_."\n";
}
# Perl 6 I/O
say "Perl 6, at your command";

To simply say, "it's not backward compatible" is misleading because it leads a reader to believe that their old code will cease to work. That's probably only as true as it would be for any major language version update (that is to say, some constructs that were depricated may not be made to work on the Parrot-based Perl 5), but overall, code will just work. For v6.pm (the P6-on-P5 framework) Perl 5 works EXACTLY as it always has becuase the underlying VM is perl. -Harmil 14:23, 10 July 2006 (UTC)

Pages we link to don't have to be encyclopedic. There are surely parts, if not all, of what Shlomi wrote in that critique that are encyclopedic. The bottom line is that if the author wrote on the topic and is qualified, you include it. If there seem to be too many links to stuff like that, then you start pruning. We haven't reached that point, and based on my research, we never will.

Here's an example of what's planned for one function. And read the replies I got to this recent question on the Perl 6 development IRC channel, including "IMO, 90% functions of perl 5 will retained in perl 6....how to do it in perl 6 is more important. functions rename doesn't hurt much. since you can make wrapper your self." I suppose it would be easier for some people to create a wrapper than to learn and re-code in Perl 6, but it sounds definitely non-backward compatible to me. You might as well tell me I can program in any language on Perl 6 if I create a source filter.

You mention just using v6.pm. Just about the only edit of mine that the editors of Perl agreed to put back in the article is about the compilation problems that Windows users may have using some Perl modules. If that's not the case here, it still sounds like you'd have to learn to use a Perl module, which I've also had bad experiences with. But who knows if a module is really all it would take, since everything I find makes it sound more complicated than that. You need to provide references. I'd accept anything authored by someone as qualified as Shlomi. -Barry- 20:29, 10 July 2006 (UTC)

I'm actually not sure I understood much of what you said. You seem to have missed most of what I said about syntactic vs. parser-mode compatibility, though. Please, repeat after me: your Perl 5 code will run. There you go, that's all you need to know. As for the essay in question: there are MANY people (read the page he linked to) whoh have shredded all of the facts in the article. It's a dead story. It's poorly written. It bares no resemblance to reality. Move along. -Harmil 23:19, 10 July 2006 (UTC)

"you'd have to learn to use a Perl module, which I've also had bad experiences with" -- good grief. It's astounding that someone with so little competency in a subject would put so much effort into denigrating it -- that suggests either psychosis or a paid troll, although I can't imagine why anyone would pay to troll Perl 6. -- 71.102.174.155 (talk) 11:25, 30 April 2008 (UTC)

Harmil, you seem to misunderstand

.

This article has ZERO criticism as it stands, making it POV biased. It's extremely unlikely that the criticism of Perl 6 is so extremely rare so as to warrant no inclusion at all. 71.166.153.191 06:03, 13 April 2007 (UTC)

There's nothing POV about absence of a criticism section in an article. Everything can be criticized and yet the vast majority of Wikipedia articles don't have a criticism section. Articles are for describing their subjects, not for providing a forum to those with an axe to grind. -- 71.102.174.155 (talk) 11:25, 30 April 2008 (UTC)

I've updated all of the inline links in this article to new-style <ref>...</ref> tags, and added the corresponding References section. Please, if you add more information to this page that isn't covered in a nearby reference, add a citation. Thanks! -Harmil 15:39, 4 September 2006 (UTC)

Per

, here's my assessment:

1. It is well written.

(a) compelling prose and comprehensible to non-specialist readers: failed

• This is not an encyclopedia item, but rather to be a more technical document about Perl 6. Therefore it is not for a non-specialist reader.
• The prose is not given in a complete story, but rather as fragmented information about the future language. For example, in the implementation section, why does it start with unintroduced pugs?

(b) follows a logical structure, contains a succinct

lead section

summarising the topic, and the text is organised into a system of hierarchical sections: failed

• Again, it is a technical documentation, thus it lacks of introducing the topic, history of Perl 6 development, etc.
• Lead section does not give a context and it is not enough to summarize the topic.

(c) follows the Wikipedia Manual of Style: failed

• According to
  wikibook, or wikihow
  .

(d) necessary technical terms or jargon are briefly explained: failed

• See about
  pugs
  above.
• And other programming-and-compiling related items are not introduced properly. Readers are subject to know a priori about it.

2. It is factually accurate and verifiable.

(a) references to any and all sources used for its material: weak passes

• Almost all sources come from perl development site, but, again, this is related that this article is a how-to documentation.

(b) the

citation of its sources using inline citations

is required: passes

(c)

reliable sources

: failed

• I found one reference to newsgroup. Per
  WP:RS
  , it is not allowed.

(d)

no original research

: passes

3. It is broad in its coverage.

(a) addresses all major aspects of the topic: failed

• Here are something missing to be a good WP article of this subject: history of the development as a background, philosophy, features, and others that is not in-programming perspective. Try read C++ for example as it is GA, or other GA articles about programming languages.

(b) stays focused on the main topic without going into unnecessary details (no non-notable trivia): failed

• Reduce all how-to explanation into minimum.

4. It follows the

policy.

(a) viewpoints are represented fairly and without bias: passes

(b) all significant points of view are fairly presented, but not asserted, particularly where there are or have been conflicting views on the topic: passes

5. It is stable, not the subject of ongoing

: failed

• This is future event and may subject to dramatically changes. It means that all information given in this article is only forecasting.

6. It contains images, where possible, to illustrate the topic.

(a) properly

captions

: no images -> passes

(b) a lack of images (not a requirement): no images -> passes

Conclusion: failed for GA.

My main objection of this article is that it is still a future event. Thus it is not ready to become an encyclopedia item. All facts given are subject to change, thus it cannot be verified. — Indon (reply) — 10:48, 22 September 2006 (UTC)

I hate to be argumentative, here, but this is not a very helpful review. It's not at all coherent in many places (that might just be a matter of the author being a non-native english speaker), and some statements such as, "the prose is not given in a complete story," are difficult to translate into an encyclopedic account of Perl 6. Where the critique isn't too vague to act on, I'll comment below:

in the implementation section, why does it start with unintroduced pugs?

A later comment then says:

See about

pugs

above.

Because pugs is an implementation of Perl 6, as is introduced in the Implementation section in the phrase, "Pugs is an implementation of Perl 6 in the Haskell programming language that will be used for bootstrapping." This really can't be much clearer. This is not technical jargon that's used to explain the topic, it's a specific instance of Perl 6 which is carefully explained in the text.

Again, it is a technical documentation, thus it lacks of introducing the topic, history of Perl 6 development, etc.

Language problems aside, I think the request here is for a history section. Not a bad request at all, I'll follow up.

Lead section does not give a context and it is not enough to summarize the topic.

I'll see what I can do about expanding the lead section, but as no specific suggestions are made, it's almost impossible to be sure how to attack this request.

According to

wikibook, or wikihow

.

Can any specific distinctions be made, here, that would help to distinguish? I'm not sure that I understand in what way the editor above is suggesting that an article on a technical subject should not, itself, contain technical details. Certainly we've tried to keep this far less technical than most of the pages on math or topology (most of which I cannot read at all).

Almost all sources come from perl development site, but, again, this is related that this article is a how-to documentation.

You're confusing two statements, here. Stop harping on the how-to thing (which you've still never explained) and tell us what sorts of other sources you feel are required.

I found one reference to newsgroup. Per

WP:RS

, it is not allowed.

This is simply incorrect, re-read

WP:RS

. Specifically, the section on Usenet says, "For exceptions, see the section on self-published sources." Indeed, we are saying that the community has concerns, and then citing the community via a reliable archive of Usenet postings: Google Groups. Rod Adams is a significant contributor to the language (being the original author of Synopsis 29), and as such his voice is particularly salient in citing the statement in question (and the statement is certainly one that needs citation). If there were a published or peer reviewed source for this comment, then we would include it, but we're talking about a process that takes place almost entirely in electronic venues. Citing the history without citing those sources would be impossible.

Here are something missing to be a good WP article of this subject: history of the development as a background, philosophy, features, and others that is not in-programming perspective. Try read C++ for example as it is GA, or other GA articles about programming languages.

Well, we certainly have features covered. That's most of the article. I see your point on history/background and that's certainly something I'll address. Philosophy is, I think, better addressed in Perl, but I'll try to expand that here a bit.

Reduce all how-to explanation into minimum.

Please explain this. What is "how-to explanation"? We talk about the language features, and we give short examples of each. This is certainly required of an article about a new version of a programming language, no? We're not going to want an article that tells people how to convert their old code or how to debug Perl 6, but a short section on each major new feature doesn't seem to me to constitute a "how-to". Certainly, I'd say this article fails to be a how-to for any aspect of using Perl 6. You pointed to C++, and yet it has quite a few examples as well. C++, however, has an easier job to do. It's not about specific changes in the language. Perl 6 is about a change between version 5 and version 6... it needs to explain those changes. How do you suggest doing so differently?

This is future event and may subject to dramatically changes. It means that all information given in this article is only forecasting.

I think you are misrepresenting this item. The GA rules require that the article be stable with respect to vandalism, revert warring, etc. This article certainly meets those requirements. Your comment here is nothing that can be addreseed by the article itself, and a good article about Perl 6 is a good article about Perl 6. The fact that language specifications may change doesn't impact that, nor make this an unstable article in the sense conveyed by the GA rules.

So, here is what I take away from this: we need more on this history and development, and if possible, we need to trim any examples. I'll see what I can do. -Harmil 18:00, 22 September 2006 (UTC)

I have now addressed these concerns, and also tried to reduce the volume of code examples within the text. I have tried to make sure that no technical term more complex than "variable" is used without clearly defining it or at least providing a link to an article that does so. -Harmil 19:40, 22 September 2006 (UTC)

Thank you for your responsive comments. If you disagree with my reviews, you can always file this article in

and ask specifically that you want a native English speaker to re-review your article. I don't mind at all.

About pugs. Read the article as you a person who don't understand at all about Perl 6. I don't understand Perl 6, so when I read the first statement in the first section, it is confusing. I suggest you change the prose, maybe like Perl 6 is implemented in bla..bla..bla... (you are native English speaker, so you must be better than me). As the statement see pugs above, it is about criterion 1.(d), that necessary technical jargons should be briefly introduced, which is not in the case of pugs above. Please read

once more time really carefully.

About HOW-TO things. Almost half of this article is about HOW-TO make a program with Perl 6. I give C++ as an example as being GA. There you'll read that syntax language definition is given as minimum. Yes, Perl 6 is a major change from previous version, then just list these changes and give a brief explanation. I think you give this major changes with too many examples that confuses a reader.

All right, again, I suggest you to ask for re-review of this article in

. I will not comment at all there.

Cheers. — Indon (reply) — 05:13, 23 September 2006 (UTC)

Hmmm... well, I wish you had given me some feedback on the extensive edits that I made yesterday[1], since I think I addressed most of your concerns (at least the ones that I could match up with specific requests for change). I'm happy to continue to improve the article if you think it would help, but I can't do so without feedback. -Harmil 18:29, 23 September 2006 (UTC)

OK, I found this article difficult to follow and not particularly helpful. My background is that I'm an experienced programmer, with some limited knowledge of Perl 5, but nothing in-depth. So I'm the kind of person who's likely to be interested in this article. Specific comments:

• Slurpy parameters -- could do with more explanation of how they work. I assume they group all additional parameters as an array, but this should be explicit. Also, do they need to be the last parameter? That would make logical sense, but it too isn't explicit.
• "pugs" is mentioned in the history section before it is introduced. Should be clarified at that point what the significance of it is (e.g., is it considered a reference implementation?).
• Object orientation -- should clarify that properties are implemented as getter/setter methods, as this is only implied by the current text
• Introduction of the "yadda-yadda operator" doesn't belong in "syntactic simplification"
• Junctions: it isn't entirely clear what they do. An example would clarify: is the result of $even_digit + 1 the value 1|3|5|7|9?

Overall it's an interesting article, but I'd say it lacks historical and cultural context. What are the primary aims of the development for instance? Does the community feel that those aims are being met? JulesH 11:18, 24 September 2006 (UTC)

• Slurpy paramers - excellent, I'll work on that.
• pugs - hmm... conflicting goals. I put in more about pugs because of the request that we go into more depth about it. There's a bootstrapping problem here. pugs is an implementation, and it's part of the history. I don't want ot just copy the definition of pugs from the implementation section to the history section... I'll see what I can do.
• OO - Can you suggest how "Note that the method "x" is not explicitly declared. This is called an auto-accessor. The "is rw" modifier on the class definition allows all of its public member attributes to be writable by default, using the auto-accessors." would be modified to suit your request? To my eye, it seems to say everything that you suggested it needs to, but obviously you found it ambiguious somehow.
• yadda-yadda operator - I'll take a look.
• Junctions - Yes, you are correct.

Can you explain to me how "At that time, the primary goals were to remove "historical warts" from the language; "easy things should stay easy, hard things should get easier, and impossible things should get hard;" a general cleanup of the internal design and APIs." does not meet your requirements with respect to the aims of the development? As for the feeling of the community, there's no way to source such a statement in a way that would make it anything other than POV, I'm afraid. -Harmil 18:21, 25 September 2006 (UTC)

OO - I'd suggest adding something like "Member attributes are accessed through methods that get and set their values." as a sentence before that; it is implied by what comes after, but it makes it harder to read, and for a technical subject like this I think we need to do everything we can to improve clarity.

I think, basically, I felt that more elaboration on this point is need. Perhaps cite an example of something that was considered a "wart", and somre reason perhaps why the internal design needed cleaning up. JulesH 07:31, 26 September 2006 (UTC)

The new intro section had a few problems,[2] so I've updated it a bit.[3]

First, there was some pretty wild speculation which was simply misleading: "discussion forums for Perl 6 had been posted to regularly through 2004, 2005 up until Febuary 2006." First off, there are no particular discussion forums which are canonical in the Perl 6 development world. The mailing lists and IRC channels used by the authors and other contributors are and have remained active throughout, with a tremendous surge of activity following the primary events in the history of Perl 6 development (each Apocalypse, the release of Parrot, the release of Pugs, and the release of v6.pm).

Second, the hyperbole was a bit thick ("extent and extended", "long essay", "major" used twice, etc.)

However, I liked the general structure. Other than moving the primary citation back up to the 2nd paragraph (from the 4th), I've kept most of that structure from the edit. -Harmil 14:43, 1 October 2006 (UTC)

Well, I've addressed everything that was brougt up, as much as I could, and I think the article is far better for it (thanks to those who left comments!) IMHO this artile is now far more complete and informative than many "good articles" that I've read, so all I can do is wait for a respectful period of time, see if anyone else comments and eventually bring it back through the process. -Harmil 17:45, 1 October 2006 (UTC)

"Perl 6 provides a superset of Perl 5 features with respect to regexes, folding them into a larger framework called 'rules' which provide the capabilities of a parsing expression grammar, as well as acting as a closure with respect to their lexical scope.[15] "

Where in citation [15] does it mention parsing expression grammars and that 'rules' provide this capability?

Is providing the capability of Ford's PEGs in Perl 6 a stated goal of the project, and if so, a

that explicitly names PEGs and their capabilities as being a goal of the 'rules' portion of the Perl 6 project would certainly be nice.

(This also applies to Regular expression, note 2.)

QTJ 19:38, 11 October 2006 (UTC)

I think you may have mis-read the section slightly. I've responded in detail on your talk-page, but the short answer is that "provide the capabilities of" isn't meant to imply that there is a direct one-to-one mapping, but that Perl 6 rules can define grammars that can be defined in a PEG. It could, perhaps be clarified. If you want to take that on, feel free. That being said, S05 and A05 are extensive references on every detail of Perl 6 rules, so I'm not sure that we could cite them and their capabilities any more extensively. -Harmil 01:01, 12 October 2006 (UTC)

Yes, thanks. I suppose my main confusion is now how it is that parsing expression grammar, a fairly recent innovation, came to be part of the lingo in so many parsing topics here on WP, working its way into phrases such as the above. There may be historical reasons for this of which I am entirely unaware. That said, unless and until I can think of a different way to word it that doesn't conflict with the desired message/intent of the statement, I'll take it off my radar. :-) QTJ 18:53, 12 October 2006 (UTC) (PS: For an example of what I mean, in theory, I could write a short article on the "bound predicate languages" and effectively say this: "Perl 6 provides a superset of Perl 5 features with respect to regexes, folding them into a larger framework called 'rules' which provide the capabilities of the bound predicate languages, as well as acting as a closure with respect to their lexical scope." While technically and provably correct, it would stand out to many as a huh? moment. QTJ 18:57, 12 October 2006 (UTC))

OK -- I've refactored the sentence to something I feel is a bit more balanced towards the discussed intent. -- QTJ 07:32, 14 October 2006 (UTC)

PS -- Harmil, if the change is satisfactory, please feel free to simply delete this subtopic on the discussion page, to reduce clutter. If not, feel free to revert and delete this section anyway, since I will have given it my best shot. :-) -- QTJ 08:01, 14 October 2006 (UTC)

It looks great. Typically, discussions are not deleted from talk pages. Rather, older discussions are archived once the page becomes unmanagably long by moving them to a linked sub-page. See my talk page for an example. -Harmil 16:17, 14 October 2006 (UTC)

This edit: [4] added two links to programmers heaven. This was also done on

09:13, 12 October 2006 (UTC)

Quality of Perl Docs - Reference No. 12

Section 3.1 A Specification states on the quality of perl docs that:

While Perl 5's documentation was regarded as excellent, even outside of the Perl community[12] ...

I agree with this point but would suggest that a more appropriate reference could be found. The article cited is, at the time of writing, a very subjective and negatively phrased interpretation of both Perl and Python doc quality. That's in stark contrast to what the Wiki states. Many of the points in reference 12 that are valid at some level, if toned down a lot, lack proper argumentation as well. Xah Lee is also a regular in comp.lang.perl.misc, by the way, so he isn't outside the Perl community, if I might nitpick a little.

PS: my first-ever edit here, so hope formatting and style is OK,

--~Veli-Pekka Tätilä 22:17, 31 October 2006 (UTC)

I agree completely, and I have removed the reference. The author who provided it as a way of strengthening the claim that Perl 5's documentation is regarded as excellent cannot have read more than a few lines. Here are some random quotes:

• Do not tech geek. Both perlers and pythoners do tech geeking. That is, (...) unconscious opportunistic OpenSource propaganda pitchings, (...), insider jokes, author masturbation on language design and comparisons... etc. (with Perl, this may be understandable or irrelevant because it is the Perl community's nature and design to be puerile and sloppy. They revel in it. (...) • Do think clearly before writing. Both Perl and Python docs's writing qualities are extremely bad. What they primarily lack is the ability to think clearly before writing. Perl docs write in the fashion of happy-go-lucky juvenile ramble. They write down their thought process and intuitive understanding of how things are, and meanwhile don't hesitate to throw in childish unix jokes and cheap word play. (...)

Someone who writes things like those has very little interest in providing a balanced view and should under no circumstances be cited on Wikipedia. And even disregarding the poor objectiveness, the link is to a personal home page and thus has little more value than a blog entry (which should never be used as cites).

213.112.27.161 08:45, 11 April 2007 (UTC)

I would agree that the reference is somewhat problematic as it says both, "Perl's documentation has come of age ... Python people really need to learn these merits," and at the same time, "Perl doc's content and writing per se, remains the worst garbage possible." It's all over the map, and doesn't clearly explain how Perl's documentatoin is a beacon that Python should strive for and "the worst garbage possible." If we had a citation that made that distinction any clearer, then I'd leap to it as a replacement. However, the correct solution is not to simply delete this citation. The citation backs up the claim: those outside of the community hold the Perl documentation in high regard. That they also say negative things about it (even very negative things, and even in the same source) is not entirely out of the scope of this article, but inclusion of that point would have to walk a fine line to maintain relevance. I'd suggest keeping the cite and re-wording the text. I'll make a first pass at that, and welcome others to contribute. -Harmil 13:19, 11 April 2007 (UTC)

OK, I won't delete again, I will only ask for the opinion of more people. In my opinion, no citation at all (or a "citation needed" flag) is far better than one of such low quality. It is problematic for several reasons:

1) it is phrased in a very biased and unbalanced way, very far from the general Wikipedia NPOV; it is enough to read a few articles on the author's web site to realize that his writings can make no claim on encyclopaedic objectivity;

2) even if it were more objectively written, it is self-published and hence has undergone absolutely no quality control;

3) even if it weren't self-published, it is a random single source of one single person's opinion and it is bizarre to use it for backing up a claim about "those outside the community". The Perl community counts in millions and the general programming community in tens of millions. It is very likely that you will find among them some who believe that smoking is good for your health (especially if you specifically look for them), but that doesn't make such a claim true. A reference should contain a little bit more than unsubstantiated opinions, otherwise it is better left out.

(For the record, I personally find the Perl documentation excellent, albeit a bit voluminous; but Wikipedia isn't about personal findings.)

213.112.27.161 19:03, 11 April 2007 (UTC)

While there certainly has been claims of perl 6 being vaporware from a number of sources due to the long development time, the article used as reference for this claim on the page was refering to the time before development even started so I removed it. It had nothing to do with what it was used as source for. Debolaz 07:24, 29 November 2006 (UTC)

Any chance of having of Perl 6 released today?.. --Amir E. Aharoni 09:03, 25 December 2006 (UTC)

There is an alpha release as of a long time back —The preceding

unsigned comment was added by 69.110.6.156 (talk

) 06:44, 27 December 2006 (UTC).

This page is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.