in reply to Re^3: v5, a reimplementation of P5 (was Re^5: A "Perl-7" that I could actually USE right now)
in thread A "Perl-7" that I could actually USE right now
You say I've "taken "use" to mean 'play with', 'experiment', 'try out'". No, not if the context is serious use. Yes, if the context is a project that is at an early stage in its development, even if the end goal is serious use. You say "that isn't "use"." I disagree. 2
v5 being able to work at the block level is simply part of Larry Wall's slang design. 3 Whether it's naive and unnecessary (your view) or brilliant and pragmatic (mine) it's nothing specific to v5 and it's 100% Larry's responsibility, not FROGGS'. It's also basically sunk cost. So I don't think it's productive to talk further about the cost of building P6 or v5 this way.
I understand the point you were trying to make with "another example of misleading information", but please know that I currently entirely reject the notion that any information I have provided thus far is misleading, including my comments about v5, so I find talk of "another" example completely unreasonable.
According to jnthn (Rakudo's architect) Rakudo's gather/take implementation is lazy, non-batching. According to Larry Wall, Niecza's is lazy and probably non-batching. (Sorear, Niecza's original author did not answer my request for clarification; he's now busy working on Rakudo so it's mostly a moot point.)
I couldn't tell, but it seemed like you might be thinking that batching is sort of laziness-lite. The P6 design specifies four levels of laziness: strictly lazy, mostly lazy, mostly eager, strictly eager. Consider a one million line file. Eager processing will read the whole file in one go. So instead you might want to process it lazily. But do you really want to read it strictly lazily, one line at a time, or would you really prefer a mostly lazy mode that reads lines in batches (even though it still delivers it to your consuming code one item at a time)? Sometimes you really will want to read one line at a time, other times batching is best; the P6 design allows you to control which strategy to use.
1 If my memory of the last couple years here at PM serves me right you've kept your P6 comments mostly focused on what you would want from P6; have focused attention on your personal top issues, with CPU bound speed being one I remember (and threads being another from a recent comment); and have otherwise generally held a healthily (primarily technically) skeptical view. I applaud all of this.
2 sundialsvc4's original post is clearly focused on serious use. However, it makes no sense to me that, if there were a project with the goal of achieving what he wants, he would not consider using early (or even late) versions of that project to provide feedback. Such usage would not properly be described as serious use but rather as trying it out or playing with it. The seriousness is about the intended usage once the project has delivered on its goal(s), not how one uses it before it gets there. That said, I did not respond to sundialsvc4.
Ralesk's comment specifically focused on an "experiment". Although I'd say "experiment" is not a suitable tag for v5 (3 month old project is better, though that ignores the years of foundation work it builds on), I thought its goal perfectly fit Ralesk's project description. Ralesk responded that he could not actually use v5. First he talks of an experiment, then suddenly it has to be finished even though no other such finished project exists? I think he may have been kidding, but this leads to another problem.
PerlMonks is supposed to be a resource for the silent majority, newcomers to the Perl world, random googlers, and more. A lot of folk who've heard of P6 inaccurately think it's a dead or struggling project that hasn't shipped software. Comments like Ralesk's reinforce that false viewpoint. If I think a commenter is obviously a troll, I generally leave it alone. If it's an obvious joke, I might reply in kind. If not, I sometimes try to figure out a response to set the record straight.
3 Slangs aren't about mixing P5 and P6. They are about recursing into arbitrary sub-languages at any point. P6 itself consists of a series of slangs for general code, regexen, strings, and so forth. Programmers will remain oblivious of this internal reality when first learning P6, and may choose to always ignore it, but the slang architecture is one of several pieces that give Perl, via P6, the capacity lisp has had since the 1950s for supporting continual, fluid evolution and innovation (in lisp's case, by writing s-expressions, in Perl's by writing Perl).