btw. what reasoning is behind the renaming of '->' to '.' ? 'like the rest of the world uses' sounds just like nonsense... Perl 6 isn't a language like the rest of t he world. And besides java, i don't know any language

hmm, i don't understand the haskell arch, but i remember autrijus mentioned on-the-fly compilation. so are you suggesting, shapr, that pugs create haskell<->c bindings on the fly according to perl6 directives? :)

New builtins will work, but it's not a sustainable approach. More sensible would be something that dumps all the names into a namespace/module/whatever in pugs, and then you can write tiny wrapper yourself.

hs-plugins does very nifty stuff. It's used in an editor that's more dynamic than emacs, because it can edit itself, save state, rebuild itself, and completely reload all the code, and then reload the state. Takes about 0.1 seconds on my dual 1.5GHz.

Because of the recent TODOing and unTODOing, I wondered if it'd be useful to have a file, say t/force_todo, in which all todo-because-of-release tests are listed. Test.pm would read that file and'd add "# TODO" to the output. So, we wouldn't have to TODO/unTODO each test, but only change one central file. Comments?

Example: In a test there's a "ok some_sub(), "test of some_sub"'. Now if this test should be TODOed for release, one would add a line to t/force_todo: "t/some/test.t 17" (say 17 is the test number of that test). Consecutive "make test" runs will treat that "ok ..." as a "todo_ok" then

mugwump - I don't disagree. I am just saying that there is no significant harm in raising the question of clarification to p6l - if it is indeed a point of contention that the concise form should be ammended

of course, then you'd probably want a little more explanation to say that it's only generated up to the point of access (i.e., my @numbers = 1..Inf; doesn't go into an infinite loop if you try to access the 8th element.)

Now that I look at the synopsis, I see why the word "flattened" was used there. The signature of tail is "sub tail(*$head, *@tail)" and those * cause flattening. What the text is trying to show is that tail(1..Inf) won't go into infinite loop because *@tail is "lazily flattened" (or how ever you want to put it)

i know lots of languages. but once i learn it, I go back to Perl. :-) that's not true actually... when i needed a lot of multithreaded stuff several years ago, i wrote a lot of Java. but still probably less than 1% of the coding i've ever done

best practice, i think will be to always put in the * when referring to global vars, and always leave out * when referring to global subs/multimethods, unless you have a good reason for excluding in the first case or including in the second. (the second would be like CORE:: today, i think)

has anyone on p6-l seen my post on "Re: [S29] pick on other things than junctions"? I sent it 100 minutes ago and still haven't seen it posted. But I used the wrong sender email address, so maybe it's being held for moderation. (Which is good--I used my private address by mistake.)