t/lib/Hailo/Test/TimToady.trn

nothingmuch: I give up, why?
fine by me, but I'm starting to wish that COMPILING was a hair shorter.
lumi: yes
though it occurs to me we didn't spec it.  Talked about it last night though.
basically we just assume a big q:code {...} around the main compilation unit.
bsb: are you cursing again? :)
bsb++
no, I'm over in the other cabin.
still, gives a way of defanging some injection attacks on eval.
nothingmuch: I don't like use of COMPILING:: within the body
I think {{{...}}} should be the only "foreign" element.
I want to be able to write a macro that can say "COMPILING" in the
user's space
right-o.
It's not ambiguous in the ordinary macro body.
but maybe stress that COMPILING:: in the quasiquote doesn't mean the same as COMPILING:: outside of it.
quasi-unquoting is weird, so it should look weird.
bsb: you mean about eval-proofing?
that's more or less what we said originally in the Apo.
It's not exactly transparent.
But I'm sure people will be willing to cargo cult it.
Yes, it's essentially "undressing" the closure so that $^s binds outward to the "wrong" variable.
hmm...
yes.
On the other hand it might be good hygiene to require :COMPILING&lt;&amp;some_sub&gt;...
At least you don't have to repeat :COMPILING for additional subs...
And it would be consistent with the "no import by default" idea.
Agreed.
I'd say go ahead and crack the whip on those lazy macro writers.
Finished off the bottle of wine, dijya?
Maybe it's {{{ ... {{{{{{{{{ ... }}}}}}}}} }}}.  :-)
Seriously, the parser should handle nesteds easily if it just pretends the inside is in {...}.
And document it in nroff.
or TeX
greetin's
You're certainly welcome.  I'm sure I wasn't the first person to explain it though...
audreyt: the idea that /[|foo]/ should mean /[&lt;fail&gt;|foo]/ is...interesting...
ingy: wonderful, now that I'm done with my talks, and almost done with my cold.
Well, at least the bad jet lag is coming back for me.  I don't mind flying west since it's just staying up later...
I put it in the same category as taking your umbrella to make sure it doesn't rain.
whatever works...
wouldn't multi delegation allow it to be an Item?
(presuming --&gt; Type is possible multi tiebreaker)
except the problem of too many levels of indirection...
or redirection...
What't the expected return type of this discussion?
I suspect .id is really .^id, assuming that .meta.id actually still
has access to the self that called it.
So if the user overrides .id, they can still get at the .meta.id.
Though I suppose some people could get burned writing .id and then
getting it overridden...
I'm not suggesting that it be the invocant of .meta, just available.
audreyt: patch looks good
caller something might be adequate
er, except we're called directly, hmm.
I don't see why it wouldn't still be .meta.  It's just the .meta of something that doesn't exist.
undef
lr\\
or "undef method"
should throw an exception.
nothingmuch: because every Dog has the same metaclass whether it exists or not.
No, ^Dog is the instance.  Dog is either synonymous with ::Dog or a compile time error because Dog hasn't been declared.
doesn't matter as long as the semantics are preserverd.
when the assign happens depends on the declarator
constant = compile time
state = first time
has = build time
my should assign at ordinary assignment time because you could have multiple of them.
shall I smoke it?
audreyt: hmm...gotta think about that...
putter: pretty much everything in S29 is still negotiable.
S29 is still really just a draft--I just whacked a few things upside the head to see if they rattle.
I'm suspecting we shouldn't have a default round() function, just all the round* variants, and let
the user alias one of them to round().
After which writing round() is a one-liner.  :-)
Er, I give up.
The AES have no clue about preludeness.
Except for what S29 says.
putter: on the P5 regex interpolation stuff m'$x' doesn't interpolate.
integral: because the last clod who did major edits was thinking more about the arguments than the module placement.
integral: no, only multi methods and submethods have to be in the same package.  multi subs can be anywhere.
Well, I'm just saying that, if history is any indication, anything I wrote is about half wrong.
I just have to be sure to Zeno the 1/2 that was wrong rather than the 1/2 that was right.  :-)
In Perl-Think, "true" is not a value but a predicate.
That should have come out as a slashed o with an umlaut.
combining characters always follow in Unicode.
my evil thought for the day:
sub main ($a, $b, :$switch, *@files);
note semicolon.
nothingmuch: both conventions are silly.
Yes, but do you have a syntax for turning the entire file into a sub?
I was just looking at some code with @*ARGS and thinking how ugly that was...
not a special case if sub is in the same category as module or class.
multi main (:$foo, :$bar);
(just call some main that matches my args...)
I spose.
hysterical raisins
sub (*%switches);
s/__/{die}/
I don't want someone to have to lean a different syntax for processing args to the main program than to a normal binding, at least for ordinary arglist processing.  $*ARGS is always available.
*learn
Are you suggesting that mere mortals have to write that?
maybe.  It'd be nice to serve mains up from that end too.
no, I think it's just multi main in Main package, and multi Main::main elsewhere.
so 'sub main' and 'proto main' would be valid variants in Main.
module Test :main{ say 'howdy' };
well, at least we know whether we were execed or used.
I think if you run a module Test we can look for Test::main to run...
A lot of P5 code currently has 'sub main'
have to translate it though.  end up with 'sub main_' or some such...
We could detect if the only thing outside the sub is the call, and optimize it away.
magically called sub should be MAIN...
why not?
error unless "is mumble"...
yeah, whatever it was...
but you still have to say that you're reopening it, to prevent accidents.
there's also 'is instead' to say that you're replacing it.
Yeah, that seems like the one I like most often..
yikes.
just a sec--i have some damian edits to commit first..
audreyt: k, s6 free
'sub is also' looks an awful lot like what p5 is doing internally with CHECK blocks, etc. except that we need 'is prealso'.
I guess most of the BEGINish blocks are 'is (pre|post)also'
'is first' is taken...
with most of our BEGINish blocks, the block itself determines whether it should be pre'ed or post'ed.  So maybe 'is also' should just tell the block and let the block decide.
can always .wrap if you want better control.
Every CHECK/INIT/FIRST/ENTER/UNDO is 'is also'
ohh a ghostghostwriter.
"Everything is an object" :)
given P6 Everything.does(Object)
given P6 { Everything.does(Object) }
There are times you want identical values to be distinguishable, and times you don't...
The point of eqv^H^H^H=== is to give you the 'values equal for value types, ids equal for object types' semantics.
use =:= if you want the other thing.
Juerd: you missed the quotes... :)
and the s/is/does/ :)
A value is an object that wants to pretend that it's a value.
Like the 3 object.
One could say that the value types are the ones that define infix:&lt;===&gt;.
I think infix:&lt;===&gt; is also related to the mystery of what you can use as an "untyped" hash key.
except historically hashes have forced to type Str.
There are, like, how many things in P6 that aren't conventions?  15 or so?
It's sugar turtles most of the way down.
Str is probably an object too.  Too much Unicode floating around to do anything else...
And we have 'eq' for forcing string comparisons.
A value is something you don't have to clone if you want another one of it.
I suspect Str has to define === though...
which would make it a value type.  Maybe it just can't decide...
=== always fails for differing types.
could
=== always fails for differing types (in the absence of MMD)
don't follow...
2,"2" doesn't even see Str,Str
we haven't really nailed down MMD distance yet, except to nail up Manhattan...
probably needs a slightly more formal proposal.
sub f (Dog $x) already means 'does', so 'as' is probably better for coercion.
Unless we mean 'to'.
Yeah, and 'does' says 'can you do this without changing yourself?'
nothingmuch: yes
C++ handles all that with constructor/coercion
That's why I originally had coerce:&lt;as&gt; make both coercion and constructor semantics, if I recall...
Maybe the constructor autogen is just an "is deep" variant.
it was historical
Anyway, I'm pretty comfy with "as" allowing a single direct coercion on MMD 'as' args, as long as we don't get into coercion chains like C++.
I presume it's just infix:&lt;as&gt; these days, but as I said, we could have an 'is deep' variant to autogen the corresponding constructor.
Actually, given MMD there's really no constructor/coercion distinction, so nevermind the 'is dep'
*deep
agreed
brain melts
But perhaps a generic 'as' could use that info to autogenerate the specific one.
feels like a co/contravariant conflict of some sort.
audreyt: I wonder if you could STORE.wrap something that redispatches MMDly to proper constructor before calling "real" STORE...
well, it doesn't seem all that important to nail down, so don't let me distract you.
are those sugar ghosts?
or turtle ghosts?
or sugar turtle ghosts?
what kind of a rant is that?  :-)
Yes, I saw your earlier rant.
thought maybe you had a better one. :)
I think @_.push probably works by default.  The "readonly" distributes along with the *.
sub f(constant *@_) {...}
constant %hash = (...) is a locked hash, presumably.
though maybe constant locks the values as well as keys.
okay to lock the values if you only change values thru existing ref.
I think constant should lock values too by default, since constant hashes are good -O fodder.
constant is more than that.  It's a compile-time thing in P6.
That's why it's a declarator unlike "readonly".
nod
obra: planetsix seems to have syndicated a huge mudball of your old bloggings...
Limbic_Region: you rang?
s/Limbic_Region/Steve_p/
Steve_p: glad one of us has it figured out.  :-)
All sorts of things are out of place in MAD.  It's usually a hard choice between fixing it up in C or letting nomad move it back to the "right" place.
But I assume you mean a C variable init out of place...
The whole MAD thing was predicated on the notion of being minimally invasive, so if you have a choice between breaking the mainline or making nomad's life harder, definitely make nomad's life harder.
But occasionally you can refactor and get a win-win.
That sound's like the kind of quote you put at the front of the next chapter in that famous novel "Jenga Book".
s/'//
ruoso: it's okay to optimize &lt;@list&gt;, of course, but the eventual plan is not to use &lt;@list&gt; at all, but exclusively magical &lt;%hash&gt;, or at least to the extent possible.
.oO(That was almost English...)
Basically, a good &lt;%hash&gt; matcher should optimize its keys into a good trie or DFA matcher.  For Perl 6 we also need to be able to map that magical %hash to multiple real hashes of things like %statement_control and %prefix grammatical categories, several of which can be scanned for simultaneously through the magical &lt;%hash&gt; mechanism, so that we don't violate the longest token rule even if some tokens are coming from one category
one way or other.
gotta run&amp;
gabor529_: eventually &lt;a a b c&gt;.uniq.each: { .say } should work too.
that would depend on the implementatoin of .uniq which has never been specified, since Perl 5 doesn't have it.
I imagine the thinking with uniq(1) is that there might be some reason to want to collapse multiple runs for non-sorted data.
Of course, these days anyone would use sort -u for that....
(I mean, for the .sort.uniq case)
gah, no coffee yet...
miyagawa: sochira mo!
I sent my preliminary slides to Kondo-san.
'sou shitai, yo!' to katta.
*kaita
*kakimashita
*okaki shimashita
LR: thnx
zannen desu ga, nihongo de wakari-nikui.  nihongo de, atama ga taihen osoku...
*osoi
jitsu wa, eigo de sono hanashi wo kikimashita.
hai
slurp should not autochomp.
slurp never splits, even in list context.  The whole point of slurp is to return the entire file as one string.
Actually, it should add a newline.  You want .print for that.
my attention will be spotty now--have to go pack for Japan...
avar: you can't prejudge which arguments of (A,B,C,D) are in scalar vs list context.
In general the flattening has to be done at parameter binding time.
Fortunately @foo and %bar don't need to know context beforehand.
Unfortunately, baz() does, so must sometimes guess list context.
Unless baz() is also evaluated lazily, which has its own problems, esp if you want to do MMD.
We still resolve lots of syntax by expecting op vs term.  Is that what you're asking?
hopefully we've tamed the syntax nudges to not have P5's problems.
well, we still have that particular problem.
that is correct.
the hope is that by making all the "desugaring" via explicit mechanism rather than deep magic, we can keep better track of the current language.
only better. :)
dave++
Perl6:: is really Perl6Acme::
"this book fills a much-needed gap."
"What is the name of this book?"
I think it'd be cool if we had something by Perl's 20th birthday.
which is when you come of age in Japan.
they even have a special word for it: "hatachi"
the birthday doesn't need to be declassified.  The conception is another matter.
fglock: s/use p6-pugs/use v6-pugs/ I think
.oO(someone just spat on my shoes)
meppl: oyasuminasai!
meppl: s/oyasuminasai/gute nacht/
audreyt: %hash .= sort maybe oughta transmute %hash to an autosorting hash that remembers the sort criterion sufficiently well to keep new entries sorted as well, or at least resorts on traversal.
I don't.
.oO(at least I think I think don't...)
In a way, this is actually closer to how Perl 5 works.  Perl 5 has no official Ref type.
It's just part of the infrastructure.
There are references all over in Perl 6, it's just that most of them don't require the extra level of indirection required by taking an explicit reference to a scalar value, which in a sense is taking a reference to a reference.
And this is really the direction we were going anyway with Perl 5, if we'd ever managed to get rid of type glob as lvalue.
the plan was to allow any aliasing (including of lexicals)
by saying \$x = \$y, which is essentially the binding op of p6
which is also essentially what happens in binding to formal arguments.
So the relationship of \$x to \($x) (p6's version) runs fairly deep.
On top of that, it's quite possible to make the implementation of the Arguments type polymorphic, just as the official Int type is represented internally by either an int or a BigInt, but that's totally transparent to the user.
does this make a little more sense now?  I admit we announce the thinking somewhat bassackwardly...
Darn it, now I'm dropping my subject/verb agreement.  Gotta stop hanging out with Audrey...
Hmm, actually, in this case it wasn't subject/verb agreement, but the past tense marker.  Still...
It's also possible that Arguments is still the wrong name.  Bindables or some such might be more accurate.
In fact, it's the process of making bindable that we call autoboxing.
:)
April fools...
first I've heard of it...
I think uppercase is still better for visibility in most cases.
(npi)
It's not Friday everywhere... :)
But yes, the net tends to go dead Friday nights.  some people have lives, it seems...
The convention could certainly change.
I don't think lowercase labels conflict with anything currently,
Disambiguating colons generally have to have at last two things before htem.
*them
yeah visual ambiguity can be a problem.
saying "next line" is kinda cool though.
but it is a little less like English.
Sticking with at least an initial cap is probably best.
the : might be illegal in map:{3} if we don't have :{} form.
the .map:{3} parses as .map: {3} actually
goto
I think the labelling policy in P5 and P6 are pretty much the same,
except for do label: {...}
statements, surely.
We could, if it comes down to it, change label syntax.  We have the technology...
Or we could have the convention that all labels are in CJK:
I suppose Greek would do in a pinch.
Hmm, now I'm worried... :)
We do have an underlying convention of all caps representing strange control flow.
that unifies BEGIN and LINES somewhat.
called magically
so an argument can be made for that.
so it would seem
cup have full/empty, but yes
*half
The whole export thing is underspecced from an infrastructural point of view.
possibly the is export stuff just turns into an IMPORT block...
possibly they should be called EXPORT blocks.
I wonder if they should work like macros...
It's kinda like "use foo;" turns into
use foo; EXPORT1(); EXPORT2();
or some such
and EXPORT blocks could use quasiquoting to return thunks to the compiler.
well, ASTs
I sincerely doubt they're all implemented yet.
And the places they are called from are going to be scattered all over.
I would have little reason to expect to see them all in one place except maybe for parsing.
And I suspect the current parser just generalizes FOO {...} as a form.
though I'm just guessing.
or maybe in has only a subset of the names.
*it
I should probably go for a walk myself, being underexercised.
plus, hanami shitai... &amp;
azuroth: see "Another dotty idea" in p6l for yet another simplification of postfix syntax that also gives us start/stop comments
In short $x.#( your ad here ).foo treats .#() as comment and reduces to $x.foo
unlike # line ending comments, would not count as whitespace.
And we can stop people from asking about nestable comments by providing them.
any delimiter allowed after the .#, by the way, for those readers without access to p6l...
don't think so
the pseudo-assignment of a declarator happens at a time determined by the declarator
just happens that "my $x = " happens at execution time, and the first example reduces at INIT time to my $foo = 72;
those just calculate the value at BEGIN or FIRST time, but the assignment is still at execution time.  If you want it to happen earlier,
you have to use "state $foo = " or "constant $foo ="
which imply FIRST and BEGIN time.
traveling and travel are both nouns, technically
you can also use "my $counter is begin(...)"
I outtagmemificated...
that one is just a progressive verb.  but "require travelling" is a gerund according to the high-school English teacher.
you can't argue with high-school English teachers...
the travelling is what gets to me...
the doubling of 'l' in travelling also gets to me...
but then, so does the non-doubling...
neither way looks right to me anymore.
the perils of being intercultural.
another one    ^^^^^
s/  / /
or we could just pronounce it with the emphasis on the last syllable, which would justify doubling the 'l'.
unless we also lengthen the 'e', in which case it would be one 'l'.
no state happens at FIRST time.
constant happens at BEGIN time.
we don't really have an INIT time declarator.
arguably our could do that, but people are used to assignment semantics there from P5.
some speculation in p6l that we should write labels as Lines: instead of LINES: to prevent that confusion.
hi everyone!
I just proposed .#() as embedded comment and as replacement for "long dot", which seems like a simplification.
realizes that all the time...
audreyt: which talk are you giving now?
and have you finished writing it?
(obviously not...)
=:= Larry Wall?
I certainly don't feel like a readonly alias...
maybe I just delegate to myself.
Nah, I'm so bad at delegation that I even delegate my delegating to other people.
never stopped you before.
just give 'em a little break in the middle...
sure
er, good question.  they have it up somewhere in .il
hang on...
http://wall.org/~larry/StumpIL.ppt
that's what I used in .il
so should work, if you're recent enough
OOo++
bye
we've been de-takahashied...
yup
yup
but the takahashified version of my stump speech is even more cryptic.
please tell me it's not a reference back to #perl6...
figgers
yep.  One of these centuries I'll have to come up with a new talk.
Actually it keeps mutating over time.
Actually, I come up with a new talk every OSCON.  It's everyone else gets the same talk.
'nite Juerd.
Though arguably all my OSCON talks are the same talk too...
Basically I never sign up for talks I have to write the abstract of in advance.
there's got to be some advantaget to it somewhere...
my throng of female groupies I can count on the fingers of one hand, and that's about all I'm allowed to do with 'em. :)
who says mine aren't?
Gloria tends to transcend groupiehood in various ways.
have you seen the Pugs Manifest from Audrey?
we shoulda put a link to it...
I'm busy revising S02 again, and it looks like it's working out very nicely.
Particularly since we still get a shorthand . . that is taken to be equivalent to .#. .
The other comments are naturally defined to make the "extra" newline into the whitespace.
So #... only extends *to* the newline at the end.
and =begin doesn't hide the newline before it.
or actually, ". ." is equivalent to ".#. .." so it still does the "long dot" trick visually.
have just checked in new S02.
pmichaud: see newest S02?
'bout 15 minutes ago
yes.
also have a response to the #. proposal queued, but my mailer is not sending right now.
I prefer the "shape" of .#() as a pseudo-method call.
looks more distinctive too in isolation
#. is too square on the front, and easily confused with plain #
also, I think $x# looks too much like the # is part of the $x.  it really need the dot in between.
And I just like the it looks like # is the name of the method in .#()
*that
you just write that $x.    .foo() now.  ". ." is short for ".#.  .."
is there.  when it's not, use .#[]
you almost always use "long dot" for lining things up, so there's redundant dots all up and down.
azuroth: no, that would destroy ###################### blocks.
me too.
cost me a nap worrying it though...
mostly residual jetlag, probably.  have to get up at 5am tomorrow to go down to San Diego and give a talk...
I do have many phases though. :)
dunno.  haven't scheduled an Australia phase yet.  I think I was supposed to come during my mid-life crisis, but my mid-life crisis turned out to be a rather pitifully small thing, as mid-life crises go...
all I did was scrap my life's work and start over...
Maybe with a quantum computer refactoring can be sped up...
Just call any(=io("*.rfc")) and see what pops out.
not any more
all places start with 'a'
do, or do not.  there is no try.
oopsie
?eval any(1,2) &gt; 1
consistent, I'll give it that...
?eval all(1) == 1
?eval all(1,2,3) == 1
?eval all(1,2,3) != 4
?eval one(1,2,3) == 1
that's also broke
audreyt: what do you think of rxen default to backtrack, rules don't?
backtracking almost never makes sense in a parser.
if $result == bool::false { say bool::false }
yes, any(@number) makes a junction.
but it's a list operator, so Juerd is right, you need the parens.
or @number.any == ...
that one's probably okay, though in p6 rules it'd be better handled with a lookahead on an ident.
yes.
well, it still has to return both the "ident" and the =&gt; tokens somehow, I presume...
but yes, the p5 lexer would certainly commit at that point.
and for P6 we've said that =&gt; absolutely quotes any bare ident on its left.
even if it's a keyword.
so it was basically taking a continuation on every identifier before...
we aren't allowed to have types unless they're already declared, so how can it be deciding that sub is a type?
then we still recognize sub as a declarator first...
gotta have a few reserved words...
and surely declarators are about as reserved as they come.
No, but expecting it to work in "my sub" should be without saying "my ::sub".
I have no problem with making people go through sigilish contortions if they want to declare things that are the same name as declarators.
?eval my my $foo;
?eval my my my my $foo = 1;  $foo;
in list context, at least
(1+2)*3
return; is essentially return ();
there are probably lots of places where you can't tell whether () is going to be in list/scalar context till you bind
p5 calls it a syntax error
For most scalar purposes, a null list stuffed into a scalar will eventually get you your warning anyway.
schlop shoen
I think it's okay for () to be a null list.  At worst, what you end up with a funny way to write "0 or undef"
$ prevents it
things which have both scalar and list natures have to use the hints
consistently
$foo always means scalar nature even if the insides are plural
yes
my smoke took 152 minutes.
when you settle down the parser again, I can run another and see what the diff is
on the other hand, one could claim that a singleton list always promotes to its single value in scalar context
the left side of dot is always scalar.
even in @foo.sort
I'm okay with continuing to overload (...) that way
ASCII just doesn't have enough brackets...  I've noticed this before...
Actually, we changed it to hash() at some point or other.
yes, basically
could MMD to hash(&amp;) I suppose
We still have dereferencing, just no references.  It's like the radio without the cat
pm's problem with unifying Capture with Match was that Match wants more info, like where the match starts and stops...
we left it at Match maybe being derived from Capture...
sleep hard
Oh, sure, nobody has much qualms about that, unless we want something more *cough* typeglobby *cough* in meaning.
parallel doesn't work well on spheres
I wonder whether a Match might just be a Capture with mixed in extra props on an as-needed basis.
Another political take on the whole ref/nonref thing is that, yes, we still have refs, but they just became, um, interestingly complicated refs.
so maybe Captures are really Referee objects. :)
Sure, and @$x is appealing to the ref.  :)
another ident lookahead for :&lt;  or :{ maybe?  Hmm..
basically infix:&lt;+&gt; is a supertoken, where "standard" p6 parser would drop down to a subparse but look like a single thing to the op prec parser.
the lower level of the 3-layer parser mode.
*model
that should do it
maybe we limit that to known syntactic categories?  (or maybe not)
of course, we'll want to let grammar writers add their own categories, but we don't need to worry about that yet.
good enough for now
could limit the =&gt; rule to \h* if unlimited lookahead is problematic
the latter
the :&lt; :{ forms were intentionally unlikely to occur elsewise
yes, but you get what you get
yup
for a good enough purpose one can of course limit one's own freedom--as long as you predeclare it...
would be so much simpler if there were also insanity tests...
if a question is not imminent, maybe now would be a good moment for me to commute home (~10 minutes)
kewl, dude(tte).
bbiab&amp;
degone
foo::bar always "autoquote" foo as well, so probably just another lexerish dwim
tokens with superpowers shouldn't be discriminated against--see X men et al.
statement modifiers are also sufficiently powerful reserved words to be recognized whether a term or operator is expected.
say if 1; is in the same category as say 1,2,3, if 1;
foo{1} would be in postfix position.  foo {1} has whitespace before it.
only question really is whether to force it on expecting term as well as operator
just a sec...
I think the correct way is to require people to say "say() {1}" probably.
it's a good spot to remember that you could have decided differently so you can give a good error message though.
but I think we have too many things like sort {} that have to eat the block as part of the operator
on the other hand, we could do it the other way, and require people to write
if (sort {}, 1,2,3) {1} in that case
but that feels uncleaner
through the wonders of backtracking...
I think eating a block accidentally is very likely to give a parsefail rather than do the wrong thing, so I think we eat the block and blow up politely when that's wrong.
on top of which, we're trying to train people into using .say rather than say()
I think say should expect a term, and {...} sure does look like a term...
we *could* exempt 0-arg list operators that just happen to be followed by a block, but as I say that wipes out sort and map
I wonder if we need to set up a separate P6 validation location that is pugs/parrot-independent.
I just wish shebang lines could pay attention to ENV vars...
so basically the &lt;space&gt;{ is special at the top level, and () blocks that.
I think I like that because it will usually be what people expect
and the foo {} listops tend to be listy anyway, so can use () around visually
that can't ever be a term
has to be postfix .{}
\yes
always
yes, and that fixes if -e { say "there" }
and if there are additional terms, we'll have plenty of opportunity to detect useless use of...
if not just notice that the if didn't end right...
actually, I'm being called to supper right now... :)
but maybe later.
okay
but if (sort {}, 1,2,3) {block} requires parens
that's the point, we're trying to get rid of all the bting
biab&amp;
the bottom-up parse has to parameterizable for terminators.  &lt;expectop&gt;{ is just the terminator
I mean &lt;space&gt;{
except, assume that =cut is probably going away.
just be careful with the minilanguages not to make the same mistake as Perl 5.  Calling out to subrules is fine.  Finding the end and reparsing is not so fine.
Also, I'm viewing the line boundaries as something more like handover points between coroutines, so it's not necessary that a pod parser act completely inside each pod chunk, or Perl chunk inside each pod chunk.
but the line transition conventions are agreed to by the two parsers so that you can, for instance, ignore the pod, or the pod can ignore the program.
calling out to a main rule is fine for now.
basically, but I don't know if they've updated Doc.pod to reflect what we talked about in Tokyo.
if there's still =pod and =cut in there, assume that's all simplified to =begin/=end with =use for a general "use" mechanism just as with Perl.
anyway, Ingy and Damian are still working it out, last I knew.
and I care about python because...  :)
placeholder is fine for now, and will probably continue to be fine as long as the line transition rules remain simple.
how does python parse =foo in general?
python can just put it all into """ =use """ blocks I guess...
=use is just an interface--I don't think it has to know much about implementation language
maybe it's all just parrot byte code.  :)
are you going to be able to do r10000 on your birthday?
let me know if I have to patch faster or slower. :)
have a good party.
sure
Python's an interesting case for pod, since pod is sort of anti-whitespace sensitive, or differently sensitive.
no, it loads something poddish called "foo".  Unlikely to be foo.pm
okay, parse pod using python, gotcha
all I really care about is that =use be there as an interface for specifying that you want the language to change somehow, instead of being implicit in whatever postprocessor you happen to run.
=use nroff
is certainly possible even.
you can do anything you like as long as you say =use whatingywantstodo first, and can figure out how to hook the line transition interface to do it.
basically =use tells &lt;ws&gt; what to do on a \n boundary.
gee, I was hoping for a +1.2 at least...
but you're also so improbable
nite
yeah, we just need to not fall into the source-filtering trap
different =use invocations might set different hooks, scoped differently
source filters are too crude of an ax.
so =use probably needs to be able to work at the "macro" level too.
define individual =foo thingies, for instance.
or whatever.
the source-filter lesson is that stream-level thingies often don't stack very well.
no, not Perl lexical scope.  =begin/=end lexical scope.
or =foo name scope
of Z&lt;&gt; thingie scope
*or
or whatever the proper scope of the "macro" is.
then you only have to worry about the interactions if people actually use them overlappingly.
it's just another form of encapsulatoin
=use can certainly switch to something too stupid to have its own scopes.
P6 is all about providing proper scopes of every kind so that encapsulation is always natural, but not everyone has to program in P6.
nor in the P6 flavor of pod
takes two lines to be orthogonal. :)
it is.
the only thing they happen to have in common is that they both require something like use to bend the rules.
and that they have to agree on who gets control at the line boundaries.
I expect most coupling to related documentation will be either by convention (located nearby) or by name.
but mostly that goes through the PDOM filter.
we're mostly discussion syntactic interactions right now.
s/ion/ing/
or lack thereof, hopefully.
yes, the whole pod notion is built on the idea that line boundaries are a very natural place to encapsulate/excapsulate different languages interleaved with each other.
sure.  =use is just one kind of special =foo, after all.
it all depends on what kind of engine we want to put under the interface.
I tend to prefer infinitely extensible engines, and other people prefer to nail down what is possible.
I prefer to give people the option of nailing down what is possible as one of the infinitely possible things. :)
hope this hurts.  er, helps...
audreyt += 42
on the other hand, I'm sure a lot of people would agree that a woman makes a rather unreasonable man.
Is :{} still free?
currently that's specced as .map: {moose} where the : turns .map into a list operator like $ does in Haskell.
positionals
anyway, maybe you can just decorate any {} to force it not to be the statement level block.
I'm gonna go to bed now, actually...
zzz &amp;
Captures can be viewed as "fat references" when it's politically expedient.
which "it" are you itting?
Fred would be shorter.
what reference?  the result of []?
[] is just an empty array in Audrey-speak
the term "array" already implies that there's a hidden reference somewhere.
every container has a hidden reference somewhere
or you couldn't store them in the symbol table.
and of course the GC still runs on references.  But that's all implicit now.
the whole point of a GC is that you can clean up when something isn't "referred to" any more.
this is more about the calling end, not the declarative end, is what it's trying to say.
when you say $a.($b), you get an invocant and one positional.
$a.foo($b) rather
when you say foo($a,$b), you get two positionals, and no invocant.
when SMD fails over to MMD, the Capture probably has to be rewritten to delete the invocant and unshift it on the front of positionals, at least logically.
that's because we made up the word for Perl 5's Camel Book.
it's the object on whose behalf the method is being invoked.
most of the other words in English either commit you to being the active subject or the passive object, and we didn't want to commit, so we made up a word.
well, Tolkien would say that being a subcreator is what we were created to be...
It's sort of a fallacy of the Modern Age's idea of specialization that you aren't allowed to be creative outside of your speciality...
well, if I don't go and work on my taxes, my wife will think up some creative way to make me regret it.  :)
or if I put it off longer, Uncle Same will come up with a noncreative way...
*Sam
so bbialb &amp;  # bit : long bit :: dot : long dot
or mention them here. :)
but if they're extensive, a patch would be nice
but LR is right that a reply to p6l is perfectly acceptable.
or to whoever installed the typos.
or wangle a commit bit and fix 'em yourself like Audrey did.  :)
some of 'em have been revised by $Larry :)
there are S's that are more core to the language def, and those tend to be on perl.org.  The ones that are basically records of negotiating between designers and implementors tend to be in pugs for now.
mostly I want things that are trying to stay stable to be on perl.org, and things that are still trying to evolve out where anyone with a pugs commit bit can modify 'em.
eventually they'll all move over, but I'm in no rush.
it just seems like a useful distinction.  not trying to fuel any turf battles either way...
I don't think he's worked on it in the last year that I've noticed.
most of the recent stuff is me.
but there's still a lot missing ,which is why it's "blessed" but still under pugs
you know, @;_ is really ugly.  I wonder if @@_ would be better for multidims...
Must be Friday night in the US again...
it would presumaby confuse Ruby programmers, which would have to be a plus...
macro circumfix:&lt;| |&gt; {...} is all you need.
But it's certainly true that we're not bending over backwards to support pure "math notation".
We've kept away from defining any prefix:&lt;|&gt; more because it would be visually confusing with infix:&lt;|&gt; than out of respect for math notation.
Pure math notation is optimized for mathematicians, not humans.  We'll make it possible to define things how you like, but Perl ain't math.
Mathematicians use all sorts of weird whitespace dependencies and two-dimensional thingies that don't work out terribly well in a computer language.
They're also quite inconsistent about what some symbols mean, even comma and vertical bar.
I was just about to say that.
At least we're allowing the user to define Unicode operators, which is a lot more than you can say for most other programming languages.
"enough rope to shoot yourself in the foot"
Biologists have simple desires.  :)
Infinite strings, mostly.
well, huge strings...
and maybe a decent database to store them in.
sort of CGI writ large.
But I think Perl 6 has a decent shot at the mathematicians as well.
Or rather, some future variant of Perl 6...
One thing I can guarantee the mathematicians is that standard Perl will never waste juxtaposition on multiplication.
I think the Wall Street types will particularly like the ability to nail down modules to particular versions, along with the ability to use different versions in the same program.
At least some of them are very picky about upgrading modules...
well, terms and operators...
@@a is just a different mnemonic.
And it looks a lot less like a bare @ with a terminator after it.
well, speaking of dinner, I'm being hauled off...
so biab &amp;
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.
then they're probably just troublemakers. :)
Well, I'm not a person to be poking labels on people, but I have noticed that there are certain people who are never happy unless they have something to be unhappy about.
I don't profess to understand the contradiction...
Maybe they thought you'd enjoy it.  I dunno...
Well, I've been fighting the flu, so I'd better toddle off to bed.
I don't think you're dumb.  You're just persistent, which can be both a strength and a weakness.
nite &amp;
audreyt: if it makes sense, sure.  The lists weren't not meant to be exhaustive, which is why I used "include"
?eval my @array .= sort;
?eval my @array.=sort
sure, as long as you point out that they don't actually declare variables.
not currently.
(that I know of, anyway)
doubtless the PDL folks will have one or two hanging about eventually...
It's not clear to me that signature is a good default arg.
we've certainly left sufficient bait in S09 for the pdlers.
how is that different from ordinary assignment?
P5 still treats it as an lvalue.
maybe temp only works on mutable objects.
distributes to two mutable objects
($x, $y) = 1,2
have to be mutable anyway.
sure, but these aren't declararing anything really
they're just instructing a mutatable object to start a transaction.
sides, you can temporize methods, and those are *illegal* in sigs.
they're just lvalues
thanks, KingDillyDilly.  I note that there are some other things that have suffered "design rot" too.  Couple places where they seem to think &lt;{...}&gt; is an assertion, for instance, when it should be &lt;?{...}&gt;.
I would think so.
KDD: there are only two &lt;{...}&gt; that should be &lt;?{...}&gt;, I think.
but the whole point of capture is to do the same thing a normal function arglist would do...
KDD, the first is Simplified code assertions: &lt;{...}&gt;
the second is the second line of the example below
rx { ( ab* ) &lt;{ $1.size % 2 == 0 }&gt; }
uh, what S3 change?
reformatted para
but *func() in list context just falls out of the fact that func() always defaults to list if it doesn't know.
I'm not sure we want to call func() lazily...
but there it doesn't matter since we can do it lazily.
certainly $x doesn't care if it's in list context.
it's only *@a that might be a problem
and *%a
fine by me.  But ** is more list contexty than *, in a way.
I'm fine with eager Capture.
novice: "What does that mean, 'Can't capture infinite list eagerly.'?"
what did we decide about duplicate named args?
right.
could go with normal sigil gets last, and new @@ sigil gets all.
though it's not the normal multidim situation...
infix?
@foo push 1,2,3;
arguably it's ,=
which we've rejected several times.
as to hard to tell from .=
*too
%foo.push would presumably add pairs to the hash
sorry, off on a tangent...
I think we have to stick with * to deref as arglist and % to deref as hash object
@pairs.push(%foo.pairs) if nothing else
yes, that's interesting, but I think it has to do what the user expects.
and they'll certainly expect that to be a list assignment.
if there are multiple subscripts
we could probably get away with just saying it's list assignment if there's a subscript at all.
how often are people going to write loop ($a[0] = 1, $a[1] = 2; ...
yep.
I think it is probably okay to train people that P6 subscripts like to pretend that they're lists.
if you say $moose[@jaw] you going to get a slice.
and it's just a little like the interpolate-ending-with-brackets rule
On the other hand, there's probably some optimizations that depend on knowing you only are getting one value out of it.
oneness lets you throw out the looping code.
you say you alredy have the code to do the analysis?
much to be said for inferring the expected context...
a mess, in other words
how about a simple heuristic.  one number or scalar, it's scalar.  Otherwise assumes list
that would seem wise.
that's defined as a single element
so yes.
any function goes list
except + or ~ ish things
I think people will be happier if we simply enumerate them.
+ is special inside [], and ~ is special inside {}.
and maybe vice versa
ooh
negation is kind of important for subscripts.
kinda goes with +
$x[$match.from] = +@bar too
I don't suppose we can delay it till we actually know how many
oh right, we just did that... dud
duh
parse as list, capture, then revert to assignment semantics?
based on 1 vs many subscripts
how 'bout [1] [$x] [+anything] [-anything] is scalar, all else list
maybe with recursive subscripts
have to include ..
; is pretty good indication too...
$x[*@list.reverse] :)
I mislike the trailing comma for visualness
except if you do have a multidimensional array, that means "all of the first dimension"
"make me one with everything"  could just be a hot dog
I think you're okay.  If you really wanted to splat the first dim you'd say $x[*;1;2;3]
well, I don't know as I'd go as far as to call it natural.
and in a sense, it's not really right, because $x[;$y] is still a single element, presumably.
nite aufrank.  thanks.
unless you want to use the same rules you use for lhs in general.
great minds...
the two are not mutually exclusive.
something before the [] maybe.
$x() is going to run into role conflicts...
I should probably sleep on it.
k
this time maybe I won't try going to sleep with one eye on the IRC screen... :)
anything else need deciding soon?
okay, g'nite, and thanks.
&amp;
.zZ( $x.*[foo()] = @foo )
* audreyt ponders the @array[{$_ &lt; 3}] overhuffmanization for
@array.grep:{$_ &lt;3}
audreyt: doesn't work for two reasons
.[] allows optimizer to assume integer slices.
and {$_ &lt; 3} would probably select indices from the current dimension
or we couldn't generalize to multidims.
I think if we install a generalized index selector, then it should go in via .{} or .() instead.
since .{} doesn't give any special instructions to the optimizer
@array{ {$_ &lt; 3} }; it would have to be
or @array( {$_ &lt; 3} ) maybe
in any event bare .[] probably shouldn't support that kind of generality.  Maybe overload .?[] or .*[] for that, if we don't swipe it for slice forcing.
but it's probably best to prototype with some kind of .foo( {$_ &lt; 3} ) first.
later we can talk about sugar if it's deemed necessary.
no, it'd be a syntax error.
sometimes syntax errors are the nicest thing you can do.
that's no better.
how bout jsut .grep: ^3, ...
first arg to grep is just a smart match
and ^3 is 0..^3
(differs for negative, I realize)
just a Range object.
: is Haskell's $ there, more or less
stands in for a left paren with no corresponding right paren.
.grep: ^3... is the same as .grep(^3...
)
yes, grep is on values
by the way, I'm thinking of destroying ... in favor of something more general.
that is, ... meaning ..Inf
it's problematic in several ways.
first, it parses as an infix that is missing its right argument.
rather than as a postfix.
so you can put a space before it like .. can have a space before it.
we never allow postfix with a space in front nowadays.
another problem is the visual clash with the yada operator.
a third problem turned up when I decided that maybe we should have xxx to go along with xx.
yes it's a minor problem, at least to the computer.
except you can't write $fooxxx 3
and 3xxx will get you funny looks even if the computer groks it
but that's just another reason it has to be a weird infix rather than a postfix.
or we force people to write .xxx
so I think what we want here is some generalization that inserts Inf on the right side.
and I think it's the fact that * with no argument means "Whatever".
3 xx *    0..*  take Whatever to mean positive Infinity (and Beyond!)
*..* would then possibly mean -Inf..+Inf.
is no term starting with ..
is the same operator that means Any in [*;0..5;*]
aufrank: if you want to exclude Inf, sure.
except that ^ has to be contiguous with ..
or you've just said 0 .. 0..^Inf
I think this is a simplfication over ...
fine, it's dead
.oO(baskerlell)
people are so used to * meaning Whatever in globbing.
copy us, xerox
this is a role that * is already being used for.
generalize that to "behavior selected by the associated operator"
argumentless * is just a Capture of the Whatever idea.
indeed.
that's how it already works in subscript slices
It is backtrackless if you ignore whitespace.
0..Whatever means Inf
yes
No, it's really 0..ArbitrarilyLarge
but we can translate that to +Inf for practical purposes.
Computers can't understand infinity any better than we do.
on the right side of .. it is.
Okay, how about ArbitrarilyLargeEnough instead?  :)
Maybe define it as the first uninteresting number...
oh wait...
"foo" xx *
my ($a, $b, $c) = 1 xx *;
$x[*;0..5;*]
there Whatever means whatever the domain of the key type
%x{*;'a'..'z';*}
see S09
rand *   :)
for * {...}
for Whatever {...}
could be the new =&lt;&gt; if we go with Audrey's new idea.
/foo/ ff *
flipflop
in this case it means "false"
It doesn't--it always means Whatever.  :)
but that's sophistry...
you mean like @foo changes meaning under + vs say
I don't think so.
to2: I'd expect it to do much the same as +(Any), which is to say,
probably throw an exception.
which certainly falls under the rubric of "Whatever
"
In general the * prefix just means "splat something in here that is not directly specified"
I don't think anyone can look at 0..* and not grok it.
s/anyone/anyone not seriously damaged by earlier exposure to computer culture. :)/
Make me one with *..*
In a selector when you're too lazy to say Num.
that's another reason for it.  'a'..*
the endpoint is *not* Inf.
It's...its...er...
Whatever.
Sorry, I already called the colon.
Whatever...
right.
"Whatever" xx *
It googles for Whatever and starts replicated the I-feel-lucky page
s/ted/ting/
was just wondering about XXishness
not to have it.
:)
I think we can just get away with recognizing a closure on the left to mean that.
{ say "Whatever" } x *
and you want that because...
Juerd, actually, we do have map EXPR, LIST now.  That's *all* we have.
map {...}, LIST is just a selector in the first arg.
"selector"
about an hour ago we just through talking about grep(0..3, @nums)
pick the entries that match the selector.
a selector is smart matched.
a smart match against a range checks to see if something is in that range.
selectors return boolean.
right, sorry
I mentally translated your map to grep
but it's still the case that the syntax is map EXPR, LIST.
it's just map does something different.
you could probably use anthing that maps though, like a hash.
map %xlate, @values
how can you tell what type is wanted in the presence of ubiquitous MMD?
I guess there's a return sig anyway
Item --&gt; Boolean for instance
We'ver already named those Selectors
I agree that EXPR is not specific enough.
If you have opinions on that subject you should help Damian and Ingy with the revised S26, whatever it's called these days...
pugs/docs/Perl6/Spec/Documentation.pod or some such.
on the other hand, the document structure will be availabe to the surrounding code.
so anything that is naturally code goes in as code, and anything that is naturally doc goes in as doc, but is still available as if you'd put it in as code.
is documented--
%=DOC++
the document model will even give you the nearby comments if you want smart comments
so just use the shiney new #{...} for your inline docs.
how...literate...
yes, except they can't start in the leftmost column.
happened a week or two ago
see S2
cool.
you get to pick your delimiter with #{}, so you can pick something distinctive.
try again. :)
all defined in S2
nto?
defined such as to include &lt;&gt;
despite not being Ps/Pe
basically, "bracketing characters" in Perl 6 are now defined to be either Ps/Pe pairs or bidirectional mirror pairs.
:)
Yes, multiples are consistently supported, though the semantics of &lt;&lt;&gt;&gt; are special in some places.
[[[*]]]
we're fixing that.
get involved in the Documentation.pod rewrite if you like.
legal
Hey, Unicode has to be good for something...
those don't match.
I think you've mixed different quote types.
Okay, the first set match--my font is screwed up.
the second can't match unless they're defined as a Ps/Pe pair.
yes?
pmurias: I don't think anyone cares about typos there.
aufrank: have to bounce that off of Audrey
I'm not sure where multidim arrays are currently, implementation-wise
my gut level feeling is that PDLness probably *would* make a good SoC project.
at worst, it'd be kludged in the way it's kludged into Perl 5, but integration is sufficiently open-ended that one wouldn't run out of things to do quickly, yet one could declare success at any point.
Plus it's something that is likely to be useful in whatever state it comes out, so people can build on it.
And it would be good to flesh out that part now rather than later, since it's one part of the design where I'm doing more guessing than usual.  (Hard, I know.)
I'm behind you 100% at least until the shooting starts...
playing marbles
I used to have a nice set *cough* years agol.
*ago
well, I'd better curl up in a corner and contemplate what's happening to the fish operator.
=&lt;&gt; for those following along at home...
that looks like a bird about to eat a catapillar
Hmm. I wonder what unary string rightshift would mean...
Unfortunately we already have infix:{'~&gt;'}
S03
string right shift
for @foo -&gt; $_ where / (\d+) / { say $0 } might work
I think you're looking for Befunge or some such.
I recognized it...
actually, I think my interpolation helped...
coming between the eyes and the mouth
what about the little chevronny things?
anyway, if we make =&lt;&gt; only ever read one line from @ARGS, then we end up with a special case on * if we want
for *&lt;&gt; {...}
to fill that role now.  As long as it's a special case...
then for * {...} is just a slightly specialler case...
I was actually a bit serious earlier when I said
for Whatever {...}
no, Whatever is what it means.
surface syntax is still *
just in that context means *&lt;&gt; or *$ARGS or some such
dunno.
if empty postfix &lt;&gt; still means ARGS though, and if we ignore @&lt;foo&gt; from Match objects
then @&lt;&gt; could mean all the lines from ARGS
but @@&lt;&gt; would mean to keep the separate file's lines as a separate dimension.
but it depends on swiping empty &lt;&gt; from @()
which we could conceivably do, since the empty key doesn't mean anything anymore to $/
but it's a little confusing that @&lt;foo&gt; means $/&lt;foo&gt; when @&lt;&gt; means *$ARGS
mmmm
explain that to a five-year old
'Course a 5 year old will simply take on faith that "for * {...}" works and run with it.
groups?
yeah, tell me about it... :/
yes, I did
for + {...}
for ? {...}
for **{0..10} {...}
that...almost works...
for "do" | "do not" {...}
for "better" | "worse" {...}
It's probably too cute, mostly because the context is too diffuse
I could more easily believe that * is the ARGS iterator if it were used like =* or @*
...
?('b'|!'b') maybe
hmm *..'x'
I wonder what a negative string looks like?
/foo$/
or would that be /oof$/
bingo
surly \$foo\
\$oof\ I mean
pity f doesn't have a bidi mirror...
I'm not sure you can ! a range...
though I suppose it could be useful.
Oddly, $a..$b is contiguous, but !($a..$b) wouldn't be...
that would generally be clearer, i suspect.
On the other hand, as a general selector...
I guess you could always pass { $_ !~ $range }
say not $a .. $b   # -Inf, -Inf,-Inf,-Inf,-Inf,-Inf,-Inf,-Inf,...
It's a set of data values along with a hint about their logical relationship
Currently junctions are only discrete values, whereas ranges are (in the abstract) continuous.
rather, use of a junction is a promise that the "legs" of it can be calculated in parallel without interference.
Unlike hyperops, even ordering is lost.
even completeness is lost, in the sense that a hyper goes to completion
while a junction is free to short-circuit any way it likes
as long as the logical relationship can be proven.
so $a ~~ 1 | 2 | 3
can quit as soon as it finds any match.
no
it can quit as soon as it finds two matches. :)
if 'x' ~~ any(@foo) { say } can quit on one match
as can all(@foo) if it's false
or none(@foo) if it's true
nothing like that
well, that's exactly what $0 is...
I doubt .. would know what to do with StrPos, but StrPos might figure out what to do with ..
and .. could exclude the endpoints. :)
I once had a font with square periods...
i wasn't making fun of your bad English
I was making a pun.
I do that sometimes...
unfortunately...
Fortunately, time is kinda uniform (to the first approximation),  Unfortunately, string lengths have multipathing problems.
but it certainly the case that we should prefer APIs that deal with the strings themselves rather than indirectly referring to them via their locations
Well, and byte boundaries are likely to be the internal form a StrPos in many cases.
but you might have a pos in a string that doesn't even *have* bytes.
espcially now that we can do things like @foo ~~ /stuff/
you get handed a string with its minimum abstraction level set to, say, codepoints, and you aren't allowed to know it's repr internally.
Or you are matching an array of token objects.
That's the Str vs Buf distinction.
that's correct.
Unicode doesn't do integers.
Even UTF-16 is not a fixed-width representation.
And at grapheme level, even shoving everything into UTF-32 doesn't help
no, they just think it makes sense...
And it does make sense, but not in the way they think it does.
They weren't using Unicode before.
The reason the default level is graphemes is because that's closest to their intuition of what was happening before, even though that's harder for us.
You can use integers at grapheme level, just as you can use integers in Perl 5 at codepoint level, but you have to do tricks to deal with variable length characters in any case.
that's yet another definition of length.
which has nothing to do with any of bytes, codepoint, graphemes, or characters...
it's just a definition that depends on knowing your output device.
or not caring.
you'll note that HTML gets along fine without %s.
basically, for interpolation, not sizing.
interpolation
q[&lt;a href="{uri_escape($url)}"&gt;{encode_entities($url)}&lt;/a&gt;]
don't deny it.
yeah
q:url($rul)/.../
s/ru/ur
Didn't we tell you?  Perl 6 is an attempt to re-invent PHP...
I think we should write it all in lisp...
declarative programming++
as long as it's all imperative underneath :)
no it doesn't
&lt;&lt;..&gt;&gt; do shellish quoting syntax
why would we want to duplicate " ' $foo ' "
good gad no
just the quoting
and that not including backticks.
it's already that, to2
a grammatical category installs two longest tokens, one ending with &lt; and one ending with {
fixing long dot would involve changing the first character to something other than dot.
right
right.
tokens would be elk :{foo} .antler :{bar} so I believe so.
(using token to include supertokens)
I think I know which is more important...
and it isn't lining up long dots
unfortunately there aren't any convenient ASCII characters left for changing the opening of the long dot.
well, I have to run off for most of the day.
As an option, though, a Latin-1 would work along with ". ".
ta &amp;
something that wouldn't be wanted for infix!!!!
really &amp;
yay, now passing over 11,000 again.
doubtless audreyt will find a way to drop that back down to a more reasonable number over the weekend. :)
I'm wondering whether we should disallow # as quote delims.
At least one of the tests fails because rx#/# eats the # trying to traverse the whitespace to find the delimiters...
A comment is always whitespace...
there is if rx trys to traverse whiteSpace to get to the delimiter...
*tries
whiteSpace = skipMany (simpleSpace &lt;|&gt; comment)
If you'd like to rewrite the parser in P6 rules, that'd be cool.
I'm sure a lot of people would find [ &lt;simple_space&gt; | &lt;comment&gt; ]* a lot easier to understand...
but it would still eat the #...
g'night
audreyt: did you see my earlier musings about outlawing # as a quote delimiter?
Just looking for simplifications...
and since that's already what Pugs does...  :)
well, we're giving them most of Unicode plus [[[...]]], so I can't see that many complaints about losing #.
also I was discussing virtualizing &lt;%.foo|%.bar&gt; earlier...
and wondering about the performance implications.
since we need to track the token sets along with the grammar mods...
virtualizing just makes it a little harder to keep track of when to invalidate the cache, i guess...
lexical to the comp unit, but dynamic to the cmpiler...
but you'd kind of like to think of each %.foo entry as its own method for overriding purposes...
which is likely suboptimal
if we keep track of all the places it's used?
or make it check a valid bit that's in a handy place...
I'm wondering if a more consistent symbol policy
like we did with my declarations
would let us process macros more expeditiously.
as in "you may not use a macro earlier than it defined in a lexical scope".
no, but you can use macros from outside the current scope
and then override them.
that's what might be made erroneous in the interests of implementation.
we basically already did that with my $foo
basically, when we start a new lexical scope, it has a single new grammar, but we just don't know it all yet.
that's the idea.  not sure if it really works though.
it probably won't fly.
and stacked grammars in a single lexical scope can be useful.
but we then do run into the same problem as with lexical vars, which is if a child calls back into our scope as its caller, which grammar do we tell them their statement was compiled with?
In particular, if that child is an eval.
and wants to default to the same language it was called from.
we need to be able to hand that child a $?PARSER that includes the macro names that were current at that point, however we define "current".
that means that &lt;%foo|%bar&gt; can't be off in some other scope independent of the current parser object.
that implies %foo and %bar are attributes of that parser object
and written &lt;%.foo|%.bar&gt;.
It's a closure that has to persist from compile time to run time, is all.
yeah, I'm sure it's doable, it just needs to be efficient.
mostly efficient for subsequent compile in this block, not too worried about eval.
though in a sense they're the same thing.
but my earlier talk of simpler policy is basically whether %.foo has to live in the current parser object or can live in COMPILING's lexical table.
hmm, you mean use COMPILING %foo?
*&lt;%foo&gt;
would have to be reimported on every subrule invocation
since it could be a different parent grammar.
or do you just mean a policy to look up %foo in teh current $?PARSER?
or the current COMPILING?
(and all of its antecedents, for overlays)
could just write the grammar &lt;%COMPILING::statement_control|...
this is basically just inside-out grammar objects...
seems a little silly, stated like that.
they?
seems like it would be really easy to generate an awful lot of duplicate closures in parsing if we're not careful.
I wonder about everything, except when I don't...
but yes, I'm mostly wondering what is the most natural API.
and I do think that people can imagine a "current parser object" more easily than they can mysterious closures.
except for the fact that COMPILING has a policy of one-nameset per scope, and %.foo doesn't imply that
well, as long as it always does everything everyone might ever want, I don't care.  :)
are you working on Capturizing pugs this weekend?
(to the extent that anyone with ADD can be said to be "working on" any particular thing... :)
k
I'm just itching to start writing bits of the Pugs compiler in P6 rules...
but when we make the Capture &lt;=&gt; Match thing bridge across, we can start rewriting rules piecemeal.
or start thinking about auto translation.
I know.  But I'd be happy with piecemeal hand translation.
if only to prototype the autotranslator
I can start thinking about that.
have my own set of distractions though...
speaking of which, I need to wander off.  anything else hanging fire?
at least such a thing can be lazily defined.
not sure it's sufficiently immutable though.  :)
Don't stay up past your bedtime, young lady!
But also, Have the appropriate amount of fun!   :)
afk &amp;
pedigree maybe?
I've not had bad luck lately with parrot installs.
in fact, I always install parrot.
this is the first time I've been burned by pugs install though...
like I say, my parrot install hasn't broken for a couple months.
but maybe that's because I have my PARROT_PATH set right
actually, as I recall, the problem used to be that pugs was believing the installed parrot over the PARROT_PATH parrot.
particle_: same thing as when ~~ matches.  !~ only changes the boolean sense
just means the Match object shows up in the else instead of the then...
hmm, I'm a lousy mentor...
but maybe I could do that.
I always read SoC as Southern California...
I don't have a google account...
okay, I get the feeling you like it. :)
I do too.  :)
I take it you're still trying to get used to [,]...
the one lossage is that [,] can't really trigger a $capture
but I'm thinking =$capture works maybe
if it's just a list, $capture doesn't interpolate.
Well, %hash makes pairs...
right.
could just force it.
one level's worth, just like * did
it's not really a force for %hash1, %hash2 because a reduction is defined syntactically.
yes, to do just one is [,](%h1), %h2
so each pair is "comma separated" at the top level.
which makes it named
presumably not.
as I say, it's just $capture that doesn't naturally continue to work.
presumably.
and =$capture, perhaps
or @$capture, to just get the @ etc.
[,] $$capture, @$capture, %$capture;
anyway, it really was seeming more and more like we needed to de-borrow * from Ruby.
the deref meme was just wrong for *.  now we're consistently globby with it.
shades of typeglobs...
I would hope it would only evaluate once.
it's still logically flattened, whether it's lazy or not.
hmm.  that's why my --&gt; Dog: conjecture said it's probably better to return an object that decides.
yes, want is a weird inside out delayed dispatch, or something.
a parallel gather/take like thing
if we had a language without side effects, it wouldn't be a problem.
I think want has to be an "observation" in the Copenhagen interpetion
interpretation, even
can want know whether to collapse the wavefunction or not?
It's like there needs to be a negotiotion.
how lazy do you want me vs how lazy can I be
gee, sounds a lot like type inferencing...
as far as I'm concerned, it could all just fall under the rule "if we don't know, it's list context".
interesting fallout from the 1-arg rule...
reverse(@onearg)
so we only get into trouble with reverse([,] @onearg)
I don't plan to lose much sleep over it...
because foo($x) really means foo([,] $(\$x))
what's your opinion of the triangulation metaoperator?
er...
I had that first.
but...there's something to be said for cute...
looks too much like a reduce on the (+) operator
is (+) a set operator?
also tried [+]\ and [+\
also played with |\ briefly.
I like that [\ is assymetrical
[/+\] would have to start in the middle. :)
yes, but at least I doctored it so that [\+] gives you the normal
reduce rather than the scan
correct.
slurpy is a manifestation of the globby meme
"pattern match a bunch of things here".
and can't be confused with GLOBAL:: because we never declare globals in sigs.
yes
though in the particular case of 1,2,3 it doesn't matter whether they're in or out
I don't expect a %() would hurt there.
=$pair possibly.
is that an assignment operator?
there's a nice consistency to the % there.
It seems like a good plan, except for the fact that different listy env vars are going to use different delimiters...
env @PATH is delim&lt;:&gt; := $+PATH
I dunno.
this reminds me a bit of @array ~~ /pattern/
$+PATH is parsed ...
wouldn't that just be a pair argument?
or does it die because of f7?
got it.
commuting home &amp;
degone
by autoconcat you mean A x B x C x D...?
that is, the syntactic rewriting of [x]?
which is what a reduce is supposed to do...
by syntactic metaphor
I don't see why it wouldn't.
not( $a === $b )
I suppose.
Then theres [\+=] $a, $b, $c
It just suddenly hit me that we already had * staring us in the face.
I think so.  Damian likes it.
'course it was the pain of rewriting all the *@foo to make * "almost a sigil" that drove me over the edge to whacking it...
as long as there's a way to do it, we can look at slicker ways to do it later.
yes.
do extra invocants turn into positionals or blow up?
clearner++
kinda goes back to the idea that the invocant is the honorary head of the positionals...
yeah.
I've been thinking of invocants in Captures as kind of a search strategy, where different types from the type bag
are more specific.
and the head of @ is just the most generic place to look for an invocant.
it took me a while to compose it...
I'm being called to dinner, but I'll whack on it later.
biab &amp;
gaal: fixed, thanks
fixed, thanks.
afk &amp;
pung
I don't see the problem with: my @a0 = () and $x0 = 1;
should be equivalent to $x0 = 1 if my @a0 = ();
on the other hand, you did say "triaging"...
and is looser
we could certainly disallow "my" on the other side though...
?eval my $a = 1;
?eval my $a if 1;
?eval (my $a) if 1;
?eval say my $a
?EVAL 1
?hmm
@list help
@help
@help ?
@?
@eval
@eval
!eval
?
@
@exit
@elite quit
?eval say (my $x)
doesn't seem quite right
Slice assignment requires parentheses, maybe
Did you mean "(@a[0,1]) = ..."?
sure is tempting to exempt commas.
Well, we can always relax it later.
Well, my brain is running out of "today", so I'd better go put it to bed.
:)
&amp;
Just means the social brain shuts down before the technical.  For most of us it's the other way around...
tanks.
Ya, kids change your life a lot more than getting married, I think.  You get to pick your spouse--you don't get to pick your kids...
Heidi
24
The polite term is a "hybrid"  :)
not really.  I'm not scholarly that way.  I just make it up as I go...
I had to rm all the .hi files to get mine to recompile.
apparently not.
maybe it just missed something
I would say that P6 is still a "single-pass" parser; I think of that as orthogonal to bu/td
I read the Dragon Book, and I would be hard pressed to tell you what I got out of it.  It's rather theoretical.
To me, a "one-pass parser" (as opposed to a one-pass compiler) is one that does no backtracking.
both td and bu can do that...
the difference is that td stores more info into the control structure rather than the data.
on the other hand, you do have to propagate semantic info up and down the trees, so the compiler is necessarily multiple pass in that sense.
(though of course for some languages you can do both in one traversal of the tree)
for contextually sensitive languages like Perl, though, the context pretty much has to propagate downward as a subsequent pass.  Generally info can pass up the tree while you're building the parse tree.
that's how P5 does it, anyway.  P5 has a third compiler "pass" that's the peephole optimizer.
but p5's parser is definitely not one-pass if you count the lexer.
what is this "theory" thing you keep mentioning?
sounds like something that was post-me.
I don't remember installing such an optimization.  But if it's just the magic system, it could certainly be my fault, at least partly.
yes, good link
I suspect the answer to Nick's last wondering is "Captures".
I doubt parrot has Captures yet.
It's just a p6 concept, so far.
in fact, not even pugs has Captures yet.
they're just rich, lazy references, but they might just solve the problem here.
different how?
howdy
sure
Smalltalk looks like a derivative of Python and Ruby.  :)
mojojojojojo
yes, audreyt sleep-fixed it.
and COBOL.
?eval for 5 -&gt; $x { say $x*$x }
yes, and they're all closures.  so Smalltalk must be derived from Perl 6 as well.  :)
how much memory do you have?
and is your disk going blinky-blinky?
I find that 512 is marginal.
ciao!
off to take a walk--have been severely underexercised while driving to Seattle and holding a baby...
&amp;
visq: by necessity, things are specced before they are implemented, and often poorly specced before they are tested to see what the actual interactions are.
and we're all just volunteers, so often things get specced speculatively long before they're tested or implemented.
with something like triangular comma, it's not at all clear what the exact semantics should be yet.  It's just a syntax that falls out of the other triangular infixes.  But the spec is just saying it's available to make it mean something useful maybe.
have you seen http://m19s28.vlinux.de/cgi-bin/pugs-smokeserv.pl?
occasionally some of the tests link back to the spec, but there's nothing official
part of it is simply that the specs aren't as well structured as they would be if we were designing, say, Ada.
part of it is simply that volunteers aren't generally into that kind of accountability.
and like POD, we make it easy for people to contribute, even if it's suboptimal in various ways.
but as gaal sez, we'll take help wherever it's offered :)
even if it's actually improving things. :)
well, I don't know how many people would actually be interested in reading that, but certainly we could check coverage by backlinking.
FIT?
seems like a good way to discourage people from reading the specs, but probably there can be multiple ways to view the specs.  :)
thanks
don't let what I said earlier discourage you.  good tools will motivate people to improve their cross-linkages if they can see pretty colors.
which reminds me, someone should put a "key" into the TAP matrix that explains what the various colors actually mean...
and I think it's a bit disengenuous to make "todo" items dark green...
purple, maybe...
I'm still not entirely sure what white means...  Untested on this architecture?
but in a real sense, the test suite is becoming the specification.  The S* are really intended primarily to just be deltas from Perl 5, whereas the test suite needs to be complete.
that's why it makes more sense to do the links from the testing end.
yep
nod
I remember writing the original TEST program in a very limited subset of Perl 1.  :)
The test suite *can* be a spec if it's complete enough, I think.  We're nowhere near that yet, of course.
but I don't know what "full spec" means.  a spec is not a container that be filled. :)
s/be/can be/
I think the government defines full specs to be ones that break the scales you weight them on.
the problem with writing a formal spec is that you have to be omniscient to write one.
we're going for a more evolutionary approach, so the test suite is as formal as it gets.
at least the spec is not the C code, like it is with Perl 5.
I think thinking about that too hard would damage me as a "language designer for the people" :)
I rely on smarter people to do that.
I love all the semantic feedback I get from the Haskell implementation though.
and I don't mind other people bugging me about areas where I think fuzzily, since that's basically all of 'em.
that's what symlinks are for  ;p
them's is too hifalutin' fer the likes o' myself
you fixed eric?
Steve_p: S03
we're back online...
obviously something setting $_ to the previous result
maybe it's a feechure.
it's just new syntax for old.
sync was atomically
resync was retry
maybe { ... } maybe {...} was {...}.retry_with{...}
that is, Haskell's orElse
so it should compose fine
round robin, I'm given to understand
correct
that's why I was trying to find a correspondence between sync and resync
hard to say now--she's presumably on an airplane to Boston.
TreyHarris: that's the intent.
though it's possible that =&lt;&gt; is going to change to =* or some such, now that we have the Whatever type.
=&lt;&gt; was really a kludgey special case.
yeah, that's a major suckage at the moment
I would imagine that two independent roundrobins in the same transaction would need to try (eventually) the cross product of all the possibilities.
not sure how that would be implemented, or how it composes though.
but maybe doesn't autowrap itself in a transaction in the current syntax.  That's explicit with sync.  If we violate composability of maybe inside that, then it can be an error.
but I'd rather have the atomic scope explicit.
my earlier remark was a misread of your example.
that's more like
sync { maybe { ... } ; maybe { ... }; OTHERSTUFF; maybe { ... } ; maybe { ... } }
that is, what if the maybes aren't contiguous within a particular sync
are they separate roundrobins that do a search for a solution
like /(a|b)(c|d)/
only they just keep cycling instead of failing at the end
actually, I think the contiguous maybes aren't allowed to have ; between.
it would be like saying if 1 { 123 }; else { 456 }
yes
good.  this is something I'm not a complete expert on...
I'm just the user interface guy... :)
enjoy!
audreyt: note, this last checkin probably has broken evalbot, since its name has changed from evalbot.p6 to evalbot.pl
on the bright side, t/pugsrun/09-dash-uppercase-c.t and t/examples/examples.t are back to passing.
seems to me that perl5/Pugs-Compiler-Rule/lib/Pugs/Grammar/Rule/Rule.pmc shouldn't be under revision control.
?eval 1+1
clkao: re Data::Bind, the call to the function is before the use Carp.  I don't know why the use Carp is that far down in the file.
it's not like it's trying to defer "require Carp" till first use, like some other modules do...
the internet is dead.  you'd think it was friday night or something...
I get my own utf8 back just fine.
so I think your font is defective...
apl backslashed circle
hot springs
it's apparently a roman numeral 10,000
except APL symbols, apparently...
"It does exactly what you want--it's just hard to explain what you want..."
must be one o' them thar meme thingamajiggers...
as long as there's a debugging switch that says "Please explain what I want here..."
I have a good feeling about this...
It's my fault!!!
that's not a space station--that's a moon!
only two?
The Perl 5 Comix layer...
okay.  I see you're on pacbell.net.  We're practically neighbors...
nite!
timings about right, just finishing my last smoke
yes, and you last checkins made no change in my 23 errors.
*your
can it support call() to next best candidate?
lexical?
I would imagine.
I'm more worried about the case of roles (Foo Bar) (Foo) where the first wants to defer Foo processing to the second.
in fact, there almost oughta be a way to say "call all the variants that match", on the assumption that (Foo Bar) only deals with the relationship of Foo and Bar.
I was afraid you'd say that...
MMD.*moose($b)
undef.*moose($b)
*.*moose($b)
I guess that means that for all normal subs self ~~ Whatever.  :)
I don't know where the min() came from.
I'm considering, but nothin's happening...
I don't see why this isn't just an argument for MMD...
of the non-CLOS variety...
sorry.
dduncan: should I wait for more checkins before my nighty-night smoke?
I seen it.
eta?
I'll wait.
'nite!
k
smokin'
results in .5 hr or so.
if anyone cares.
course I'm only testing the Haskell branch...
yeah, but I get scared when I see the prereqs.  :)
and I'm not sure which of 'em should come from CPAN, and which from pugs/
true 'nuff
reconfigged, I presume.
mine's just standard Fedora Core 5 perl, pretty up-to-date via yum.
today is tomorrow now
or vice versa...
so good morning &amp;
ajs_home: commit bit on its way to you
ajs_home: please add your name to AUTHORS as first checkin.
I guess it depends on whether you think "ext" stands for "external" or "extra"...
I think that would be a recipe for disaster...
yes, saw that.  though some of the from_perl6_rules tests were knocked out because they were for testing Perl6::Rules, TheDamian's old module, if I recall.
np
I think subsets of Perl should be called Perk.  :)
"Perl"--
maybe with a modifier saying what's left out.
so Perl-u is no unicode
*Perk-u rather
And Perk-u2 would be missing, er, both Unicode and threading...
Perk-abcdefghijklmnopqrstuvwxyz would run on nanobots
using a tree structure to represent multiple dimensions of concern is always a bit problematic...
and 3rd party is more about licensing, I thought.
let's just put everything in an RDBMS.  :)
yes, I think the absence of feedback is actually good in this case.
nobody could think of anything to complain about. :)
nothingmuch: I've updated S03--so tell me if there's something there that I should clarify.
it's pretty much what we discussed.
pity about the rest.. :)
k
there's always nits...
?eval 1 == 1
not such a crazy idea
?eval (1 == 1) + 42
or are you asking for Icon's semantics?
I don't like those...
yeah, that's Icon's semantics...
except they call it "success" rather than truth.
it might well even work that way underneath, by my experience with Icon tells me it's a lousy thing to try to get newbies to understand.
s/by/but/
me having been a newbie once trying to understand Icon...
Yeah, we use "or" to return things other than booleans all the time in English.
but most of us don't use &lt; to return $b but true
hmm.
semblances can be important.
that's why I dissemble frequently.
I always pretend when I patch synopses that the implementation will just naturally follow along without effort.  :)
If I thought too much about how *hard* some people are working on this, I might get to feelin' guilty or something.
instead, I sort of perform the Jewish mother trick: "that's okay, I'll just sit here without Perl 6 for a while."
now you want to be a non-commercial pilot, or a commercial non-pilot?
me, I'm a non-commercial non-pilot...
maybe that's why they gave you the special pat-down treatment at the airport...
but hey, I have a friend who claims she's an anarchist...
no, but he did.
that's okay--ingy's good at taking responsibility
grep?
I don't think I've worn a pink shirt for a year or so...
you don't have a pink dress?
I don't know a tartan from a tartar from a tart.  Well, okay, I can recognize a tart usually...
sure seems like a Friday night...
It has to tell bad Muppet jokes I think.
no, every bad joke is like a muppet joke!
hrr,hrr,hrrrrr
we'd like to thank our special guest tonight, nothingmuch.
but we won't.
hard to simulate a saxophone playing the wrong note though.
I'm op for it if you're op for it.  har har har
the Mupbot Show
I try not to anticipate fun with exit rows...
but do you understand English well enough to read this card?
but can you follow spoken directions?
or any directions, for that matter....
I expect the clod sitting next to the door to open it and let in the fire...
flight's at 10:50, or boarding time?
they're shouting vewy, vewy siwentwy.
well, I'm gonna go off and be boring now, so have a good flight, where good is defined as not getting either too wet or too hot.
dduncan: thanks.
theorbtwo: fleeing now, thanks. &amp;
well, :dontignorepatternwhitespacebutusetomatchrealwhitespace seems a bit long...
used to be :words, but that's differently opaque
also considered something like :rule to mean "use the semantics of rule whitespace", but that's also rather abstruse.
if they have to look it up anyway, might as well use something that isn't a word.
so you can google it at least.
but it's also possible we just haven't thought of the right word yet.
I do rather like the utility of ss/// though, just from a typing point of view.
trouble with using ws in that context is that it's specifically _not_ referring to the &lt;ws&gt; rule, but to the ws in the regex.
it's just an accident that $rule ~~ s/&lt;ws&gt;/&lt;ws&gt;/, as it were.
and that's why we decided to call it something more like s:sigspace where that really means :rxspace&lt;ws&gt; rather than the default :rxspace&lt;ignore&gt; or p5's :rxspace&lt;sp&gt;
but as I say, we haven't really nailed this down in concrete.  er...
it'd be pining for the pine box, or some such.
but it's not nailed shut yet.
I just like the reduplicative ss/// to mean "match multiple things here".
It's just a pity that "rule" doesn't start with "s".
or that "token" doesn't start with "ratchet".  :)
and basically, I think ss/// is the most common use case (at least on irc), so whatever the adverb is, it has to start with 's'
and it's about time to give ms/// a different meaning too.  :)
though it takes away from the reduplicative argument that it's not mm///
um, make that ms// and mm//
hmm, though :m isn't taken...
s:m has a small problem though...
so if we call them mules instead of rules, we could have :m short for :mule :)
there's a lot of things we wrote off in P5 as "not the language's fault".  It was a rather convenient excuse at times.
but there's always tradeoffs.
but I don't think we could persuade people to call them ratches instead of tokens...
ratchets.  can't even type it...
rats maybe...
so we still have tokens ratcheting and rules sigspacing...
dolmans: then it's a bug, I expect
I note that for (1,2,3), (4,5,6) -&gt; $x { say $x }
seems to work right.
howdy
stevan: but you've just proven that Perl *5* is the new Lisp...
I want it now.  Wah! Wah! Wah!
if that's not it, maybe something's blocking the http port?
bbl &amp;
I see no diakopter on openfoundry.  or do you have a different handle there?
there's a wilson_huangtw
could be.  I don't see an outstanding invite either, so maybe you need a new invite.
what's your email?  feel free to use " at ", etc.
if you didn't get an invite, what email are you looking at?
i think you need an invite from the pugs project.  hang on.
okay, I clicked the pugs box to add you to that project.  but I don't see a "wilson".  did you use some other id?
nevermind
yes, it's there.
you should be good.
np
dinner &amp;
it's customary to add yourself to AUTHORS first, by the way, in case you didn't know...
and if you did know, well, it's still customary.  :)
CPAN
so yes, PAUSE
your svn id would be in quotes as your nickname.
and your chinese or klingon name goes on the right.  :)
and there you are.  welcome aboard, or abroad, if you're from Taiwan. :)
re-dinner &amp;
audreyt: f(3) is an error.  hopefully detectable at compile time in this case.
Note that this is the \'type\' of a \'sub\', and has nothing to do with
subtyping.
Maybe we should s/Sub/Code/ on SubType, SubMethod, etc.
since they're VCodes, after all.
biab &amp;
you have c_undoBlocks in there twice
arguably you just want to put undo and keep blocks in the leave list with conditionals around them.
true.  probably premature optimization
on the other hand, maybe they want to interleave execution
something like that.  arguably most blocks won't have any of these properties...
goto label; repeat { ...; label: ... } while 1;
I suspect it's just Pair, but Pair does Hash, or some such.
on the other hand, maybe the intent is to transform into a Hash.
maybe, but if Type($thing) always constructs a new one, we need some way of saying that we don't care if there's a new one.
new Type can construct, and Type() can just ask for the interface one way or another.
so Type() would be a noop if it already supports the role
whereas new would force a new copy anyway
seems intuitive that saying "new" makes a new one.
and the longer thing is more work.
after $a := Type($b) we don't care whether $a =:= $b
or whichever one it is...
anyway, I think %$pair is Hash($pair) and not Hash.new($pair).
?eval my $pair = :when&lt;now&gt;; say $pair.does('Hash');
yep.
either that, or .does is hardwired to return True.  :)
?eval my $pair = :when&lt;now&gt;; say $pair.does(Hash);
?eval my $pair = :when&lt;now&gt;; say $pair.does(Int);
?eval my $pair = :when&lt;now&gt;; say $pair.does(Array);
whew
True is return value of say
?eval my $pair = :when&lt;now&gt;; $pair.does(Hash);
?eval my $pair = :when&lt;now&gt;; %$pair.does(Hash);
so it would seem
agentzh++
i've always thought of using classes as roles more like taking a snapshot of the class and calling the snapshot immutable.
what is noop?
why not the latter?
as long as you ignore subsequent changes to Moose?
I would think so.
hmm.
seems like we have two kinds of "does" here.
on the other hand, if a real role includes an attribute, it has to be handled by the class.
so maybe it's sane to just say does Class ignores attributes.
I dunno...
MEGO
could have something to do with it almost being midnight though...
Roles don't actually contain attributes.
they merely have the skeletons of attributes that the class sets up
we probably need stevan to hammer on this too.
I always install parrot, but I'm prepared to hand-uninstall it if I get weirdness.
actually, when I said "snapshot" I wasn't thinking of inheritance at all.
just immutability of the current class
but it's an interesting idea nonetheless
A12 speculates that roles can mix in inheritance sneakily already.
well, we have other containers that are immutable but whose contents aren't.
and we'd certainly like to have sneaky delegation.
yes, I'm just this role, but I actually delegate to this other object...
well, welcome to duck typing.
next METHOD is only going to find a method of the same name, but not maybe the same meaning,  but that's a red herring, yes.
my brain is never working 100% yet...
even with coffee
which is actually important for delegation-emulating-inheritance.
across languages, say.
we are in violent agreement.
wrestling?
I think you're confusing two different Jesses
hippo happo bithutththdi
you're what, 19 now?  :)
fortunately, years are not objects.
thanks
happy mulch
gaal: did you see my hate-mail about %?CONFIG  :)
%*CONFIG would be the global namespace...
anyway, things that can pretend to be objects with lots of fiddly bits could use to be top level in ? twigildom.
Think how often $^O is used in Perl 5.
needs to be huffmanly short.
thought maybe not that short.
s:2nd/t//
%?::('grumble')
certainly not.
we haven't even really decided whether authorities are really part of the version
use Foo-(1.2-Mike|1.3-Ed)
I really say really to often.  really!
*too
I like the :parrot&lt;mumble&gt; notation for that reason.
though presumably one could get away with :pugs(6.2.12)
assuming orderedness is preserved.
which it presumably is with built-in versions
but problematical with tutti-frutti versioning schemes.
could have string versions that are savvy about 1.2.3-anything
before - compares version, after compares string
gets you alpha and beta in the right order, anyway...
except it puts those after 1.2.3
1.2.3-alpha &lt; 1.2.3 &lt; 1.2.3+foo
but generally, i think string comparisons would have to be forced in some policy spot
1.2.3.-2 == alpha
1.2.3.-1 == beta
but that screws up using - to delimit authority.
maybe - delimiter is bad anyway.
1.2.3.-1@JRAND
OM
heh
1.2.3.-1&lt;JRANDOM KRANDOM&gt;
hard to fit into a filesystem.
is there a buzzing in the air?
wow, I think "use v6&lt;pugs&gt;" passes the P5 test.
and &lt; and &gt; are unlikely to occur in a url.
and - is likely to occur in a random version number from the wide world.
filenames containing &lt; and &gt; would be a problem though.
hmm.
on the other hand, we can write funky versions alreayd like
use Foo-('1.2.3.-1')-JRANDOM
maybe
P5 doesn't like ^
P5 doesn't like .
and it only sort of likes &lt;pugs&gt;, since it thinks it's a readline or glob.
looks like use v6-alpha.pugs; could work
but not v6.pugs, which was the whole point, sigh.
v6-alpha+pugs and v6+pugs seem to both work to P5.
assuming no -w
-w gets in the way of a lot of possibilities, sigh.
well, we could still make - part of the version in P6, and use bare v6-alpha in P5.
that's almost cleaner than using alpha as an authority.
use Foo-1.2.3.-42.1&lt;http://foo.bar&gt; still looks kinda good to me.
can always mangle the &lt; and &gt; for the filename.
I like the pillness of the authority.
well, I have to go do some archeology in my garage...
later &amp;
smokin'
she probably went back to sleep.  it's about 4am in Taiwan, give or take an hour
I don't know of anything like webgui.
it varies depending on residual jetlag, i think.
say all(1,2,3)
for each(1,2,3) &gt; any(@foo)
hmm
maybe junctions do something a little different in list context.
Damian originally had a .eigenstates method, or some such.
.values gives you the values out of an any or all, but after a comparison you just get booleans.
maybe list context can change that, or maybe each() can change it.
yes
might be busted at the moment though.
most of the tests in t/oo seem to return pugs: user error (no tag found) for me
on the other hand, my last smoke, they seem to have worked.
dunno what changed...
prove6 works better than './pugs -Iblib/lib'
so it wants something I'm not supplying...
doh, it wants blib6 not blib
class CGI::Application-6.0.0 { ... }
version is automatically part of the longname of a package or class
has doesn't go in the heading
class CGI::Application-6.0.0; has $.tmpl_path is rw;
would work as first thing in file
otherwise you have to put the has into {...}
TreyHarris: okay, have now specified meaning of "for any(@new) &gt; all(@old)" to dwym.
turns out grep {...}, @x can also be spelled any(@x) ~~ {...}
$class.bless( PROP =&gt; 42 ) is one way, assuming it has $.PROP or $!PROP already.
bless ends up calling all the BUILD routines with the named args you pass it, so each BUILD can pick out what it wants.
this is all described in S12, btw
or you can just say $!PROP = 42 after the bless.
$.PROP if you want it virtual
it's just the old "init" stuff that most OO languages have
but we already used INIT
it means self.PROP = 42
so if you're children override the .PROP, it does the right thing,
presuming that's what you want it to do.
depends on your abstraction level.
usually a constructor wants to set the storage directly with $!PROP
the ! being mnemonic for "don't do the fancy thing"
decommuting &amp;
it's a private variable, and not accessible to child classes.
you have to use $.found for that
children always use accessors
that's part of why $.found is really calling the accessor.
anyway, really &amp;
?eval $*OS
and we recently renamed them "pointy blocks" because they have more semantic affinity to blocks than to subs.
but yes, it's a syntactic distinction primarily
should be C&lt;=:=&gt; probably
does something need to be specced for Perl 6 for this?  (well, duh...)
?eval [1,2,3] &gt;&gt;+&lt;&lt; [4,5,6]
yes, couple days now...
that's why I mentioned it.  :)
[&gt;&gt;+&lt;&lt;] is fine
except you have to worry about list context
\m/ is the "pulling down the clothesline" operator?
you'll have to define infix:&lt;m/&gt; first...
hmm, culturally means different things though.
when you said "named captures", I was thinking "sub foo (\$capture)"
and was dubious...
k, I'll just do a lookbehind
or maybe I should have done a lookahead.  &lt;headscratcher&gt;
@foo = [\&gt;&gt;+&lt;&lt;]&lt;&lt; @bar
We've tried to keep the metas out of the sym table because if they're in there people will screw 'em up.
yes
so far we've only really allowed reduce ops
the mathematicians *will* screw up the hypers if you give 'em a chance though.
it's either that or complain bitterly.
we do have to have some internal way of doing syntactically magical reduces like [,]
or more semantically magical, I guess
but reduce is the one we already have an escape valve for
and there's a sense in which all the names of the available metaops have to be pregenerated so that longest token can win.
so I guess they all go in lexer table, if not sym table
in failures?
I think maybe I'll start a smoke?
that means yml is useless now?
whew!
still, have started new smoke to see how many more tests pass with hyper fix.
if we have [&gt;&gt;!===&lt;&lt;]&lt;&lt; in the lexer table it becomes rather easy to look up and carp about, since those are just magic hashes that can be used without the magic outside of regexen.
we need to be sure not to add any metaoperators that produce exponentially more lexer table entries though...
hmm, still getting:
ext/Benchmark/t/basic.t line 10,
and following
french naughtiness?
Updated to revision 12468.
I like triangulate as in "narrow in on the answer"
widening in on the answer?
produce is far to generic
*too
it's almost as bad as "scan"
yay
your meter doesn't scan.
and you're not allowed to rhyme with the same word...
Meteor?  Run!
howdy do!
is my alias for "svn up"  :)
I got it, which is why I didn't say anything.
because I'm kind.  :P
or is that type, or wtf?
unconditional lover's quarrels...
*lovers'
01:54 I think
yes, real [+] only lives in %prefix
ask 'em all, and STM will sort it all out
bbl &amp;
audreyt: cmp is not chainfix so you couldn't apply ! to it even without &gt;&gt;&lt;&lt;
but !&gt;&gt;==&lt;&lt; is also nonsensical, I think
if you mean &gt;&gt;!==&lt;&lt; you should write that.
right
&gt;&gt;!==&lt;&lt; would return a list of booleans
yay
I don't really have a feeling one way or the other about (x=&gt;42) yet.
or the decision to de-order is done lazily based on context...
like the meaning of *
sub foo (\$foo) { # can I here get the original ordering?
not suprising, since I keep boxing in all the parsers with strange ideas... :)
I suppose one could tag them so that you could at least sort them back into the right order.
or the named list is threaded through the positionals
I hate throwing away information...
is kinda like a generic Unix command processor
many Unix commands have ordering dependencies of various sorts.
sort, for instance
good, I can let my smoke run now instead of restarting it every few minutes. :)
emulate a log
length unpack('B*', $number) # base 2 log
funny way to write int()
you wanted $0
$1 is gonna match a lot of nulls...
a LOT of nulls
still thinking about the last thing you said, i suppose
I thought evalbot had resource limits, but maybe if it has delegated to pge they don't apply?
probably get the choice
actually, the manpages on setrlimit and fork are unhelpful
go ahead and write the test.  if you get a parsefail, slap eval '...' around it
yeah, not counting inside parens
*not* counting inside parens
an adverb outside parens doesn't modify an operator inside
yes, it just has to be where an operator is expected
in which case it becomes a named parameter for operator in question
hmm, could have said that better...
so anyway 3..(2+2):by(2) will become infix:&lt;..&gt;(3,(2+2),:by(2))
MacVince: dunno--I tend to use vim myself.  It's possible we broke it recently without noticing.
In which case, it would be good to have someone using it regularly.
everyone maintains everything around here.
so just whack on it if it's hosed.
we operate on the easier to ask forgiveness principle
well, that, and revision control.  :)
looks like renormalist has done most of it.
as far as I know it's manual.
if I see a comment go by and wonder about it, I just watch which files update in the next svn up.
does it not like \xFg or \x{FFF}?
I suppose whatever figures out variables needs to be taught about twigils.
probably can be considered a fossil.
(the false)
yes.
short for Bool::True and Bool::False, but "but" will intuit unambiguous enums.
well, actually, all imported enums are considered type names that just happen to represent one value.
in the lexical scopes where both exist, you'd have to disambiguate.
better than silently doing the wrong thing.
at least it'd be caught at compile time
sure
I dare say most module's enums won't be exported by default.
however, Bool is one that everone gets for free.  :)
yes, unless they lexically scope it, which is probably dumb most of the time.
but most imports will be of simple subs or types (incl enums), I expect
if you import a simple sub it hides all multies of the same name.
(lexically)
import is lexical by default in P6
almost everything in core will be multi
if you set up non-core multi in a scope, you generally do it with a "my proto".
but that proto multi can explicitly call outward if it decides to.
think of it as an exercise in brain plasticity.  :
:)
biab &amp;
araujo: did anyone send you a commit bit yet?
that's no excuse.
all of us are learning.
araujo _at_ gentoo?
TreyHarris: they execute once at class construction time.
sorry, flakey connection
well, I'm in a remote location that just happens to have wifi, sort of
\
yes, pseudo assign to attrib is suppoed to happen at BUILD gtime
A12 explains better than S12, probably.
araujo: still waiting for openfoundry to log me in...
araujo: commit bit is on its way.
traditional first checkin is to add your name to AUTHORS
and then you're emotionally committed.  :)
checkin philosophy is to ask for forgiveness rather than permission.. :)
have fun!
seemed kinda slow to me.  :)
lambdafolk generally seem to catch on about as fast as anyone...
we consider differences to be features around here.
sure, I've learned Haskell several times already...
which timezone are you in, araujo?
the other lambdafolk are scattered about the world, so around the world, so you can usually get advice here most times o of the day o rnight.
sorry, relocated to better reception now, so not typing blind anymore...
the place is infested with those...
though in both of those places most people will be more familiar with Perl 5 than Perl 6.
==&gt; and &lt;== also theoretically make feeds
but yes, zip(@a;@b;@c) is a zip of 3 feeds
yes, but the multiple feeds get flattened unless bound to @@
9 I think
I don't know why it should be a syntax error.
woops, is there now.
zzz &amp;
btw, not expecting a fix soon, but my Test.pm.yml makes my pugs segv, even if complete tree is regened.
I can run the part of it that doesn't use Test.pm :/
since sometime yesterday
I'll try the specific regen, but certainly a full make won't work.
complains about unexpected " at line 298
yes, print "not " unless $cond;
print "not " unless $cond;
apparently from some previous line
I don't believe the error message shows with a full make, but a partial .yml would explain the segv...
./pugs -c ext/Test/lib/Test.pm works
fails if I put -CParse-YAML in
compiling
now I get pugs: user error (no tag found)
same parse error, unexp "
looking at prelude now
blew away both .pm.yml files, same problem
biab &amp;
audreyt: no output
yes, unexp " line 298
nothing
not surprising, considered I blew it all away and redownloaded
*whistles*
good morning, hope you got more sleep than I did last night...
audreyt: still a segv
audreyt: in fact, the .pm.yml I generate is identical to the one you sent me
maybe I should just try a reboot.  could have a corrupted memory image persisting or something.
biab &amp;
:P
reboot didn't help, so if something is corrupt, it's on the disk.
will now upgrade 6.4.1 to 6.4.2 (available via yum)
(pity they don't have 6.5 yet...)
yeah, I know, but that's work. :)
but if my ghc is corrupt somehow, upgrade will fix
agentzh: allow me to also say that I'm exceedingly impressed.
It might be related to the game of charades.
but culturally I think it's a form of golf
"I can express that idea in fewer words than you can..."
it's meta-info, so doesn't count. :)
there's a one-word metaform from Mr Rogers: "Can you say ___?"
It's a form of intellectual snobbery to be able to sum something up in very few words, I think.  But you have to call your shots, like in pool.
the upgrade seems to have fixed my problem.  so must have been disk corruption, I guess, unless 6.4.2 fixed it somehow...
well, maybe it was just a cosmic ray.
Limbic_Region: yes, they were mostly place where P6 requires whitespace to keep postfixes straight from infixes or statement blocks.
if($x){.say} is illegal two ways.
if($x) parses as a sub call.
and if($x){.say} parses as a hash subscript on the sub call
gee, I've never heard that sentiment before. :)
I was actually kind of delighted to see how much clarity it forced on the golf examples.  :)
audreyt: did you see my spec changes to "is" yesterday?
et tu, audrey
the BUILD in the role
don't want to reBUILD the existing object
I was just channeling you. :)
et three
yes
MAIN binding works the same way
oh, it's [,]%param now, now *%param
*not
[,]now
*not
:)
it's often easier to fix the bug than to remember to fix it later.  :)
howdy.  Jet lag hits.  --more--
you lose 20 hit points.
I'd be better off if I hadn't stayed up the night before last doing JIT speech.
but I knew that's when I'd be awake
no, it's just a sublanguage like rx//
which is how you do a sublanguage...
morning audreyt
we need to undo prefix:&lt;*&gt; at some point...
rand*10 should have given a "two terms in a row" error.
pity that won't help for rand+10
grepping for \*[$@%] only gets 2324 hits
mostly sigs, I expect
weird, splat.t has things like "my $b = *@a;"
./src/PIL/misc/prelude/Array.pm is full of splats
heh, found some in the specs too...
bunch 'o stuff in ext/ isn't gonna parse...
I'll whack on the *'s when I get a chance.
lot's of superstitious *@foo passed to a slurpy *@bar
*lots
down to about 200 hits now
Perl6::Bible never was authoritative in that sense...
X as in windows?
well, I use X but I wouldn't really count myself an eXpert
we're very glad to share advice whether we know anything or not.  :)
is the X process still running?
if X isn't running, restarting X would fix it.
might already be dead or hung.
yes, but they might already be hosed.
what kind of linux are you on?
dunno whose X Ubuntu uses...
have you tried switching virtual screens with Ctrl/Alt+numbers?
I mean ctrl/alt/function
sometimes switching to a different virtual terminal and back can clear it too, is all...
yeah, if the session manager was the problem, that could fix it.
heh, it's, like, Friday night...
I like the fact that they're visually distinctive.
as far as I'm concerned they're no weirder than a lot of other operators.
biab &amp;
polymerase chain reaction
audreyt: ideas on how soon @.foo() syntax will be supported?
k
hmm, my make smoke hung on ext/Perl6-Grammar/t/basic.t, not using any CPU.  Looked like an infinite sleep or something...
it's waiting for a subprocess:
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
larry     2876  0.5  0.5  12268  8536 pts/7    S+   09:33   0:00 /usr/bin/perl -Iperl5/Pugs-Compiler-Rule/lib -MPugs::Runtime::Match::HsBridge -ePugs::Runtime::Match::HsBridge::__CMD__
maybe it's finding an old installed Pugs-Compiler-Rule or something...
nope, removed those, and it still hangs.
probably just getting out of sync pipewise.
as with parrot, I'd much rather run an embedded PCR than a piped one...
I should not have bragged about my server staying up for six months...it just crashed.
it's just a thinkpad.
ghc 6.4.2
and I always compile optimized
because I have enough memory to do it fairly rapidly
(1.5Gb)
(also I'd mostly recompiled before from when it was hanging...)
but it's the thinkpad obra++, so I think it came with some extra TLC.
s/,/gave me,/
anyway, thanks for the fix! putter++
audreyt, TreyHarris: I don't think any of those are an adequate looks_like_number.  What you've got is more like looks_like_number_in_canonical_form.
if malformed numbers return undef but Num, (+$x).defined could be looks_like_number
I mean, if you have "123foo", you get Error("malformed number") but 123 or some such as an unthrown exception.
and by the unification of errors and warnings we could make it continue working as Perl 5 does.
it's an "unthrown warning", as it were.
main problem from a p6-on-p5 perspective is that it requires that you either have real continuations or at least run all your exception handlers before unwinding, neither of which is native to p5.
hah
the speed of light is a rather large constant...
...even when it's 1
like any warning?
or potential warning?
you'd have to override longjmp somehow, or avoid calling it in all the places it's hardwired into perl.
well, you'd want to avoid that on the other end too, but that part's easier.
just don't use eval {...}
--&gt; zzz
using the built-in routine is the safest approach.
I learned not to try to second-guess the run-time in Perl 4...
depends on what it's for, I suppose
just "return True" should be adequate.  imported enums don't have to be qualified unless there's a collision.
on the other hand, 1 knows what to do in a boolean context.  :)
the only real difference is what happens in string context.
and that raises the question of how we convert "False" to Bool::False
looks_like_boolean()  :)
so does Bool($string) return a different value than ?$string does?
?"False" would be true
at least according to p5 semantics
I guess we really haven't thought about the generic problem of converting the string names of enums back to enum values.
eval "
seems like overkill
but after declaring your DayOfWeek enum you'd like to be able to say DayOfWeek("Friday")
or maybe it's a hash, so you can install abbreviations.
actually, DayOfWeek:: is already a hash of names
so it's just DayOfWeek::{$d} to get back at least to the subset type
and I suppose the type numorstringifies to the appropriate value.
could autocoerce for numeric enums, but that doesn't work for stringy enums.
since both values are strings.
I just meant there needs to be an explicit way to convert
when you know you have the external form rather than the internal
true 'nuff, MMD would probably sort it out
I am being assailed with dinner. &amp;
MY is as first class as any other package, but is considered immutable once its scope is compiled.
the package name is really MY::
why not?
seems to me that's part of why we flattened the namespaces to not have here-to-end scopes for the lexicals, among other things.
You don't really need an initial :: if there's one elsewhere in the name in most places.
on the other hand, I've been struggling to keep :: free as a postfix so we can have $proto.:: and get the corresponding package for the prototype
that's also why we require GLOBAL::&lt;$foo&gt; and not just GLOBAL&lt;$foo&gt;
the latter would be trying to subscript the type rather than the package.
no it doesn't, I don't think.  it has to be .'::'
I fixed that already.
several days ago
done
the most interesting part of that fix is that it now allows ."foo$bar" kinds of method calls.
and a way to disambiguate .+ things from .'+' things and the like.
.+foo vs .'+foo'
that's kind of ambiguous with .prefix: &lt;moose&gt;
unless the syntactic categories have special keywordish status in that location.
I think so.
I don't think listop is a grammatical category
yes, though the official listops are supposed to have a space after them--not sure exactly what decides to enforce that.
probably an equiv to an existing listop.
or maybe the *@ implies that, I dunno.
okay, the *@ now forces listop precedence by default.
no, you'll be asked if you would like a commit bit.
would you like a commit bit?
we're still having fun with it.
impatience is a virtue...
pugs is a lot of fun if you'd like to play with it.  we're about to put out a new release in the next few days.
night!
sounds sane, to the extent that I can detect sanity at this time of night...
feel free to whack on the syn
zzz &amp;
audreyt: see previous
the Container has a list of kids, but when I call $kid.visit() it ends up calling the parent's visit method, albeit with the kid as invocant.
I wonder if eval(:lang&lt;yaml&gt;) is defaulting to the last dispatcher class it saw.  The bogus classes are properly named via .WHAT, but dispatch to Container despite not being derived from Container in any way.
anyway, I was tearing my hair out trying to understand how Perl 6 was reading my mind and installing derivations for me.  :)
huh?
even when explicitly smd with extra arg?
but even with MMD failover, it should have tied between Leaf::visit and Container:visit
but even without the failover it's calling the wrong visit on the first Item.
because Item is explicitly derived from Leaf.
wolverian: something like method true () is deeply { Bool::True }
maybe it's multi Bool (MyType $x) { Bool::True }
and multi Num (MyType $x) { 5 }
with maybe some "is deeply"s thrown in there
yeah, that's maybe a different approach to "is deeply"
my Foo $x = context($y);  # explicitly do some coercion implicitly :)
my Foo $x = force($y);
my Foo $x = dwim($y)
my Foo $x = *($y)
multi * (MyType $x --&gt; Num) { 5 }
that's almost cool.
decommutationalizing &amp;
yay
audreyt: I'm more inclined to try to keep the insides of &lt;&lt;...&gt;&gt; as close as possible to shell quoting so that it's easier to write portable "shell" scripts even on Windows and such.
back to zzz &amp;
@messages
it's ugly, it doesn't compose like &lt;...&gt;, and we didn't remove it.
qw// still works, as does qw ()
but qw() itself looks like a function call, so that's what it is.
sure is.  just not in Perl
one could say that about a lot of thins. :)
our goal is to surprise p5 programmers on a surface level and delight them on a deeper level.
well, gotta run, and don't know if I'll have connectivity for the next N hours...
(taking Lewis to a quiz meet at an unfamiliar church, so don't know if they have wireless...)
yw!
afk &amp;
audreyt: see above
a "realclean" doesn't help, nor does making fastprof.
blowing away and restoring the HsSyck and HsJudy subtrees doesn't help.
I'd really like to be able to figure out why my 10 hr program is 98.9% GC.
which means it ought to run in 6 minutes...
thank!
have -Ofun
maybe it's time to install 6.6, sigh...
yow, my last smoke took 20 minutes longer than my previous one.
hi
@tell audreyt something that got checked in last night took my smoke from 48 minutes to 68 minutes.  Pretty sure I didn't have anything else running...
nap &amp;
smoking r14339, after much hassle getting recompiled.
there's something out there in some subdirectory that still wants HsJudy that isn't cleared out by realclean.
don't know offhand which subdirectory, but src is a likely suspect.
anyway, blowing it away and re svning up seems to have fixed it.
also commented out some Judy stuff in Makefile.PL, not sure whether that was necessary or not.
lunch &amp;
avar: sure, see S06:1128 "Unpacking array parameters"
yay, my 1st 100%
I had a lot of trouble rebuilding.
on Linux
my error was that it was still trying to link in HsJudy
eventually I blew away src/ and several other subdirs and re svnup'd
something isn't getting realcleaned I think
but I didn't have the patience to chase it down.
well, I don't keep anything of my own in the subdirectories as a matter of policy so that I can do that.
it was *probabl&amp; src
*probably* even
but I also blew away several other dirs so I can't say for sure, and it kinda sucks to get all the way through and have it fail again
I think "realclean" fails the DRY principle.
just as I think keeping a list of force_todos in a separate file is a recipe for disaster.
I know there have been systems that actually tracked what files were produced by the various subprocesses in a build so they automatically know what to clean up.  Unfortunately make has always been a bit too simpleminded that way.
we'll I've done that, and regretted it.  :)
*well
I did discover that if you blow away blib6 but not ext, you end up having to go through and remove all the pm_to_blib "touch" files.  :/
another example of braindead makery...
did you install ghc 6.6 in one of your subdirectories?  :)
I see.
not likely--it's in support of some proprietary hardware.
unfortunately the people paying me to work on a real problem would have a real problem with that...
across the street from Google.
links okay?
...cant...breathe...
huh huh huh huh
well, mine went 100%
couple minutes slower than my previous run, prolly statistically insignif
given there were other things running on my computer
well, she's got one day if so.
it seems pretty solid from the Linux perspective at least.
probably most of the remaining work is changelogging...
the eqv thing
or maybe it's just not reading the Perl 6 code in text mode...
isn't Windows supposed to translate crlf to \n for you?
then why did we add binmode to Perl?
well, but that's the opposite problem.
but if you look at the string in Perl 5, it just as a newline.
s/as/has/
but it seems like Haskell isn't maintaining a \r free zone.
looks like slurp is defaulting to binary rather than text.
whatever it's defaulting to, it's not the same as the parser...
is the \r on the expected or on the actual?
you can't deduce this from whether it's in the .t file
oh, so the newline policy is wrong on the file maybe?
hmm.
imagine a beowolf cluster of pugses...
when will Haskell get GPU support?  :)
okay, how 'bout cell support? :)
IBM cell
and PS3, is it?  think so...
I think it'd be cool if ==&gt; could feed cell processors on a PS3
yeah, more for pipelining than S
SIMD
or so goes the theory.
it's likely to be considerably milder than the stuff you're taking, so it might just have no effect.
postassignment?
you mean other than the main one.
seems like it should be pretty atomic to me.
durn monads...
well, there you have it.
now if only we had real quantum computers...
:)
I'm certainly on record as saying we're designing Perl to be better than we know how to make it.  :)
works for me.
smokin'
yes, that's all part of the hyperpromise.
more likely than those are warning control exceptions.
depends on whether some CONTROL block somewhere suppresses them.
could have a pecking order.
so last always beats next, for instance.
I suppose if a hyper is going to produce a lot of identical warnings, it would be friendly to try to coalesce them a bit...
unless they include the data, in which case it gets harder to factor out the common parts.
as I said on, I think, p6l, exceptions within hypers are a good reason for unthrown exceptions.
still on all_parse.t, grumble...
gotta get up early tomorrow, so likely to turn in soon.
anything else on your mind?
you're welcome, I hope. :)
zzz &amp;
will try it here.
removing if x -&gt; $y {...} seems to have made no difference at all.
@tell audreyt removing if x -&gt; $y {...} seems to have made no difference at all.
audreyt: no, but feel free to steal from anything I've said before, or from anything you think I might say in the future.  :)
"Optimizing for Maximal-Order Perl"  --Dominus
generally most such terms are transliterated anyway
really depends on the culture and on the field of endeavor.  in Japanese, you'd be in trouble in chemistry but not in comp sci, for the most part.
simultaneous translation, I presume
easy things easy and hard things possible is very much like a food pyramid...
'course, the problem in Brazil is that they think that the base of the pyramid should be meat...
lunch &amp;
lexical scopes are very important for any language that aspires to be multiple languages.
it's entered into the package as soon as the compiler knows about it.
yes
not explicitly, but presumably 'no' could be made to work.
:my&lt;foo&gt;, :no&lt;bar&gt;
import to nowhere...
does Mammal[:no&lt;placenta&gt;]
:O
Trey_Harris: yes, it should do what you expect.
er, wait, no.
P5 doesn't introduce the new variable that soon.
now you're confusing me...
been in P6-land too long, and not long enough...
only meaning of unary | anyway
infix | is of course junctional OR
It's a junctional OR that gets coerced to a set.  :)
yah
so what's the js emitter gonna do with 'use v5'  :)
no
looks pretty good to me.
go ahead and check it in.  we operator on the forgiveness-rather-than-permission principle around here.
*operate
I believe so
might run util/add-svn-props.sh on it too
that would probably be more than most of us have done. :)
we just don't use the word "should" around here terribly often...
I think the regex part was mostly already there due to :ratchet emitter
I was wondering last night whether we need to partition out t/ into MP6 and non-MP6
not without running it through the P6-to-MP6 translator.  :)
more like p6 ast isn't yet a proper superset of mp6 ast.  :)
I predict someone will eventually write P6-to-MP6 just so that they can run P6 on their nanobots.  Who cares if it's "slow" if there's quadrillions of 'em running at molecular speeds....
It's possible the gray goo catastrophe will be programmed in Perl...
talk about disruptive technologies...
anatolyv: the ordering in question is supposed to be how the magical hashes are ordered within the &lt;%foo|%bar|%baz&gt; construct
S02 is obviously not terribly clear on that point.
anatolyv: that will be up to whoever writes the grammar.  the specified mechanism is local, so global ordering would be by policy, not by technological requirement.
diakopter: you lookin' fer me?
diakopter: have sent your friend a commit bit.  please tell them it is customary to add yourself to AUTHORS as first checkin.
however, if they want to post incognito, I can understand why some people might be in that position.
audreyt: that's an interesting question that I don't really have an answer to.
we have * on signatures, and I've mumbled a bit about putting * on the end of a short list to lengthen it.  Maybe Seq defaults to Seq[*] somehow.  and we distinguish Seq[Int,Str] from Seq[Int,Str,*]
dunno
the type passed to Seq[] is sort of an inside out Sig
seems worthwhile, but I'm not a type theorist...
the other question is whether it'll slow things down, either performance or in getting P6 out the door.
~Str?  Do you mean ^Str?
?eval ~Str
seems sane
need to go help cook dinner before mother-in-law pitches a fit...
well think about Seq a little.  &amp;
*will
have the appropriate amount of fun...
have a smooth sequence...
&amp;
I know several good ways not to write an interpreter...
there's no harm in asking
I think whether it's a win would depend on how the data is structured.
you could lose all your performance gain just trying to get all your data lined up to feed to ADD or whatever
unless the data structure was already conducive to vectorizing on some level
Samb: well, so does Perl 5...
you can spend a lot of time trying to optimize function calls away, and then discover that that's not really what's slowing you down in a modern processor.
usually cache behavior is the overriding factor these days
it's architecture dependent how much they slow you down.
they were very slow on a Vax, and a lot of the design of Perl 5 reflects that.
again, highly architecture dependent.
often "leaf" calls can be very fast if they can just switch to a throwaway register set and avoid all the save/restore
On a vax you try to avoid lots of little functions, but on some modern architectures you actually try to maximize that...
especially if a heavy factorization manages to get all your common instructions in cache
the differences between in-cache and out-of-cache performance tend to dominate these days.
for Perl 6 we're looking more toward explicit forms of parallism, using GPUs and cell processors and such
some of that syntactic information would help with a setup like you're proposing, even on a single-thread machine
because we're introducing syntax for explicitly saying you don't care about the side effects or interactions between parallelizable operations, such as hyperops
the problem with saying anything general about interpreters is it's so highly dependent on what kind of programs and data you feed them.
the usual dictum of "profile first" doesn't really help.
because you don't know which parts of your interpreter will be in the middle of someone's tight loop.
about the best you can do is design things not to rely on any one particular model, so you can substitute in a different model under different circumstances.
but that tends to work against having a consistent semantic model, such as universal continuations and such
at least with a CPU you pretty much know what you're working with down to the metal.
but an interpeter is likely to be ported to other architectures.
it also really depends heavily on what kind of programming you're going to do on top of it.
functional programming puts an entirely different set of stress on your interpreter than OO does.
depends on your model.
there's probably an ecological niche for such an interpreter.  don't know how big it is though.
such as you are proposing
old-time biologists tended to think of ecological niches as continent sized, but most ecological nices are limited by other factors than geography
some of which are not predictable, such as other species' development
you can't know everything.  at least, I've been trying for more than 50 years, and haven't got there yet...
at the end of the day, most of your knowledge won't tell you how to trade off all the facts you know
you try something, and it either helps, or doesn't
then you try something else
that finite amount of information is provably a superset of your brain
it's not clear that the state-space of the universe is encoded primarily in what we think of as particles.  nevertheless, we think we know how much information can be encoded in a particular volume without turning into a black hole.  :)
course, it's kind of an interesting question whether someone is thinking of our universe as an experimental interpreter...
God was your stat teacher?
we only did ten flips, but I flipped all heads.  thought I was in R+G are dead...
except he hadn't written that play yet...
well, Scott Card thinks about a lot of things, including drama.
seems a lot like a Friday night...
you must use $!nick in a BUILD, not $.nick.
BUILD routines should not be calling virtual methods.
on the other hand, I'm not sure that part of the spec is implemented, so something else might be going on...
can't tell until my pet peeve gets fixed...
every time it says "No compatible subroutine found" I want to ask "compatible with what?"
something to do with the rw probably.
maybe the rw makes it autogen a different method that hides the one that works.
is there a derived class involved?  that could slurp up a virtual method away from this class.
and then fail to bind properly
root4o: it can do either depending on where you put semicolons instead of commas.
Limbic_Region: interesting.  I note that the problem itself doesn't say the numbers have to be contiguous, though the example seems to indicate it.
there are many sets of 4 numbers on the same straight line that aren't in one of the 8 cardinal directions
actually, it limits it to vertical, horizontal, and diagonal, but the continguity is still somewhat implied by the example.
anyway, I'll whack on the P6 version...
np
Looks like a good way of showing off Perl 6.  I just wish XX was implemented...
yow
the X*X cross product metaoperator
X and XX are just common shortcuts
but maybe it's not needed here, since the first line wants to [...] each 4 nums.
but I'm sure we can hyper some things.
S03:1708
he doesn't realize there's a min operator and [min] either...
you can click the problem list on the left and get to 11
my solution uses max instead of the unimplemented [max], and prints in E notation, albeit with sufficient precision.
also haven't thought about hyperizing yet, but I'm being dragged out for a walk by my health advisor.  :)
yes, but not immediately.
maybe I'll just put up my prelim version now.
Gothmog_: thanks, I used your version in a followup that throws a lot of fancy tricks at it.
the last statement now reads:
say max gather {
for ^@data XX @dir {
}
}
the hyperop is actually bogus according to current specs though...
all I'm saying is that if there is a Char type, it gets treated as Str.
yes, it's the abstract container of the largest possible character in the current Unicode level.
If you say .chars, it's the count of those abstractions.
Text implies bigger than Char to me
bit strings are Buf variants, and Bufs are abstractly composed of integers
don't really think so.
subset Char of Str where { .chars == 1 };
strange.  svnbot I guess, but then it shouldn't be marked PST
bbl &amp;
"foo"."chars" is specced but not implemented.
?eval "foo".$('chars')
?eval my $bar = 'chars'; "foo".$bar
.$() should work too, but doesn't
again?
hyper is specced for methods, but only considering .foo as a postfix
by itself . is not an operator
there is no &gt;&gt;.&lt;&lt;
part of why we allowed ."foo" is that it prefers prefix:, so ."+" means apply prefix + as postfix.
there is no _ operator either
what do you think _ is?
not for about 3 years now...
it is ~ for that
and &lt;a b c&gt; X~X &lt;a b c&gt; would not be &lt;aa bb cc&gt;
&lt;a b c&gt; &gt;&gt;~&lt;&lt; &lt;a b c&gt; would be that
and X is short for X~X
we need a new table of the operators periodically.  :)
diotalevi: bit resent
assuming you want it sent to the same gmail address...
commas are required after all normal arguments, and that includes the first argument to grep and map and such now.
well, not after the final argument, of course...
anyway, blocks used as arguments are no longer magical.
yes, at the beginning of Perl 6 they were also magical.
but we decided it was more important to have consistent curly policy
especially at the ends of lines.
it generally means you never have to remember which blocks require semicolons after them and which don't.
comma in grep and map was a small price to pay for that.
after all these years, I still can't keep it straight in C which kinds of block are which.
and it was rapidly going to become untennable in a language that can be extended with new block types.
untenable, even
many of the seemingly weird rules in Perl 6 serve similar extensibility purposes.
the fact that postfix requires the absence of whitespace, for instance.
perlDreamer: that's cool.  the smartlinks are in a state of partial completion currently
the basic realization was that perl 6 is not one language, but many
and many places where Perl 5 was busting at the seams can be looked at that way.
perhaps more like IndoEuropean...
indeed.
diakopter: yes, that is the intent
use APL;
!!&amp;*&amp;R*WER&amp;W*ERQ(Q@&amp;#$%($#$
that was just unrelated line noise :)
cat sat on the keyboard, and cat's hind end doesn't know APL...
anyway, point is that "all is fair if you predeclare", and we realized that means your current dialect.  In fact, I realized this for Perl 5, but did a lousy job of designing for it.  Good enough to inspire CPAN though...
if it only gets everyone to add a version number and naming authority to every longname, that will be progress.
all source filters should at least be refactored to use grammar munging and macros.
the business of reparsing Perl N times, one for each source filter, is for the birds.
prototypes also needed a lot of fixing.
mainly by scrapping them and putting in a real type system and MMD
and making evaluation lazy enough not to commit to whether @foo will be in scalar or list context till binding time.
?eval 1+1
-&gt; is not an infix
?eval @a = ("one",  -&gt; $x { $x**2 }, "three")
it means you have to put a comma before it.  :)
It's using non-breaking space there.
makes sense to me.
using nbsp there makes the pod a lot more readable than other ways of preventing people having to read about Perl
5
or, for that matter, Perl
6
on the other hand, I recently discovered that PerlMonks translates it to ordinary space instead of &amp;nbsp;, which I find irritating.
gotta go cook dinner &amp;
I'm still wandering in and out while I try not to burn dinner...
riffraff: yes, that is correct.
Juerd: I don't think turning Perl 6 into a 6-letter word is hazardous to their word-wrap policy...
It's just they don't really believe in Unicode yet.
yes, it should
except, you still have the problem that the return value is sorted as a string
I don't think pugs recognizes that {+...} sorts as numeric yet.
so length 11 sorts before length 2
It already is, I think.
well, maybe not.
needs a "use utf8;"
no, wait, that's only for the literal I put in.
should work already on normal data from the outside...checking...
need to make sure the filehandle is reading it in as utf8
if the smart links are patterns, then use . maybe.
riffraff: I think most of that is waiting on MO integration
pugs people prefer commits
that's just a Hash/Any
And, um, yes, I'm pretty familiar with the Synopses...
I know many of the authors...
yer welcome twice then.
lots of surprises, I don't doubt.
why didn't it require a "my", I wonder...
?eval $x = 1
maybe it's non-strict
used to always complain without my
| would be a no-op there
the | operator really only makes a difference when interpolating into a capture context that has to lazily decide where the argument boundaries are.
luqui: I've been thinking a lot about Num semantics lately for some reason.  :)
there are various approaches we could take
I think we should generally steer the naive user away from having to think about Rats.
but that doesn't mean we can't have the available
either lexically
or possibly Num semantics do "lazy division".
much like Int semantics are "better" than int semantics, we could leave num semantics as bare floaters and make Num a little smarter.
or we could make a lexical pragmatic choice about which division / etc means.
most things just work "right" with MMD, but division wants to kinda be special
and **$fraction etc.
well, Perl 5 gets along quite well with just int and double
yes
I agree, I'm just wondering if it buys us anything to defer 1/3 division
till we really need the floater.
I think people think they want Int whether it turns out they do or not...
I think Num can choose any internal representation it wants for a given number
idiv fdiv rdif
if we went the pragmatic route then lexically infix:&lt;/&gt; ::= infix:&lt;rdiv&gt; for instance.
and then it make Rats.
and Rats presumable dispatch differently
bly
er
I mean "my infix:&lt;/&gt; (Int, Int) { rdiv }" actually
Num/Num would presumably still call fdiv, or ndiv, or whatever we call it.
long form should probably be intdiv, numdiv, ratdiv for clarity
make that "my multi infix:&lt;/&gt;"
so it still MMDs correctly to nonInt
would have to think about Int/Num Num/Int etc oto
too even
and other operators like **
used to be that floaters could completely suck up ints until we went from 32-bit to 64-bit ints.
but potentially with loss when using 64-bit float
I think we need to think about it from the use case end--who wants which guarantees?
a lot of people just want fast and "accurate enough"
a lot of other folks want "as accurate as possible" and don't care very much how fast.
dduncan: part of what makes the fast kinds fast is to commit to it.
which is why I'm thinking about Nums that do Rat up to a point and then revert to floaters
default should be "not exact" like Perl 5
but Int gives us infinite precision anyway, unlike P5
yes, to both of you.  :)
sort of the Ada approach.
in Ada you say "I want something 0..1_000_000" and let it worry about the representation
but it always bothered me a little to have arbitrary boundaries when the actual base type probably can store more...
which is more or less the Ada approach in disguise.
Ada has the concept of "universal integer" which is your infinite integer
but my memory is fuzzy, it may be that universal integer is only supported at compile time.
anyway P6 Int is "universal integer"
not sure whether it makes sense to let Num be an infinite type though.
part of why I was wondering about whether a Num could decide to be a Rat inside.
at least up to a point.
it might make it easy to do lossless scaled arithmetic on money, for instance.
Rexx used exact decimal arithmetic
so "string of digits" approach
so I wonder how polymorphic/generic Num can be in a given lexical scope.
and if one scope thinks Num is strictly floaters, while another thinks it's strictly decimal strings, what happens then?
one approach is to say that we attempt to do exact arithmetic until something ridiculous comes up like you mention, and then just punt to floaters for irrationals or approximations.
and the Big question is whether lexically scoped multis give us all the flexibility we need.
well, arguably floaters punt all the time on / and *
and on +/- when the numbers are ~15 digit precision or so.
if there is a pragmatic lexically-scoped solution, I wonder how many knobs it has.
or whether one knob with several settings will suffice
I don't know for sure, but I suspect Mathematica does some of that.
seems like you'd have to do that to do reasonable integration/differentiation
or you won't know when you can get away with multipling infinity by 0 and get a reasonable answer...
heck, let's just make everything a 256-bit floater.  :)
free ram upgrades for everyone!  three chickens in every pot!
the mere mortal just wants it to be a Num, and run fast, and don't bug me about it.
so probably different kinds of Num have to be taught to interoperate as seamlessly as possible.
probably MMD gets us most of that, with enough definitions for conversion functions.
though perhaps we might distinguish lossless from lossy conversions and make the latter a little harder to get.
dunno.  if you're gonna go that far, most scientific type people would just as soon it calculate your error bars for you.
this has been attempted in the past, with notable lack of long-term success.
people would usually rather have a fast answer and just guess about whether it's accurate.
so they stick with floaters, and external analysis.
(or more frequently, non-analysis :/ )
as long as you stick to integer arithmetic on the Int type, yes.
and ** get problematic though
er, / and **
and you can't tell with / whether they *want* idiv or fdiv...
why not just MMD over to returning a fractional result?
dduncan: that is not what the naive user would expect.
which gets a different result from int($a/$b)
. isn't concat in P6
I think pugs already supports a bunch of them.
a lexically scoped pragmatically selected default.
just wondering if / is the same.
default default is ndiv, but user can change default to idiv or rdiv.
I think the minimum convertibility between any two types has to be guaranteed to be with at least the precision of floating point.
and two given types can negotiate greater precision of conversion if they like via MMD
I think we could be rather more regular about this
make / and % default the default to ndiv and nmod
dduncan: yes it does.
but also have idiv and imod, rdiv and rmod, etc.
r is rational
Int/Num/Rat
and maybe D for Dec
arguably Dec is just Rat where the denominator is constrained to a power of 10
int/int -&gt; rat would not be the default default, but could be selected if we make / mappable to one of the others.
Int/Int -&gt; Num is the default.  But one of the approaches I mentioned to luqui earlier is to make Num do Rat internally when it makes sense.
not sure if that's well defined though.
dduncan: you can pick the default results for certain operations, but once something is constructed a certain way most of the decisions are made by MMD.
I think in practice / is where almost all the decisions are made on which type to return.
RealFrac being floating point?
wait, you just said that.
okay, what I've been arguing for is that Num be something like RealFrac then.
what's the difference?
being more familiar with Fortran where real is floating
P5 just punts that to the user.
Ada has a huge section on it.
ingy: we're almost to happy happy now.
the latter is the Ada approach.
quick answer: miniperl6
see v6/v6-MiniPerl6
Ada had a very complicated answer to that that basically boils down to "It depends."
I'm inclined to say that == continues to behave much as it does in P5
convert to floater, and check for exact.
if you want to parameterize the test, use an eqv variant.
floating point is like the basic rules of diplomacy.  any two countries are free to negotiate better or worse relationships...
well, yes, considering that mp6 has been the main push for the last couple of months...
I wouldn't worry about that too much; the test suite is what is supposed to guarantee eventual convergence.
and mp6 is really only going to replace the current Haskell compiler in lambdaland.
anything in the runtime is likely to be useful for a goodly long time yet.
after all, the specs merely say that the parser for Perl 6 has to be written in Perl 6, not the run-time.
dunno, svn should be able to tell you.
usually if someone reverts something they're nice enough to put a comment or log entry explaining why.
Alaska or Southwest are usually the cheapest.
but nothing is terribly cheap these days, what with fuel prices...
you can almost certainly do better than that.
just OSCONs
have always flown to YAPCs
also tend to fly to EuroOSCON for some reason... :)
probably
currently Southwest will round-trip in April from seattle to austin for about $200
329 for fully refundable.
not sure which city is YAPC though...
also, they don't book far enough in advance to see what it would be in June
actually, I'm looking at it wrong, round-trip is minimum of about 300
houston same as austin
I've been through the Rockies on it, not too bad.
well, at least it doesn't do loop-the-loops inside the mountain like the railroad tracks do...
you shoulda kayaked across Canada instead.
was taunting the ingyness
that's the right place.  can't help with svk tho
@tell luqui the main problem I see with single dispatch on the right side of ~~ is junctions.  $pat.accepts($_) has to autothread or it doesn't have a dispatch type.  But that messes up current policy on all(@foo) ~~ any(@bar).
most people here have done it by rewriting the routine in C.
hmm, was this channel really dead for more than 9 hours?
ah, yes, I see that on colabti
odd, I always keep a connection running under screen.
maybe freenode or their isp hiccuped
cause it looks like lots of people were disconnected then.
I'm using irssi!!!
ah well, if it doesn't happen again, I'll chalk it up to a cosmic ray.
but for some reason I didn't get reconnected like usual
So, I'm curious.  *Why* do the Dutch continually deprecate their own language?
It's not a very Indo-European attidude... :)
attitude, even.
my father and his mother used to tell jokes to each other, and then the punchline would come out in Flemish.
we'd say "what's it mean in English?
and they'd say "It's not funny in English."
Dutch 3000, more likely.
In my head it was pronounced "whatsit", not "whatizit"
Might be a California thing though
But I don't think so.  "What's it to ya?" has 4 syllables.
no, P6 only specs that native types are biased towards optimizable.
date reform. :)
most USians don't mind that form, since it puts the month first.
well, if you were used to starting your letters with July 4, 1776 style dates...
luqui: I was worrying about reordering all(@foo) ~~ any(@bar) into any(@bar).accepts(all(@foo)), but I think by the rules in S02 the all always trumps the any regardless of the order, so maybe we're okay on that.
S09 rather
any(@bar).accepts(all(@foo)) :)
it is true if all the elems of @foo match somewhere in @bar
well, with the .accepts rewrite, the invocant must autothread or we don't have a proper type on the left
it simplifies if the argument to .accepts also autothreads, so we never write any of those with Junctions.
that is, all the method defs are straight types, not |Junction
yeah, I know.
but English tends to priviledge the first one.
the rules in S02 basically say the all always autothreads before the any
S09, darn it.
Whatever the rules are, I'd just like it not to be counter-intuitive for ~~ if all the other operators MMD left-to-right instead of right-to-left
linguistics isn't generally gonna give you a consistent answer on that sort of thing...
is the theory funny in Dutch?
anyway, it's possible that S09 has the precedence backwards on autothreading.  I do like that there is a precedence, if it solves the ~~ reordering problem.
on the other hand, doing it by left-to-right consistenly might just mean we need to desugar ~~ to something smart enough to autothread backwards.
That's the whole point of what we're doing.
trying to see how the single dispatch form works out
I don't mind that reversed forms have to be written "when .accepts($value)"
I'm just worried about the junctions at this point.
I did (briefly) think about spelling "when" backwards.  :)
get what for free?
but yeah, in the abstract rewriting twice could give us the autothreading in the other order naturally.
what is fairly certain to me is that the underlying comparison routines don't generally want to accept Junctions at all.
unless the Junction can be guaranteed to be type homogenous
any(1,"foo") ~~ any($a,$b)
even rewriting to $a.accepts(1|"foo") | $b.accepts(1|"foo") isn't gonna dispatch right if
the right arg wants to distinguish Num from Str
so I think it just wants to completely autothread, based on Patterns that never contain junctions.
The Selector type includes Junctions though, because it has a different purpose
well, to pick nits, it's a syntax error without a space after the given.
right, that's what Selector is for.
we're trying to be consistent about mumble(...) always being a function call.
that might work.
but why not just "given 1|2 {...}"
anyway, it just pokes the junction into $_ is all.
I don't think people will expect threading the whole block.
I think the assumption with given is that it's a distributed/factored ~~
so each when is in charge of its own autothreading
well, you could pass in a junction within a container of some sort, but that takes type collusion
how to force grep(all(@foo), @bar) to autothread is an interesting question.
currently doable as "all gather for @foo -&gt; $x { grep $x, @bar }"
er, with a take
all gather for @foo -&gt; $x { take grep $x, @bar } would do it.
it doesn't?
oh, you mean in returning values
I'm trying to decide if it would violate Least Astonishment.
It's probably okay.  Question is whether a final for in a function works the same.
or whether it's just "do" that turns on the collecting.
in p5 probably returns the virtual undef off the end of the list
possibly there's a performance issue
if you collect up all the results, and you were only interested in
the side effects, or you return 90% thru.
then you collect a bunch of stuff only to throw it away.
much like a final map would
P5 at least tracks whether the sub was called in void context.
I suppose P6 could also.
anyway, I don't see much reason for "do for" except to mappishly collect all the results.
so we could certainly do it there, I think.
well, "do" just makes the context come from the expr on the left rather than the outer blocks context.
and presumably the expression on the left may supply a context that is known at compile time.  But that's not certain either.
a bare "do" on the front of a statement is kind of a no-op, mostly.
It's hard to keep everything in mind simultaneously.  :)
I think of programming as a protracted negotiation with the computer over which order it should throw away information.  :)
or somethink like that...
I suspect you'll start complaining about comprehensions shortly whether or not I'm too long... :)
I think we need spelling reform in Perl.  when =&gt; wen for instance.
change do =&gt; doo
my *@args := would flatten
looks like "too many args" to me.
you don't put a g in the middle when you pronounce it?
luqui: yes
my @args := [@foo,@bar] would work though.
don't what people assuming it's a listop.
Khisanth: no, [...] constructs a new array.
yes.
$x = item @foo
oh, what you want is my @args := \(@foo, @bar)
captures don't commit to flattening or not
in that case it should probably be [item @foo, @bar]
or you're just pushing the @bar object into @foo.
sockets are supposed to be 2-way
that's what distinguishes them from pipes, primarily.
if you want to use a socket two ways, you probably need to use sysread/syswrite to avoid buffering issues with &lt;$sock&gt; and print $sock.
and the answers to this question will almost certainly be different.
pragmatically, as well as pholosophically...
ofer0: Second System Syndrome Done Right
Perl 6 will be mistaken for a lot of things, I think...
the list() style comprehensions are just a way to write the corresponding grep.
I agree they aren't full list comprehensions.
so your reading of "1 &lt; list(@a) &lt; 10" is correct as it is currently defined.
it's just grep {1 &lt; $_ &lt; 10}, @a
list is possibly not the best word for that.  at one point we were using all(), I think, but then realized it implied unordering
used to be "for all(@x) &lt; 32 {...}"
already use "each" for something else.
for every(@x) &lt; 32 might work.
but it's just sugar.
mostly just waiting for suggestions from young whippersnappers.  :)
actually, "do for" is now close
@list = do for @a { $_ if 1 &lt; $_ &lt; 10 };
but that doesn't let you extend the do without {...} added.
-&gt; $a, $b ?
hmm, cursors...
we're already dangerously close to getting lynched just for introducing lazy lists...
-&gt; $x where { 1 &lt; $_ &lt; 10 } {...}
It's one of them thar Selectors...
assuming for is smart enough to skip and not fail.
in theory our bindings are dependent, but don't auto-iterate lists.
-&gt; $a, $b = $a {...} is legal
these remind me of database joins as well.
mercifully I forget
was that a 'bot?
different address tho
but see also S09:606 "Parallelized parameters and autothreading"
-&gt; $a in @A, $b in @b where { $a &lt; $b } { f($a,$b) }
einstein?
ah, yes
-&gt; $a in @A, $b in @b { f($a,$b) if $a &lt; $b }
-&gt; $a, $b {...} in @a, @b
nod, just brainstorming
it's a strange signature that doesn't look for an argument, unless they're really defaults.
sigs already allow constraints
using where
@fido in @pound where Dog
that'd be cool, at least temporarily.  :P
nap time &amp;
no, just getting old.
semi is a method for yielding to another candidate you have more confidence in than yourself
night
drat, company meeting...will be distracted...
everything that is make-like is bogus; everything that is non-make-like is also bogus.  :)
pay no attention to the peanut gallery behind the curtain
you should bounce this off of obra
Jesse Vincent
Hiveminder
maybe
how do you define "watching"?
putter: pong
poke it into a public_html somewhere?
would be nice if a unified AST was in there somewhere
event model
hopefully it gives you consistency across platforms at a lower level than syntax
I/O model
docs processing flow
there's a reason I'm not a project manager.  :)
how the documents get from where and how they're written to where and how they're read by the end user
need to get up at 5:30 myself, sigh.
but it's a good start
maybe make writing the emitters to the platform a separate step...
though probably done in parallel up to a point.
Oh, the MOP!
and maybe a circularity saw if the prelude is circularly defined.
things defined in terms of each other, on the assumption different platforms will nullify different parts to supply as primitives instead.
there is also still some work to at least move the todos to separate lines so different platforms can keep their status independently.
I get errors but it seems to calculate file stats right.
kinda funny to have P6 on P6 out there without anyone depending on it.  :)
arguably, P6 on P6 is just part of the test suite.  :)
depends on what you mean by "core"
writing a VM in Perl 6 is specifically not on the agenda any time soon...
though maybe an OS or two...
still think "core" is far too overloaded
it's a machine, which may or may not be virtual...
that's the plan
I'm gonna shutup now so we can all sleep...
masak: take $i = ... is returning an lvalue because = returns an lvalue
I generally use http://sial.org/pbot/perl6
have it as a button in my bookmark bar, in fact...
I think "take item" works, probably
that's straight from P5, actually ($x = $y) =~ s/// wouldn't work otherwise
item is $() really, and list is @().
I just added : forms to go with the () forms
they have list infix precedence on the right
so you can instruct a zip how you want it contextualized
equivalent to the "chunky" we've been discussing in p6l
and @@:split gets you a chunky split, instead of the default flat one.
"source of wisdom" I was taking it.  :)
in p5, split just adds extra fields
split(/(delim)/) gets you field,delim,field,delim,field,delim
chunky would get you [field,delim],[field,delim], etc
@@: 1,2 XX 3,4 gets [1,3],[1,4],[2,3],[2,4]
by defaults it's just 1,3,1,4,2,3,2,4
s/s//
so you either write
for 1,2 XX 3,4 -&gt; $a, $b {...}
or
for @@: 1,2 XX 3,4 -&gt; [$a, $b] {...}
so the default @: works well with the default signature
and zip defaults to not needing [...] in the sig to unpack
but you can get a list of array if you want via @@:
and we can unify zip and each into just zip
and don't have to have two versions of split, map, take, etc
@@: automatically takes a list of
list of Capture and turns it into list of Array
also applies to m:g results
when you say "return 1,2,3" you have no idea what the caller wants to do with the listiness of it.
so we do it lazily
just like when you call "mumble 1,2,3"
it waits till it knows what it's binding to
1 might be in scalar context
2,3 might be list context
Captures and Match objects are very similar
they try to capture the original "syntax" of ordered and unordered things
morning | evening
np, I used an inclusive or
er, which rant is that?
yes, I've noticed that chord pattern is rather common :)
someone with more time than I have should rewrite cbstream.rb in p6...
wolverian: not yet.  :)
[particle]: two changes.  .accept =&gt; .ACCEPT and added @: syntax to be a listop-y kind of @()
cbstream.rb is the irc gateway that's feeding PerlMonks' chatterbox to #cbstream on freenode.
that's so that we get @@: to mean "chunky".
So @@: means pretend you bound this to a @@ and return what you'd've got if you'd done that...
And $: @: %: &amp;: @@: are just $() @() %() &amp;() @@() without needing the trailing paren.
basically reusing the meme that ":" turns a method into a listop.
except we tweak the precedence slightly so it governs operators like Y and XX as well. (sounds genetic...)
anyway, the implicit cbstream.rb challenge is at http://www.perlmonks.org/?node_id=596867
seems like a good chance to see how async {...} works
and, of course, to show how much prettier Perl 6 is... :)
that's funny, considering S01 specifies that we not consider any implementation "the official Perl 6 implementation".  An implementation can be "an official implementation" if it passes the test suite.
gonna sic Perl::Critic on me?  :)
I don't always follow PBC myself... :)
I just threw the pieces of gold into the fire, and lo! out came this Golden Calf...
I probably shouldn't be putting stylistic notes into the S's in any event.
SamB: so break the stone tablets again. :)
sure, but they're scoped to the subrule, which doesn't do you much good.
making pretty good progress on the Official Grammar, btw
to keep "actions" from cluttering things, I'm writing the rules such that they can be preprocessed
so we have rules like:
when    =&gt; rule { &lt;block&gt; {*} },                    #ACT sc when
the {*} is a placeholder where you might want an action
and #ACT sc when is the identifier of that action
in this case "statement_control when"
the hope is that the grammar can be used as-is for mere syntax validation, but preprocessed into various derivative grammars for other purposes
nothing says the preprocess couldn't s/&lt;'{*}'&gt;/{...} {...}/
looked at various ways of sneaking the identifier into the rule, but it really cluttered things up.
prefer symbolic
also it doesn't look like a longest-token stopper
and {*} looks like a closure because it is one
just doesn't do much.
so you really only have to translate the ones that you want to add an action to.
well, there's always eval...
there's probably some form of textual macroing, but it could *really* screw up the visual semantics of which field is $3
now all I need is define all my terms.
oh, the ' ' key in a magic hash tells it what to check for between the key and the value.
so it's easy to force word boundaries there, for instance
not sure.  there may be other things that token implies that regex wouldn't.
for a while was considering that token/rule implied longest token on | while regex didn't, but decided consistency was better
but mostly it's "token" to keep reminding you that it doesn't do whitespace like "rule".
tokens don't do :sigspace
though "token { \{ &lt;expression&gt; \} }" automatically gets whitespace inside because &lt;expression&gt; is a rule
presumably with auto-ws fore and aft
we try to push as many tokens into hashes as possible to keep them officially independent.
and deletable as well as addable
dinner, so entering attention deficit mode. &amp;
@tell putter backtracking vs not doesn't have anything much to do with mutability, nor does token vs rule.  rules don't backtrack by default either.
@tell putter we're not changing the grammar out from under ourselves in any case.  we're only changing the grammar to parse the rest of the block.
@tell putter it's sort of a continuation idea.  But yes, how one actually does the overrides is the real question.  The problem with the hash approach is it tempts us to reinvent inheritance badly.
@tell putter and the old &lt;%foo|%bar&gt; notation is really a form of MI.  even the new /%foo|%bar/ is still kinda MIish.  anyway, will think on this derivation mechanism s'more.
never heard them called that...
end-of-line comments is what I call them
do you mean #{...} comments then?
code #[[[ comment ]]] code
where any set of brackets works
is disallowed if # is in column 1 though.
that's always line-end comment even if followed by bracket
because people do 'a,'zs/^/#/ and expect it to work
also, we encourage people to use pod for block comments
I'm working on the official grammar right now.
but a compiler is a lot more than just a grammar...
there are lots of good starting points, and we've started at most of 'em already.  :)
a chance? sure.
you can say that again
that goes without saying
"Say it again, Sam!"
mornin'
we're slow out here...it's only 09:13, er :14
must be frustrating; most of the world is waiting for California to wake up most of the time
armed goons like to go on vacation too--where is he?
then I'll send the armed goons back home.  :)
nwc10: it was linked last week from PM
putter: it's the "conditional" construct
oh, dmq answered it already...
no, I meant putter's Q
oh, you did too, nevermind
still too early, obviously...
putter's code? oh, thompson's...
not knowing the encoding is the only real problem.
many engines just pretend it's bytes and merely put extra constraints on where the character boundaries are considered "real"
Jperl did that with JIS, iirc
there is literature on that subject.
"tagged transitions" is one thing they call them, if I recall
yeah, implicit .*? on the front...
which a lot of people mistake for implicit .*
I'm still not sure the concept of minimal matches can be fit cleanly into true regular expressions...
rsc seemed to think so.
troo nuff
I see no enemy here &lt;ow! quit it!&gt;
| is unordered in real regex
* is primitive
x+ is xx*
and {n,m} reduces to some sequnce of x x? or x*
s:31st/&lt;null&gt;/e/
well, yes, that's where you get your famous state explosion.
well, state explosion is not an issue when you calculate your states on the fly only for the current piece of data.
as all modern greps do, for instance.
?
that's just ordinary state collaps
e
that's no good for /arf|a{1000}/
you might start another arf in the middle a{1000}
yes, your parallel NFA execution gets to that point and throws away all the unreachable states, and then is just linear to the end of a{1000} with one state, that's all.
trying not to unroll into NFA is a false economy
just unroll it, and let it keep its one state, and then it can also handle the case where /arf|a{1000}/ has to start splitting states again.
and it only has to do that if it sees 'a' in the data
could unroll lazily too, I suppose
but for some patterns maybe that's where you just throw it over to the backtracking engine.
at least if you can prove that a{1000} will stay one state
this is basically what we're trying to figure out with the P6 engine, how far we can push DFAness and then smoothly transition to a procedural approach
hopefully without much explicit guidance
that's what all this "longest token" stuff is about, basically.
though we really want to push it a little beyond that.
we are requiring it for | and disabling it with ||
| becomes declarative, || procedural
I'd call it "old age and treachery"  :)
and the expert user will be instructed to use || if they really want leftmost
anyway, it also fits in with the meaning of | and || outside regex in P6
I suspect p5p might notice if you tried to do it treacherously.  :)
that doesn't mean the jailor will respect it
more likely a pragma, I'd think, since you'd want to write a grammar with it.
and because the P6 interpretation of | extends to subrules!
all is fair if you predeclare
hey, that's kinda catchy...
later
CL doesn't really have true multis, I think
it just has a way of emulating nested switch statements left to right.
putter: on the subject of derived grammars, I'm basically coming to the conclusion that deriving from mutable grammars is a Bad Idea.
samnes if I know...
no, you're supposed to reply "no dhit"
I do not recognize this word "dorry"
when I say "use MyGrammar" I want it to stay consistent all the way through this lexical scope.
I don't want someone changing the grammar halfway through
also, mutable grammars (see magic hashes) make you reinvent dispatch
note also that you didn't succeed.
you blew it on the last letter
putter: so I think grammar munging maps to mixin semantics, but I think we'll need to be lazy about recalculating our longest-token engine, or every new sub declaration will force recalculation.
well, arguably every declaration changes the recognized language, including "my $foo".
but we could probably finesse non-macro defintions not to recalculate even without laziness, I suppose
it's easy to visualize how deriving a new anonymous grammar and adding a production to it hides any corresponding production in the parent grammar
the sticky point (and this is where the hashes were (mis)-aimed) is enumerating all the currently visible rules so that the longest-token/DFA analysis can happen
so I think we still need some kind of regex registry that transitively calculates the set of currently visible regex given some entry point or other.
been making any sense at all?
and instead of having %prefix := { '+' =&gt; rule {...}, ... } there are methods with names like "parse_prefix:&lt;+&gt;"
since "prefix:&lt;+&gt;" is the name of the actual operator, not the rule that parses it.
re one thought: yes, but I try not to step across the little line marked "possible/impossible".
and mutable grammars are balanced close to that line.
especially if someone can mutate them while I'm using them.
s:3rd/&lt;sp&gt;/ else /
anyway, it'd be nice not to have the grammar recalculation tied into some kind of external event notification.
even if it were sane
another thought, perhaps deriving from a grammar is more like "does"
(with the implied semantics that if you "does" a class it takes an immutable snapshot of it for the role)
and the role doesn't see subsequent changes to the class that was snapshotted
well, that's definitely the Rubyesque approach.  :)
hoping to give the optimizer a little more rope to hang you with here, though.
could go as far as to say that grammars are all roles, and only every have anonymous classes generated from them when you're actually compiling.
this is very like the declarative / procedural distinction we're getting for regex.
how would that be different from doing any other role?
&lt; putter&gt; which sounds like parse_prefix:&lt;+&gt;, or no?
yes, except
I was thinking you'd never write parse_ yourself
that'd just be "macro prefix:&lt;+&gt;" or some such.
so we can also hang all the same properties that the user might, such as precedence
and the parse_ form would autogen from that
but yes, it could autogen both a parse_-ish form and a &lt;prefix&gt; rule
except that the &lt;prefix&gt; has to regen when you derive
and the parse_ form doesn't
well, &lt;prefix&gt; regens if anything in prefix_* overrides, I guess
but arguably all subs are prefix:&lt;foo&gt; underneath
I guess (with similar furrows, I guess)
our %foo in role %A is A::&lt;%foo&gt;
I think...
sometimes it's hard to know what's auto-generic in a role...
so I'm probably wrong, and it's $?CLASS::&lt;%foo&gt;
that's probably sane
I remember them well, and am still fuzzy.  :)
well, I think I'll see how far I can drive the idea that if you say "macro" in a grammar, it's defining a token from the user's point of view.
but that's probably a stupid idea.
how would we tell that from a macro to be used in the grammar?
hmm
ss/used in/used by/
maybe "token prefix:&lt;+&gt;" can be recognized specially
token prefix:&lt;-&gt; is equiv(&amp;prefix:&lt;+&gt;) { &lt;expr&gt; } or some such hybrid
with some additional declaration that establishes any policy that applies to all prefix: while letting the actual &lt;prefix&gt; autogen.
k, I think this is closer to fitting in my brain.  perhaps if my head were to get bigger it would help...
well, that's essentially what we have
prefix:&lt;+&gt; is just naming convention
and we'd really like everything to just be methods underneath
albeit with an implicit object that is the "current match we're attempting"
I can imagine &lt;foo: bar&gt; sub-multi-ing based on the type of bar, but it would still be primary on the current match object, I think.
so it's still "multi method" not "multi sub", I expect
well, a parse is just an object instantiation of a grammar class.
so it's $parse.mumble(args)
I could be lying, of course.  :)
but delusion is more likely
it might well actually be the Match object that comes in as $parse, but I presume that Match knows its current Rule and/or Grammar object and can delegate
that page says that Perl 6 development happens on p6compiler, but that list has had three messages in the last month...
trouble is I'm not sure what to change it *to*
should it send something here?
run away!!! it's the devil bot!!!
whew!
but did the patient survive?
should the channel topic be pointing there somewhere?
the spew here does
it seems cumulative
.++.++
why don't you put in "constant" as a declarator instead.  :)
I tried earlier and failed... :)
inlineable, anyway
and run at compile time, probably
maybe BEGIN is "constant sub BEGIN {...}"
dunno, I didn't write that trait
macro body isn't "real" code
it's metacode
at this point, I don't care if it's really constant
I just tried aliasing it to "my" and it didn't work
presumably
aliasing to my and throwing a readonly on it would work for now
I wonder if the dup junction could be related to multithreading the junction
I don't like the voting metaphor
audreyt: we've already got "is leave { .close }"
er, "will leave { .close }
I wonder if explicit reference counting should be built into open/close generally
and you make an explicit ref-counted link with some kind of reopen
will close
except then it'd chew up the normal body
is closed
is autoclose
hmm
anyway, if we culturally generalized open/close to refcount semantics, we could have a consistent way to pass out a refcounted object
or clean it up if nobody took an explicit refcount
merlyn: didn't get a chance to congratulate you!!!
well, don't start now.  :)
where in the world are you at the moment?
I know the place...
so maybe role Handle is our official way to do explicit refcounting
maybe we're trying to get rid of the wrong thing here, and it's the "leave" that's the usual case
which would give us "will { .close }"
or throw out "will" and replace it with "leave", "keep", "undo" etc.
"leave {.close}"
but I'm not sure this will be used often enough to warrant any default over "will leave {.close}"
yes, but most of most programs is processing lines, not opening files.
I do realize that P5 programmers will balk at writing even that much...
maybe its -&gt; Handle $h that is magically scoping
FileHandle is also rather bulky
well, I guess IO is our shorthand
it's almost turning into a monad...
nah, that's just the prototypical monad
anything that doesn't behave programmatically can be a monad.  :)
I often speak hyperbolically
no wait, that was the other L guy...
use perl5:Foo == thread the Foo module with the perl5 monad...
audreyt++
speaking of which, why doesn't audreyt++.++ work?
oh way, that's the value
nevermind
Derivable languages
I keep picturing Perl 6 as the root of a big naming scheme for all languages.  :)
use perl6://now/I/am/Python
but I understand you are trying not to scare the audience too much :)
I think so, have to check with my executive secretary to be sure
she sez it should be fine
you would be most welcome at our humble adobe
it's probably closer to the googleplex than their accomodations
quite walkable, in fact
name it debcon7 and you'll get crackers coming by accident
look, our kids ranged from ADD to Asperger's...we're ready for anything
well, almost anything...
kewl
ah yes, my favorite diagnosis PDD-NOS
"not otherwise specified"
they didn't have Asperger in the Dmumble IV
PDD-NOS was the closest they had
the DSM IV, sez my executive secretary
oh, that's that new one, which has it
Glo says III was just PDD-NOS
well, nice that half of silicon valley is no longer "miscellaneous"
can't say I haven't noticed.  :)
laziness=PDD impatience=ADD ... hubris=profit!!!
actually, hubris is some form of narcissism, I expect
obviously we need to find some place where the normal psychotics can fit in.
accumulating useless facts is one of the symptoms
I've accumulated quite a wide variety of useless facts
yes, but they accumulate normal useless facts, not abnormal ones.
when I was young I read the entire World Book encyclopedia
hey, hey
usually dynamic, can be static
where is "here"?
that would have been my guess, considering your address ends .se
basically, the difference between miniperl and perl
just need to make sure it builds a .so on most Unixy systems
I believe it's a Configure option
I note that fedora comes with /usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE/libperl.so
which perl
and that's what /usr/bin/perl links against
/usr/bin/perl itself being a 14k program.  :)
basically look in perlmain.c to see how perl embeds itself to make the ordinary perl executable.
is certainly doable
ah
thought it looked a little familiar
hello, buddy!
attempting to use a statment modifier on something that heavy almost certainly means you shouldn't be using a statement modifier there.
and why would do need to be mentioned in the discussion of return?
return is defined to go to the enclosing sub, skipping any non-sub blocks
a do block is not a sub declaration
is that what is bothering you?
yes, I see how that can be misinterpreted.  I'll glare at it...
rhr: it could perhaps be construed as a bug.  I can argue that both ways.
a bare block where a statement expected automatically calls itself
the question is whether a bare block with something after it really qualifies as a bare block.
it depends on whether your ... is setting up the expectation of a statement.
I have no idea what you mean
k
in that case, certainly
the question is how picky we are on when to supply an implicit .() after the block.
for instance, we certainly should not supply a .() if there's already one there.
?eval { say "hi $_" }.("there")
?eval { say "hi" }
or does not expect a statement after it
so or {} will never supply an implicit .() for you.
the implicit .() is only for a block used as a statement.
and statement modifiers are kind of on the boundary.
yes
arguably a statement modifier is both a statement as a whole and contains a statement on its left.
I work for a company called Netlogic Microsystems
whether that's "gainful" is of course subject to interpretation
I've been known to use pugs here
it was for real at the time, though I ended up translating it back to Perl 5 so it'd run faster.
but it's certainly a good language for at least thinking in
I guess it depends on what the definition of "is" is...
speaking of cigars...
I've never tried a cigar.  Tried a cigaret once when I was in junior high...
I don't mind a good wine, but I'm not allowed to imbibe at the moment because I'm taking some pills that are already hard on my liver, and we don't need two people here with bad livers... :(
only what I know from her popping in here occasionally.
my guess is she's gonna still be very much out of it for at least a week and subpar for considerably thereafter.
well, I understand people can donate half livers these days.
and it may yet come to that.
I would certainly donate half my liver to audreyt in a flash, but that would certainly be suboptimal from an age standpoint, not to mention I'm probably disqualified anyway for various reasons such as having had a transplant and various transfusions myself...
just pray once with a hyperoperator on it.  :)
also, not sure what the culture of transplants is in Taiwan.  I know they're rather rare in Japan, though, because it's very hard to find donors.
well, from where you are, that's over the north pole, so that's pretty icy...
maybe there will be a lot of spare polar bear livers available soon.  :(
well, must decommute
bbl &amp;
fg
rhr: might be more like Pipe.open(:w, "xclip")
or Pipe.to("xclip") and Pipe.from("xclip") maybe
yeah, just low on tuits
only for a specific Str.
though a StrLen could know n bytes, m codepoints, o graphemes, etc.
StrPos doesn't care as long as it points between things at the abstraction level you're concerned about
passing a byte StrPos into a routine thinking in graphemes may have to adjust the pointer or be unhappy
I believe I speculated about all this in the original apocalypses
considering there's no .length method...
how would you do it without specifying
$a.chars == $b.chars specifies chars in the current unicode level
$a.bytes == $b.bytes requires the byte count to be the same, and fails if either string doesn't care to support byte ops
a StrPos is a position in a particular string, so no
a StrLen is not related to a particular string if you force it to tell you a number
but it might be lazy about that and keep two StrPos till it knows
in general we should be getting away from string lengths in the API as much as possible
there should be a substr variant that takes two StrPos, for instance.
or the lazy StrLen can see if its lazy beginning happens to be the same as the substr pos.
then it doesn't have to count anything.
you reconcile them by choosing a good abstraction level for the default and then providing clean ways to escape the default if you need to.
and to the extent that the data types themselves allow you to escape
StrPos is precisely what it returns
if you ask for the .beg or .end of any matched thing
.pos is a StrPos
the age of fixed-width characters is largely past us, I think.
and of fixed-width strings.
you'll note that formats are now largely obsolete for the same reason
they're defined at the beginning of Functions.pod, of all places.
Char is defined as the maximum abstraction level supported in the current lexical scope.
so with "use bytes" a Char is a byte
with "use codepoints" it's a code point
by default it's a grapheme
if you say "use Arabic" it's an Arabic letter, whatever that is...
I believe audreyt was attempting to push this view into the Haskell community at one point, with mixed success.
ah well, Perl has to be better at something than Haskell.  :)
which is why these distinctions should only ever be conventions, not mandates
and what do they mean when they say "length"?
well, maybe we can help drag database technology into the age of no arbitrary limitations.
every string has a minimum and maximum abstraction level it will deal with, so you can easily declare a codepoint string within a grapheme section, for instance.
yes
bearing in mind also that U+10ffff is a single codepoint represented with two surrogates.
it's cheating to say that a Plane 1 character is two codepoints.
?eval "\x[10ffff]".chars
?eval "\x[10ffff]".codepoints
?eval "\x[10ffff]".codes
:)
?eval "\x[10ffff]".bytes
?eval "\x[256]".bytes
yes
apparently
I think pugs is at codepoint level currently
does Unicode consider them combining characters?
certainly that sort of thing can change when you throw in a "use Hebrew"
which presumably changes the abstraction level from language-independent graphemes to hebrew characters
I use the j sound
consider it encouragement to write a token or a rule instead.  :)
the whole point of regex is to reject most things. :)
depends on which canonicalization you've used
in general as long as all your data uses the same canonicalization, you don't have to worry
yes
see http://unicode.org/reports/tr15/
people argue about whether NFC or NFD is better.  the answer is that they're better for different things
NFC is more compact, and NFD is more future proof.
but NFD compresses down about as well as NFC does, since the information content is the same.
NFC is likelier to give you something close to one codepoint per grapheme for most national character sets.
NFD will split out accents and such to combining characters, so you're very much in the realm of a variable width encoding in terms of codepoints per grapheme
the default Perl approach is to simply claim that the abstraction will be maintained, even if you have to do normalization on the fly internally.
given that Perl may be pulling in both NFC and NFD data, there's something to be said for the lazy approach.
it does mean that $a eq $b may be doing more than just memcmp() though
but yes, to the user there is no encoding, at least until they have to send it to an API that needs to know.
probably.  we're looking at doing something like in http://www.seas.upenn.edu/~lipeng/homepage/unify.html
westymatt: would you like a commit bit?
*contend
and the thread continuation monad may provide similar for thread vs event issues
assuming we take the approach of http://www.seas.upenn.edu/~lipeng/homepage/unify.html
someone else mentioned it first a while back here...
hmm, must have been somewhere else I saw it first...colabti only sees your new entry.
maybe it was in the chatterbox
yeah, audreyt, http://colabti.de/irclogger/irclogger_log/perl6?date=2007-02-09,Fri#l363
well, it succeeds in the sense that it doesn't blow up...
There are still lots of infelicites, such as the fact that only one of each multi regex shows up...
which is likely something the "cheat" script will have to deal with anyway for bootstrapping.
putter: that's the section written by TheDamian.  I'll have to think about it some.
putter: I think you're missing that the latter are bindings to something quantified and hence always would be an array anyway.
the first binding is to an unquantified thing
I don't see the problem
there are constructs that for $ to really be an array
but @ just says, "push whatever you find even if if it's just one thing"
s/that for/that force/
'tis quite possible I'm being dense, of course.  happens to me every now and again...
bbl &amp;
um, that wasn't me...
um, who is being me?
@moosages
specbot seems to be going nuts and rehashing old stuff
maybe the backlog will explain...
looks like specbot is reminiscing
or perhaps its life is flashing before its eyes as it dies...
diakopter: sure, problem was always that I had too many answers...
shh, you weren't supposed to notice that.
are you implying that spec changes made in haste result in negative karma?  :)
gaal: lol, e.e.cummings were a good poets
we are amused
@tell putter I like your little chart, and it reminded me that @x:=[...] only captures text, which I'm sure p6std violates in lots of places.  I also think I like your infix:name idea, at least for generic matchers with no fixed sym.
@tell putter however I will probably change the part about "flattening" into the more modern lazy flattening that can be undone by @@ context.
heh, I just realized we're using "is context" for two completely different things
we used to have "is context(Scalar)" on parameters, which we've all forgotten to remember.
which means that particular usage should probably die
no, it collides--I've been putting "is context" on parameters to turn them into environmental vars
and the fact that the "is context(Scalar)" section has a big disclaimer at the bottom that it doesn't work half the time...
is another strike against it
should probably just be relegated to special macro processing anyway.
since it's something that has to be known at compile time.
so I'm just going to delete it.
putter: note in my message I'm thinking about changing it to lazy flattening undoable by @@
you can ignore the symbol stuff in S05, it's already obsolete
in fact, I just now deleted it
Range.max just returns the endpoint, ignoring :by
so pugs is correct
Schwern++
the "Perl 7" discussion, I think
not to mention the strange regex ideas
There's little wrong with Perl 5 today that wasn't already wrong in 2000 when 361 RFCs were written...
I think of them more as macros than methods
WHICH is more likely to call stringify or some such
depends on the MOP I think what the meaning of object identity is
[particle]: you mean on .max?
[particle]: I'll need to think about that
&lt; svnbot6&gt; r15382 | audreyt++ |     vv('foo').HOW;      # Str
arguably that should return ^Str rather than STr
*Str
I think it needs to stringify to ^Str to avoid confusion with the Str prototype
hmm, I wonder if (1..10).push should return (1..11)
Range is currently mutable
and we always said you could iterate a range on either end, but never said how.
hmm, maybe .minmax is a no-op, and infix minmax should always be done with range objects to preserve inclusive/exclusive distinctions.
a PDL programmer would expect that to work, but I'm not sure a mere mortal would
S03 has always said it's mutalbe
*mutable
the place where it says "Range objects are lazy iterators"
there's no such thing as an immutable iterator
I suppose if you're doing the problem where the fly flies back and forth between two approaching locomotives...
you'd end up with (3..0:by(-1))
the problem with using two Scalars is that you have to keep the inclusive/exclusive information out-of-band.
and I think people might rather write $a..^$b minmax $c^..$d than using lists of two elements.
for a given Range construction
I think so
at construction time
1..100:by($x) is fine
we don't have to decide whether .min and .max swap ends until construction time
when we see whether $x is negative
well, you'll wait a long time if rand returns 0 :)
but 0..1:by(0) is no worse than 0 xx *
bbl &amp;
my make smoke loops on two of the regex tests
audreyt noticed it last night too
and left a message for fglock regarding it
194.145.200.126
this is #perl6.  I don't know what makes you think you'll get Haskell help here.  :)
oh, well that's okay then...
morning audreyt
how'd it go a gooooogle
did they like it?
did they ask any good questions?
ya think?
sides, a googol is only 10**10**2
saw a short talk from Pike mentioning it here in MV
though it was mostly about stats gathering
er, not that either without parens...
pretty much
should I add anything to Perl 6?  :)
things with whitespace as syntax maybe?
we'll just have to write a stone-age to space-age translator for them.  :)
but it looks like not much of anyone is signing up to be a mentor
ah
that I'm willing to help mentor.  :D
they're putting a Python grammar onto Parrot under the name of pynie, if you hadn't noticed, or even if you had.
given it's in pge it'd probably be pretty easy to filch.
I'm still thinking translator
maybe someone should just port haskell to run on parrot.
after all, there's only 2 or 3 actual primitives in haskell...
great minds *cough*
a SMOP
that's the idea; porting haskell would keep the parrot folks honest, albeit not without some swearing here and there.
it's really easy to just keep porting the languages that are easy.
(relatively speaking)
now, porting Perl 5 to run on Parrot just involves swearing without a lot of honesty.  :)
speaking of taking over the world, I just defined the module declaration syntax to allow a Perl module to claim to support the API defined by a module in another language.  it fell out naturally from the ability to claim to support older versions of the same module...
'course, claiming to support the API and actually doing so are two different things
I think a Python to Perl 6 translator would be not terribly difficult, but I think the world really needs a refactoring PHP to Perl 6 translator more.
the problem with PHP is that people are slowing getting boiled to death without realizing it.  I don't think of a translator as something they will look for without prompting, but something that will become popular if Perl 6 gets cool.
and just remove the impediment to migration when they want to for other reasons
same for any other language, really, even COBOL or Java.
is that recalculating the candidates each time or with checking last lookup to see if it's the same type profile or some other kind of caching?
not too bad then, if 90% is same type profile
candidate mismatch detection probably could
putter: people keep talking about the recent unification of regex and method, but in fact if you go back and look at A05 they were already unified in 2002.
as for the naming problem, you'll note that methods generally have names.  :)
minimalism is always a bit seductive
I always said Perl should be a "last" language.  :)
Turing: All heres are created equal, but some are more here than others.
Haskell is completely constrained by the compiler, so there's no point in thinking about constraints anywhere else.  :P
putter: on StrPos, it is not precisely required that a StrPos track its string, though that is one implementation.  What is required is the invariant that a given StrPos will end up at the same position when used on the same string even if the current unicode level is different from when the StrPos was generated.
so a StrPos can cut itself loose from a string if it translates itself to a tuple of offsets by byte, codepoint, graphame, char (however many apply)
such a translation may not be cheap, though
I don't think you can put a proto after an only at the same level
it's like a multi in that regard
two onlies would warn about redef
yeah
fatal is fine by me
also fine
(in same scope)
lichtkind: okay
lichtkind: several of us were saying it at the same time.  it seemed like a good approach to keep us from messing up interoperability.  the first "official" mention of the idea was the april fool's joke, but it was already in the air.
um, yeah, ascii.
I wouldn't go so far as to even assume Latin-1 though
howdy
lichtkind: I didn't realize there was another question
basically, april's fool jokes don't work unless the idea is already plausible
I remember a year before we announced Perl 6 getting funny looks from people at a CPAN meeting when I suggest cooperating with the Python folks...
such questions are impossible to answer quantitatively
Dan certainly thought of the cross language thing independently, and certainly did a great deal of work to bring it about.
but then so did other people.
rhr: when you ask that many questions at the same time, the tendency is to mark it for later analysis, and then to not get back to it.
at least, that's my tendency...
so basically it was still marked as N in my list.
I still hope to look at it.
Turing says that's a silly question
I think the abstract view of the short name is more correct
most of the time we've gotten away from so-far-ness in a lexical scope
it's a failure of consistent meaning
I thought that's how eval already did it
and why my $x; my $x are the same var
I was just bragging about 'one name always means the same thing in a lexical scope' on p5p
might fall into the category of trying to bind a type inconsistent with the type associated by declaration with the name
I think the compiler knows that manifest type of 'g' is multi
arguable either way, I think
so &amp;g := &amp;f just replaces the set
I don't mind outlawing it for now even if that's not the longterm right answer
yes, a short name is more like a Scheme symbol
so I think that's fine
I think anything that is an &amp; object needs to be wrappable, even it it represents a set of candidates.
can't really do AOP otherwise.
only if the .wrap is temporized
I think the &amp;f is reclosed over the new multi in the first block, so while the .wrap is written as a global effect, perhaps it's a global effect to a container that is lost on exit to the preclosed state
so the wrapping isn't seen by the second block because it's accessing &amp;f the old way
seems like
doesn't seem insane, but I'm not perhaps the best judge of that...
welcom
night
bbl &amp;
as long as it's something that can be reconstructed on demand like the line number of the call, and not something that has to be physically done on every call, I'm fine with it.
It shouldn't be called caller() then
maybe caller is &amp;frame.assuming(1)
it's what it's called in gdb
dynamic_context is a bit longish
now where did I put my puke bucket?
$+foo is short for CONTEXT:: so maybe switch the whole thing to context(0) etc
and maybe leave caller as &amp;context.assuming(1)
since we also have CALLER:: to refer to the immediate caller
they don't already?
hmm, they did at one point, or were at least close
but maybe we decided &amp;context.want was sufficient
and want() is &amp;context(0).want
sort.() should sort itself out once we switch to STD.pm for parsing.
darn it, now you've gone and destroyed everything.  we'll have to start all over.
see, it's all gone :(
well .perl is always going to return a string, not an undef
undef.perl isn't undefined.  :)
?eval ().perl
?eval undef.perl
a Scalar containing undef, perhaps
my $x; $x.perl
val 'say "foo";'.eval.perl
?eval 'say "foo";'.eval.perl
say is returning True
?eval ~{return 1;}
there's your &lt;
?eval $::('*PID')
?eval $::('*OS')
translation: I haven't the foggiest idea how to "call" a list.
to the event handler it looks like sending information to a thread scheduler queue, kinda sort.  From the thread viewpoint it looks like unblocking.
you more or less said "make me an empty list", subscript it by .{'a','b'} and tell me what you find.
which is nothing, twice.
nothing twice in Perl is [undef, undef]
double or nothing...er, double *and* nothing.
what did it say?
should parse as |([...]) | .say, I think
though unary | without an arg is probably an error
inside (|)
?eval 'please ignore the gibberish'; |[{(|[])}]|.say
yeah, the inner | needs an arg
?eval 'please ignore the gibberish'; |[{(&lt;|&gt;)}]|.say
I don't believe clone is implemented
it does seem a little odd not to get undef on first f(0), but it's mostly because you've conditionalized on $compiling
doesn't seem like a big problem to me.
see S10:84
and given there's no tests for it, I doubt it.
I think more for extensibility.
and showing off smartmatching of type parameters.  :)
where the type is being treated as a value parameter match
It's possible it's redundant in the usual case.
but also you could ask for weird containers there.
I think CANDO is assuming that someone has already figured out the desired container type
and $name is just an arbitrary string to it
I dunno, traits maybe...
I suspect *%args is mostly just a placeholder for things we haven't thought of yet.
how do you dispatch to a value like 42?
a proto-type is just another value that happens not to be defined. :)
multi f (Squirrel) { "Moose" }
I think in the usual case we just intuit from the sigil
I don't think it has anything to do with want, really.
CANDO is asking "do you choose to declare this?"
yeah, something like that.
the non-method multi matches on package as first arg
just saying you could write it more generically than a single package
and the intent is that CANDO gets to choose whether to create the actual object eagerly or lazily.
in the latter case making use of AUTODEF, presumably.
hmm, well, any wrappable routine has to allow that the new wrapper is going to call it even if the old "core" didn't, so compile-time analysis doesn't help much there...
but if the original call site threw away info that the wrapper wants...
yes, and likewise for protos
the main point of protos was to enable that rewrite.
if the data is in some format on some stack, all we need is for .nextsame to point the wrapped function at the same (presumably immutable) value lists
as long as they agree on the format, doesn't have to be a Capture
and maybe if the wrapper tries to pull it out as a Capture, it's just
"best effort"
"here's a Capture that could have produced these arguments..."
I don't think so.
if you want to monkey with the arguments you should use callwith instead.
we can just say that $x := 123 is erroneous.
.HOW.callsame
$.nextsame?
It's quite possible that we want to reserve is as a HOWish not-quite-a-method thing
and we can do that if it helps optimization later.  Not every primitive has to be user overridable.
not without we also give them a very sharp circularity saw...
Perl Evaluator Runs Lisp
we have to give the optimizer some rope to shoot the user in the foot with.
Paradigm Exchange Research Laboratory
People Experience Renewed Love
Please Everyone, Right &amp; Left
Persistent Energy Reinvents Life
Perennially Emergent Reinvention Language
Power Enterprise-Related Labor
Perform Excellent Refactoring Liberation
Pele Energy Releases Lava
Please Enhance Real Life
that's enough for today. :)
so's ERPL :)
People ERPL Really Late
I've been learning Perl 6 for 20 years now...
not that text macros are entirely sane, but then most killers aren't.
Patriarchal Entity Requires Lassitude
Please Emit Remaining Language &amp;
no, but Makefile.PL was touched a day or so ago
general notice: if anyone has trouble resolving any of the other feather.perl6.nl names, I have perl6.wall.org aimed at its current address.
http://perl6.wall.org
there you have it
do you have to be an operator for that?
anyway, I'm assuming the address is fairly static.  if it changes, someone lemme know and I can repropagate it in 10 minutes or so.
and of course it doesn't help you with the missing virtual hosts...
not yet.  I've been asking for that for months, but it's been waiting on the type and signature upgrades, so hopefully soon.
metalfan: yes, but we're waiting on the new type system.
it's taking a spiral approach; many of the features are roughed in, and we're starting in on the cycle of finalizing various bits of it.
for a graph of the project, see http://dev.pugscode.org/browser/project_planning/a_dependency_graph.png
we're just coming up on a 6.28 release of pugs
though the recent snafu with registerfly has unfortunately slowed things a bit since feather.perl6.nl is registered there... :/
also, audreyt is still recovering from hepatitis
putter did it, but he's also out for a couple weeks...
sure, but people don't get very excited till they see it show up in the repo.  :P
and I don't think svk helps much with the Hep-B part...  :/
perhaps a version that refuses to work when audreyt should be sleeping... ;)
you could mark it for deletion and see what happens.  :)
kay, thanks.
yes
that sounds about right. version 1 was released in late 1987.
I don't know exactly.  I know the actual implementation was about a month old when Geneva was born May 12.
but the disk drive containing the original info was long ago melted down by the U.S government...
and I don't down it was melted down, given it was for a secret project.
wasn't really supersecret, just secret.
but secret enough..
would be a lot harder for me to get now that I've been in X different countries...
if it had been the company's business I'd never have been allowed to release it as open source.
and I couldn't really even ask permission, since open source really had not been invented yet.
and in fact NSA abandoned blacker; last I heard only Canada was till using it, and even that is old info.
anyway, haven't had a clearance since I left Unisys.
ich habe Deutsch ganz vergessen...
biab &amp;
fglock: not sure what you're asking, but within a given compilation unit the code does not care whether it is running at compile time or run time.  The compilation unit is exempt from having to specify COMPILING:: to refer to the currently compiling scope.
and when it starts up at run time, the comp unit has a snapshot of what the comp unit ended with at compile time.
bug, rvalues should not be attempting to autovivify
on *say, I think that every compilation unit starts off with a clean GLOBAL space when compiling.
at run time, however, only the main program gets to keep its snapshot of GLOBAL
so the main program can use BEGIN to set *say, but non-main would have to use INIT.
alternately, nobody gets to set *say except the prelude, or anybody gets to set *say, and we have a problem managing transactions.
a module has to be precompilable without knowing what context it will be used in.
(unlike in P5)
meaning, at the point of starting to compile a module, * is whatever the prelude gives you, and nothing else.
however, for multis, I think the main application has to have control over what is or is not in *
multis can be added or deleted at run-time, but onlys can be assumed to be permanent over their scope.
I don't see the distinction you're trying to make
well, send me a link when you figure out how
why?
first, I doubt the compiler should be printing errors with a redefinable routine like "say".
but leaving that aside
I think it's strange to have more than one GLOBAL namespace
and the user will assume they have only one.
the basic problem is that different comp units will end up with different ideas about GLOBAL
and I think the main comp unit has to win there, for some definition of "win"
at the moment I'm happy with just throwing away the module's idea of GLOBAL after the module is compiled
it just has to run with whatever GLOBAL the main program provides.
(exception: modules imported by the prelude)
rather than just throwing away a module's GLOBAL, it might be possible to try to mesh them like a Palm resync, but that gets complicated.
an intermediate solution would be to just check for obvious conflicts and warn them if two module's GLOBAL sections seem to conflict
we also have modules that may or may not be the main program, so we'd have to keep the GLOBAL around for when they run as main, and ignore/warn/mesh when not main.
in general, for setting multis an INIT would be good enough if there's already an appropriate global proto
as long as you don't need the multi at compile time
globals have to be global
perhaps we can have "multi *say (*@_) is export {...}" and then importing say to the main scope installs the module's multi in main's global space, which persists into the runtime.
it's a nice compromise: USians like it because it puts the month first, and non-USians like it because it's the "correct" order in reverse.  and everyone likes it because it sorts better.
the sun is up, but not out.
though literally, the sun is out, but not in...
it seems to be confusing compile time with run time.  the $env arrow is at run time, not compile time
well, it's at use time, which is run time for the module.
so, are the Zulus in the Zulu time zone?
at the time the module is compiled there is no $env arrow.
it is likely the main is not compiled yet
maybe you want to draw it more like a protocol negotiation between two entities over time.
ok, I was misreading the blue as a module compile
It's not really coroutines
the only thing running is the compiler.
but the parser can generate closures to be executed by the compiler.
and those closures are special in that they do not have to say COMPILING::
maybe you're trying to put too many dimensions in at once.
maybe not
but in that case I still don't see what the $env arrow is doing.
it points to the lexical scope currently being parsed and compiled
er, I didn't know/didn't remember you were supposed to be. :)
so don't sweat it... :)
I think of the arrows as pointing the other way, arrows of reference rather than data flow...
rindolf: it takes me a long time to transition back to thinking about P5 internals, so in general I'd rather not unless it's in large batches.
I've been saying that Ruby was the real competition for Perl for about ten years now...
Ruby is trying to take over the TMTOWTDI niche.  Python isn't.
I think offby1 is counting all that under "and stuff".
thorat: do you have a commit bit?
would you like one?
you /msg me your email, and I send you one
(or most anyone else here can do it)
you add yourselve to AUTHORS and that makes you an author.
you want to be "thorat" there?
commit bit sent
dunno, I've only ever used the svn
a lot of folks around here swear by (and at) svk
I don't know if that contains the extras you need
anyone?
nope that's fine
I guess
I don't know how CommitBit works really
I'm just the Chief Cargo Culter around here...
across the street from my place of employment is the Googleplex, but I don't live there
I live on the other side of the computer history museum.  seems appropriate somehow...
4
hmm, unlucky number...
hmm, with the latest change, my Dog $fido .= { :name&lt;Fido&gt; } could mean to make a Dog lazily, I suppose
do you pull in strict with an env var somehow?
in any case strict.pm starts with "package" so pugs ought to treat it as perl 5 code...
I realize it's a lame answer over the long term, but most of us never do make install
it's one of those things like GC bugs, it doesn't tend to bite you till after the damage is done.
what are let and temp types?
let and temp are just functions on an lvalue, not declarations...
the type of such a variable is orthogonal to let or temp
that's because it's not implemented in pugs, I think
all the temp and let tests in the smokes fail
hmm, but probably by parsing as declarations, which was bogus
changed the nick to TimToady_" but it's the other way around.
moritz: see above
I think that no human society this side of heaven will be composed of perfect people.
and even the perfect people tend to get crucified :)
those concepts are orthogonal to perfection, I suspect
(assuming you mean "sensible" in the old sense of the word)
No, I mean more in the sense of people who get crucified.
such people are known to get emotional occasionally, and that's okay
Loving unlovable poeple is not guaranteed to always be enjoyable.
anyone know why the smoker is misreporting elapsed times?  I thought maybe it was because my YAML::Syck was old, but after upgrading it still reports 0.45 min when it took 27.73 minutes according to the header.
I suspect it thinks a minute is 3600 seconds long.
hmm, no, that would come out to 0.46 rather than 0.45...
ah, it's pulling the duration out of the html file, and that recently changed to reporting in minutes rather than seconds...
and the 0.45 instead of 0.46 is caused by scanning 27.73 minutes for \d+
I checked in a patch to smokeserv-server.pl that should handle the change in duration format, but the smoke server will still be offby60 until it svnups.
@tell ruz .{@keys}:p is currently specced to do what you want, though it may end up as .:pairs{@keys} instead.
@tell ruz however, it's not yet implemented either way
@moosages
$obj.HOW.method or $obj.^methods
dolmans: packages are for public interface only
that is correct
(and it isn't in P5 either)
if by symhash you mean symbol table hash
in P6 the standard layout is "P6opaque", and not even the class itself is supposed to worry about the layout
anyway, this is spelled out in S12 in gruesome detail
most of the time users of P6 won't even know there's a metamodel behind it.
not officially. historically audreyt has made some available from time to time, but lately I think most of the osx folks have been rolling their own from the sources
I'm not an osx folk myself...
and it may be that most of the osx folks who hang out here are asleep right now.
only about 270 revisions behind...  :)
always something to be said for improvement...
and then backend to P6?
that is, to P6/pugs
geoffb: I don't think anyone knows.  audreyt was making some hopeful noises last week, but my guess is that the family obligations are somewhat open-ended.
meanwhile the rest of us are peddling as hard as we can, but it seems that we all make better progress when audreyt is able to hang out
I think perhaps fglock does something like genetic programming.  :)
I'll be there
caffiene, schedule, guts--pick two
that's us all right...
I wonder if it can see the fjords from there...
when the load average was 12, there were two bots using trac, googlebot and msnbot
that was several days ago that I looked
just run it through py2p6 and then it'll run slow all the time...
no, Foo has to come before sub
which means you need a declarator before that: "my Foo sub bar"
though maybe we can relax that eventually
the (--&gt; is a known bug.  the "cheat" translates it it ( *%_ --&gt;
generally you want the return type on the right if you're going to define it in terms of types on the left
you can't use T retroactively in a sig
you're PerlJam, not Perl
next you'll be wanting &lt;-
I don't consider &lt;-- to be the same situation as &lt;==
doesn't "happen" after the regex, except for binding to the existing $/
the regex knows the $/ it's supposed to bind the result to
but the $/ variable is declared from the top, like $_
'course, you can argue that if you do want to specify a return type, it's exceptional, and should be in front
but in that case, bring it all the way out front
the of type is, but not the "returns" type
sure, but we currently call that the "of" type
if you declare a "returns Int" it is explicity not part of the sig
it's just an implicit coercion on all your return statements
could well be
maybe it's an "as" type or some such
on return types for tiebreaking, this is discussed in S12:899
sub foo (::T $b where T === Bool)
maybe it's ugly on purpose
unnecessarily restricting your arg types is construed as bad polymorphism, generally
no, you just think you like strong determinism.  :)
and ugly. :)
?eval 1 as Num
?eval Num(1)
dduncan: most Perl programmers would find such semantics abhorent
all is fair if you predeclare
there used to be an "as" operator, but I think we deleted it in favor of Foo($x)
?eval 1.Num
but that isn't implmented
?eval 1.as(Num)
::T $arg where T === Foo doesn't look the same
Foo $arg can be coercing if Foo is defined that way, but that's the default only for Int/Num/Str types
not really; they're that way because they define themselves appropriately
that makes it mutable
or makes it look mutable, anyway
Bar! $baz
but might be confused with Bar $baz!
dduncan as Diner
the two are not mutually exclusive
I can see arguments for Foo $x as Bar, but the common case is perhaps Foo $x as Foo
which Foo! $x might be short for
mushrooms work
on the assumption that $x as Foo means Any $x as Foo
I'm tired of bouncing now.  I think today would be a good day to replace my old Linksys... :/
cool!
if you need to refactor STD into chunks for some reason, feel free.  'course, cheat assumes it has the whole grammar when it generates its rules at the end...
but we can always cat *-STD.pm | cheat
but if you need to chunk things within the file, like group regex in a subgrammar, you can do that too.
I'm just explicitly giving you permission to restructure original STD if necessary, as long as the top level grammar ends up doing subgrammars.  but if you don't need to do anything like that, that's also okay.
just thinking you might run into unnecessary roadblocks with that approach, and I'll be out for a few hours, so trying to be "proactive"  :)
I know you're already lazy and impatient enough--just trying to convey a little more hubris in your direction.  :)
aloha
konnichiha
Juerd: how much bandwidth do you lose moving out of the datacenter?
in particular, will it slow remote svn downloads for new folks?
whoops, forgot to spinclad++ on s:g/basal/super/
yay
unless [particle]++ sees them...
but we mustn't observe [particle] or we'll break the quantum entanglement between pugs and parrot
it's feature complete except for whatever I've forgotten.  :)
but it's only a parser
I also need to go back and retrofit some of the decisions there back into the synopses, which are a little out-of-date on the grammatical categories
the todo at the beginning still lists four things
status faqs tend to go out of date rather rapidly, which says something about the status :)
but how people respond to the answers often tells us whether they would be good contributors, so it might be worth it
especially if we can share the load
sending people to a faq immediately sort of says "go away and don't bother me"
maybe we can tell people they can get a status update for free if they sign up for a commit bit :)
obra: looks interesting as an intermediate solution, though we can perhaps do better with direct P6-to-Java.  But it at least shows it's possible, I think.
I wonder how much emulation it has to do?
it says bytecode
"how to make a sow's ear out of a silk purse"
though of course I always backlog...
@messages
maybe we could have a micro tell that just tells you to backlog with a link to the irc logger
I figure if someone stays logged in they intend to backlog, probably
when I type dd&lt;tab&gt; and it doesn't autocomplete, I figure you're not on and @tell you
I'm thinking the Array role doesn't provide rw, just the Array class
but it might be some other name
seems not very monotonic to allow removals
well, it's potentially a compile-time error if deducable
"error: this will certainly fail at run time"  :)
but yes, this comes back to the same question of whether mutability is really a role
in the abstract, a mutable object is always just a container for the current immutable value
however, if you implement it that way, it can be very slow
well, I need to wander off, but I'll think about it some
perhaps because I was thinking of haskell when I said it?
I noticed... :)
well, that is the FP view.  the OO view is that a container is a stateful object, not just a reference
but the two views are duals of each other
anyway, vamoosification &amp;
didn't you help write the spec?
heh
?eval say ('foo' eq any &lt;bar blah asdf foo&gt;) == Bool::False
that is bogus
I think 'foo' eq any &lt;bar blah asdf foo&gt; should just return True
not a junction:
?eval 'foo' eq any &lt;bar blah asdf foo&gt;
rhr: yes, that's how I think of it.  I think we're getting eq and friends returning (True|False) to mean "true", and the boolean tests just all happen to test against the True part rather the False part, so it always looks true in boolean context, unless you actually ask whether it is also === False, in which case you get a bogus result
and that's what my test is testing for
@karma lambdabot
prism: which language do you think perl 6 wasn't based on?  :)
P6 will have erlangish semantics in its underlayer, see http://www.seas.upenn.edu/~lipeng/homepage/unify.html
but P6 will also have better transactional support on top
okay, P6 has better transactional support on top  *cough*
yes
yes
I'm downloading Fedora 7...
s/C//
howdy!
the only problem with morning is that it comes at such an inconvenient time of the day...
except when it's an inconvenient place in the world...
Caelum: yes
see util/perl6.vim
no, I just run smokes when I can't think of anything better to do, which is usually... :)
Caelum: do you have a commit bit?
if you msg me your email, I will attempt to send one
thinking about working on something is also considered working on something around here. :)
and feather is far too slow...
darn, my firefox crashed, have to start over...
Caelum: while I'm waiting for commitbit again, what would you like for a project nick?  Caelum?
only in a regex
...almost there...
...almost there...
commitbit sent, finally!
Caelum: it is customary to add your name to AUTHORS as your first commit to make sure everything is in working order
yes
or blah $foo: "bar"
the : rescues the indirect object syntax from ambiguity
?eval say $*OUT: "Hi!"
hmm, wonder if evalbot is still down...
?eval say $*OUT: "Hi!"
?eval 42
have restarted evalbot, appears to be reconfiguring pugs and rebuilding
gonna be a while--this is feather...
none, effective, since a list in scalar context promotes to array
*effectively
well, use on the left of . is scalar, so I'm not surprised that the extra $ is redundant
s/use/context/
there we go
?eval 42
?eval say $*OUT: "Hi!"
mind, it's logging everything to my terminal, so I don't know what it'll do when I log off feather...shoulda redirected to a file, I guess...
probably find out the slowness of feather is caused by some ancient screen treasuring up a terabyte or so of output...
?eval $x := (1,2,3); $x.push(4); $x
?eval my $x := (1,2,3); $x.push(4); $x
?eval my $x := \(1,2,3); $x.push(4); $x
?eval my $x = \(1,2,3); $x.push(4); $x
well, at least it works as rvalue...
the above would have behaved differently if so
pos is in a prespecced state
?eval "a" ~~ /&lt;alpha&gt;/
oh yeah, evalbot doesn't do character classes...
yes, unless we decide that attaching .pos to a string is a violation of some principle or other
but it'd be nice to be able to continue one regex in a different regex like P5 can
possibly .pos would have to be both per string and per thread
or generalize it into a marking facility, and pos is just one convention name for a mark
*conventional
"REFERENCE MARK"
but then we lose our multidim Whatever, sigh
maybe we could just lose the : after @@: as long as we have a space, basically say that a sigil with a space after it is a contextualizer listop
for @@ 1..3 X 'a'..'z' {...}
still pretty ugly...
but fits existing listop syntax better, and is slightly less ugly
hmm, but we can't easily do the same with turning a type into a listop
currently Type: args expects a term after, and bare Type expects operator.  :/
listops are allowed to take 0 args though...
so $class = Foo; could still conceivably work as a typecast with no arguments
hmm, STD doesn't allow func; as a valid listop syntax; that'a a bug...
well, up to a point.  depends on how much better...
moritz: bitrot of some sort, or maybe just audreyrot... :)
I haven't worried about it too much, on the assumption that most folks here also follow p6l.
but my karma suffers as a result.  :)
was gonna install Fedora 7 this morning, but got sidetracked into revising slicing...
forgot to eat too...
anyway, here's the checkin log:
Dropped : from all listop contextualizers, whether sigil and typename.
The @@ contextualizer is now also named "slice".
Consistent with that, we have regularized slice nomenclature:
* A "slice" now always refers to the whole multidimensional subscript, or the list of lists corresponding to that.
* We now try to avoid calling the individual sublists "slices".
* The parameter to a subscript is *@@slice, not *@@slices.
* The term "multislice" is now deemed redundant.
so now basically we can write either
for 1..3 X 1..2 -&gt; $a, $b {...}
or
for @@ 1..3 X 1..2 -&gt; [$a, $b] {...}
and foo $ bar almost looks like Haskell...
being equivalent to foo $(bar)
no, because it would just create a bunch of duplicate keys
you can't have both 1=&gt;3 and 1=&gt;4 in the same hash
you'd just end up with a hash containing 1=&gt;4 and 2=&gt;4
maybe we'll end up with a set context though.  %% perhaps
they're just listops
@tell ddwagnz I never chatter off topic...
Argh!  I woke up with Tristram and Isolde in my head this morning, and now my brain is better than it sounds!
Wagner
could be
google agrees with you.
ah, it also occurs as Tristram
http://www.bartleby.com/65/tr/Tristram.html
so when I played it the title was probably anglicized
"The names of the two chief characters appear in various forms, such as Tristran, Tristrem, or Tristan and Isolt, Yseult, or Iseult."
no, see my linked article
I really did learn it as Tristram and Isolde.
considering T&amp;I is a medieval story, any influence probably went the other direction
but it's also possible the old name mutated in the direction of a more familiar name over time
or was just confused
It's really amazing how many chinese characters arose by confusion with other characters...
I know, which is why I said "the other direction"
but I really don't know enough about the history of the names to know if they're one name that diverged or two names that converged
I think most change is caused by kids hearing what their parents say but reanalyzing it differently in their heads.
not sure I'd call that a "mistake"
ramifications of her liver problems earlier this year
she'll be back eventually, but just needs time
well, basically, her ADHD meds were keeping her liver from recovering from the liver inflamation, so she had to go off them, and it takes time to get over the bounce back effects.
it'll just take time, mostly.
and it still fits in with the Perl 6 timeline of letting it take however long it takes to get to Christmas.  :)
so if she wants to start easing back into doing some things, we should be careful to let her do them without expecting any more than that.  We all have to learn to pace ourselves as we get older...
I know I've had to learn that several times by now.
a few more times than I've gotten younger, alas
ThEn We'Ll See a LOt of tHIs...
we'd have to gather a large corpos of data, alas.
*corpus
so we invite all the spammers to a Spam Day
I don't know if you can invite someone retroactively...
I suspect bayes would notice GPA itself
"php is a great waste of time"
oops
it's certainly wasting a lot of our time here...
just count letters with tr///.
I don't use any serif fonts...
I've only cared about I vs l about once in the last year
a really *good* OCR would care about as often as I do.  :)
Sazanami Gothic++
18 pt for my aged eyes, but the Kanji look good
I don't see any ? on that page...
looks blurrier in firefox than in irssi to me
but maybe that's because I run irssi in reverse video
and one of the reasons I like the sazanami gothic is because it stands up better to antialiasing than the more spidery mincho
at least to my eyes.
which, while much better than 10 years ago, are still not perfect
and with plastic lenses in my eye I only have fixed focus, so if I don't look through exactly the right part of my glasses everything is always just a bit blurry anyway.
I also like white letters on black background because someday we'll have OLED screens, and white on black will use less power than black on white...
so I'm trying to get used to it ahead of time. :)
er, but that *is* p5...
what is this Template thing you mention?
the only TT I'm familiar with is myself...
yes, though as with many things, I've only thought enough about it to keep P6 within shouting distance.  others will write the actual grammars
seems like it wouldn't be terribly difficult to derive a grammar from p6 that is static
indeed :)
it would be pretty easy to knock out those rules in the grammar; supplying some of the missing functionality would be more problematic
though strict is default, fortunately
could probably use an approved list of "uses" that don't change grammar
hard to be extensible without being extensible though
does that include not linking in new function calls?
no, not really; a given construct is always parsed consistently; it would just fail if there weren't a function there to link to by the end of compilation
I think we were pretty careful about that.
might be useful to be able to lock the current grammar down for the rest of the lexical scope or file
just as a general facility
"use 100% pure Perl;"  :)
yeah :/
don't know much about p5...
hmm, well, doesn't do you much good unless you also inline it like constant subs
I'm not aware of any variable inlining of constants in p5
but it's certainly a case where it's likely to remove large chunks of "useless" code
BEGIN { my $x = $^O eq 'VMS'; eval "sub is_vms () { $x }" }
anything $?ish should be considered compile-time constant
that's basically what $? is for
of course, just because $?OS ~~ 'VMS' doesn't mean that $*OS will
if the bytecode is sufficiently portable, could be compiled on VMS and run on MVS
it's already specced that $?OS can vary from $*OS
prolly
"unwarranted chumminess with the runtime..."
in general, one wants to isolate os dependencies into their own files
and it would be *nice* if most of the public interface were OS-independent
which file?
presumably one can compile for different targets if one really needs to
but I confess I haven't thought much about cross-compilation yet
cross compilation in that view is just forcing $*OS to a constant at compile time, where that constant is different from $?OS
$?OS is the os the compiler is running on
$*OS is the os the runtime is running on
if we take that view of cross-compilation as a constraint
(on $*OS)
not if you want write-once-run-anywhere, in which case you let $*OS flap in the breeze and compile everything in
well, a JIT can optimize futher down the way
*further
as I say, most such dependencies should be off in a library anyway
well, it does complicate the naming of modules
nothing says $*OS has to be rw once INIT sets it
for a few modules
in which case, we didn't have very good encapsulation...
well, yes, like module Foo has never been ported to AmigaOS...
that's why we need to keep track of OS dependencies as part of the long name, probably
I'm not so worried about the dead code problem; memory is getting cheap, but yes, distribution can be a pain if ambiguous.
not familiar with that
I think that's a good place for spreading out the polymorphism across OS-dependently-named modules
multiple implementations can share the same API
but the OS names are all adhocly added to the name rather than being metadata.  *that's* the problem
if it's metadata you can just not download the OS's you don't want
if I'm downloading for Darwin, I can look at the Win32 morph and ignore it because I know it's for Win32
I can't do that if the OS is magically encoding in the module name in an ad hoc fashion
here we have some modules that are ...::Win32
and other modules that are Win32::...
no consistency.
well, it's a potentially treeish namespace under OS, I'll grant
where different versions of OS may or may not be considered the same
you can still have arbitrary names, silly.
I'm just saying we can do a much better job of giving modules long names (including identifying metadata) such that it's pretty easy to look at a module "long name" and determine whether you want it or not.
diakopter: ah, I misunderstood you then.
including recursively want, even though you don't know you want it
which is why our long names are potentially hierarchical now.
all I'm saying is that our spiffy extensible "use Foo:foo&lt;a&gt;:bar&lt;b&gt;:baz&lt;c&gt;" scheme can have as much specificity or genericity as we need going down the road.
it's really a kind of big multi dispatch: "find me a module that's good enough"
and if you can't, die
I'm wary of imposing a fixed solution where the problem changes from year to year
anyway S11 discuss long names using version and naming authority, but I can see that os comes into it somewhere too (where os can also have a version and naming authority...)
different uses can be pickier than others, and if a module/multi fails its constraints, you keep looking for something a little more generic
yes, we're mostly just trying to add what's obviously missing right now, but leave the door open for additional constraints on the long name
no, not all metadata, but it's very important that every piece of unique functionality have a unique indentity
(modulo $^Oish tweaks)
perl has not survived this far by being worried about limit cases, but about common cases.
first we do easy things should be easy
later we worry about the impossible
the world wide web exploded because they have a nice extensible way to name things.  Once the URL was invented, everything else just kinda happened.
at some point the community steps in and refactors, that's all
and with the authorities, we can now do that
well, some subset of %Config is the identifying part, and some of it is noise.
Um, no.
You forget who wrote Configure and metaconfig in the first place.
I'm the one who originally argued for feature-based configuration and not OS based. :)
No, I was only somewhat right then, and only somewhat wrong now. :)
yeah, but you're in the Down Under, so you see the graph upside down
well, anyway, I think it should be obvious to any casual listeners that we've thought about it a lot, and need to continue to think about it s'more.
well, we got pretty far with it.
what do you mean by OS?  :)
indeed, that is most of the design of Perl N, to do just that.
looking forward that.  :)
s:2nd/&lt;ws&gt;/ to /
we're still honing the rough edges for a while yet, so feedback on P6 design is welcome.
eyes going crossed, so I should probably retire soon, having learned to pace myself several times already. :)
don't want to learn again
night &amp;
I suspect L_R is the expert on Win32 compilation around here
Personally I got frustrated with cygwin (probably too easily) and used strawberry
but if you want to whack on it and make it work, a lot of folks would probably be grateful
mainly you have to be careful not to mix them up, I think, since the libraries are incompatible
I seem to recall having to point my /usr/bin/perl at the strawberry perl to keep it from mixing in the cygwin stuff
or something like that
aharoni: the worst anyone would do is revert it. :)
well, they might call you names, and revert it. :)
but we work under the "easier to get forgiveness than permission" principle around here
maybe make it optional with an env var if it is likely to bother anyone
but its not like the build is exactly quite now
*it's
so I don't think anyone will mind much
I don't think any synopsis discusses it in detail
basically, every pad has its own $_ and $/
an official Routine does not initialize the value of $_, so it starts undefined
blocks without arguments assume the first argument is optional, and if supplied, binds $_ to it
otherwise binds to OUTER::&lt;$_&gt; as default
so the signature of a bare block is something like ($_ = OUTER::&lt;$_&gt;)
maybe with an "is ref" or some such thrown in the middle so it stays rw
don't think so
p5 tends to dynamically scope the "current" match, though that is inaccessible directly
so I don't think people will necessarily expect $/ to escape from a block
pattern matchers look for $/ in their outer scope and alias it to their result
it's possible that the regex version of $/ should be named something different from lexical $/
right now, we use the same name for two rather different things
if we split them, then $/ would automatically mean the outer one in a closurely way
and we wouldn't need to have a special rule about what $/ means
hmm, but if we split them, then the definition of $&lt;foo&gt; changes :/
me either, I've already undecided that :)
ENOTENOUGHCOFFEE
maybe you could ask the dons for lambdabot's email address, which could be related to http://www.cse.unsw.edu.au/~dons/lambdabot/COMMANDS
run it, but perhaps not link it to a cygwin compiled module
depends on whether the file formats are compatible, I imagine
you *might* be forced to compile ghc under cygwin  :(
if someone hasn't done it already somewhere...
but I'm just guessing--don't let me discourage you  :)
hiking &amp; # spouse wants me to survive longer for some reason
obra: pong
I slept longer than I thought...
blurg
I'm more or less ready
Let's see, I'm allergic to crepes, eggs, waffles, pancakes, sandwiches, and burritos.  That makes it easy.
See S02:829 for p6's take on Sets and Bags and their relationship to hashes.  Pretty much exactly what you folks were reinventing here...
yes
or Sets as Bags that can only count in Bool
s/3/2
course, if people actually did read them and comment, we'd have to change 'em all again :)
need to distinguish values from containers
sets and bags are immutable values.  a KeySet can represent one set at a time, but when you change it, it's representing a different set
no, that would be a good thing for someone to work on
there might be some of it in Prelude.pm, but I think it's mostly in Haskell
to the extent that there is anythin
well, they'd be roles in p6
nap &amp;
hmm, most things sound tasty.  My wife married me because I'd eat almost anything... :/
water you talking about?
oh, somewhere about medium-light would be good
that would be fine by me
bloonix: currently works as follows:
?eval my %a = a =&gt; 1; my %b = b =&gt; 2; sub foo (*%hash) { say %hash.keys }; foo(|%a,|%b)
thud &amp;
bloonix: positional args aren't composable.  BUILD is required to be named, and the default new can only understand named, but you are free to write your own new in any order you like.
well, first, you can't put a submethod into a module, because it needs a class instead, presumably with some attributes
it's the names of the attributes that you use
class Point { has $.x; has $.y; }; Point.new(x =&gt; 1, y =&gt; 2)
fixed
bloonix++
@tell masak two other reasons for sigils: to distinguish nouns from verbs (the absence of the sigil indicating either a verb or a type) and finally sigils open up an extensible namespace for twigils, in case you want to add more weirdly scoped variables
bloonix: yes, the synopses tend to be long on what and short on why
biab
a module is really just a package with a different name so that we can 1) distinguish p5 from p6 and 2) have a different export mechanism
shouldn't I think
sec, have to check if taxi is here for airport
no, not yet
basically, p5 didn't distinguish packages from classes, and it turned out to be very confusing, along with not distinguishing subs from methods.
arguably, since a class can also be used as a module, modules are redundant
and since we fixed sub vs method, less confusing
but I think it's useful to be able to group non-OO subs in a place that explicitly indicates no constructors need be autogenerated
package is the same as module, but doesn't support "is export"
taxi here &amp;
a macro is just a convenient way for a user to write a new grammar rule
there is some speculation in the comments at the top of STD about that, but obviously they are not entirely fleshed out yet.
certainly you are correct that it doesn't make much sense to swap in grammar rules without also adding corresponding semantic rules
unless you're just testing for syntactic correctness...
but basically you just never return something from a grammar reduction that you don't also have a way to handle downstream
there is no "the compiler"
Perl 6 isn't a single language
{*} is just a kludge currently to avoid speccing the AST transforms in STD.pm
the important point about {*} is that it is bound to a semantic identity
if you change the semantics of {*}, then you have to give it a different identity
p6 is all about maintaining identity of the "current language"
yeah, though I think they are kinda tending to clutter STD in the same way that explicit reductions would
maybe we can get those indirect like the reductions
well, of course, minimally you can just interpret the AST like pugs.  everything else is optimization.  :)
which, of course, explains pugs blazing speed  ;)
*pugs's
*not* interpreting the AST directly is one way that p5 got faster than p4
but I completely agree that it's a fair amount of work, or maybe an unfair amount of work
we were working on something like that earlier in the design of p6
mostly based on binding tree nodes to signatures
with a sufficiently restricted subset of returns you can even make it reversible
after having spent months teaching the p5 compiler not to forget things just so I could do p5-to-p6, I am a little more pleased with the idea of reversibility than I was 15 years ago...
[particle]: well, by definition a comment wouldn't affect anything, but it also doesn't give you anything that actually gets called.
a &lt;?{*}&gt; assertion doesn't affect longest token and still gets called (eventually)
I don't like smart comments, actually
the #= stuff notwithstanding
I think we even mentioned &lt;*&gt; a couple of weeks ago.  It's certainly available.
#= was aimed at enabling a preprocessor kludge
I wasn't expecting pm to turn it into real smart comments. :)
masak: depends on which subset of p6 you want to run.
I was hoping the implementors would just all get together and agree on an AST, just like they did a grammar, oh wait...
I'm going to have to spend a lot of time backlogging after lunch...
the irc logger seems to be broken
&lt;p&gt;&lt;a href="/irclog/out.pl?channel=perl6;date=2007-07-29"&gt;&amp;larr; Previous
doesn't like the &amp;, apparently
false alarm; did a yum upgrade and it confused firefox till I restarted
demq: your code emitter can just emit ~'foo' ~'bar' ~'baz' and it'll do the right thing
assuming some higher precedence operator doesn't strip your final arg, of course...
in which case you might want parens
but I'd say in general a code emitter should have a better sense of the structure of what it's doing than to use tricks like that
I've always been kind of insane about making code emitters produce code that resembles what a human would do
whois pugs_svnbot
hmm
moritz_: um, use it in an rvalue context?
you don't exactly; in fact, there's no guarantee that $bar even exists yet at the time foo is called.  foo must return an object that has a STORE method of some sort.
see S06:249
we don't follow the getters/setters model because it confuses the identity function of foo() with the operations it supplies
you'll note our autogenerated methods don't do getters/setters either, unlike Ruby
even within a class, if you say $.foo = 42 you can't be sure whether you're setting $!foo directly or calling an lvalue method
with getters and setters you always have to keep track of whether you're setting a variable or calling a method, and that is a leaky abstraction.
dduncan: yes, &lt;?ws&gt; can match either of those.
and I think the proposed radix notation kinda sucks visually
we certainly can't use :f
I think having something that looks like part of the number that isn't is precisely what sucks
I don't have any problem with the 16
well, sorry, but I think it *wouldn't* be nice...
from a psychological point of view
also, why specify base 16 as f, which is off by one?
yes I know, but it still means 15
where else in the world do we try to make metadata look like the data it describes?
have the appropriate amount of fun  :)
yes, I'd suggest reading S05 before trying to understand STD
square brackets are only for grouping now
you use &lt;[...]&gt; for character classes, or better, named classes
you just use which is more convenient
start with a token, and if you find yourself scattering &lt;?ws&gt; all over, then you probably wanted a rule
if you want backtracking, you probably wanted a regex
there are really only about two places where STD wants backtracking
well, in that case there's no difference, since foo can't backtrack
literal words don't need to be quoted
I doubt anyone's tried it in the last N months
so I'd be surprised if it worked
decommute &amp;
n
if someone wants to hack in real Range objects, that's be cool
*that'd
it's a pun on methylate
?eval my &amp;square := -&gt; ($val) { $val**2 }; square 20
interesting that it gets rid of the /1
I think it should print the return value iff there's no output maybe
#echo `ls`
it's an alias
pmurias: yes, except you can't start a term with * because it'll look like "whatever"
* is just a twigil, not a sigil
and is the same as $*foo
the :: isn't necessary unless you want to say $*::($foo) or some such
you really want to say %GLOBAL::ENV every time you want to get at the environment?
or $GLOBAL::IN
?
just extend the twigil token from the standard grammar.  :)
nope :)
hmm
well, return is defined to return a Capture, so that isn't always positional
that's more or less what a Match object is supposed to do, but pugs doesn't make it easy to derive from Match, alas
I'll be en route to Vienna tomorrow...
but 'nite
q!foo! should work
sunnavy: S02:543 gives rat and complex as examples of native types, though of course a rat composed of two ints is not able to represent as many values as a Rat of two Ints, which are arbitrary precision
I am sitting in Vienna airport, btw.  freewifi++
native type support may be somewhat lacking in 6.0.0, esp for marginal types like that
and rat and complex were given more as examples of possible native types
it'll depend on who implements 6.0.0 first, and whether they manage to get those types in.
lots of things are still negotiable
yes, block comments are gone
fixed, thanks
well, they're calling my flight, so...
decommuting &amp;
stupid DSL line...
masak: are you asking how local behaves in Perl 5?  yes, local clears the array in p5.  (but temp doesn't in p6)
are you using "local" to describe a "my"?  that's...confusing...
I agree that my should start () in either p5 or p6
that's what they're called technically, though of course that's a bit wrong too...
if they were really and truly lexical then recursion wouldn't work
and they'd act more like state vars
actually, more like our vars
it's Str
which is a kind of undef
which makes $s .= new works
*work
well, it's a problem of distribution: if you have my Str @array, then each individual element is notionally Str/undef by default, but the array as a whole is just empty
but for more on bare typenames grep for "protoobject" in S02 and S12
speaking of which, Damian and I are planning to break &lt;?foo&gt;
and make &lt;?foo&gt; symmetric with &lt;!foo&gt;
so that neither eats positions
current &lt;?foo&gt; needs to change to something else
so &lt;?ws&gt; might end up &lt;=ws&gt; or &lt;.ws&gt;
or possibly even &lt;ws&gt; if we flip the capture default
that could work too, but it needs to interact well with whatever the naming syntax ends up
I'm thinking $&lt;foo&gt; := is too heavy
so we might end up with &lt;foo=bar&gt; with &lt;=bar&gt; as a degenerate case
meaning &lt;bar=bar&gt;
but it's not entirely thought through yet
all I know is that &lt;?ws&gt; must get fixed
it's not assignment
could just as easily use &lt;foo/bar&gt; and &lt;/bar&gt;
but the = is a bit more suggestive
but if foo= is a prefix like ! or ? then maybe even &lt;1=(...)&gt; falls out of it
grr...
I think the telco unilaterally upped the speed on my dsl modem and made it flakey...
but anyway, then you could say &lt;foo=bar=?!!?ws&gt; if you wanted to
currently only ? and ! are recursively defined on assertions
I'm just saying foo= could be too for naming
I suppose in a sense &lt;+alpha+digit+[_]&gt; is also recursively defined
where +alpha is defining the base set and subsequent terms refine that
though I'm not sure recursing back to ? or ! makes much sense within such a thing, so it's a different recursion
sorry, just thinking out loud here...
by the way, I've pretty much figured out how to partition metholated rules into the longest token part and the "action" part.  at least, I have a hand-coded example.  so I should in theory be able to model the longest token matching pretty soon.
albeit by exhaustive calls rather than DFA matching
and fortississimo?  they've been there all along, pretty much
had to have some story for p5's scalar ..
I just lowered their prec lately
so you can write $line == 42 ff $line == 45 without parens
I don't think ff will be smart enough to match 42 implicitly against $. since there is no such variable in p6
but maybe we could have a $*LAST_INPUT_HANDLE...hmm...
in which case ff could match an Int against $*LAST_INPUT_HANDLE.line
yeah, I think p5 dynscopes it, but I could be misremembering
well, it plays other games with local($.) anyway
maybe that's what I'm thinking of
basically local($.) does dynscoping of last input handle
another way of looking at it is that $. in fact *is* last_input_handle but just happens to numerify to the line number
anyway, if input just binds $*LAST_INPUT_HANDLE to the current handle it's probably sufficient for emulation
or we could go as far as to have a $. which is lexically scoped, I suppose.  don't want to make closures any heavier though
not that many people ever used it
well ff was for a2p, fff for s2p
to mix p's
but some number of people figured out what flipflops do and use them productively
that's more or less what I'm proposing, since $. is really $handle.line, for the right handle
so I'm just thinking input should set $*LAST_INPUT_HANDLE and leave it at that
anything that wants $.-like functionality just looks at that global
yeah, I did one of those too.  :)
it's hard
I think p5 still gets a bit confused with if/else
esp if the line transitions get optimized away
they track positions in the string, which can be translated to line numbers as long as you keep the string around
or a table of line-number offsets
speaking of things that are too complicated to understand...
but yes, we need to be careful not to throw away useful information
p5 was very good at throwing away useful information :/
anyway, p5 knows at run-time the line number of the statement you're executing (and all its callers)
&lt;before foo&gt; isn't quite the same as &lt;?foo&gt;
&lt;?foo&gt; would be the same as &lt;before &lt;foo&gt;&gt;
so before isn't entirely redundant
but other than that, eys
*yes
hmm, pity that &lt;[...]&gt; is taken, or &lt;0=[...]&gt; would naturally do a numbered capture (under the recursive def theory)
hmm, maybe character classes could dehuffmanize to [[ a..f ]]
cool!  :)
to avoid people miscounting () maybe?
'course, already have that problem with &lt;( )&gt;
but right now &lt;( and )&gt; aren't required to be symmetrical
and if we defined foo= recursively, &lt;foo=(...)&gt; would have to be symmetrical, implying that &lt;(...)&gt; are too
well, &lt;+alnum+[[\-]]&gt; maybe
heh, great minds... :)
esp if we teach people to use more whitespace &lt;+alpha +[[ \- ]]&gt;
the idea was to require \ to catch thinkos like a-z
though just catching a-z and a-f and 0-9 would get most of them
I find I usually just use &lt; $ % @ &amp; :: &gt; instead of a char class
they understand a..z is the main thing
which is, of course, usually wrong. :)
yes, that would theoretically work, I think
assuming anything listy (including Range) does | matching
okay, I'll call the juerdwords  :)
*them
if ]] were the terminator then not even ] would need \
whitespace is your friend
s:g you mean
yeah, so is ..  :)
and you'd have people leaving the | out of [0..9 a..f] accidentally
apart from the .. means . . problem
I'd be more inclined to special case .. within &lt; $ @ a..z &gt;
or maybe &lt;&lt;..&gt;&gt;
a-z is 'a' with the 'z' removed
and ranges are everywhere else .. in P6
that's spelled !~~ in p6
kinda
I like .. for ranges
I was talk about the EBNF -
*talking
which if I recall works for more than character classes
well, the whole charclass idea is breaking down anyway with some chars being prefixes of other chars...
currently /(A) $0 !~~ B/
and maybe /(A) !~~ B/
except that's inconsistent
so probably the first, assuming that the left term of ~~ doesn't rematch
otherwise I'm not sure how you'd write the first in terms of the second
and it's nice to be able to match against a $0 that was captured some time ago
or maybe ~~ just distinguishes $0 ~~ from [$0] ~~
in which case both forms could be made to work
though it's a bit of a discontinuity
well, that's essentially A !~~ B, which I think read better
and the &amp; again forces you to put the things contiguously that have to match the same
it also implies that the left and right side of &amp; come out to the same length
which means &lt;m...&gt; would magically scan to any length outside of itself
which is odd
and all of this because I don't like &lt;?ws&gt;  :)
hmm, if we can teach peopel to put whitespace consistently after quantifiers, +[ a..z ] and -[ a..z ] could be made to work
I think we'd have massive rebellion if we tried that...
but if +[ a..z ] works inside &lt;...&gt;, maybe it should work outside too
well, +[ would be the token
I'd think I'd want to reserve [+ ... ] as a synonym for [ ... ]+
in case people want their quantifiers up front on brackets
I was thinking it would just be a pragma to allow prefix quantifiers
but that does work against +[] for cclasses
sigh
*nod*
not sure how well it composes though
not arguing that, question is how it composes
what moritz_ said
how do you combind char classes?
and do set ops?
currently we have &lt;+alpha-[aeiou]&gt;
&lt;alpha&gt;+beta wouldn't work at all
and that's kind of a wart
double the warts  :)
&lt; rhr&gt; hmm, I'd be more comfortable if everything inside the [] was part  of the cclass
it's like saying the first char inside "..." changes its meaning
you wouldn't like that
yeah, well, it's kinda hard to put a class modifier outside the class when it's the whole file...
so the "is" is outside the delimiters
in class Foo is Bar {...} too
but the insides of a character class are much more like a string than a program
I much prefer the current "\q[...]" for that
and these are all escape hatches for when the outer declarative style is insufficient
s:i/.../ is preferred over s/:i.../
and class is Bar {...} is definitely preferred over class { is Bar; }
and q// is preferred over "\q[]"
but [+...] forces them to use the inside form
hmm, since we restricted adverb args to parens in regexen, maybe :i[ pattern ] would work now
in a sense it is
but it's just interpreted as a pattern rather than as an array subscript
anyway, :[ a..z ] would be a possibility then
I'm not entirely sure the whole hash thing isn't going away, at least for 6.0.0
we put it in for STD, and then didn't use it.
yeah :/
it's for saying "this isn't really a longest token, even if it looks like one"
but the whole "use the key as the longest token" thing broke down
because we wanted longest token to include anything DFAable
and the hash mechanism didn't do inheritance correctly anyway
so the user couldn't define new entries without duplicating the hash
that's why STD now uses infix:sym&lt;+&gt; and such
those can interleave user-defined and standard operators
working on it. :)
yes
my first step is simply to separate the token from the action
only an STD translator for the moment, but a proto of something more general
well, that's assuming nothing is ratcheting currently
I also have a ratchet version hand-coded
wolverian: no, the for loops are to generate all the possible matches
but everything is (mostly) single-assignment or better
the ratchet version currently rebinds $_ as a shorthand for nested closures
but the whole thing with the gathers and takes is assuming pure functional programming so that many matches can be "in flight" simultaneously
relying on laziness not to generate extra paths through the pattern when they aren't needed
anyway, it seems to work on the metholated STD, at least up to parsing 42+1
in the gather/take version, failure is indicated generally by returning a null list
in the ratchet version, I'm currently assuming a boolean status, but it should probably be using definedness as the definition of success if we're to generalize it to logic programming
optimizing non-ratchet to ratchet will be an interesting exercise in determining which rules are 1-1 (or 1-0) vs 1-many, with transitive success taken into account
because the scope of the gather has to be determined
most of those are unnecessary, assuming a longest-token autogenerated lexer
I only weed out some of the constant string matches currently
could extend it into &lt;?before &lt;sym&gt;&gt; matches, but that's a hack anyway
really needs to walk the tree to make the token/action separation
but I wasn't in a hurry to do that optimization because I wanted to exercise a lot of STD code anyway
most of the time is still pugs reparsing anyway...
when the thing stabilizes it'll definitely be a candidate for precompilation
still don't quite have binding working right yet either
I can attach names to matchstates, but .matchify isn't quite succeeding in pulling them all in to the new Match object, or maybe it's losing track of them after
since these states are continually cloning themselves
well, I've only ever had one compiler course, and didn't grok most of the theory...
for many years I relied on yacc to tell me what it thinks.
but yacc isn't up to doing Perl 6
well, to the first approximation the Perl 6 compiler is simply recursive descent, with a bit of operator precedence thrown in for good measure
that's all
most of this recent fanciness is just from attempting to autogenerate a lexer from the grammar
well, and all the extensibility stuff is also basically research
most everything else is just sugar :)
actually, that's not the ratchet version that works, since captures are problematic
commitbit comes up in about 5 seconds now
anybody want a commit bit? :)
and Perl will then be old enough to drink.  :)
Audrey must take good care of herself.  I'd much rather have Audrey alive and Perl dead than the other way around.
worry is generally construed as obsessive, while concern is not
"to worry" actually comes from middle English "to strangle"
as what a dog does to its prey
so it still has some violent overtones, though it has softened considerably
don't let it worry you.  :)
afk &amp; # walking, worry about busses :)
s/nekobuso/nekobasu/ &amp;
you certainly don't want to say "busu" in Japan, or any old ladies nearby will take great offence
since it means "old hag"
but buso doesn't mean anything, afaik
anyway, if I ever get hit by a basu, I'll hope it's a nekobasu...
afk &amp; # really
or GLOBAL::GLOBAL::GLOBAL::GLOBAL::GLOBAL:: if you want to sound like a turkey
avar: note that lambdabot is down currently
pugs: say $*PUGS_VERSION
it's at patchlevel 17871  :)
which happens to be the svn revision number
amazing coincidence, that...
I just did an svn up
(successfully)
MU9214: you mixed up " with ' there
pugs: print "test"
MU9214: if you want to play with pugs heavily, the best thing to do is to install the current svn version
(the CPAN version is nearly a year old)
or you can try the runpugs webpage
they've been "upgrading" it lately, so maybe it's busted
MU9214: looks like the development version is at http://feather.perl6.nl:8080/runpugs/
the run.pugscode.org page doesn't have an obvious link to actually run the page.  I had to go through the "no javascript" link to actually find the page
MU9214: that looks quite ancient, and mixes up the pugs install with the parrot install
http://www.perlfoundation.org/perl6/index.cgi?download_perl_6
be sure it's at least version 6.6.1
and the moment you want to fix something, someone here will give you a commit bit :)
don't think so
you can probably just install http://haskell.org/ghc/dist/6.6.1/ghc-6.6.1-i386-unknown-linux.tar.bz2
or use bunzip2
how much memory?
but compiling pugs will also chew up a lot of memory
even if you have binary ghc already
it'll be unusable while you're compiling Parser.hs  :)
it's quite likely to thrash while compiling some of the larger .hs files
kb6 and parrot are moving faster at the moment
kp6 rather
my keypoarp is pyslexic
fedora
might be pretty ancient
what revision?
I'm not sure bare 6.2.13 shows the revision number.  If not, it's almost a year old.
we were about to roll a new version when audreyt got very sick
she got hepatitis
you could get an account on feather and run it there
or ^D
I think you're just about to the point of bragging about a 17 day compile time...
I used to dream that our old black-and-white TV magically turned into a color TV.  But that never happened in real life...
most of that is startup time having to do with reading in the Prelude
(currently stored as yaml)
when we get the Prelude compiled straight to Haskell pugs will start much faster
of course, it starts much faster on a much faster machine as well... :)
yes, Match isa Capture; it adds .from and .to attributes, and maybe others
I believe it is likely to end up real, but likely with some restrictions on just where you can put it
since the order of the regex is not necessarily the order of the code that results
one can implement /a b/ as (match a).map: { match b } or map { match b }, match a
and I've had it both ways already, and several other ways.  :)
I like the :my syntax better than, say, &lt;my ...&gt;
since it's not an assertion, and :foo influences the subsequent lexical scope anyway
:my just does it more violently
biab &amp;
it would be possible for #line to have a runtime effect, but that would also be very small
you'd have to be relying on the line number somehow
and feed it a large line#
for example, if your program took the factorial of the current line number...
is the sign of sanity + or -?
one of us must be redundant... :)
rudundant array of insane developers
maybe it's a match
just put it into the IO monad, and everything will work out
or rather, you will have worked everything out by the time the compiler is happy  :/
memory is a necessary but not sufficient condition to make the Haskell compiler happy :)
dlocaus: did you feel the earthquake last night?
I figured you did, given your pacbell location
which is very close to my home's
I'm also on snfc21
though not as far as irc knows...
let's see, that puts you at about Santa Rosa
or Dunnigan :)
our cats always wanted us to stop the rain
I was on top of a stepladder when it hit, so now I've fulfilled one of my life's goals.
cats always do that in the doorway even when there isn't snow
anyway, the epicenter was only about 15 miles east of me, so I got a pretty good ride
I was about to do a circuit test on the tweeter of the right speaker in my church, which has refrained from tweeting.
the speaker, not the church
it's an ancient Yamaha speaker that weighs about two tones
*tons
well, 1 volt is not usually much of a problem
funny thing is that I was the guy who put the extra earthquake straps on those speakers 15 years ago
'cause they're right over some of the exits, and I could just imagine them coming down on people panicking and running out...
actually, they only weigh about 119 lb each...
but that would still be a bad day for someone
anyway, I didn't realize at the time that it could have been a bad day for me.  :)
yup
not really, wasn't the SAF this time
but given the overall trend here, they're probably a few fractions of an inch further apart now
calavaras
interesting question is now whether the hayward will pop off, given this was right at one end of it
water is divisible, y'know...
what's so sacred about 55 gallons?
rock on.  now all we need is the drummer.
darn it, now you've gone off topic.  :)
let me guess, you're running 5.10 like me, 'cuz I get the same error
s/CREDITS/AUTHORS/ # a forgivable slip twixt parrot and pugs
*nod*
moritz_: there isn't really a hash context; pairs don't decide how to behave until they get bound or assigned, so list context generally suffices (of course there's a referential context that expects a hash object/role, but that's just a type)
Tene: just my laptop is starting to go gimpy in spots, none of which are quite showstopping, like the cd reader keeps ejecting by itself.  :)
and I've got a bizillion messages saying hub 1-0:1.0: over-current change on port 3
and the space bar doesn't work some of the time when I push it with my right thumb
rgs: what's the Q?
S03 sez:
Array     Hash      hash slice existence    X.contains(any @$_)
yes, only one item needs to match
and .contains is a key match
not a val match
P6 kind of views hashes as sets with an associated piece of data called the value
Tene: yeah, my shoulder biceps tendons don't like to be used quite as much as I use 'em.
and I've been having trouble sleeping because of it, which greatly reduces my productivity
but I think I'm getting better, except when I don't think that...
doesn't seem to correlate with keyboard use, more with heavy lifting and pushing the car door open and such
and I've got lots of keyboards sitting around  :)
most of mine are spare because the new computer came with a new one, and with four kids you end up with lots of new computers periodically
and keyboards are the easiest thing to scavenge from an old computer
sure, but that's kind of like ants trying to decide which way to push the huge crumb :)
hmm, my sister-in-law just had new hardware installed in her shoulder...
can you do it on a volunteer basis?
I'll bet TPF would give you a tax writeoff for it...
@tell ispy_ you can use "for %hash&lt;something&gt;[] -&gt; $element { }" to get at all the elements; scalar values don't automatically flatten in a list even if they happen to be compositie objects
yes, the basic problem with eval "" is that it has to reparse the entire string, including (often) large quantities of non-varying code
a quasi quote allows you to parse the non-varying bits only once at compile time, while still allowing you to plug in bits of AST for the varying parts
not only is this more efficient, but it's also more secure
(much like the placeholders that DBI uses to prevent SQL injection attacks)
seems like it, doesn't it?
on the other hand, we can probably parse bits of code with an eval-like operator that returns AST
as long as the parser knows which rule to start with
so as long as the same rules are called, it doesn't matter so much if the trees are different
but that approach would not be quite as safe as directly constructing AST
so yes, I'm hoping for convergence there
or maybe there's some common AST form that each implementation can transmogrify into its own form
pmurias: correct
thunk &amp;
rhr: no, formal parameters can't take subscripts
mncharity: not exactly.  MY should give a view of all lexically scoped declarations including "our" and "state"
arguably it's misnamed
also, it doesn't fallback to GLOBAL under strict
(or do the package CANDO lookup either)
under strict, if it's not lexically declared or imported, it's not visible
you can certainly apply subsignatures to array arguments, so there's doubtless some way to work it so the nth element gets bound to a particular variable name, but subscript notation doesn't have much to do with it on the formal end
you can match a signature to any individual listy parameter using [$a,$b,$c]
so $c is by definition the 3rd element
see S06:1328 "Unpacking array parameters"
lunch
&amp;
Auzon: you have to have a comma after map's block, unlike in p5
[particle]: skip does not require a block
and you can leave out the 1 on the "1 skip"
if you say 3 skip a block only counts as 1
I prefer "hey you!"
hey me
a statement counts as starting at a line with "is" et al, and terminating with a line with  ; (and optional comment)
I finally got my pugs smokes working again by skipping the tests that spat out malformed utf-8
we probably need another verb in fudge like "inline" so we can just insert code to call "skip_rest" and such
I made fudged files end with exit(1) so they come out "dubious" despite passing :)
what version of ghc?
(I use svn so can't help with darcs)
yow
still at 6.6.1 meself
[particle]++
It's actually quite fun to watch rakudo following in pugs footsteps wrt testing and development
it's a concrete example of the good kind of cross-fertilization
and a sign that we can use our differences as a strength rather than a weakness
anyhoo, thanks for helping with fudge
zzz &amp;
you either want to drop the 2 or the block there
the block only counts as 1 skip
probably still need a way to say the following should be multiplied by N for loops and such
maybe I should force the count on a block to be interpreted that way
but I still think it's an attribute of the block, not the skip command
since it's shared by all platforms
maybe a #?all: scale 5
or some such
I'll think about it overnight.
meanwhile, it really doesn't matter so much if the count gets off
well, didn't get a nap today, so really need to thunk...
zzz really &amp;
hmm, does that work for native types, I wonder...
well, you need to have a representation of the bits somewhere, and there's little point in duplicating if you don't have a machine code that inlines and forces indirection
instead
and as long as you keep your readonlyness straight, it works
well, it was easy enough to change them in Fortran
the Internet is a big place
it's possible that there are universes in which Perl 6 is done already, and maybe the Internet leaks between universes.
sorry, he's rocket lee in that universe
it's a strange quirk of english that jets aren't rockets, but rockets use jet propulsion
we'll release as soon as we get up to about 40,000 passing regression tests.
so you'd better get busy :)
to the first approximation, a capture is just a list of generators
some of which are marked as invocant or named, but to begin with they could just live in a list
and the methods could comb them out of the list on demand
well, $ @ % &amp; are essentially just methods too
I don't see why they have to return containers
they're just context
no, it returns an item
and @ returns a list, not an Array
sure, but 1.STORE fails
only in the sense that everything is an object
and all objects are containers
presumably FETCH would be a noop on a nonScalar item
you only need a Scalar when you have an lvalue, not an rvalue
$foo = 42 requires a Scalar on the left
if you say $foo := 42 then $foo isn't in fact a Scalar anymore
and $foo = 1 will fail after the binding
just like Array or Hash, but not needing a subscript
that's for creating an unbound call?
seems reasonable; the syntax is designed so that you can sort out the inf/pos/named at compile time
.item .list .hash are the corresponding context methods
(and .slice is a variant of .list)
well, sure, low-level binding needs to do whatever will be efficient
and even when binding to *@_ and *%_, those proxies are only the *remaining* args
so shouldn't be confused with @($capture) or %($capture)
you do probably need to be careful that you have a way of preventing eventual assignment to a formal parameter that isn't declared "rw", even if the actual argument is "rw"
but it's just something to be bear in mind
that's fine; is how all computers really work anyway...
well, most of them
there have been computers with fine-grained ro/rw attriubutes
sounds like you're on the right track
certainly you want the mechanism to be fast when it can be proven that a formal parameter cannot be written to
no point in protecting it if there's no threat
if protecting it implies overhead
have you thought about optimizing multiple dispatch yet?
depends on what you mean by native
certainly captures and signatures are at the top level just values
it's only by indirection that you get generators or containers
Signature and Capture are listed as immutable in S02
well, sometimes you have to box values
and most value types are punning with an identically named role
well, in a sense there is no int type
the type of int is Int
but with restrictions on storage
yes, Int is a role that can be mixed into make other RIs
but we can restrict Capture/Signature, or call 'em capture/signature, if we need to
you don't have to convince me--I want dispatch to be fast
the lowercase ones
we still might like a Capture role that can mix
for instance, into Match objects
but then you just have to unbox to capture
if you use it that way
maybe the original boxed Capture goes through the invocant if you don't have one.
maybe not
bbl &amp;
lichtkind: optimal in which dimension or set of dimensions?
(it's primarily optmized for the visual dimensionh)
it's an unusual thing to want to do
and the triangle part of it is kinda pretty
yes, the left vertical and the backslash suggest a triangle
[\,] 1..10
1
1,2
1,2,3
1,2,3,4
1,2,3,4,5
almost the same slope even
well, you and me both :)
not likely unless somebody comes up with something spectacularly better
yay!
I need to convince someone to make a specsmoke target for rakudo...
I think we should probably have 40,000 tests by the time 6.0 comes out
well, I'd be happy if anything ran all the tests we have now  :)
(except for the incorrect ones, of course :)
using prove6?
main problem with prove6 is I think it has to run in top-level dir
but maybe that has been fixed
oh, t/harness is parrotland
perhaps t/harness should be taught about fudge
oh, perl6/t/harness is already taught
looks like you have to use --fudge
I mostly just "make spectest" or run the *.rakudo file directly
I noticed that rakudo doesn't seem to do eval yet, through try seems to work most of the time
todo() required two arguments till earlier today, and fudge only gives the reason argument
since it marks each test individually
and it looks like the only way to have default arguments is via multi
todo should work now, as long as you have the most recent Test.pm
if it blows up the parse, use skip
since eval doesn't work yet
try works at least some of the time, but doesn't help with parsefails
the point of the if is that there might be a sequence of tests interspersed with non-test statements, and we only want to mark the test statements, which are recognized by putting is/ok/etc at the beginning of the line
looks like it's working okay to me
I mean fudge looks like it's doing the right thing.  my perl6 blows up on the first index call
without the change
the correct 2 tests are commented out
so the $IS is recognizing the "is" on each line
suppose some test had "say '# comment'" in between those lines.   It would mark the say rather than the 2nd is with your change
night!
decommuting &amp;
:)++
:bytes would also need to know normalization
though I suppose one could make a case for :bytes&lt;nfd utf-8&gt;
or vice versa
but I don't see a strong argument either way for bundling/unbundling
bundling associates it more clearly in people's minds
and I don't know that :enc makes any sense without :bytes
(or :bytes)
on the other hand it could be viewed as setting a lexical default
"whenever I say :codes below I mean :nf&lt;d&gt;"
I dunno, whichever way we do it will be wrong :)
well, in perl tradition, anyway...
crumb, I just figgered out that binding should be &lt;- and list assignment should be :=
that's an extension of the normal mathematical notation 1 &lt;= $roll &lt;= 6
with the additional constraint that both rolls have to be the same
you can string together as many comparisons as you like in p6 that way
otherwise you'd have to write
okay, nevermind
I don't want to write it out... :)
although it shouldn't really be using === there when == would do
no, it's a serious proposal to do away with the arcane disambiguation rules in S03's description of assignment
yes
the proposal is that = always be tighter than , and := always be looser
(assuming the theft of := from binding)
::= could be &lt;&lt;= but I dunno about =:=
&lt;-&gt;
oh wait... :)
actually, &lt;-&gt; would work, I think
it's &lt;=&gt; that wouldn't
on the other hand, could just be VAR($x) === VAR($y) with no loss of clarity
so we could probably just do away with =:=, cute though it is
I can be a ruthless sob at times...
biggest Q is how to get there from here, I think...
first need to invent &lt;-
then switch all := to &lt;-
and when all platforms are clear of :=, switch that to list assignment
sure, shift all these values left and bind them :)
&lt;&lt;-
&lt;&lt;= is undefined currently, though &lt;&lt;== and &lt;== are
alas, we can't use &lt;= for binding
so you can say zip(1,2,3;4,5,6)
pugs: 1,2,3 Z 4,5,6
pugs is not up to date there
it had an old zip from before we invented slice contexts (S09)
pugs: 1,2,3 X 4,5,6 X 7,8,9
pugs: die
pugs: die "again"
yes
but it's already required before
or you have a postfix .&lt;&gt;
I think people will already be consistently putting whitespace around their comparisons
(and hopefully most other infix operators)
er, binding already is list binding
oh, you mean thrown out assignment :)
*throw
ain't gonna happen, I don't think
assignment is important for distinguishing value semantics from reference semantics
@a = @b should *copy* the value of @b, not make @a and @b identical
the fact that other languages confuse them results in FAQs for those languages
well, it does both, depending on the operator, just as $x can be either numeric or string depending on the operator
but that's why we can get away with saying that p6 doesn't have references; it does, but it's all hidden away most of the time
you'd either have to use parens or := under the new regime
well, actually, you could also say my @a = list 1,2,3,4
dunno, something's busted on rakudo maybe
but since rakudo is now the official name of parrot's perl6 implementation, we should probably redirect pugs download elsewhere
just to avoid confusion
afk &amp; # errands
that does not look correct to me
should just flatten @a into the list
yes, that's what I mean
pugs is wrong, I think
pugs: my @a = 1,2,3; (@a,4).join(':')
it's probably just not in any valid context
pugs: my $a = (1,2,3); ($a,4).join(':')
that one's still nested
mugwump: mostly we won't be using async {...} or locks, I hope
most of the threading will be done by gather/take, lazy lists, and ==&gt; operators
and most of the (non)-locking will be handled by STM
using contend/maybe/defer
which "it" do you mean?
STM?
mncharity: at the method level (not at the rule/token level) the return values and the "self" are the current match continuation, which is proxying for both the current grammar and the current match object
it might well be that we need an explicit .extract_match to get the actual Match out of the continuation
(when implementing in something other than p6)
especially since the match data might not actually be stored in a hash yet, but scattered through a list of recent continuations
in short $here represents the complete state of the current match, including both current language and current results
there's also some monkey business going on about collecting all the old match data into the current reduction, which EXPR probably neglects to do yet
actually, that method is currently called .matchify, but I kept running into pugs bugs trying to collect match info, alas
.matchify is defined in Cursor.pm
note also that metholate can already emit non-backtracking code without gather/take; except that pugs doens't implement andthen or allow me to work around its absence
is anyone else having trouble with svn up?
maybe I'm just getting MetroFied
mncharity: there isn't a MatchContinuation type, it's just an instance of Grammar
the Perl grammar also derives from Cursor
afk &amp;
fg
so it would seem...
mncharity: how'd the meet with obra go?
doesn't work, just pull it from svn to get the bleeding edge (which requires GHC 6.8.1 I think at the moment)
back from dinner
thanks
mncharity: what is the difference between YAML::Syck and YAML::XS?
@tell mncharity yes, it would be very nice if any fast form of yaml had its unicode act together...
what's a routine_declatorot?  :)
I don't believe anyone has actually implemented the currently specced multi dispatch
because MO is necessary but not sufficient
multiple dispatch tends to live outside the purview of any one type
though of course the Code types have to deal with it on various levels
it's another one of those areas that everyone else has been avoiding thinking about, like longest-token matchers :)
so I wouldn't be surprised if that was something I had to prototype after STD is "done"
but by all means, feel free to work on it! :D
at which point you have a bootstrapped kp6 compiler, but not necessarily a bootstrapped p6 compiler... :)
I'm just pointing out that there's not much meaning in saying "a bootstrap" without saying a bootstrap of what
okay, same question, self-hosting of what?  ;)
that would probably be better English
well, my point is that I'm not sure what self-hosting buys us if the thing that is self-hosted isn't p6
after all, there are a lot of self-hosted languages in the world already that aren't p6 :)
well, I'm just grumpy this morning, mostly because gimme5 is making me think too hard about the differences between cursor objects and match objects, when I want to think about longest tokens...
and I don't think any of the other parsers have solved those problems yet
and I'd really prefer not to use tie in p6 to emulate delegation of pseudo hash subscripting to the cursor object
s/p6/p5/
gimme5 is a program that translates STD.pm to STD5.pm, which runs the standard grammar in p5
and is currently stuck at parsing things about as complex as -42+1
no, grammar of perl 6 with perl6 rules implemented in perl 5
yes, gimme5 is a very ad hoc translation of STD.pm to a version in p5 that uses p5 methods to implement STD parsing semantics
well, gimme5 is the translator, not the translation
gimme5 is actually a version of metholate, that used to translate to pugs
but pugs was to slow and buggy to support it
STD5.pm and Cursor5.pm actually run quite fast, and reproduce the bugs in a stable way :)
translation of rules to method calls that emulate a regex engine
because you can do backtracking with gather/take on lazy lists
that was what was translating STD.pm to pugs code
nothing to do with spec
metholate and gimme5 are basically the same program with a different target engine
__Ace__: it's prety much mandatory to parse from memory
currently the p6 parsers mostly assume you've just handed them a string
and to make it work little-by-little from disk would be harder :)
p5 can read from a file on the fly, but I think we have big enough memories now that that is suboptimal
and it's better to always slurp in the whole file as a string and then parser
*parse
those are compiled separately
there's no such thing as "include"
oh, likely, but given most of the platforms we're targetting, you'd probably just compile down to some kind of object code and send that
or send a bunch of half-compiled ASTs and just emit the right code on the other end
lots of ways to dice it
what about 'em?
lichtkind: sure, everything is negotiable :)
__Ace__: you could put a subset of the official library either in the same directory or even in the same distribution file; we've defined versioning in S11 such that, once you know the full name of a module you can be sure it's the official one
P6 is agnostic about the storage format of the official library
you can also have personal modules that aren't "official" yet
but I wouldn't use that mechanism for your personal copy of official modules
maybe--making documents act like modules seems like a square peg in a round hole
but I'm actually more worried about the _ than the TITLE/NAME
Most documents in the world are not required to have names that are a single identifier :)
and the CPAN namespace is rather limited even for p5
would it work to have both a NAME and a TITLE?
feel free to experiment on S29 in the pugs repo
I can change the rest of them if you find something we can agree on
well, it's called Functions.pod in the repo
yet another "title" :/
rhr: "The page you're currently looking at lives in the Pugs repo as docs/feather/syn_index.html, and is resync'd every few minutes."
have at it :)
one wishes one could instruct yaml not to follow certain links...
trying to dump out a Match object without the associated cursors (including all prior cursors) is a problem for me
and I don't even have links back into the matching rule yet, which I suppose is your problem
maybe writing a custom yaml visitor is the solution
I've been fiddling with putting matches inside of cursors, and cursors inside of matches, and I'm not happy with either approach...
basic problem is that p5 doesn't really have any data type suitable to represent match+cursor objects, and any approach that separates them makes for circular references sooner or later
and p5 doesn't handle circular refs well...
but there's enough difference between the match interface and the cursor interface that they're hard to combine into one object too under p5
FOO}
if I could poke a glob into $foo and then do $foo{HASH} I could use globs, but that doesn't work either
and because tie is done on individual values, not types, it's not really suitable for defining an immutable type that has to clone rapidly
(a cursor containing a match object isn't immutable from the user's point of view, but one can view the mutable match bits as a mere cache of "prior" cursor history)
so I think I'm just going to have to make $/ dereferencing non-transparent at the p5 level, sigh
at least that should make it pretty easy to prettyprint the match bits without the cursor bits
(where when I say match I mean something more like ast...)
sure, just using yaml because it's quick and dirty, for some definition of dirty
how astish it is depends on how you write your {*} reductions
arguably Capture, if you don't look too hard at immutability issues
Capture doesn't natively have .from and .to, but those can presumably be mixed in to produce a Match
well, and Capture is just an immutable list of mutable containers, really
or you wouldn't be able to bind to a rw parameter...
in my regex engine I'm treating Cursor as immutable, though of course p5 doesn't care
but by cloning cursors as we progress, I can resume matches anywhere at any time without having to restore any values in the match state
presumably it'd even be thread safe
but as soon as I call into a user's {...} I have to make it mutable according to current S05
the eventual $/ returned by a match is not necessarily mutable though
maybe it's just wrong to allow $&lt;foo&gt; = 42 inside user closure, I dunno...
on the other hand, maybe it's safe to allow mutability in that limited scope without confusing the regex matcher, as long as it doesn't go reentrant
(but how would I guarantee *that*?)
need to go buy my cat some food, likewise bbl &amp;
mncharity: there is no canonical order of implementation.  t/spec is ordered by synopsis, which will tend to reduce forward refs
however S29 is a bad example of that...
it would be almost the last thing tested
and array interpolation should probably be in about S02
and t/spec is still rudimentary because we've only just begun moving tests from random t directories into t/spec, and fudgifying as we go, which does much more to reduce implementation dependencies than trying to guess who does what yet...
and putting on my language designer hat, I have little motive for making it easy for people to implement half the spec.  :)
I can see the argument for the other side, but I don't think it warrants a lot of extra mechanism just to get all the green bars before all the red bars
it got renamed to STD.pm quite some time ago, so that's probably an old copy, or a derivative
what does svn status say?
biab &amp;
mncharity: if someone else wants to work on a literary dialect of p6, that's fine, but I tend to be more interested in mobile documentation than in mobile code.  And it's certainly not on the critical path...
are you asking if the standard Perl 6 grammar has a purpose? :)
no
pugs development quit before std development started
I think you are confusing pugs the repository with pugs the program
there are many things in pugs repo that are neither doc nor used by pugs the program
STD.pm is intended to be executable code, not just doc...
no clue what it would be in parrot repo, or if it's even related
what is its path?
I don't see any such file in parrot repo
lichtkind: probably, what did you last see?
(you can always check the irc logs to find out if you missed something.)
http://irclog.perlgeek.de/perl6/today
it's even close to you :)
you must be looking at a file that is generated at run time
what does svn status say about that file?
and there is no rakudo dir...it's name is still perl6...  # confused...
*its
well, that's only about 137 revisions out of date...
(to be fair, parrot revisions, not grammar.pg revisions)
that is the more recent version of the file, so that's okay
it's kinda misleading that the url points to an older version of parrot
sorry for the thinking the sky was falling...
mncharity: btw, speaking of STD_deconstructed, those categories that are rules rather than tokens are making me rethink how automatic whitespace should be handled in rules
because the autolexer doesn't like leading ws
which is why STD.pm currently has unspaces on those rules
but I'm thinking a general policy would be better than having to backwhack those whitespaces
well, just the fact that you classified them that way reminded me that there was something bogus about using rules under LTM
I don't know whether the right thing to say is
that rules in general should ignore their first ws
or that a protorule should automatically slurp &lt;.ws&gt; on behalf of its subrules
well, we actually went back and forth about leading whitespace in ancient design meetings
though the case in point at the time was rule {:foo bar}
and whether the whitespace after :foo was significant
at the moment all whitespace is significant, including trailing
(except whitespace between an atom and its quantifier)
(well, and whitespace within other constructs like char classes...)
in terms of LTM policy, the canonical thing is that all alternatives (including categoried alternatives) should have the ws eaten before they get there
er, that looks backwards
but $ is not going to work there
unless &lt;a_rule&gt; matches the ws
hmm
implying that you could match postfixes and infixes in the same alternation. hmm...
except we don't want to mix those anyway for recursive descent reasons
since the postfix wants to attach to the term, and the infix doesn't
question is there a use case otherwise...
maybe the proto rule is the right place to make that choice, if the default isn't right...
since a proto rule implies alternation
whereas a standalone rule doesn't
on the other hand, lots of standalone rules will have alt at their top level anyway
and as you say, the standard lexer eats ws eagerly anyway
so that should almost certainly be default behavior
however
we have to be careful
not to write any rules under &lt;post&gt;
if the top alternation autoslurped the ws
so it still has to be attached to "ruleness" rather than LTMness
so it still comes down to the question of how a rule's skipping of leading ws can feed into LTM usefully
I think the LTM has to know itself whether it should call &lt;.ws&gt; before feeding the new pos into DFA engine
and that info is propagated up from any rules that may be transitively the head of the match
it's not simply passing \s* out as the head of the ltm regex
since &lt;.ws&gt; does line transition stuff
I think if we factor &lt;.ws&gt; out to LTM for correctness, nobody will notice :)
so it won't have to be explained. :)
the problem is this
as it currently stands, (or stood, before I installed backslashes in STD)
statement_control:if would implicitly have a sigspace call to &lt;ws&gt; before the &lt;sym&gt;
and the LTM factoring engine would see that and stop cold
so there would be no token "if" in the LTM match
and basically LTM would be useless on any call to &lt;statement_control&gt;
which is madness
so I install unpspace backslashes right after the opening curlies of those rules
assuming that whatever calls &lt;statement_control&gt; will eat the whitespace
which it probably will anyway
but unspace feels hacky there
rules should just behave right by default
and I think if I factor out leading sigspace to the LTM
it's just work as expected
since LTM is, in some sense, just supposed to be an invisible optimization
(except for the explicit non-orderedness of | alternatives vs ||)
so basically LTM has to know if any of its alternatives would call .ws and call it before the dfa engine
so that the dfa engine can usefully match /^if
because dfa engine doesn't know how to call .ws correctly
and can't, because .ws is officially a side-effectual subrule
if there is a mix of tokens and rules in the alternatives, I don't think it hurts to call .ws before the tokens
as long as the grammar handles whitespace dependencies with pure token alternatives
(as STD does)
the grammar breaks miserably  :)
perhaps it will help if you can't mix rules underneath a proto token
it would be easy to break a derivative of STD
token term:sym&lt;myterm&gt; { &lt;naughty_rule&gt; } would do it
well, term wouldn't care
it's postfixes that care
but same idea
on the other hand, they'd notice *very* quickly if they broke all postfixes :)
perhaps there should be a token annotation that can be placed on &lt;post&gt; that it disallows subrules with leading .ws
and that would catch it earlier
depends on how start_rule is written
if it's written rule start_rule { &lt;stuff&gt; } then it will eat ws both fore and aft
the assumption is that anything written at the rule level can safely ignore all whitespace distinctions
which is what bugs me about having to put \ in there
which is isomorphic to {\ &lt;stuff&gt;\ } vs {\ &lt;stuff&gt; } vs { &lt;stuff&gt; }
in any case, almost all rules will be written with leading ws
(mostly unthinkingly, because of the basic assumption above)
so I think factoring .ws out to LTM is the right thing
it's just an unspace, as defined in S02:217
it's not a literal space match, as it would be in old regex
which is, by the way, a trap for the unwary
so I imagine "\ " in a non-rule should always warn
and direct user to write \x20 or some such
or &lt;sp&gt; if we still have that  :)
except very often when people write a literal space match they should at least have written \s+ instead
or \h+
so maybe &lt;sp&gt; is too conducive to bad programming
and \x20 is appropriately ugly
the other problem with it, yes
in which case you should be calling &lt;ws&gt; likely
or just using sigspace
yes, more readable (but longer)
well, actually, simply ' '
these days
even ' '+
or " " if you like the heavier quotes
hence, no pressing need for &lt;sp&gt; really
and if you don't want to squint, \x20
particularly if the rest of the expr is full of \xab already
which most of the regex I see these days are
since they're scaning for viruses and such  :)
(at $dayjob)
so &lt;sp&gt; dies, or remains unded, or something
token sp { ' ' }  # not an arduous workaround
I think I'm kinda liking this language  :)
unicode is perfectly adequate these days with plane 0/1 chars, but by now it's a political fight more than a technological :)
well, there are still languages with horrific rendering problems
but those language users tend to blame themselves rather than unicode :)
I mean human languages, not computer
I'm sure the Unicode consortium would say "yes"
and I'm just as sure there are other people who would say "no" :)
well, the definition of "official" (and "adequate") depends on which official you ask
All character defining bodies did not automatically become subserviant to the Unicode consortium just because the Unicode folks might like to think so. :)
yet another "standards" body...
*subservient
MS has also preferred to stay "on top of things"
or maybe just "on top"
it would appear to me that they are ignoring all the plane 1 compatibility characters
it would also appear to me that this is a case of more-than-one industrial variant of Shift-JIS, since they refer to NEC specifically
NEC having the same relationship to legacy character sets that MS does.  :)
in what sense did it destroy Web 2.0 the first time?
seems to me that Web 2.0 is already in the process of destroying itself :)
re STD, well, just contiguous time and energy to work on it
$dayjob and health have both been interfering
and these days I prioritize both of those rather highly
I thought it was dated 2004 or 5
for plane 1, before 2005 for sure
maybe not before that, I don't remember
mostly the plane1 chars were added for names
but to the first approx, Web 2.0 doesn't need MS's blessing to survive at all
except insofar as various companies prohibit use of, say, firefox
which I doubt many companies do
in fact, the very incompatibilities you mention are part of what pushes people to firefox/opera/etc
so the MS tail can't really wag that dog
BTW, I'm not opposed to MS making a decent living--I have at least two relatives who work for them :)
and I think another company is taking over the mantle of Little Brother
whether they think they're doing Evil or not...
cross-platform JS is mostly a solved problem these days, according to the folks I talked to yesterday
and these were people who should know...
well, I'm not to worried.  Web 2.0 interprets MS as damage and routes around it.  :)
*too
fine, but every half generation or so a *different* Great Satan arises.  I don't think MS will be the next one any more than IBM is the current one.
you have to be forward looking :)
speaking of forward looking, I should finish enjoying my morning coffee if I want to get dressed before noon
biab &amp;
or vice versa...
to be quite fair, I pay much less attention to standards than MS does. :)
spinclad: and &lt; &gt; is already take for &lt; a b c &gt;
most of 'em keep resurfacing from time to time  :)
well, maybe not most, but some...
I've never really seen a good definition of what exactly Abstract Syntax is...
speaking as a linguist...
if it merely means, "having forgotten details that you might regret not knowing later"
then I don't think it's all that interesting...
and in particular, I have an anti-interest in having to invent something like P5 madprops to get back to the original language for P6...
I'm trying to devine what about the Match tree makes some subset of it unsuitable to be viewed as an AST...
*divine
but maybe de-vine too
and whether that just means our definition of Match trees is insufficinet
*cient
fine, but now you're talking semantics, not syntax...
I do realize that there was a school of linguistics that overanalyzed semantics as if it were syntax, and that the leader of that school also had considerable influence on comp sci, but I was never that kind of linguist. :)
certainly, linguistics if full of 'em
don't get me started on morphophonemics...
*is
well, that's essentially what all the --&gt; coercions are in there for
the "Match tree" is already abstract syntax
if you look into the coerce functions implied by --&gt;, you'll see (commented out for now) a mixin, which is a kind of blessing
ah, but now you're back to defining it merely as a forgetting
look for but=
and I am allergic to forgetting things after my MAD aversion therabpy
*therapy, though I like the alternate spelling too...
now you're just arguing granularity of types
but yes, the granularity desired by the OPP is not necessarily the same as that desired by an emitter
I'm mostly just kicking up a fuss about the term Abstract Syntax
I'm not against tree transformations...
on the other hand, I don't see offhand why a macro would prefer to deal with some intermediate semantic representation much deeper than Match tree
quasi-quoting will already handle nearly all the needs for binding, so there's not much need to introspect the tree for variables
and in any case you probably want them in prebound state anyway so you can decide
in any case, the parser has to decide the binding right then and there anyway
so that level of semantics has to be interwoven already with syntax analysis
the parser must realize "my $x = $x" is recursive
we mandate $x gets poked into the symbol table when the parser position is after "my $x"
that kind of decision cannot be deferred
any Perl parser has to be ready to know the complete meaning of any previous bit of code at any point, up to and including running it
(BEGIN and friends)
but also constant folding
merely keeping track of the symbol table on the fly is just a small part of it
the fundamental nature of Perl is that it not only be able to compile code at run time but also run code at compile time
(hopefully with better control than Perl 5 exercised)
basically, the parser must know (or have ready access to) exactly what language we have at the moment
and every declaration changes the language subtly.
there, you've already run into a problem of forgetting something by getting too abstract too quick... :)
well, you weren't the one doing it, which is small comfort... :)
I am home from the hospital, and now recovering from that...
while I was there I got 4 units of blood, a CT scan (negative), and an upper endoscopy (also negative)
severe anemia, probably from bleeding somewhere
but it's not a reoccurance of my GIST tumor of 4.5 years ago
nor is is stomach ulcers, so possibly ulcers farther down
(which is easy to do when you don't have a valve on the bottom of your stomach...)
anyway, I'll have more tests over the coming weeks
well, I'm certainly less anemic at the moment, after 4 units...
but that's not a good long-term solution
and being less anemic, it's even possible I'll be thinking more clearly (or rather, less unclearly :)
s/no/every/
vaguely possible mine is hemolytic, and they've just mistaken it for bleeding
not sure if they're run all the tests that would distinguish it
spinclad: I wasn't trying to mix in lxx spellings, it just happened.  :)
welcome temporarily back
much better than a sesequiweek ago
*sesqui
well, not done with tests yet
but I feel much better after topping up with half a gallon of blood
ct scan, chest xray, upper endo (with ultrasound!) all negative
in a week I'll probably go in for lower endo, joy
but at this point it looks like best bet is some kind of angiodysplasia
which is something like varicose veins on your insides
well, my insides, in this case...
still several other things it could be too...
I'd settle for a sayaka
symmetrical?
sorry, I shouldn't be trying to play doctor over irc :)
I just have my _REDUCE method attaching the tag currently as a proxy for a rule pointer, since subs in p5 aren't really 1st class objects
and my current EXPR just looks at /^infix/ on that tag to see if it should pop 2 terms instead of 1
nounphrase having moved into EXPR, more or less
but it's not quite right yet
and there's something squirrely about prefixes and postfixes that dominate a nearby infix
because the prefix dominates a following infix, and for symmetry a postfix could dominate a preceding infix
-$x**$y is the canonical case in existing operators
but the reverse of that could hold for a user-defined postfix
but a prefix can't dominate to its left, nor a postfix to its right
so $x**-$y can't make the - looser than the **
and then there's the little case of what do you do if there's both a prefix that dominates what's after and a postfix that dominates what's before...
say, for the sake of argument, there were a - postfix that did what - prefix does
you can get cool stuff like $x**-$y-**$z
which seems a bit bogus
not to mention ambiguous
the prefix would be trying to turn it into $x**(-($y-**$z)) while the postfix would be trying to do the mirror image
at the moment I just track whether to pop 1 or 2 args, assuming that prefix and postfix are just simple unary by then, but may have to rethink
this was a lot simpler before the mathematicians got involved with their -$x**$y   :)
well, that's obviously got to be asymmetrical or illegal
but the question remains whether the $x**$y- analog works
and means ($x**$y)-
well, if you have prefix:&lt;-&gt; and circumfix:&lt;- -&gt; you're already in a world of hurt even without the postfix:&lt;-&gt;
pmurias: that's what I had before
(with nounphrase)
but it doesn't parse -$x**$y right
s/right/"right"/ if rand &lt; .5
s/rand/rand()/
so the way the mathematicians want it, it needs to be parsed more like 0-$x**$y
ignoring the detail that prefix:&lt;-&gt; has a different precedence than infix:&lt;-&gt;
and I can do that pretty easily in EXPR
question is how/whether to apply the same logic to postfixes dominating a preceding infix
only for prefixes :)
indeed, but it's my job to figure out if the user is going to want the precedence of, say, postfix:&lt;i&gt; to be outside that of infix:&lt;+&gt;
so that they can say 1+2i
wait, that doesn't want to dominate the +, nevermind
but some similar situation
maybe the user wants listops that go at the end of the list instead of the beginning
but postfixes are already syntactically distinguished
since the require no whitespace
*they
already the case for postfix, basically
I'm just wondering what happens if a user defines a looser postfix
such as a hypothetical postfix:&lt;-&gt;
where $x**$y- could mean the same as -$x**$y
yes, but the question is what do you do next
it's trivial to create a postfix:&lt;-&gt; with looser prec than **
but will it do anything with that precedence, and if so, what?
and the crazy thing is that the leftward precedence of a term is specified by a postfix, while the rightward precedence of a term is specified by the prefix
pmurias: no, we just have to parse superscripts correctly  :)
unfortunately Unicode doesn't have superscripts on superscripts...
so it's hard to write $x**$y**$z
anyway, ** has been "proper" ever since Fortran
and arguably, ** is better huffman coding of a heavy operation than superscripting is
so Backus was just fixing math notation  :)
there's no requirement to hang an action on every tag :)
the {*} is serving also to indicate explicitly where LTM must quit, if it hasn't quit before now (which it usually has)
** is higher order than * in the sense that ** can be defined (roughly) in terms of repeated *
and you learn it later in school
so "mentally" heavy
and $x**$y tends to do more "violence" to the value than $x*$y, in some sense
please do not put actions into STD.pm
the main point of {*} is to avoid installing platform dependencies
yeah, the quoting in STD may be in for some refactoring as well, so I'd fake it for now.
on &lt;eat_terminator&gt;, need to cogitate a bit or two
probably will end up deleting the call in use and no
since eat_terminator is supposed to handle the need for ; when you stack to statement_control on the same line
since foo {...}; bar {...} requires the semi
and the use/no calls probably predate that decision
but that's just gut feeling, not thotthru
but in any case &lt;EXPR&gt;? should be greedy enough to get us to the ';' anyway
so we can rely on statement's call to e_t
is a bit strange to reduce it (and having side effects!) before eating the semi, but seems benign, and you have to do that anyway if there's no semi
'course, arguably, that means that eat_terminator doesn't need to be its own rule
however, it's probably good to make it available for user-derived grammars
(for similar reasons I've been tempted to make all the regex matching rules into multis, but I keep resisting that temptation. :)
I did rename all the regex rules that have names that are too long though...
instead of all the ordered/unorderer mumbojumbo, it's now regex_{first,every,any,all}
for || &amp;&amp; | &amp; respectively
should probably check in my current STD et al, though it might regress some things
but since I'm really the only one running it, that's okay :)
break early, break often...
well, you could at least glare at the diffs
term:listop
walk &amp;
I've been reading too much greek lately, obvously...
well, it's actually neither...
you want rough breathings there, not smooth
but yeah, no decent greek input method here either...
and likely to be modern greek in any case
(no pun intended)
yes, just cnp
there's some discussion at http://mail.nl.linux.org/linux-utf8/2006-01/msg00019.html
but looks like an overall mess
now if only I had a geek input method...
most geeks already have an input method for coffee
mncharity: fixed, listop shouldn't have have traversed \s before &lt;nofat&gt;
the &lt;!before \s&gt; is only to prevent &lt;nofat&gt; from matching in the middle of an identifier
\w rather
j
bp 114 72 104
well, if you want to know my blood pressure last night...
was trying to open your reverse patch and hit the wrong button :)
and yes, you can bind any object to any sigil, though some sigils may require minimal support of certain roles
pugs doesn't really do Captures yet
and @@ is called "slice context" for a reason
a Capture is an argument list that has not yet been bound into a context
pugs does not yet implement @@
nobody has really implemented much of S09 yet
I think pll would be a nice visual abbrev in sans-serif fonts  :)
no, there's only one anonymous class generated for Num
it memoizes
which is fine, since role is immutable
going the other way, you can only make a role out of a class by taking a snapshot of the class's current state
it's still debatable whether that is generally allowed
well, that's the metaclass, which presumably has some way of dealing with its bits
it's anonymous so we can pun the name
and so that JMD doesn't have to have Tie::Array class to go with Array role
it's just Array class and Array role
no, a class is not a metaclass
that is likelier to work
it's something that does the metaclass role, I suppose...
roles also work for interfaces
if you just ignore their suggested implementations
$x ~~ Array
you mean composition...
just override all the methods
seems like a pretty easy thing to do
a class can override any colliding methods
so don't use imperfect role models :)
nobody does S09 yet
[] is one dimensional as a term
so just -1
.[] is 0-dimensional
I suppose Array is 0 dimensional :)
are they the newer :exists and :delete forms?  If not, they're probably fossils
sorry, don't have time to check it all myself--still trying to catch up with p6l backlog... :)
invocant is rw already
S12:755
and in fact, splice doesn't need the rw
presumably the exported versions of methods also mark the first arg as rw
pugs: say $?PUGS_VERSION
~.
hmm, svnbot seems to be down...
most operators are defined via Prelude, which means they're lexically scoped, and don't use the global namespace at all.
it should be easy to override your own ~~, but hard to override everyone else's
unless they agree to your dialect via declaration
ruoso: that would depend on whether signature matching thinks it's using infix:&lt;~~&gt; or some underlying primitive
matching a signature against a capture is just one of the things ~~ does, so it could well be delegating that match to the underlying primitive used by ordinary sig binding
I expect this is rather orthogonal to the scope of ~~, which is intended as more of a dwim operator than a basic one
you're really talking about something more like .ACCEPTS at the lower level
in other words, it's a confusion of abstraction levels to think that overriding ~~ will change how signatures bind.
you can't use multiple dispatch to implement multiple dispatch...
(not that ~~ is really multi dispatch anyway, it's a reversed single dispatch)
that's fine, just don't think of ~~ as the mmd operator. :)
various places in S03
@tell ruoso the signature is the pattern, so the signature accepts the capture, which means it's the operation underlying Capture ~~ Signature (note reversed args from Signature.ACCEPTS(Capture))
ah, that was the case I was replicating :)
mncharity: re parsefails, that's why fudge comments out the code when you use "skip"
the whole point of fudge is to allow these sorts of tweaks without fragmenting the test suite, which most other approaches do
but I do expect the code to stabilize somewhat once I get the quoting sorted out
and I do expect to have more time in the next few weeks
basically, the LTM works fine for derived grammars, but there were various spots in STD that should have used derived grammars that didn't
quoting, regex, etc
and certainly some of your NONSPEC is due to lack of LTM, isn't it?
STD will not only be making LTM possible, but relying on it
as it already does, which is why there's no longer &lt;nofat&gt;, for example
how easy would it be to generate a list of those?
(I realize many of them have floated past here already... :)
as far as the parser is concerned, it's just a closure that executes *
which does nothing
however, the idea is that it's an easily recognizable nothing that you can attach various reduction hooks to via preprocessing
so any given compiler is allowed to substitute other reduction actions at that point
presumably keyed by the comment out to the right
as an official side effect, it's also equivalent to :: in terminating the longest token
though it doesn't affect backtracking as :: does
biab &amp; # decommuting from $dayjob
that's part of the refactor
look for user-defined quotes, then nibble the insides
but in my copy it has worn down to "quibble"  :)
and the modifiers like :P5 are handled by derivation: &lt;quibble(Perl::Q.tweak(:qq).tweak($&lt;quote_mod&gt;))&gt;
well, :P5 would be based on regex language, not qq language, but same basic idea
dinner &amp;
you've got a whole bunch of 'em inside you
base 4, actually
that was my point
no
the multi syntax is exactly as in Perl 5
the single-dispatch syntax is purely $what_to_join($separator)
$what_to_join.join($sep) rahter
and there is no failover (at least, not there)
there is no fall back if it hits the .join method in Any
and may never be any fallback anyway if we also open Door 3
but that's an independent decision, more or less
ruoso: hasn't come through yet, so I'll have to remember to forget it...  :)
no, but I can probably think about it after my talk on Monday
brane is currently in STDspace
most of the need for fallback was already dealt with via "is export", which handles the case where you *do* want to shadow the method with foo($invocant,@args)
it's just that join isn't one of those
which is why I asked for a use case some time ago, and haven't really heard one
yes, a reason to include the feature
well, it would just be one dispatch calling the other dispatcher when it runs out of candidates
Positional implies indexibility, and you can join something that you can iterate, even if it doesn't provide a subscript interface
so maybe Iterable
or some such
I wish people wouldn't use the parrot shortcut to name operators...
much easier to read, I think
*unambiguous
holst: it would depend on which new perl6 system you're talking about.  Perl 6 the language doesn't care, though if it did care it would tend toward C.  But Perl 6 objects are opaque in layout, and that includes arrays.
and then what do you do when they say $foo.push(1,2,3,5)?
$foo.push([1,2,3,4],[5,6,7,8]) rather
we've certainly been trying to keep the hpc folks in mind while designing :)
just as Perl 5 allowed you to talk to two databases at once, so too Perl 6 will allow you to specify your ordering both ways if the underlying implementation supports it
it is hoped that the Perl 6 type system is flexible enough to slurp in any existing metadata and run with it
the only real question is whether it'll be too flexible for the optimizers to get a good handle on
hi ingy
there already
you in .tw?
I'm at the hackathon
hadn't planned on it, but you never know...
S09 and S12 talk about shaped arrays and the object system
from the language view
well, obviously, if you're dealing with different layouts, someone has to take responsibility to interconvert, and hopefully Perl 6 can be that someone if it has the right metadata
but the language itself takes pains to keep the shape an abstract concept
course, that still doesn't mean that you can just write Fortran in Perl 6.  :)
requiring determinism to achieve a correct solution is one part of the problem :)
yes, but relying on accidental implementation-based determinism is bad, when you should make explicit what the dependencies are in your code
if the code doesn't express the required dependencies, it's bogus in some sense
which "for" are you referring to?
the latter
audreyt++ for learning hard lessons on Sustainability :)
decommuting &amp;
s11: the .t files are the standard test files.  the .rakudo is a preprocessed version of the .t that takes into account the "fudging" needed to run under rakudo
the perl6.vim file can be found in util/
diff the .t and the .rakudo and you'll see what fudge does
zzz &amp; # thunk
yes
I keep forgetting to say .text as it is...
just try to keep your changes localized, because I'll be working offline for half a day or so and will want to merge
afk &amp;
I doubt there's anything not related to Perl 6.
lichtkind: maybe--we could define { =&gt; } as a closure that gets evaluated lazily in hash context; this would be a departure from Perl 5 semantics though
it would be nice if map { $a =&gt; $b } would do what the user expects
and I'm trying to answer the "when" of that question
in p5 the expressions are evaluated immediately
I'm saying if we did it lazily, we might be able to finesse the map { $a =&gt; $b} problem
and not decide till it's used whether it was intended for a hash or a function
well, it actually genererally shows up as map { $_ =&gt; func($_) } or some such
but people expect it to return a list of pairs, and they get a syntax error instead
because to the parser it looks like a hash composer
eh, currently it does full eval; we're speculating
basically it currently adds .() if it looks like a hash composer
bbl &amp;
@tell pmurias a mutable object must specify its WHICH identity in terms of an immutable value type; immutable value types are their own identity and are required to support consistent canonicalization for eqv etc.; and canonicalization is hashable without knowledge of type, so no explicit .hash required
@tell pmurias, IOW, hashes are always keyed on canonicalized .WHICH, though the particular form of canonicalization may depend on the hash key's declared type
nobody else was crazy enough to reimplement perl5
we expect a lot of people to be that crazy about perl6  :)
the current situation *is* what the community agreed on  :)
oh, and it parses "use v6;" correctly now :)
Obsolete use of $" variable; in Perl 6 please use .join() method instead at line 1:
------&gt; "$" ";"
yes, I was just telling you what STD says
only the "$" comes out green and the ";" comes out red
I suppose within double quotes $" could give a different error
surprisingly easy to arrange these days :)
Now says "Can't use a $ in the last position of a string at line 1:
should just work if you have ANSI::Color
the part it thought it parsed is green
but yeah, could fix that...
or maybe I should set it up so we can highlight something in the middle with yellow
'course, I've picked the worst colors for anyone who is RG colorblind...
well, I should really be getting subscript declarations to parse, or maybe heredocs
I was originally just going to parse a subscript declaration as a subscript, but last night I ran into:
Failed to parse a required term at line 270:
------&gt;     my @arr[--&gt;Num] = &lt;1 2.1 3.2&gt;;
and --&gt;Num isn't a normal lvalue :(
*rvalue
well, probably want a special rule for it anyway, since subscript declation is a rather restricted language
moritz_: subsets are "Just" types
well, it might just give you a bunch of JITted code... :)
companies want their security-through-licensed-obscurity...
but I think reasonable efforts should be made to provide .perl where possible
and that includes closures generally
how does pugs do it?
that's Perl, not YAML
this is, I suspect, a good place to follow the lead of pugs
well, applying := to a "" is probably illegal really...
actually, I think that's spittout out Haskell there maybe
*spitting out
not awake enough yet to see straight
but anyway, the pugs notion was that everything just desugars down to primitives, so .perl might give  you the primitives, but it still has the same meaning
we probably have to keep some kind of representation like that around internally anyway if we want auto-optimizing/pessimizing jit alternatives
or at least you have to keep a fully pessimized version around to fall back on if the optimized version's preconditions are violated
but that sort of all-or-nothing view reminds me of source filters somehow
so it's probably better to keep the semantic representation and re-emit
well, maybe it depends on whether you're asking for .perl of the continuation or not... :/
but certainly something that references lvalues can't work outside the referential scope of them
not without ipc that communicates back to the original machine  :)
so basically we're talking about a universal naming scheme for anonymous values at that point...
which is not terribly practical unless you really need relocatable code
I don't know Perl 6 will end up with, but Perl 7 will be fought with sticks and stones...
it's probably just something to bear in mind for now, but in generally wrapping up code has to wrap up its entire visible state, and that's not terribly practical
*general
so I don't know if we can mandate .perl on everything easily; what we *could* say is that the AST for a comp_unit must be kept around by default unless explicitly discarded
and then a closure's .perl can be emitted assuming that information, maybe
not sure how cloning fits into all that though
the continuations tend to sneak back in
I'm not an expert on these things, and it feels PhDish
I've already earned enough of those with Perl 6... :)
it seems a bit antisocial to put away messages on a channel you're just lurking on...
well, I was just wondering if a mild kick was in order
well, our ban table is full, so not on the table :)
but I wasn't suggesting that
my make test seems to have hung in examples/algorithms/lambda-calculus.pl
@messages
audreyt: I'm not really interested in substituting one buggy tagged dfa implementation for another :)
@tell mncharity after t/ I'm probably going to be working on mutating my TRE-prevention code into a real dfa matcher, then translate that to P6.
@tell mncharity but to get t/ parsing right involves adding symbol tables/pads to STD to implement user-defined operators and post-declarations
@tell mncharity and of course, performance improvements are always in the back of my mind in some kind of repressed state, and translating Cursor to p6, and prelude, and...
it's handled automatically by the fact that cursor_fresh starts a new language and _SUBSUME throws it away at the end of the construct, but of course that begs the question of how the new grammar represents its lexical symbols to itself that aren't new rules
sub postfix:&lt;!&gt; needs a new rule, whereas my sub foo just needs a new lexpad entry
_SUBSUME automatically propagates the language it entered with onward
the add_macro has to figure out which language to add it to, really
so it probably needs to tell some higher SUBSUME to switch to the new language, maybe more than one
it probably needs to change any SUBSUME up to the statement level
since it needs to influence the rest of the declaration as well as the next statement
I wonder if we could fake it by failing and reparsing
that is, fail back to the statement level, add the symbol to the language, and reparse.
probably not workable for deeply embedded declarations
anyway, I will think about how to do that, since we need it for the one failing test in t/spec
that's what p5 does, but that's got its own problems
which is why p6 tries to consistently introduce it right at the name, even if the definition isn't complete
but it's basically a situation that we're adding a method to a base class and expecting the autolexer to cope, I think
(which it doesn't currently)
it may be as simple as invalidating all the lexers derived from the current statement language and letting the autolexer recalculate (hopefully lazily)
anyway, there can be more than one "next" statement when the declaring construct contains a block, and we'd like to be able to express recursive ideas, like using postfix:&lt;!&gt; in its own definition
a related interesting problem is that if we introduce infix:&lt;foo&gt; right when we see the name, we don't yet know its precedence until the traits are parsed
so the natural place to introduce a new symbol may be after its traits
this works for parameters in sigs too, since an earlier parameter is visible to a later parameter's default expression
and parameters can have traits
this is probably all magically orchestrated by the COMPILING scope somehow, since that represents the current lexpad, so maybe it keeps an autolexer valid bit somewhere that sublanguages can check
at some point we'll probably also have to think about how different autolexers can share common elements so that we don't have to regenerate everything every time we mixin a new symbol
using polymorphic tries or some such
at the moment I'm just hoping most mumble:&lt;x&gt; definitions get added without being used soon, so we don't have to autolex the intermediate languages
and I'm also banking on the fact that normal sub defs don't really change the language, but just add to the symbol table accessed by a \w+ match
(which is why we can have postdeclared identifiers, but not post-declared operators)
but after thinking a bit longer, the correct solution is probably to just provide a way for SUBSUME to have some way of merging interior declarations with the outer language, if there's some sane way to represent the current set of pending declarations
the list of pending declarations could even be used as an exception list of some sort in the current sublanguage, so the sublanguage could decide on its own whether to go to the trouble of autolexing a grammar that will soon be thrown away
but maybe this is isomorphic to tweaking the outer grammar in a way that is visible to inner grammars
in any case, it is an *interesting* problem  :)
I thought it would continue when I ^C'd the hanging test, but it stopped everything, and I didn't restart.  next time I'll try kill
and it wasn't a smoke, but a test
starting a real smoke to see how it does
ext/Cipher/t/0-cipher-oo.t seems to loop
rakudo: my @a=&lt;1 2 3 4 5&gt;; say @a;
Limbic_Region: pong
well, pugs actually has it right :)
but in general, :foo&lt;bar baz&gt; is short for :foo{'bar', 'baz'}
or maybe :foo['bar', 'baz'] really
but the question is whether the [] is constructed by the infix:&lt;,&gt;, which I suspect it is
it ought to be equivalent to "foo" =&gt; ()
since &lt;&gt; is really qw//
but () in scalar context is likely to be some kind of undef
pugs: ("foo" =&gt; ()).perl
pugs: ("foo" =&gt; (1)).perl
pugs: ("foo" =&gt; (1,2)).perl
pugs: say ("foo" =&gt; (1,2)).perl
pugs: say (:foo(1,2)).perl
pugs seems to be representing pairs as captures of 2 positionals
that aside, I think pugs is behaving more sanely on () probably
I think it could be bad to promote () to [] in general
moritz_: .produces is just a placeholder for however those results should be evaluated; it's just modelled on the notion that Match and Failure both have a .produces tester, neither of which do.
probably really wants to be a multi rather than a method
but I didn't know if parrot already had some way of testing against those particular specs
anyway, my job is to make sure it parses under STD, not under anything else :)
small commits usually make it easier to back out something broken as long as consistency is maintained, but a partial patch breaks things too, so as usual "it depends"
we're talking about building the basic tests into the language so you can just start with plan
maybe "produces" should be a very low precedence infix
so we can multi it
originally I was just going to write "ok produces(...)" but that was kinda ugly
yes
and any others we deem common enough
and all easily overridden by a real "use Test::FooBar"
but just basic functionality
the idea being that we make it easy to write TAP the way we made it easy to write POD
(this was discussed on Wed's conf call, and was generally approved of)
we could do that to
though it forces you to do "is also" on non-cooperative classes
or put it into Object and redispatch to a multi
but if we're building in ok and friends, we could also build in an assertion that could be appied "en passant" to values
and an infix "produces" would work pretty well for that
it would depend on the types of both the left and right args
you check Match objects differently than Failure objects
yes, because ~~ notionally returns boolean, not the left arg
it's like a POST block on a value expression
open to better words for than than "produces"
on the other hand, we're using it as a boolean inside "ok"...
so kinda ignore what I just said :)
it's okay for "produces" to return Failure if it's checking a Match that fails, but it's not okay for it to return the left object if it it happens to be Failure tha you're crosschecking
but maybe that just means that checking for appropriate failure turns some kind of true object
I'd say, pretty much everything that the test suite is currently using
but, oddly, perhaps not "is"
since it's almost always better to specify the exact comparison with "ok"
most of those should be "ok $a ~~ 42"
which is only, what, 2 characters longer than "is $a, 42"
and hopefully has pretty much the same DWIM semantics
the same DWIM semantics that "is" *ought* to have, I should say
yes
I can see a class of macro-like subs that just happen to remember the text of their 1st arg
assert() for instance
sub ok ($bool, $mess) is assertion {...}
not sure how you get at the text though...
depends on what kind of exception you're talking about
user-defined ops can be macros, but can only influence parsing on the right
however, they can do anything they like with the existing AST on the left, so yes, you could wrap the left arg with an eval node
well, a try node
presumably the AST on the left can return its text too
of course, a prefix macro can do anythig it likes, even with the parsing
but macros are kinda hard, so I wouldn't really want to enforce full macro support onto a budding implementation
hence the proposal for "assertion" subs that can just get the text of 1st arg magically
or, I suppose, any arg, once you've declared "assertion" good enough for the parse to see it
maybe it's an attribute of a parameter instead
and causes the argument value to be annotated with a text property
and Failure doesn't boolify correctly inside ok()
so we can't just return the left arg anyway
sure
since ~~ is determined by the type of the right value, we need to distinguish patterns that will work correctly against whatever left types we want to test
obviously if we're going to test match objects with the "mob" notation, something has to interpret that notation
I just threw the info in there as a string for now, but that obviously won't work directly
arguably Failure ~~ /text/ can be taught to work, but is also somewhat perilous in forcing particular error messages
though I suppose standard error messsages aren't such a bad thing...
currently though they're just parrots idea of what messages should be, which are unlikely to match what other implementations are doing so far
*parrot's
we probably need to work out message identities that are independent of what language is emmitted
*emitted
so Failure ~~ messid("F_42") or some such
would like granularity down to individual messages sometimes
so only if every exception has it's own type... :/
which are types
well, I'm just worried about the poor guy who just wants to write a simple 'die "my message"' without adding an id of some sort
we probably allow that, but make it easy to add the id: MyId.die("my message")
actually, given that types are coercions, just MyId("my message")
assuming exception types know how to coerce from Str
I've alway thought that the built-in exceptions should live in package X
X::Parsefail("oopsie")
well, parse failures are something else really
but X::DomainError and such
if we put them all in Exception or even Error, that discourages people from using them
especially in exception handlers
or maybe we could put them all into the &gt;&lt; package  :)
anyway, feel free to mung .produces into anything else; as I said, it's just a placeholder really
there's little about the Female Brain that cannot be explained by having to keep 5 kids from being eaten simultaneously with feeding them
nope, just shooting my mouth off, as usual
the Male Brain, on the other hand, had better concentrate on one Wooly Mammoth at a time
most of my non-fiction is magazines these days
Currently reading Pirate Freedom by Gene Wolfe
before that, Jhegalla by Steven Brust
before that, the Tough Guide to Fantasy, arguably non-fiction :)
(by Diana Wynne Jones)
but the more fantasy you've read, the funnier the book is
well, Bujold is still my favorite author, and she's a bit hard to classify, even when writing "sci-fi" or "fantasy"
she really tends to write somewhere at the intersection of romance and anthropological fiction
well, generally closer to the latter
I am not familiar with Feist
anyway, I just don't know anyone who's better at mixing levity with gravity than Bujold
if you want other recommendations, my wife knows the field and can usually predict what else you'd like from what you've liked so far
especially if you can figure out why you liked it
or why you didn't like the other stuff :)
got it in one
and she'd be delighted to advise you
Bujold falls into the category of book that we read out loud to each other
but she reads pretty much anything except horror
well, some of Bujold we don't read to kids until they grow up :)
'bout to start in with Lewis and my son-in-law Sean, who (with Geneva) are staying with us
don't know that last one
but when I think of a Wrinkle in Time, I think of all these little Python programmers coming out of their identical houses and bouncing their balls in unison. :)
most tokens are not named
they're implicit in the _from/_to
when you say gimme5, do you mean STD?
yes, it doesn't appear to capture that at the moment
though one node has the 0 and another node has the 3 for the beginning of the args
but it's not generating an AST yet in any case, just a parse tree
oh, I see what happened.  I snarfed off the identifier into $i so I could feed it to another routine, so it didn't capture under $&lt;identifier&gt;
the problem with labelling nodes with rules is that you have to deal with derived grammars and such, if you want a complete name, and the derived grammars are often, in fact, anonymous
but it'd be easy to tag with a short name of some sort
you just might not know which grammar's version of that rule matched
and I didn't want to put hard links all over the place because that slows yaml way down
and, by and large, when I wanted to deal with context, I used a context var.  :)
and also, presumably some of this processing would be done by reduction closures in a real grammar to make real AST nodes
that's what parrot does, anyway, and it seems to work for them
still working on duce, use, cycle first...
that's why we have {*} stubs
so we can keep the actions out of the grammar
being called to dinner &amp;
yes, need to do same thing I did for internal rx/ :P5 a+b.../
which does parse as p5 regex
(as of a few days ago)
the external :P5 is just a fossil
see P5Regex class
decommuting &amp;
the radix is always decimal
only the functional form
so :16("0b1001001") is legal, but not :16&lt;0b1001001&gt;
the first is a function call
you could be passing :16($x)
the second is just a quote form
:16(...) is a function call
:16&lt;...&gt; isn't
the argument to a function call can be any expression
use it for what?
literal or functional?
it's like the difference between 42 and x(42)
the literal provides a value that is known at compile time
:16($x) isn't known at compile time
yes
though inside [] is an expression too, so maybe just &lt;&gt;
actually :16("0b100") is illegal anyway, if you mean binary
since since 0b is legal hex
yes
same as :16&lt;a&gt;
no
it encloses a list
that's what [] usually does in subscript position
and adverbial syntax is parsed as subscripts are
bad programming
it would convert 10 to a string, then use that as hexadecimal
in fact, the test suite used to have those brainos in it
radix.t already tests a lot of htose
*those
I believe so
yes, STD allows it
line 1765
syntactically, yes, but it will be rejected in semantic analysis
specifically, in radcalc(), which is currently commented out
I think += should be able to turn an Int into a 0
or a Scalar into a 0
I don't know how generalizable the thing is
but maybe it's related to the table of degenerate reduction ops
if [*]() is 1 then maybe *= autovivs to 1
I suspect the question is already answered. :)
I think there's a deep relationship between assignment ops and reduction ops
np, I still believe in forgiveness over permission
well, that takes a while, and testt takes even longer, and I do it periodically anyway
and it was pretty obvious where to look for the bug. :)
so either way is fine
I'd much rather have progress, regardless of whether it's 1 step at a time or 3-steps-forward-2-steps-back at a time.  :)
whee
dunno
not sure why it's a proto either
well, I don't even trust STD's output yet :)
half of the fixes to viv involve fixing STD too
well, there's that....
I'm trying to think of a way to simplify all the sigil hoisting that is more like attribute grammars than procedures
yes
here's an interesting ambiguity:  -&gt; $x { #&lt;I am a hash unpacker&gt; }
and you can't change it to -&gt; $x{...} because that's a shaped array declaration
s/array/hash/
well, %x{...} would be, anyway
not sure there are shaped scalars :)
actually, it's not clear why we shouldn't just unpack arrays and hashes with sub-signatures, which parse already
sub quicksort ([$pivot, *@data], $reverse?, $inplace?)
could just as easily be:
sub quicksort (($pivot, *@data), $reverse?, $inplace?)
other than the doc value
but sigs can unpack mixed positional named
the bad ambiguity goes away if we change
sub register ({:$name, :$addr, *%guest_data}, $room_num)
to
sub register ((:$name, :$addr, *%guest_data), $room_num)
modules and packages are objects too :)
but the distinction seems to be rather like the @x.method vs $x.method distinction
on the other hand WHAT is really a macro
not sure I've had enough caffiene to puzzle it out yet
I think Foo::Bar is first of all a package name
which can in some cases be used as a class
it's first of all a package name that can also be used as a protoobject :)
I guess the question is where there are ambiguities in "how is it being used?" and what we need to do to clear those ambiguities
or however you say that in English
one could consider all packages to be protoobjects
it's just that
no methods are automatically constructed unless it's a class
well, ruoso thinks sideways from the rest of us, which has both advantages and disadvantages :)
was wondering that earlier, but it makes a discontinuity of sorts
it may be that Foo:Bar.randommethod should fail just to keep all package names looking like undefs
except for methods that are defined on undefs, of course :)
but WHAT is exempt as a macro
so I think WHAT on a package name/protoobject should return the packagename/protoobject probably
it's just you can't do much more with it than you could before :)
anyway, WHAT is fundamentally not an ordinary method
I think that's where the discontinuity should be
not between packages and classes
I think, probably, fundamentally packages and modules are also classes; they just guarantee certain extra apparatus when you use a particular keyword
so maybe it's fine to put a method in a package and call it, but you get no automatic EXPORTALL method, for instance
(unless we want to support @ISA somehow in that case for old time's sake...:)
so you could import methods from a module into a class maybe too, albeit without the protection of roles
and by default they'd be imported as "my methods"
which seems like it might be useful for importing infrastructure
since roles are mostly for composing api
certainly STD doesn't care where you define a method
certainly ruby gets along by making everything a class really, but we can be clearer about intent
if we want to talk about a package as a container, maybe it's VAR(package)
so Foo::Bar.method is more like $x.method than like @x.method, which is what I was trying to get at earlier
or Foo::Bar:: is also perhaps the container
which is why Foo::Bar::{'$foo'} works
yow, does that mean would do away with VAR and just use $foo:: to mean the container of $foo?
s/would/we could/
doesn't backport to ::Foo::Bar
with the current meaning of that
which is, I know this is a valid package name, don't check it
package/type/protoobject...
yeah, I need to go break my house
pugs are fond of rats
now that I've broken the house, it's time to go on the roof
example is right, but comment is wrong
fixing
afk &amp; # roof
sure
see  https://svn.pugscode.org/pugs/t
and we'll probably be building the basic testing calls right into Perl 6 eventually
the proposal is to have a testing adverb that can turn any built-in comparison operator into a test
but we already have 18,000 tests or so for you to look at
"Statement not terminated properly" is what rakudo says when it can't think of anything better to say, which is usually :)
it just means, "there was a syntax error somewhere near here"
STD will generally give you a more informative error message, assuming it's actually in error
was the last thing on the pugs map too
as far as I know, STD is the only thing that even parses macors
*macros
btw, the latest change found an error in the test suite
Can't put required parameter after optional parameters at ../../t/blocks/currying.t line 47:
------&gt; sub __hyper ($op?, Array @a, Array @b) {
you mean p6c?
decommuting &amp;
moritz_: no, there's not a Class type in official p6.  a class is represented by a protoobject of the same type as the object
if you call in Class people will get confused
*it
why?
maybe it's ClassHow or some such
then people will think it defines how Class works, and there isn't one :)
Howclass maybe
though that's not quite right either
more like Declclass
but this is all under pre-caffiene disclaimer
could maybe go for Dclass, Drole, Dmodule, etc'
s/'/./
re KEEPALL
I still think you guys want a decorated _ array
what is a Class?
it uses class-based lingo, not Class-based :)
are you asking about the type of .HOW objects?
and that is what is not a classical class, which is why I'm objecting
that would work, if we'd stuck with my earlier suggest of howness :)
Knowclass maybe
Classic
Classhalfempty
Halfclassed
Declassified
I still think if it's returned by HOW it should be something with "how" in it
it very much says "I am the *implementation* of class, not *a* class"
Cow&lt;Brown&gt;.HOW :now
even better HuffMAN coding, more remote from normal
@tell time
@till diakopter
I wonder if I should install a rule in STD that carps if someone tries to use the word "Class"...
"Perl 6 has no Class at line 42"
actually, tomorrow I probably have two classes...
since I just got a call from Sharon, who can't teach her class
macro package_declarator:&lt;controller&gt;
or just derive a grammar
a macro can turn that into anything else.  and a grammar can have random actions.  beyond that, I don't really care
something has to be left for the programmer to do :)
and one of my assets/liabilities as a language designer is that I'm not actually much into meta-ness
tennis
er, pong
well, it was reds for "reductions", then I added span for the from/to span calculations
it was only later I realized it might be confusing with redsix...
I'm not particularly attached to that name
I mean redspands, not E*
wow, it's already tomorrow here...
chow
er, ciao
I would think it would end up with 2 chars
pugs: chars [~^] &lt;m oo se&gt;
we could probably cut down memory usage by not storing the tree if it's just going to be thrown away anyway.
I'm thinking of detecting a call to parsefile in void context, and throwing away all repeating elements, on the assumption that anything that checks a repeating element for its value is only interested in the final one.
so it would throw away each statement when it has parsed another, for instance
you'd still get all the action calls though
it'd be enough for redspans, or for checking that a file compiles correctly
maybe just hardwire it to throw away old statements in void context
might cut memory usage way down for files like rx.t
looks like svn is down on feather
anyone here know offhand how to restart svn.pugscode.org on feather?
just restarted it
doesn't help
it's using https, at least from my machine
I wonder if bare http works?
yeah, http works, but not https :/
I only switched to https because of a temporary firewall restriction, so I guess it's time to switch back...
@msg juerd http to svn.pugscode.org works, but not https for some reason; restarting apache didn't help
@tell juerd http to svn.pugscode.org works, but not https for some reason; restarting apache didn't help
er, oops
@tell ruoso you can pull out your ws workaround code now, I think
value perhaps
@tell azawawi you should find your parsers running somewhat faster now, given that STD now parses itself twice as fast as it did yesterday (given a preloaded cache)
you don't get quite 2x gain on random tests because it still takes a second or so to parse all the p5 code involved, so shorter files parse in about 3/4 the time they used to
don't know what the relative memory usage is though
and I still haven't actually implemented a decent trie/dfa-ish lexer, so the cache is still 400MB or so after parsing all the tests
but now that TRE is out of the way, I'm running out of excuses :)
basically, instead of using TRE and then doing my own ltm backoff, I just started with my stupid ltm backoff at the beginning, and surprised myself when it ran faster
it's probably more efficient because of all the digraph caching, so it doesn't actually have to run over all that many patterns typically
and we no longer have TRE for a dependency either, which has something to be said for it
some of our programs still use cat
I basically agree, since assignment should try to behave as much like p5 assignment as possible
however, I think eager context may recognize iterators that are known to be infinite, and flip to lazy at that point
so @a = 1..* would still work
well, the problem is that the failure mode of not detecting infinite lists is rather harsh in any case
it could warn
I think gratuitous failure is antisocial.  :)
I'm fine with a warning, but it should DTRT anyway
Perl is more about DTRT than consistency
certainly; the initializer is just an initializer
it's how you reify unreal values, but if an element is reified already, it is just an ordinary array element
a push would of course fail
well, maybe not
it could just add another initializer on the end
surreal lists
it is in list context :)
well, might be
sure, but we're haggling of the api in any case :)
*over
or just "give me a reasonable length to eagerify over"
so I know how big to make the real part of my array
sure, as would any eager evaluation
I think that one should just assume real stays real and spec stays spec
I'd think it depends on @b
it's fine if @b has a finite spec for @a to end up with that eager, but mostly specs in arrays will be infinite, I suspect
the specs probably have to be cloned, since the two arrays are reading independently
which is a good argument for treating IO as finite
I think eagerness only becomes lazy on things that are provably infinite
on assignment, yes
that's the notion we're discussion
*discussing
since assignment has copy semantics
it is naturally eager-ish
we talked about this a couple weeks ago too
it's no problem to copy iterators that are conceptually immutable
but copying a file handle is trouble
1..* is conceptually immutable, but iterable
so it doesn't matter if you clone it
it's also fine if you clone a mutable iterator derived from it, since you presumably already cloned the earlier values too
it's that pure-in-the-Haskell-sense that makes it okay
but in the absence of that purity, I think making eager the default for assignment is sane
and what a p5 programmer is expecting in any case
I think I need to hack the spec a bit though...
if an iterator doesn't know if it's infinite or not, assume it's not
worst case is no worse than p5 now
I think we can assume that 1,2,4...{mumble} is infinite
we can probably also assume an explicit lazy list is to be treated as "infinite": @a = 1,2,3, lazy 4,5,6;
or something like that
I guess we currently only have lazy { 4,5,6 } syntax
depends on where the signature is
in any case, it's not really what you want
if you want to bind an actual Array object with Array semantics
that lets you modify values that were initialized with immutables
more like *@a is copy
perl6: my @a := 1..10; @a[1] = 42;
should fail
my @a := Array(1..10); @a[1] = 42;
perl6: my @a := item(1..10); @a[1] = 42;
perl6: my @a := [1..10]; @a[1] = 42;
that shoulda worked, I think
pugs: [1..10].WHAT
my @a := [1..10]; @a.WHAT
pugs: my @a := [1..10]; @a.WHAT
grr
feed operators are considered bindings rather than assignments, I think
perhaps it's just the syntax for adding a spec to an array
@a &lt;&lt;== 1..10 adds a spec
@a &lt;== 1..10 replaces
maybe I didn't
in any case, I think feeds should try to be lazy
we're in violent agreement
I think that's sanestest
and everyone is dwimically pleased, we hope
I need to go dwim some lunch &amp;
what they said
we know when, we just don't know the date of when
then your teachers didn't understand present tense either? :)
I think we should have a teepee party instead.
and the ribbon will therefore be white
the smokers can stay on the second floor
used to be only two, but they grue
you can be a gruesome twosome
they can all be grue members
I'm not allowed to attend maisons
funny, my church says the same thing
well, actually, it's the manual that sez it
go for it
msg me your email and preferred nick
hmm, commitbit seems to be hung, might take a while
well, I can't seem to get it up
(don't take that wrong...)
you can go ahead and work on it anyway, and someone could always apply a patch for you, till we get feather straightened out
bingo, got on
commitbit sent
it's customary to add yourself to AUTHORS as a test commit
seems like you could omit the highlight:
it's still doing identifiers wrong; it shouldn't make True blue in
push @basetypenames, "True", "False", "Bool::True", "Bool::False";  # in quotes lest gimme5 translate them
identifier is also wrong in constant %term            = (:prec&lt;z=&gt;);
and something strange is going on with parameters; they;re two-tone
*they're
also token statement_control:unless {
irssi is fine with 'em
the "unless" should not be highlighted, it's just the key of a pair
and some :syms are colored while others are not
vim isn't trying to use the standard grammar...
$longname comes out wrong too
it's coloring the longname like its a token name
you have to ignore 'identifier' most of the time, really
generally identifiers are part of something else that determines the color instead
and if the more important context comes later on the line, you have to ignore an earlier "identifier"
nibble, pairs, and variables all hide identifier
yes, STD.pm
and I really don't understand what's going on with when it decides to make :sym red or blue
but it seems rather random
in method EXPR ($preclvl)
it changes from blue to cyan after the p
you shouldn't be calling is_routine on that identifier
@tell masak yes, p6 macros are hygienic, as long as they return AST and not text.  quasiquoting provides a convenient way to return AST.
$: used to be a list operator, but now it's just $ args
btw, can someone tell me which hemisphere I'm in today?
$:foo is the twigil now
maybe Many Worlds?
should be
yes, STD thinks it's an error (as rvalue)
hmm, currently STD requires a space between $ and : in a sig
that seems fine to STD
might just be the bare sigil form of parameter is too picky
well, can't really look at it right now--don't even have time to backlog yet...
bbl &amp;
@tell mncharity thanks for the p5regex nopaste
the block of map needs a comma after the block
rakudo: map { .say }, 1..4
yes, there is no indirect object syntactic slot like there is in p5
and nothing defaults to $_
to throw out one of the lists of exceptions that people had to memorize
it's not that much harder to say .say
you don't have to know that certain vars are the same var in every package anymore either
rakudo: [1..4].map: { .say }
it's just that Range objects aren't sufficiently listlike yet
map should probably be coming out of some kind of Traversible role
I'm not familiar with symbian, so you'd have to ask the parrot folks
what is symbian?
Any is okay for now
but that doesn't explain why Range couldn't find it...
or is that not checked in yet?
but eventually it probably wants to be abstracted into some kind of a role for anything traversible
which might or might not be the same as a List role
course if anything not traversible is its own list of one element, then maybe Any is appropriate
I think the basic question is, what does this look like in list context?
so certainly hashes work
it might also be closely related to the Iterator interface
driving to socal today, so feel free to pass on ops to other long-term denizens if you start running short of ops
@messages
biab &amp;
Matt-W: do you need a commit bit?
heh, &lt;lambdabot&gt; Plugin `tell' failed with: thread killed
hmm
pmichaud: not really, other than similar things go close, and ops are in prec order
cspencer: not sure.  can try issuing commitbit under other name and see what it says, or maybe there some way you can fix it
I've tried a reissue, but it didn't show up in the list as pending, so I dunno...
masak: I backlog
$a..$b:by($c)
yes, but I could see possible uses for fractional values if we treat 'A'..'Z' as a list to be indexed into by the current numeric value
'A'..'Z':by(.5) ==&gt; AABBCCDDEE...
though I'd not go out of my way to support that
since it could be considered Born Obfuscated
but if it has no other meaning and falls out of the semantics
so 'A'..'Z':by(2) would be ACEG...
'A','C','E'...*   ;)
did the new commitbit help at all?
re $a..$b:by($c), it actually parses wrong, since identifiers can be extended by adverbs
so it parses as $a .. ($b:by($c))
one would have to say $a..$b :by($c)
it works find as long as the final value of the range doesn't end with an identifier
yes
just as in P5
sure, but nothing happens :)
you have to have a null range possible from $a..$b and you can't if it autoreverses
that was how it was designed, but I'm thinking multis should always be imported by default
most languages that do multiple dispatch just make them all global
we don't do that, but importing all the multis we find anywhere seems like the next best thing
where, in this case, "next best" actually means "better" :)
we could just merge them into a multisig proto
then we complain only on a multi that doesn't match either of the protos
on the other hand, it might pessimize rewriting named args to positionals, and make it much harder to do multiple dispatch
readonly to whom?
no, they're rw
yes, "is rw" is applied only to the accessor, and since there aren't any accessors there, it's a Useless Use of "is rw"
we could require it in the spec, but that seems like overkill
in general, it's fine to warn about anything the compiler knows is completely bogus
it's when it starts guessing that it gets into trouble
there are some instances of .= that STD currently guesses about wrongly, for instance
well, guessing on warnings has less danger than guessing on the actual p6 parse...
and in the case of .= it continues parsing as if it's a mutating method call, but it doesn't like my Fooz $f .=(:x(1)) from t/oo/construction.t
it's because multis are really more like methods than like functions
you don't have to worry about exporting methods either
they Just Happen
the only reason we don't just shove all multis into GLOBAL is that we want different lexical scopes to be able to support different languages
and we don't want magical action at a distance, esp at run time
so we want to know at least the set of protos by compile time
we could go as far as to disallow run-time multis in packages unless there's a compile-time proto in that package
because it would be really nice for the optimizer to know exactly what set of multis it's dealing with
=~ rather
in p5 ~= would be the xor assignment operators
or maybe that's ^=
indeed
the warning is entirely correct
and p6 will parse that as $_ = ~/.../
so it's Simply Wrong
doesn't allow file globbing in args very well
most users will only see the mundane options
even if they desugar to something with ++foo ... ++/foo
in this sense p5 only has mundane options :)
I do think I'd capitialize all the magical ++FOO thingies though because it's hard to see them otherwise
what there's other compilers than gcc?
it must be 2008 or something
I think they want to be shouted
otherwise the proper subsystem might not hear :)
p6 knows how to deal with failure :)
--CHECK seems unnecessary when you can just say -e 'CHECK {...}'
bbl &amp;
[particle]: you missed the -e
[particle]: as in -e 'CHECK...'
only thing is, -e would throw off the line count
all the self!foo should be replacable with $!foo
and as pointed out earlier, 'is rw' is useless on private vars
ovid: Doctor, it hurts when I do this...
if it's a public method, you should just use $.foo
if it's private and you know it's a no-op, why do you have it?
then give the backing store a different name, since it obviously doesn't mean the same thing :)
^^ &lt;!before '.'&gt;
funny that that also means pugs
"the mouth is fitting" :)
9 strokes
can search on that too
you'd have to ask putter about that...
it's just a method call
and Grammar.parse($string) should work
or StoryGrammar.new($string).TOP
also .parsefile($filename)
ruoso: storing packages under "Foo::" key seems okay to me, though presumably one could also store it magically within the Foo protoobject somehow
presumably the long name has all the version numbers too...
either that, or Foo::Bar::baz can mean different things in different scopes
sounds good
for some reason it's really easy for me to fall into P5-Think now and then... :)
equiv to :export(:DEFAULT) really
indeed, and :DEFAULT is just a term
do we want to disallow :export($?FOO) is the question...
is export&lt;foo bar&gt; is possible
some value in preserving the pair "look" for consistency though
no, not semantically
would be more like is export('DEFAULT')
presumably the trait still has to poke an alias into ::EXPORT::DEFAULT
but traits are active, not passive, so doesn't seem like a big problem
I need to glare at S11 a bit and think about it, but maybe
might need to reserve bare names for something else like aliases though
doesn't everything?
junctions are mostly for doing comparisons in boolean context
so any(&lt;a b c&gt;) ~ 'd' eq 'db' is True
slavik: we do use such ideas all the time in English: "If the value is 1 or 2 or 3"
there is no guarantee of serial processing. the computer can try to decide the fastest way to falsify it
but it's specifically for logical parallelism where you plan to throw away most of the results
if you say all(@list) == 42 it's allowed to stop processing @list as soon as it sees something that is not 42
yes, I'm assuming that
I personally thing that junctions are only for that
*think
if you want other forms of parallelism, we try to provide those too
so attempts to make junctions do that are a bit misguided
which is why we don't provide a lot of user-visible methods on juncitons
we don't want people trying to do set theory with them, for instance, except in boolean contexts
the hyper keyword says you don't care what order the following list is calculated in
it also asserts that you likely interested in all the values
in the sense of eager()
hyper is a form of list context
as is eager
slice context is another modification of list context, but orthogonal to hyper/eager/lazy
hyper for does that
but that's becuase for knows it's in list context
hyper for is identical to hyper map, except for argument order
yes
note, hyper says you don't care what order evaluation happens, but the list is still serialized
well, Erlangy things will tend rather to be done with ==&gt; and &lt;==
an object pipe with signature matching on the end is very Erlangy
my job is just to make sure it's clear which constructs promise which parallel semantics, but there is no real guarantee of parallelism anywhere within any traditional von neumann computer, so that's about all we can do
for instance, ==&gt; basically promises a clean thread fork
where the definition of "clean" is still under negotiation
it's very analogous to | in a shell
not yet
had to wait for holidays to pass, and still have to be cleared by my gp
and that may depend on what my GI guy tells me about my capsule endo
very strange to swallow a pill with a xenon flash bulb going off twice a second...
well, I checked for a week, and didn't see it, so it could still be in htere
well, as my doctor said, if it does get stuck, it's Diagnostic...
take care
yes, just because STD parses something doesn't mean it would interpret the bits like you would, if it did interpret the bits, which it mostl doesn't :)
masak: we could probably use a p5-identical pack/unpack, but long term we'll probably be de-emphasizing the template language as something that a user would deal with directly
rather, we'd use compact classes to represent layout, and ask the class for the template that will unpack it
or something like that
but an identical pack/unpack will at least be useful for p5 migration
and precompiled templates can dispatch via a different type than Str
or we'll just have a direct serialization interface (.pack/.unpack?) for the class
I don't see any problem with that
and it's not something we have to "get right first"
on 4-arg substr, I haven't made up my mind yet
it's not clear to what extent P6 strings are mutable outside of a variable containing a string
so it may be some OO notation is better for mutating a string variable in place
we do already allow .[] on Buf types
Str is not a Buf type
otoh, NFG is not variable-width in terms of graphemes, so maybe we could allow .[] there too
masak: you can cast as long as it's perfectly clear what hte mapping is supposed to be
Normalization Form Grapheme
not something you'll find in the Unicode docs
well, a pragma could set up defaults, but in general you'd want to have an interface much like Encode provides
NFG is basically a local mapping of multiple codepoints into a single grapheme number so it can be stored in a single array element
we assign them temporary negative numbers so as not to confuse them with Unicode codepoints
speaking of syntax highlighting, I noticed perl6.vim seems to be making my vim slower and slower... :/
considering I own the overall copyright on Perl 5, unless the individual file says otherwise, I'd say there's not problem
then feel free
you have officially "made other arrangements with the copyright holder" :)
it pretty much has to, since it's short for ('aa') or {'aa'} when used as a subscript
I think it's relatively harmless unless you get into the habit of using &lt;&gt; where you should use ''
for bare terms, pragmatically you only ever use &lt; a b c &gt; for multiple items
and with .&lt;&gt; subscripts, it mostly doesn't matter
some of us do go back and forth, and there will always be some recurring brainos because of that  :)
s1n: basically, no one implements :by yet
though STD parses it okay
std: (1..10 :by(3)).say
that means it likes it
dinner &amp;
that's why you should use .comb instead of .split
rakudo: "  a b c".comb.perl.say
pugs: "  a b c".comb.perl.say
rakudo: "  a b c".comb(/\S+/).perl.say
should default to \S+
oh, and the p5 behavior of trimming trailing fields is not in p6
(for split)
rakudo: "  a  b  c ".split(/ &lt;.sp&gt;+ /).perl.say
I think rakudo does that right
c didn't have a space after it before
quick, hit the undo button
yes, it is, but Friday night is perhaps not the best time :)
nevertheless, /msg me your email addr and preferred nick and I can add you
commitbit sent
it's customary to add yourself to AUTHORS as first checkin to make sure it all works
diakopter: okay, that's good to know.  going through the whole restart procedure is a bit of a pain...
:$bar, not $bar:
a sig of ($bar:) would indicate that $bar is the invocant of a method
the invocant marking : is a comma variant
$self: $a, $b, $c
yes
manfile?
well, from a FP viewpoint having a function with options means your functions aren't correctly decomposed
so having options is a bit of a design smell at times
but not everyone is a functional programmer :)
so we're in the business of encouraging clean code, not requiring it...
okay, I see what was confusing you
that $string is in fact an invocant
and as such, a positional parameter
the task is to allow :$string on the call
or string($x)
:string rather
and have it map to positional
(presumably because the position of the name can be derived from the proto decl)
can omit the () in that case
but because it's the invocant, there's no notation for using a name parameter as the invocant
so line 85 is a bit misleading that way
*88
sorry
my foot slipped
well, actually, that particular method is exported
so there is a function form where $string is just a positional parameter, not an invocant
so capitalize(:string($x)) makes sense
an exported method sig should get rewritten to a function sig
but an exported function sig doesn't need to be rewritten
when we export a method, it's no longer a method, but an ordinary function
it's how we "pun" various builtin methods into functions without having to write two implementations, one a method and another a function
so @array.push(1,2,3) and push(@array, 1,2,3) are really calling the same code
yes
it's the "is export"
it's mostly the latter
most user defined functions are just 'method foo ($x, $y) {...}'
or 'method foo (Int $x, Int $y --&gt; Int) {...}' if you get typey
typical function is 'sub foo ($x, $y) {...}'
or 'multi foo ($x, $y) {...}'
well, a multi is likelier to have types
it means there are other definitions of the foo subroutine, and the dispatcher should pick the best one
suppose you also have 'multi foo ($x) {...}'
then it knows which one to call for foo(1) vs foo(1,2)
but same principle for types as well as argument count
all the builtin operators are really multi subs with funny names like infix:&lt;+&gt;
so when you say $a + $b it can decide whether to add to integers, or floats, or complex numbers
s/to/two
the default is an "only" sub, as in p5
so mixing one of those with a multi is likely an error
and an only sub is easier to optimize
an inner "my only sub" hides all outer multis of the same name
I just mean an inner lexical scope
anyway, the main point is that in perl 6 we try to encourage the programmer to convey the intent such that we can catch mistakes of the 1 vs many variety
that's also why hyper operators are explicit
like vector addition on a Cray, or in a GPU
@a &gt;&gt;+&lt;&lt; @b is also acceptible, though uglier
well, not acceptable to lambdabot :)
those are the "Texas" versions :)
pugs: (1,2,3) &gt;&gt;+&lt;&lt; (3,2,1)
well, without the reduce part :)
pugs: [+] 1,2,3
that's the reduce
it's intended to be visually distinct, and have associations with lists
then you can always call reduce()
it's only defined for infix operator
but that includes user-defined ops
no need for the 'sub' since bare blocks are closures in p6
pugs: (1,2,3).reduce({ $^a + $^b })
there you go
try http://perlcabal.org/syn/
:string
Str is the type, and isn't used for named params
therefore :foo($x) should work
to the function call, but not to the method call
in theory, either should work, though the latter is arguably bad style
we outlawed it once upon a time, but I think it's currently valid. and positionals are just filled in after the named parameters are bound
or, looking at it the other way, any given parameter looks for a named binding before shifting the next positional
the bindings have to be done left to right in the parameter list of the sig, so that defaults can refer to earlier parameters in the list
how mean do you feel?  :)
good testers feel mean most of the time :)
nobody will shout at you for installing failing tests...
in fact, that's kinda the point :)
and we tend to go on a forgiveness rather than permission basis, so if you goof it up, we'll just fix it later
though it also doesn't hurt to ask if you're unshure
that's what revision control is for :)
well, if you happen to know that it will cause a parsefail
then you can install a "fudge" line like you already see lots of examples of
and then the fudge preprocessor will comment it out or eval it or whatever
no, it should parse fine
std: samecase($pattern, :string($foo))
that means it liked it
std: Int: 42;
that means it didn't
it's just the STD parser
it says how many seconds it took and the memory
but since it doesn't run it, it says nothing else if it's correct
yes, pugs can't handle it, though I'm not sure if it's a run time error
anyway, you can use fudge for pugs too
it'll rewrite foo.t to foo.pugs, and then you run that
or foo.rakudo, or whatever
the make test tends to do that for you
well, gotta decommute, have fun
bbl &amp;
no, but hyperchomp should
s1n: the whole point of multi is to support overloading, or are you asking for something else?
in theory they're meaningful, most of 'em
if .() is just a funny method, then there may be more than one candidate
in which case .*() makes some sense
or there may be no candidate, in which case .?() makes sense
yes, do all of them
until one says its the last one
see S13:162
method postcircumfix:&lt;( )&gt; ($capture) {...}
we don't support those any more, I think
fossil from when :r et al. were implemented that way
no, any postfix may take an optional dot
(except alphanumeric ones, I guess)
we're trying to establish generic rules for extensibility
yes. $x.i must now be written $x\i
or ($x)i
so the dot form is becoming less important
might go away someday
possibly the dot forms could give direct access to a method form, if the dotless form is mediated by a multi function
currently only alpha methods work as private, not sure if we need to allow non-alpha, esp if it's ambiguous
would make it hard to define postfix:&lt;!&gt; as factorial, for instance
I haven't really had much to do with the .^! forms, that smop internals :)
*that's
so perhaps not officially part of the language
yes, still working my way through it all
got stuck on your first remarks, and found STD needed some non-trivial work :)
well, infix:&lt;;&gt; disappeared today, since semilist can parse statements anyway
all that is dependent on work in the lexer, unfortunately
the current form of metas is kinda hand-to-mouth to get the common ones to work
but I'd like to support all combinations of metas that aren't recursive
and it doesn't do that yet
nope
can't have left recursion in a DFA!
well, can't have recursion in a DFA at all..
well, it's an accident if it works recursively
that's illegal
postfix may never have whitespace
std: $a.&gt;&gt;&gt;&gt;++
hah
well, it's not doing that with the lexer :)
yeah, it cheats on those, basically
they aren't really in an alternative, so the lexer doesn't come into play
but infixes can't do that
not and keep LTM working
I could if I abandoned LTM for metas
but then things get dicier in other ways
that's my feeling
you can always define your own infix and go from there
yes, well, that part of the lexer isn't fully up to the task yet
you'll note even the reduce meta cheats
instead of calling infixish
it calls out the infix and meta-infix separately
but infixish has side effects that prevent it from composing right as it stands
again, a hardwired solution to composition rather than a general one
it's very easy to get a combinatorial explosion of possible tokens
it's quite possible that I'm trying for something impractical in fitting all the metas into the LTM
and maybe in the long run the meta bits will have to be considered as separate tokens, and the metaops parsed normally
another approach is to require complex metaops to be space delimited
thought that doesn't help with postfix, necessarily
*thoug
h
grr
especialy in mtnview :)
ll
grrr
well, gotta get up at 6 to take teens to a quiz meet, so I'd probably better retire me own self...
seemed pretty self explan
night, thatnks!
s:3rd/t//
afk &amp; # zzzzz
not in the same namespace, that would be an ambiguous dispatch, hence illegal
however, 'my multi' can be used in an inner scope to override the outer def with that sig
afk &amp;
all functions not defined in the prelude need to be exported, and pack/unpack aren't methods
re substr, yes
I don't know if anyone actually implements the StrPos type
perl6: my StrPos $p = 3; say ($p+1).WHAT
that ought to print StrPos, not Int
perl6: my NoneSuch $p = 3; say ($p+1).WHAT
nobody really has the types right yet...
yes
didn't I say that already?
09:54 &lt; frew&gt; also: in the substr test substr(Int, Int) is the only multi (it seems) that gets tested.  Should we added substr(Int, StrPos) and substr(Int, StrLen)?
10:08 &lt;@TimToady&gt; re substr, yes
np
yes
but not a negative StrPos
on the other hand, code that assumes StrPos and StrLen are integers is probably wrong
you can't have a position in a string earlier than 0
but a StrLen is the difference of two StrPoses
and they can come in either order
we don't do that in p6
not for array subscripts either
we use *-1 to count from the end
so we know explicitly that it was intended, and not accidental
@foo[*-1]
* means "whatever"
which a subscript will interpret to mean, plug in the size of the dimension here
I oversimplify slightly
but the basic idea is that any operator can decide what * means when passed to it
so 1..* means one to whatever...
good question
it really depends on whether we ever allow strings with variable-length encodings
but we're moving toward a fixed width encoding by default, so maybe it's okay
biab &amp;
read the spec?  :P
S03:3227
or thereabouts
sorry, bad connection with huge lag times...
and have to go catch a ferry
back in a couple hours &amp;
I've been pondering the e question...
and more generally, the subject of constants
my inclination is to say that e is a funny enum
like True
because then it parses without the expectation of arguments
we don't currently treat 0-ary functions specially like p5 does
easier, I think
yeah, well, any color as long as it's ruby
to perl6, all other languages are DSLs
I guess if we treat the type of an enum as overloadable, we can say enum Num is also :e(2.7182818) or some such
assuming we make sub definitions override types
so what happens if someone defines a sub named True, I wonder...
and what happens if they declare a sub named Bool, I wonder
or Num
from the parsers standpoint, I have to know whether to expect an infix or term after Foo
*parser's
I guess the difference between a type like Bool and a type like True is that the enum is actually defined, not a protoobject
named values want to parse like types, but e.defined should be true
if you say Bool(), it's just a coercion from nothing to Bool, which presumably gives the Bool protoobject
but if you say True(), it's not a protoobject, since it's defined
pugs: say True.defined
I suppose it's okay to say "coerce this to True"
where this is nothing
but it really bugs me to see tests for e() for some reason
and I certainly don't want e 1 to parse
or worse, e + 1 to parse as e(+1)
I don't really want to special-case 0-ary subs, when 0-ary multis mustn't be special-cased
multi foo () {...} has to look for arguments in the parser to know where there are any to feed to multi foo ($x) {...}
s/where/whether/
so I don't really want to treat constants the way Perl 5 does
so enum values seems like the right model for named singleton defined values
or imported
it can still live in Num
so Num::e is unambiguous
but I'm thinking defined values really shouldn't be responding to () unless they does the right role
so I think I'm gonna say that e() is illegal
well, not illegal, but a call to sub e
not a reference to the constant value
std: e()
heh, well, we're already there :)
std: pi()
std: pi
std: e
yes, it's called tryfile--I always just copy-paste the svn output containing tests to it
however
if you feed non-.t files to it, it'll get confused
and it can't tell the difference between p5 and p6
you might have to add a t/ link to your perl6 directory though
I suppose it could search up the directory tree
std: i\i
you can't use a metapostfix with whitespace, though I suppose it could be unambiguous
well, no, it would mean $_&gt;&gt;.foo presumably
not sure how it's actually parsing past the hyper at the moment
oh, of course, it's looking for the infix
those aren't LTM anymore
listop requires whitespace
not sure if that helps though
$&lt;&lt; $a
std: $&lt;&lt; $a
wonder why my compose key stopped working...
now it's working again, weird
TheDamian was suggesting forcing X= to mean the other thing
that is, [X]=
lunch &amp;
but only , has the exception currently
oops, afk &amp;
you mean submethod BUILD?
perhaps if we were designing classify now we'd make it return a Capture of positionals for numeric values and named args for string values of the closure
yes, well, classification is a bit unweildy :)
and class is taken...
I like verbs
and Nasa has a long tradition of nouning verbs.  "Go for deploy."
dduncan: that's not very user-friendly, at last for the typist
*least
perl6: say ('a'..'z')[24,4,18]
std will only tell you if the syntax parses; it says little about semantics
what would it mean?
repeat the last element?
when used as the only element, it means all the subscripts
though I doubt anyone implements that yet
perl6: say [1..10][*]
* means all the subscripts in this dimension, so for one dimensional, it comes down to that
note that [] is 0-dimensional, while [*] is 1-dimensional
perl6: [1..10][*;*]
see S09
std: (1..10)[Stuff::and::nonsense]
we need to describe all the basic types in real P6 code
but anything that is iterable should be coercable to Positional somehow
if you use a range as a list it should behave
it should be no different from using a range as a part of a list
std is a parser, it doesn't know semantics
though it knows that "isa" isn't real
perl6: say Range ~~ List
no, it would be a does
pretty much everything is a role as well as a class
most of the basic types are punned
certainly, you can iterate over a range without using indexes
not really
iteration over an Array is non-destructive
so something has to keep track of the current index
even if that's hidden in an anonymous spawned iterator
perl6: for 1..10 { .say }
biab &amp;
re "class is Foo {...}", you can currently use class { is Foo; ... } as a workaround
also :: parses as a package name, and could be forced to mean anonymous
std: class :: is Foo {...}
much like you can currently say "sub &amp; is bar {...}"
or "my $ is baz = 42"
if (state $)++ is perhaps a better example
probably
looking
sorry, got a phone call, looking again
[] is now used to disambiguate multiple metaops
basically any infix maybe have [] around it without change of meaning
$a [+] $b is same as $a + $b
but you can distinguish X[+=] from [X+]=
(description of reduce should probably mention that it only takes infix ops too)
I think you missed use of [] to declare a shaped array
{N} and {N..M} in regex are wrong
it's just ** N and ** N..M these days, though a closure is allowed after **
in lparen, the (&lt;&gt;) entry is wrong
() is just capturing, &lt;&gt; is metasyntax, and they're unrelated
though &lt;( and )&gt; are standalone tokens indicating start and end of official match
maybe you meant &lt;(...)&gt;, but that's &lt;{...}&gt; these days
+ is no longer a twigil, * now indicates contextual variables defaulting to global
oh, we also add &amp;[+] as a short name for &amp;infix:&lt;+&gt;:(Any,Any)
(or something like that)
- may now be used (along with ') in the middle of an identifier eat-fred's-sock($x)
I do not see how - has wildcard uses in versions
- and ' aren't quite equiv to underscore
_ is simply considered alpha, while - and ' require a following alpha
(and may not occur at the front)
oh, just a nitpick, technically - isn't a dash to a typographer; dashes are longer, hyphens are short, and - is somewhere in the middle
er, minus is somewhere in the middle
also, * no longer means GLOBAL, but you know that
I'll have to look at the rest of them later, my ride home is here.
yw &amp;
@$x is fine
@shaddap
shinobi-cl: smartmatch with a list doesn't do any() automatically
pugs: say (1,2,3) ~~ (1,2,3)
but the official flattener is prefix:&lt;|&gt; these days
I haven't been tracking the IO work
pugs: say 'a' ~~ any('a','b','c')
I don't know why it didn't find test; looks like a bug
I guess it's because pugs never got as far as implementing Captures
rakudo: sub test($aa, $bb, $cc) { say "1:$aa 2:$bb 3:$cc"; }; my @numbers=7,8,9; test(|@numbers);
I guess rakudo is still hosed
anyway, that should work
| is a no-op in list context
pugs: my @list = &lt;a b c&gt;; say "yes" if "a" ~~ any(@list)
dinner &amp;
digitalicarus: Perl 6 is *potentially* faster than Perl 5 because the optimizer has more information, but we're concentrating on "correct" before "fast"
fast will come later
digitalicarus: these are all turing complete languages, so the official answer is "no"
but there are certainly differences in what is easy
here's fibonacci in Perl 6: 1,1...&amp;[+]
Perl 6 will have a better native interface than Perl 5
if for no other reason than Perl 6 can actually declare APIs with C-like types
at least for primitive types and simple structs
and the OO doesn't require translation; it can just encapsulate the actual C struct
Perl 6 is all over freedom, and the killer app will come
it's a controlled freedom, so you don't do it accidentally, but all the defaults are tweakable underneath if you want
basically, things that seem generalizable in Perl 5 but aren't really, actually are generalizable in Perl 6
that's okay, we've tried hard to keep Perl 6 a language you can learn small-end first
but they'll be there when you need 'em
assuming we finish implementing it, of course...
certainly, there aren't many things you have to unlearn
$foo[$ix] becomes @foo[$ix], for instance
but that's more regular
and we use .foo instead of -&gt;foo for method calls, for various reason
reasons
and foreach loops are now written for @list -&gt; $elem {...}
because $elem is actually a formal parameter to the block
in some ways, but hopefully better designed
certainly -&gt; $x {...} is like ruby's {|x| ...}
interestingly, ruby is borrowing the -&gt; form, last I heard
60-70% of ruby syntax is straight out of perl
I'm waiting for Perl 6 to run on any platform
have fun
hmm $?PROGRAM makes no sense
the program name is not necessarily known at compile time
it can only be known at run time
it's another topicalizer, but I think "given" is more natural; "with" is too non-specific
that's basically from Pascal
we almost have the same, as long as you put an extra . on the front
given %foo { .&lt;foo&gt; = .&lt;bar&gt; }
lose
but then it would be potentially ambiguous anyway
and you can say given %foo -&gt; $f { $f.&lt;foo&gt; = $f.&lt;bar&gt; }
even if %foo is very long
well, in that case, $f&lt;foo&gt; = $f&lt;bar&gt; is fine
most of the folks around here aren't doing C
lotta people writing tests
pugs is written in Haskell
the STD parser is written in Perl 6 :)
elf is at least partly in ruby
but you can program in Perl 6 if you write tests :)
or there are docs, wikis, etc
even just blogging your learning curve can be useful
well, most of the Perl 6 folks hang out here, and most of the Parrot folks on #parrot on irc.perl.org
various people do various bits of it
and nobody will be offended if you ask around
would you like a commit bit to the pugs repo to start with?
could always use help in portability
I've sent you a commitbit to the pugs repo; which contains the specs and test suite
it's customary to add yourself to AUTHORS as a test checkin
for pugs repo stuff the principle is forgiveness rather than permissions, so hack away
pugs repo is not pugs program
most of the pugs repo has nothing to do with the Haskell implementation
that's still two terms in a row
that book is somewhat obsolete these days
need another ;
} only terminates a statement before newline
std: my @list = 'a', 'b', 'c', 'c', 'f'; given @list -&gt; $l {  say "Reversed array:";  .reverse.say;  say "Sorted array:";  .sort.say;  given .uniq.elems {  when  $l.elems { say 'There are no repeated elements'; };default        { say 'There are repeated elements'; }  } }
if you -&gt; $l it doesn't alias $_
pugs: my @list = 'a', 'b', 'c', 'c', 'f'; given @list {  say "Reversed array:";  .reverse.say;  say "Sorted array:";  .sort.say;  given .uniq.elems {  when $OUTER::_.elems { say 'There are no repeated elements'; };  default        { say 'There are repeated elements'; }  } }
shoulda worked...
pugs: try { die "Foo" }; say $!.WHAT
pugs: for "a".."c" Z ("?", "a".."b") -&gt; $x1, $x2 { say $x1, $x2 }
looks right to me
shouldn't need the parens, either
pugs: for "a".."c" Z "?", "a".."b" -&gt; $x1, $x2 { say $x1, $x2 }
std: say [+] 1,2,3
std: my $a = [+] 1,2,3; say $a
std: my $a = [+](1,2,3); say $a
huh, wonder why it didn't work earlier
probably lost track of the infix cache in lex, or some such
might have the wrong precedence on Z
Tim Bunch was working on one
*Bunce
dunno how far he's got
looks like there's a dbi2-dev@perl.org mailing list
probably waiting for us to get done :)
maybe he can give you something to do, anyway
he's probably better at delegating than I am :)
good luck; let us know if you want a commit bit to the pugs repo
which has all kinds of things in it in addition to pugs :)
pugs: async { for 1..100 { .say } }; async { for 1..100 { .say }};
The end is near!
what did you mean?
no, the index
.[*-1] gives you the last element
pugs ('a'..'z').[*-1]
pugs: ('a'..'z').[*-1]
pugs: ('a'..'z').[-1]
pugs is pre *-1
pugs doesn't know shape yet either
frew: dimensioned array
re rakudo v bot; it's a Cosmic Divergence
my @a = [1,2,3] only puts 1 element into @a
frew: um, it was the other way in Perl 5.  why do you think I changed it?
it's also surprising when someone writes print ($x + 1) * 2 in Perl 5
if you really want a little visual separation you can always say foo.(1,2,3)
but p6 get a lot of its power and extensibility from being consistent about postfixes
the consistency runs the other way too: you can be guaranteed that foo() will always call a function
even if foo is otherwise a keyword
std: if()
yes, to define your interface, for instance :)
if expr requires whitespace
because the expr is not a postfix
people have got into all sorts of bad habits based on C syntax
we have to break a few of those bad habits in order to make Perl relevant 20 years from now
$a doesn't interpolate the list into list context
you're still trying to interpolate $a in a list context
use @$a
|$a should work too
bug, probably
it should flatten nested Captures but not nested Arrays
frew: I'm missing the context
the parens on an adverb are not arguments to anything, they're just a list
so you don't need extra parens unless something binds that list to a scalar later
in list context, parens are a no-op
(same as in p5, btw)
yes, that's what parens are for :)
when binding to scalar context, then grouping becomes important again
pugs: say infix:&lt;+&gt;(('a','b','c'), ('x','y','z'))
pugs: say infix:&lt;+&gt;('a','b','c', 'x','y','z')
however
pugs: say('a','b','c', 'x','y','z')
pugs: say(('a','b','c'),( 'x','y','z'))
pugs: say(('a','b','c'),(((((((('x','y','z')))))))))
no difference in list context
they're concurrent, however the implementation chooses to do it
on a Cray you'd use vector processing
the design of parallelism in p6 is to specify where you want it without specifying exactly how or how much
when you say "if $x eq any(@values)" it can evaluate those in parallel too
when you use a feed operator it's more like threading
pugs doesn't know the &lt;&lt;&gt;&gt; form, I think
foo() ==&gt; bar(), like a unix pipe
only with objects
yes, it's a bullet
I'm fine with -Inf for that
looks like pugs has it that way too
I haven't tried installing either parrot of rakudo after the big move
I try to stay out of politics :)
decommuting &amp;
in theory we'd like to write all of it as a circular definition and then take a "circularity saw" to it for specific implementations for bootstrapping and efficiency
but different implementations could break the circularity in different places
as long as semantics are preserved
which, of course, they never quite are :)
but the short of it is that there's no reason not to attempt to write any particular part of it
depends on which circularity saw you pick, but grep is unlikely to be in the bootstrap
grep should be fairly trivial though, given it's just a ~~ over a list
It seems likely that we'd want to expose the return type to the optimizer at least
so could well be
but maybe the param is the whole sig including --&gt;
but maybe it should also depend on how generic we want the types to match when we do type matching, dunno
I guess we need to see use cases to decide
certainly return type is more like the typical array
but it seems like the shape of an array is like a sig
and that's part of the parameters, it would seem
for matching purposes, you'd almost like to know how to wildcard the params that were defaulted
which also says you want to have wildcards on matching defaulted params
you'd probably want to ask that on #parrot
oh, for p6, we're certainly thinking about books
but p6.0.0 happens some time after parrot 1.0
well, everyone here is so impatient that they're working on it  :)
whether or not they have time...
mind, some of like to answer snidely :)
jnthn: of course not, I'm not that smart :)
I thought I'd just wait and read the book :P
just thinking along the lines that $array ~~ Array[$ret,$shape] can wildcard match when $ref or $shape are defaulted
and maybe Callable works the same
so all code matches Callable, and less matches Callable[Int], and even less mathes Callable[Int,:()]
or maybe we do something explicit with Callable[Int,*] when we want that
anyway, something to thunk about
seems ripe for autocoercion of some sort, but how to define it?
this reminds me a bit of the problem of letting a literal remain generic until we see what type it's used as
and certainly Perl has the notion of Any --&gt; Int autocoercion built in philosophically
but there needs to be some distribution of that notion over composite types, and that depends on the container
much like a sig could specify how much latitude there is in matching a parameter that it can handle
certainly
Array[Any as Int] or some such, but specified in the sig
so you get it automatically when you say Array[Int]
maybe a property attached to Int
but I like your idea of noticing it at the point you'd fail the type check otherwise
but maybe that's the wrong way to think of it
@a = "1","2","3"?
that can't work
not without making .delete a macro
that's why we spell it %h&lt;k1 k2&gt;:delete now
that's another approach, but we decided to just make it a modifier on the subscripting operation
likewise :exists
is potentially less overhead as well
and &lt;k1 k2&gt; is a slice, if you were asking
or even if you weren't...
so it would delete both keys
someone should write a boticelli
the secret is out, you're actually a bot
I wonder how sort and hypers will suppress "use of undef" exceptions...
well, that one we could conceivably handle with -&gt; $a, $b?, $c? {...}
I think of "interface" as a kind of barrier with holes in it, in general
it does?
darn, now I'll have to figger out how importing is supposed to work...
o_O
well, viv can spit out regex AST
std: say (1+2*i).polar
I expect that STD will take over the world eventually :)
pandemic, we hope
I'm not enough of a math wonk to have an opinion on that
most of that stuff has moved to S32
so it's not a bug until the spec changes
it has certainly been discussed there before
the point made in the thread was that it becomes easy to find the quadrant if you know the sign of both the real and the imaginary parts
and presumably easily normalized the other way with %2*pi
er
%(2*pi)
'course, -pi would give you the quadrant in the other case, so it's not a biggie either way, as far as I'm concerned
but it seems like something p6l would like to haggle over^W^Wvote on
(again) :)
well, we could always say the funcitons can return whatever they like, and you have to do your own % (2*pi)  :)
I bet everyone would hate that
the alternative would be to have multiple versions of the function, or a parameter
clobber the namespace, or clobber the performance :)
there's something to be said for a foolish consistency
anyhoo, I don't profess to speak for the mathematicians
but somehow I doubt the mathematicians could find a single spokesperson they'd agree on :)
the number of opinions on the subject you'll get on p6l will approximate 2*pi, I believe, because there are about pi mathematicians there, and about pi non-mathematicians who will have an opinion anyway.
bacek: first one should be True
I can argue it both ways
the fundamental question is whether [\op] treats comparisons as short circuit or as independent tests that are only anded at the end
and beyond that, which interpretation is more useful for any purpose at all :)
or * op $a
by that interpretation, the anding should latch off as soon as it's false
that's probably what people will expect
the list could be infiinte
the question is whether it will always be of the form 1,1,1...0,0,0,0,0....
I'm thinking of various "find first" algorithms
if we go with the 110000000 interpretation, then what I said earlier about [\!=] is wrong
because it should use the identity value for &amp;&amp;, not 1=
*!=
chained comparisons are specced to short-circuit
1 &gt; 2 &gt; die("this is never reached");
only for [\,]
you can't subscript a scalar with [*-1]
only [\,] returns list or list
*of
it should produce a list of Bool
pugs: say [\+] 1..10
pugs: say ([\+] 1..12)[10]
pugs: say ([\+] 1..12)[10][*-1]
pugs: say ([\+] 1..12)[10][*-1][*-1]
pugs: say ([\+] 1..12)[10][*-1][*-1][0]
pugs: say ([\+] 1..12)[10][*-1][*-1][0][0]
on the other hand, [op] 1,2,die doesn't short circuit
in the sense of suppressing the die
in only short circuits in the sense that it in [==] 1,2,3 it doesn't have to test 2==3
I think that still argues that [\==] 1,2,3 should return 1,0,0,0
and [\!=] 1,2,3 should probably return 1,1,1,1
yes, i can't count
*nod*
we need to be careful to return Bool when we mean that so we can multidispatch on it right
that is, +$bool returns 0 and 1, while ?$num returns False and True
sorry 'bout that, my fault
I'd better go mangle the semantics of my Honda instead before it rains...
funny thing is there are two completely unrelated things wrong with it that require door panels to be removed
unfortunately, different panels...
power windows controller on one side, mirror on the other...
car hacking &amp;
S04
rakudo: for 1..4 -&gt; $f { say $f }
$f is a formal parameter to the block in p6
std: push(@stack, pop(@stack) + pop(@stack));
std: my @stack; push(@stack, pop(@stack) + pop(@stack));
rakudo: my @stack := [1,2]; push(@stack, pop(@stack) + pop(@stack));
rakudo: my @stack := [1,2]; push(@stack, @stack.pop + @stack.pop);
rakudo: my @stack := [1,2]; push(@stack, @stack.pop + @stack.pop);  say @stack[0]
you either have to use := [] or = ()
in theory pop(@stack) ought to work
the push as a function seems to work
rakudo: my @stack = (1,2); say pop(@stack)
seems to work in isolation
binding vs assignment
[] creates a single scalar containing an array
if you assign that, you end up with only one element that happens to be an array
yes, basically
decommuting &amp;
std: sub foo {...} for 1..10 -&gt; {...}
thinking...
perhaps it returns a Rat  :)
not specced yet
on the other hand, if Int does the Num role, it's fine to return an Int for a Num return type
but it matches Num more closely
maybe they both do Numeric
or maybe + just doesn't commit to a specific return type
well, AnyAny would convert to IntInt in that case
which seems okay
infix:&lt;*&gt;:(Any,Any) converts via +$x * +$y
which would make two integers and call infix:&lt;*&gt;:(Int,Int)
unless we short circuit the strings with extra candidates, but it doesn't seem necessary
basically, if people rely on the Any cases they get slowed down, so there some motivation to cast explicitly
yes, + can just make the most specific type it can, I suspect
even something to be said for Rat in some cases
esp if the string is '355/113'
well, if the string is 1+.2i, what're you gonna do, truncate it?
we guarantee to recognize radix numbers in strings too...
starting to sound like a longest-token problem
parse this string with term:* and ...
but can other types add term: rules, I wonder...
or maybe we need a number: category
wouldn't be difficult to arrange
indeed
I love it when a plan comes together :)
assuming we require $ too
probably we want to short-circuit normal ints and nums, and only revert to parse on fancy stuff
but that depends on the overhead of regex setup
with or without the "sub"?
they're different
pugs: (sub {}).WHAT
pugs: ({}).WHAT
pugs: ({;}).WHAT
Code
rakudo: {;} ~~ Code
rakudo: sub {;} ~~ Code
because it's a Hash
oh, wait
the value of False is 0
current spec only gets the name via .perl or .name
so we should probably generally only see 0 or 1 on output, unless it's .perled
last week it was stringifying to False, but I decided that was inconsistent with the native type behavior
False should never turn into '' though
that's a p5ism
try it
not sure rakudo returns a value from a named declaration
rakudo: sub (Int $f, Code $b) { say $f; }.sig
rakudo: &amp;push.signature
rakudo: &amp;push.sig
ah well
pugs: &amp;push.sig
pugs: &amp;push.signature
there you go
no
you can't eval expressions as parameters
what are you expecting it to mean?
what would be the use of that?
you can do smart matching on signatures
so there's probably a way to do it
yes, smop is proto-based
the thing ruoso and pmurias have been working on for most of the last year
Simple Matter Of Programming :)
yes
either can be modeled on the other
all depends on how you set up the responder interfaces
this is all swept under the carpet of the object's .HOW metaobject
which decides how to be an object
strange error, but you see it's in the metaclass
rakudo: [].HOW.methods
we surely hope so
std: sub foo ($a, *@@s) { $a.perl.say; @@s.perl.say; }; foo(1) &lt;== 1,2,3;
std: module Foo { our sub bar($arg) { say $arg; }; module Bla { our sub bar() { say "ok 1"; } } }; say "1..2"; Foo::Bla::bar(); Foo::bar("ok 2\n");
std: module Foo { our sub bar($arg) { say $arg; }; module Bla { our sub bar() { say "ok 1"; } } }; say "1..2"; Foo::Bla::bar(); Foo::bar("ok 2\n");
I don't understand why std changes its revision number out of sync with clobbering lex...
std: module Foo { our sub bar($arg) { say $arg; }; module Bla { our sub bar() { say "ok 1"; } } }; say "1..2"; Foo::Bla::bar(); Foo::bar("ok 2\n");
std: module Foo { our sub bar($arg) { say $arg; }; module Bla { our sub bar() { say "ok 1"; } } }; say "1..2"; Foo::Bla::bar(); Foo::bar("ok 2\n");
std: module Foo { our sub bar($arg) { say $arg; }; module Bla { our sub bar() { say "ok 1"; } } }; say "1..2"; Foo::Bla::bar(); Foo::bar("ok 2\n");
'bout time...
I imagine some cron job woke up and rm'd lex/
@tell ruoso addition of number category to STD may or may not break mildew
@tell pmurias addition of number category to STD may or may not break mildew
Perl generally prefers to build its monads into its objects; all objects are Maybe/Error already, for instance, unless subtyped to prevent that
that being said, all is fair in a lexical scope
as long as it doesn't clobber other lexical scopes via spooky action at a distance
perl6: sub infix:&lt;\&lt;-&gt; ($a,$b) { say "I'm a $a &lt;- $b" }; 123 &lt;- 42
std: sub infix:&lt;\&lt;-&gt; ($a,$b) { say "I'm a $a &lt;- $b" }; 123 &lt;- 42
std: sub infix:&lt;&lt; &lt;- &gt;&gt; ($a,$b) { say "I'm a $a &lt;- $b" }; 123 &lt;- 42
heh
rakudo: sub infix:&lt;&lt; &lt;- &gt;&gt; ($a,$b) { say "I'm a $a &lt;- $b" }; 123 &lt;- 42
pugs: sub infix:&lt;&lt; &lt;- &gt;&gt; ($a,$b) { say "I'm a $a &lt;- $b" }; 123 &lt;- 42
there you go
perl6: say map {$_+10}, 1..10
I have plenty of challenges already, thank you...
zulon: but by default, Perl 6 optimizes for you not having to be a space alien
Haskell makes things easy for space aliens, not normal folk
slavik1: you'd have to speak to the parrotfolk about that; I'm just a recovering linguist
ask pmichaud or jnthn
I know you can do inline PIR, so the answer is likely "yes" on some level
haven't the foggiest idea what Weblogic/WebSphere do
I'm not a webbish person
gotcha
but perhaps a bit less probabalistic than mapreduce?
finally, a good use for network transparency :)
so basically it's a kind of virtual server fronting a cluster
what does that have to do with logic or spheres, I ask myself...
I agree.
I should say, I agree with the first part, not the last
it doesn't really need special syntax beyond an lreduce function
if that
whatever, [Rop] @list.reverse
masak: how about .ins and .outs?
missing a colon, I think
.:&lt;=&gt;
skids: assuming it's an unthrown exception, it's just an undef thing
masak: I'm in the middle of a heavy IO edit
but on your Q, newline is not linefeed
in C it is *supposed* to mean the abstract line terminator
you know, guys, "method Int foo (...)" is not legal syntax...  :/
now to go kill termites  :(
rakudo: say ~(1,2,3)
just put the thing in string context
what do you mean by ONCE?
you might be looking for START {}
it's what state vars use the first time through to init
no, and ENTER would
START isn't quite the same as p5's ONCE
if you clone a closure, START will run again
since it's logically a different sub
p5's definition is a bit too static, actually
yes, that looks kinda bogus, given it's specced to switch to Perl 5 when it sees that...
yes
at least, it's allowed to short circuit in any order
so it can do what it thinks are the cheap tests first, or the ones likeliest to falsify
even one() can short-circuit as soon as it finds two
I don't understand your question.  any(@a) is exactly equivalent to 1|2|3|4
@a there doesn't contain a junction
so that doesn't apply
to the first approximation, that means if you pass junctions as part of the list context part of the arguments, they're just scalars
so you end up with 2-deep anys there
but it also means if you pass in @a as a scalar argument it doesn't matter that it contains junctions
my @a = 1, 1|2, 3|4; sub foo(@x) { for @x { .bar } }; foo(@a)
no autothreading happens until $_.bar
if you declare the parameter to the block as Any, it'll autothread
map -&gt; Any $x { $x.say }, @a
but blocks default to Object now
it's supposed to just all fall out of whether the dispatch fails to Object, which delegates to junction
it's secondarily about threading, and mostly about distributing an operator over data values linguistically just like English
if $f equals 1 or 2 is good English
and it works very well where the comparison is implict, like with when statements
std: given ($body) {when(.hasfeet&amp;.hashands&amp;.hashead) { say "doing well"} }
basically, it likes the syntax
but usually you want whitespace around your binary ops
since if it gets out of sync, it could parse &amp;.foo as a function call
er, method call
std: given "body" { when .hasfeet &amp; .hashands &amp; .hashead { say "doing well"} }
well, someone might have monkey patched it :)
well, it should probably be returning Nil, not False
amoc: dunno, I don't track that
depends on what you mean by that
there's no guarantee all the threads will run
if you want guarantees you should be using hypers instead
hyper map {...}, list
you'll still get the results in the same order, however
rakudo: [1,2,3]&gt;&gt;.map: { .say }
pugs: [1,2,3]&gt;&gt;.map: { .say }
std: [1,2,3]&gt;&gt;.map: { .say }
() doesn't make anything
it's only for grouping
clintongormley: you shouldn't ever have to write a function to "do autothreading" if it uses a correct multi dispatcher; the problem with substr is likely that it's using a parrot builtin directly
clintongormley: you should not have to worry about junctions in the implementation of substr *at all*
autothreading is a function of the dispatcher, not of the individual function
all you have to do is declare a correct signature, and it happens automatically
if rakudo isn't autothreading, it's probably because substr is hardwired to a low-level parrot routine that bypasses the normal multi dispatch
rakudo: substr("foo"|"bar", 0,2)
no, no, no, no
you never have to worry about Junctions, period
if the types are declared correctly
(and if it's not hardwired wrong)
but it sounds like substr is accepting an Object rather than an Any
(or it's hardwired)
rakudo: &amp;substr.signature
anything under Any autothreads
or are you asking if Sets behave like juncitons?
you have to say any(@$set) or some such
or maybe any(%set), if it's bound to a Hash interface
well, $set.any probably works too
but the basic point is that you can turn any list into a junction using any(), all(), none(), or one()
junction is not a role that other types take on
don't use split, use comb
which even defaults to words
@strings = $string.comb
rakudo: .say for "foo  bar  baz".comb
oh, but capitalize wants to preserve whitespace, so nevermind
really wants to be $string.subst(/(\S+)/, ucfirst($0), :g) or some such
no, but it does modify its callers $/ to that $0 means the right thing
ordinary comma args can never assume a closure unless you have a macro
oh, yeah, you should always write an explicit closure there
my bad
sorry, distracted...
I don't think it should special case it
s/// is already the special case
and commas should generally mean normal arguments
there's still a place for pure-Perl implementations, but probably in a generic setting with circularities that defines semantics
which implementations (like rakudo) are allowed to override for efficiency
if people want to write a generic CORE.stg in src/perl6 in the pugs repo. that'd be fine
setting?
whatever, just seemed like .set was wrongish
anyway there's already a CORE.pad there that in the long run wants to derived from a CORE.setting
probably not
oh, you mean that kind of capture :)
yes, it should return those in alternation
but comb doesn't return the whitespace at all, so it's no good for capitalize
that's why I switch to a .subst
*switched
"Are those cookies made out of real girl scouts?"  --Wednesday
you need more playing time :)
yes, am admiring the weather in Houston on the telly.  I suspected there was a golf tournament in Houston cuz I saw a blimp when we stopped there yesterday, and confirmed when I got home :)
well, it's nearer Humble, really
yes, all five talks went pretty well
though the one at Bloomberg was very nip-and-tuck
actually started a minute or two late because we had to run a video cable to another room
their "video wall" didn't like my laptops output, or vice versa
s/ps/p's/
anything hanging fire that I haven't noticed in my brief dips in the cyberstream?
besides junctions, of course... :)
that's how I've been thinking of it, don't know how hard it is to implement that way though
and maybe not general enough, given some of the other speculations
but maybe for 6.0 we'll just do something conservative
the specs are some unhappy hybrid of p5 and p6 pod, I suspect
groceries &amp;
seems like cmp should be commutative, whatever it does
been thinking about cmp
I think for different types we want it to default to something dwimmy as long as consistency can be maintained
trick is not getting into a situation where three types do A &lt; B &lt; C &lt; A
if the default is something like coerce to Str and then cmp, then we get a warning on undefs
though we might get a *lot* of warnings...
0 and a warning, if we stick with p5 semantics...
but something to be said for sticky undefs on that sort of thing
yes
so that's grep out undefs semantics
which doesn't help with cmp
since you don't know which way to bias it
Tene: sure, but your half motivated is better than a lot of other people's fully motivated :)
this is a volunteer effort.  this includes the charismatic leaders and the purveyors of the wonderfulness of STD :)
at the moment, I'm still recovering from my last charismatic roadtrip to purvey
charismatic purveyors have to be especially on guard from burnout
those of us working full tilt on getting to Christmas tend to view these things as good but not on the critical path
and when we do get to Christmas, there will be plenty of motivation to do the other things
but at the moment we're still in passion week, so things look pretty grim from time to time :)
and we've done plenty of big splashes in the past, some of which result in negative backlash when instant gratification is not forthcoming.
so our current strategy is to keep it on a low boil
just keep mentioning p6 from time to time on perlmonks and such
this process is a lot like trying to steer an asteroid
doing it with nukes is apt to be counterproductive
just slow steady pressure in the same direction is cumulative
well, time for my Good Friday thing.
bbl &amp;
there's nothing fancy about BUILD signatures, as long as you realize all the arguments are coming in as named args
(and that BUILD needs to be a submethod)
ack is a recursive grep
you need to set the private attributes $!foo
Ask not what Perl 7 can do for you; ask what you can do for Perl 7...  :)
and since Koine Greek was invented by God to be a language in which theological truths could be expressed with mathematical accuracy, you can also use it to produce a 100% accurate translation into English.  :)
sorry, my tongue seems to have become permanently stuck in my cheek somehow...
I remember one of my greek teachers one day saying, "some of you are going to be preachers, and I'll be sitting in your audience"
and you'll get up there and say "dynamai means 'dynamite'!"
if you do, I will stand up in the middle of your sermon and say "It does not!"
and sit down
dynamai simply means "I can".  It's a vanilla word
most greek words are vanilla words
that lesson has stuck with me
most words are not explosives, but small tools to approach the truth
and it takes a great number of them to head off false interpretations even approximately
and there are precious few 100% accurate statements in any natural language, including Koine
but this is as it should be, because it prevents us with coming up with a formula, when the truth is something that can only be discovered by living it
this does not stop people from coming up with formulas for success continually, of course :)
but we should not be fooled by them in either a theological realm or a programming realm
the error is certainly peculiar, but it should be complaining that it cannot find method .sound
so maybe it just printed the wrong string
rakudo: class Cow { has $.sound is rw; submethod BUILD () { $!sound = 'moo'; }; }; say Cow.new.sound;
you certainly can't call .sound with a private attribute
rakudo: class Cow { has $.sound is rw; submethod BUILD ($a) { $!sound = 'moo'; }; }; say Cow.new.sound;
rakudo: class Cow { has $.sound; submethod BUILD ($a) { $!sound = 'moo'; }; }; say Cow.new(:a&lt;arf&gt;).sound;
rakudo: class Cow { has $.sound; submethod BUILD (:$a) { $!sound = 'moo'; }; }; say Cow.new(:a&lt;arf&gt;).sound;
rakudo: class Cow { has $.sound; submethod BUILD (:$!a) { }; }; say Cow.new(:a&lt;arf&gt;).sound;
rakudo: class Cow { has $.sound; submethod BUILD (:$!sound) { }; }; say Cow.new(:sound&lt;arf&gt;).sound;
rakudo: class Cow { has $.sound; submethod BUILD (:$sound) { $!sound = $sound; }; }; say Cow.new(:sound&lt;arf&gt;).sound;
rakudo: class Cow { has $.sound = 'woof'; submethod BUILD (:$sound) { $!sound = $sound; }; }; say Cow.new(:sound&lt;arf&gt;).sound;
well, perhaps BUILD isn't entirely up to snuff yet in rakudo
I suspect they know it already :)
several of the things I tried should have worked
there was some discussion of it several days ago, i think
though it doesn't make sense to declare a $!sound is rw, since the rw is what is applied to the (non-existent) accessor
rakudo: class Cow { has $.sound = 'woof'; }; say Cow.new(:sound&lt;arf&gt;).sound;
rakudo: class Cow { has $.sound = 'woof'; }; say Cow.new.sound;
well, that much works at least
but I think rakudo's .new is faking it at the moment
night, thanks
likely... :)
adding methods to existing classes is kinda evil.  we call it "monkey patching"
and then you use "augment Str {...}"
though nobody implements that yet
diakopter: nevertheless, the current approach is the least worst way to do it, and consistent with other quote constructs, and very easy to work around if you're unsure by doubling or tripling, or by using a different character.
and the mechanism is primarily intended for in-line comments in any case, not multi-line, and it's pretty easy to see if there's potential interference
in case of error, the error message will be fairly indicative of the nature of the problem
if we required people to use curlies, that'd be one thing, but people can use any brackets they like
and the bottom line is that ignoring nesting also producing the wrong result
*produces
so the issue devolves into "Doctor it hurts when I do this..."
the fun third, likely
some people's idea of fun is to do the hard, necessary third :)
std: .=flip
it will never end
depends on how the buffering works
and the implementation of say
I would not expect say to do a join
if it's implement by just fprintfing each value, then flushing on newline, you'll still get intermediate results
when the buffer fills
it's likely the stringificaiton of 1..* will "go meta"
std: 42 ? 43 : 44
std: 42 ?? 43 : 44
std: 42 ?? 43 :: 44
'length' is underloaded
std; my @a; @a.blurfldy
looks like I kill std:
*killed
std: length('ouch')
std: use v5; length('retroactive murder')
std: say [*|+] 1,2,3
std: our $count; multi foo (Str $x where { ++$count } is cached) { say "foo!" }; foo("baz"); say $count;
std: our $count; multi foo (Str $x where { ++$count }) is cached { say "foo!" }; foo("baz"); say $count;
rakudo: our $count; multi foo (Str $x where { ++$count }) is cached { say "foo!" }; foo("baz"); say $count;
std: say [=&gt;] &lt;a b c d&gt;
std likes it
LylePerl: whatever we come up with has to support both one current dir for the whole process (Unix model) or a separate current directory for any dynamic scope that overrides the current directory, which supports things like an apache server running independent threads
the latter has to have some support from with IO, of course
specced as not necessary for 6.0
LylePerl: another design point is that the same interface should work for both cases, so that you can incorporate a standalone script in a server
$*CWD (or whatever name we end up with) is a contextual variable, so can be overridden in a dynamic scope
so separate threads could have different wds
at a fundamental level we're trying to get the same abstract separation that Unix processes get, only between threads
and contextual variables are really modelled on env vars
(except we can have rw ones)
where any child can write
so such a variable would have to have locking
no
I am dubious :)
I know folks would would say "You're using Windows, so it wouldn't matter."  :P
*who would
how do we then explain that Parrot runs Perl 6 better than it runs Perl 5?  :)
masak: it's :: because what's really going on is Cursor.Grammar::rule()
well, $cursor.Grammar::rule
fine
but nameds don't participate in multi method dispatch in any case
rakudo: 3.how.Str.say
rakudo: 3.HOW.Str.say
placeholders are only for use within bare curlies
however, a bare block in a for gets executed immediately (in theory), so { say "$^nth time!" } for 1..3 should work
don't think rakudo does it yet though
rakudo: { say "$^nth time!" } for 1..3
wowee
paint me impressed
but you made it brown!?!
and now my shirt and pants are brown too!!!
rakudo: my @x = ({$^nth ~ ' time} for 1..3); say @x
no, only if you use a for
1..3 is a single argument
an array is also a single argument
you'd have to use prefix:&lt;|&gt; before either of those to flatten
rakudo: my $x = { "iteration first $^x second $^y third $^z" }.(|1..3); say $x
rakudo: my $x = { "iteration first $^x second $^y third $^z" }.(|[1..3]); say $x
what's not intuitive
the whole autoflattening thing is inside out so that parameters like @foo and %bar behave correctly
and context is lazily determined at binding time
the | tells whatever follows to become multiple arguments
even in P5, [1..3] would be a scalar
in P6 .. makes a Range object, which flattens, but only in list context
and $^foo provides scalar context
likewise for parens
(1,2,3) interpolates in list context, but not item context
which rakudo doesn't do yet
but you can't put in {} either, since
that would have its own $^vars
ARR, THEM THAT FALLS BEHIND GETS LEFT!
* hasn't been a prefix op for some time now
think of the | as a sword cut into which you can stuff the extra arguments
is that an inclusive or?
azawawi: see last checkin
well, jet lag has to be good for something...
jnthn: I think the Big Confusion has to do with not distinguishing non-stateful roles from their stateful counterparts
Bool, in particular, is both a readonly interface to values and a readwrite interface to a bit attribute
when we mix in Bool::True we're mixing in the value interface
but when we say "does Bool" we're saying we want to add a Bool attribute
these must be distinguished better somehow, so we know for instance that Array and Hash want the rw versions of the corresponding roles
perhaps "does" pulls in attribute definitions, and "provides" or "presents" or some such leaves them out.
or we have some marker on the type to indicate whether it's pure or not
such that mixing in Bool::True actually mixes in Bool:ro with a readonly .true method, while mixing in Bool:rw gives you a rw .true method
notation is, of course, up for bikeshedding
but the idea is, if you're not specific, things default to the current notation, more or less
and instead of RangeIterator, we might have Range:rw or some such
and Array would be an alias for Positional:rw
well, have to get up in &lt;2 hr, so I'd better try to rest more
zzz &amp;  # maybe
looks like EXPR isn't showing up as a method
pmichaud: see my musings ~2hr ago on what's going on with .true et al.
STD already builds symbol tables, kinda
shower &amp;
azawawi: the packages are all attached via {'CORE'} in the top node, find other packages in CORE::GLOBAL
lexicals are (temporarily) accessible via $*CURPAD, so the reduce action could capture a link to that
afk &amp;
rakudo: ... message
std: ... message
std: ... 'message'
hiragana? :)
you mean, besides all of 'em :)
missing icu?
well, various latin-1 chars are more likely, though long term we'll end up using some number of the mathy ops like set ops
seems like a compose key is more useful than a keyboard
then there's APL :P
I'd like a keyboard I can define my own compose sequences on the fly  :)
can't complain at compile time because you don't know what your dynamic context will be
and $* will look up the dynamic context
yes
with $*, the closest analogy is environment variables
until you run the program you don't know whether it's defined at all
it's just we're treating every dynamic scope as a "process" in that sense
for now, it always puts the warnings at the end, after "Other potential difficulties" or some such
and currently the undef/redef errors are all warnings
I suppose I could put out a special marker between
%p{$key}, not &lt;$key&gt;
&lt;$key&gt; is equiv to {'$key'}
&lt;&gt; always quotes
consistency with the qw form, convenience without special-casing {} like p5 does
and the fact that so many hash lookups are done with fixed keys anyway
not all of which are identifiers
and it became more important with adding the sigil into the variable name: CALLER:&lt;$x&gt;
CALLER::&lt;$x&gt; rather
same as $CALLER::x
but gets the sigil where it belongs
likewise OUTER::&lt;$x&gt;, etc
oh, S02:2000 or so
fetch kid from karate &amp;
zzz &amp; # now dejetlagged to somewhere between CDT and MDT :)
perhaps O'Reilly could just add a couple butterfly wings to their current camel...
well, okay, what's the logo of Linux that isn't Tux? :)
if you want to make big camelia look a little more like the 32x32, esp in the P6, that'd be okay
that too
when she wants to be
LylePerl: note that the smoothest existing version is pugs/misc/camelia.odg currently, since it's in OpenOffice Draw
just had horrors of trying to work from the .png  :)
the 16x and 32x versions are also in pugs/misc
ruoso: well, maybe we can raise the bar on logos as we have raised the bar on other things  :)
but certainly camelia was designed to decolorize, among other things.  it's one of my requirements
pistols at dawn?
well, I can leave that up to the various Perl Distribution Corporations to come up with
yes, trademark is a potential issue
pmichaud: Oh, I don't doubt we could call them on it, but doing so could induce ulcers
diakopter: the latest version will probably blow up better since it's got more transparency info
feedback welcome
I think we have to undilute it before we dilute it  :)
anyway, see misc/camelia.txt now
diakopter: thanx for the bux
it's unclear whether I'm a better lawyer than a graphic designer, but at least Artistic 1 has stood up in court (for now)
or would you prefer swords?
...not to mention the fact that I have two daughters who are both excellent at graphic design, and a son who has done the cover graphic on *two* books.
ben: I'll never tell... ;)
ruoso: detailed critique is fine, but meta-discussion tends not to be terribly useful to me, is all
maybe we should rename one of the things named "proto".  I'm thinking protoobjects could use a shorter name in any case.
I suppose we could just call them types...
but the idea of "prototype-based" OO is that your parent is a prototype, which isn't what these are about
the main thing is there's no Type type, since p6 types are just undefined instances
I guess if we went QM they're most like leptons, as charge carriers with little mass
thinking how we explain it...the type of a type is the same as any instance of the type, er...
even for those types that can't have instances, er...
it's a type carrier the way certain particles are charge carriers, gluons and such
I suppose we can just say "type object" when "type" is ambiguous
sorry, that's two syllables :)
mold...cast...caste...
O kinderlein kommet...
that's a curried type
that's why they sell curry combs for Dogs
but any time you can name a type, or use .WHAT, it shows up as one of these objects
it's a whatitis
as opposed to whatisit, which in Hebrew is "mann", iirc
*manna
how so?
that's not how we define class
in p6 a class is just a type with a certain kind of .HOW
that happens to share a metaclass object among multiple values
so .WHAT is really the identity op, while the type is a .HOW carrier
so it's more of a howzit
so far I'm not getting any bad vibes about renaming protoobjects to types
there's only like 464 uses of the term already in the specs... :)
hmm, "ilk has no plural"
but they have the same type
you're thinking of protoobjects as prototypes again
there's no such thing as a Type
all Dogs have the same type, including undefined ones
or more linguistically, including the generic Dog
I would think of a Dog with a WHENCE as a partially instantiated Dog
but still a Dog
actually, it's lazy instantiation
since we can't really run the WHENCE until we have a real object to put the attributes in
all these things return the same Dog object for .WHAT
including Dog itself
Dog.WHAT.WHAT.WHAT.WHAT === Dog
Dog.clone.WHAT === Dog
===
basically we treat the issue of instantiation as completely orthogonal to the type
Socrates does Man
Man does Mammal
yes
well, 2 is a subset type of Int
but subset types don't show up as the types of actual storage
does's arg is taken as a storage type, not as a constraint type
the type of True is Bool
even though True is a constrained type of Bool
rakudo: True.WHAT
rakudo: say True.WHAT
pugs: say True.WHAT
pugs: say False ~~ True
just as Dog{} is a type plus a WHENCE, a constrained type is a type plus a constraint
True is Bool where { 1 }
but subset types are like that, they're named as types, but if you try to use them as a type rather than a constraint, they squirrel off to being their actual base type
this idea comes from Ada, actually
see http://irclog.perlgeek.de/perl6/2009-04-25#i_1093620
pmichaud: did you look at my backref?
all the boolean contexts call .true, so it's fairly fundamental
we can certainly provide a .Bool that calls .true and returns a Bool enum
correct
and .true may or may not map to a storage bit
depending on whether we're using Bool:rw or Boo:ro
I think this rw vs ro thing runs through a lot of other roles too
do we want the interface with or without the attributes, basically
or maybe, if the accessor is overwritten and doesn't access the storage, we don't allocate it, but that might be hard to compute
like, there's Positional:rw and Positional:ro, and Associative:rw and Associative:ro
give or take a notation or two
as soon as you allocate has Bool $.true it's a storage mechanism
or bit, or whatever it is
but we don't want $x but True to allocate a bit when it doesn't need to
precisely because Array === Positional:rw
okay, back up a step
I'm trying to look at all the typish things we've defined so far
and we've given different names to things that are really the same interface, but with rw characteristics
but the Bool discusion seems to indicate that we *haven't* done that with Bool
there's a BoolBit vs a BoolIF
we have no way of distinguishing those currently with a single name Bool
it's basic value semantics vs variable semantics
immutable vs mutable
why do we split some of the names but not others?
they don't do Bool:rw, but they do Bool:ro
we have a Range with is Range:ro, and a RangeIterator which is Range:rw
or maybe the other way around :)
I don't know, all I know is we're being very inconsistent
it's a good question
by analogy with the but True, I'd say
that 'but 42' adds an Int:ro role with a .Int method that returns the constant 42
or something like that
method Int () { return 42 }
but with Bool it's method .true, seemingly
well, .Bool and .true could just be the same thing.  It's true() and Bool() that are multis, and on a different level
I'd be okay with .Bool being fundamental, if it's more consistent
that would depend on how Num() is dispatched, I suppose
and what we consider the new type to be, since it's a mixin
as a runtime mixin, one could argue that the Intliness should override the Strliness
on the theory that it's the new anonymous type that does Int directly, but Str is ancestral
but it kinda plays havoc with our notion of pseudo-named equivalence
we know that $x does Int and we know it does Str
nothing is ever "the reason" for anything
there's always lots of reasons
PerlJam: yes, that's the question
it *does* both Int and Str
but it *is* still a Str, I think most people would expect
but how hidden?  $x ~~ Int
arguably, they're tied
and you have to say foo(+$x) or foo(~$x)
since we can argue it both ways, a failed tie is probably the correct answer
and then require + or ~
yes, which argues for .Bool (or .bool) being fundamental
why not just mix in a method
unless it's role Int:ro[42]
well, at the moment we're making a fundamental distinction between 'but True' vs 'but Bool'
well, this is all very simple in Ruby where everything is single inheritance and duck typing :)
it was to the world at large
the point is that ruby doesn't do anything like role-based multiple dispatch, or even MI
but in SI, the type is biased toward the derivative, not the parent
so I'm leary of biasing toward the parent
if it's an anonymous role then $x ~~ Int would return false, which also seems bogus
well, we do want some way to do that, even to making .Int = 43 work sometimes
I can imagine adding a $.Int that isn't rw
but we don't have syntax for it
unless you write the role yourself
I think add a .Int value and a .Int rw var are the two common desires
adding a .Int ro var seems like something nobody will want to do
having a ro var seems a bit perverse to me
when you're already forcing it from the outside
and nothing inside the old object knows how to change it anyway
so Int(42) vs 42 seems reasonable
or maybe Int{42} is more like what's going on
if WHENCE took positionals...
trew
okay, seems like we're achieving some kind of consensus, or at least mutual confusion
yes
and 'but Int' is short for 'but Int(Int)'
can't be, wolmers++ just joined  :)
go ahead and scribble
*wollmers++
sorry
wollmers: did you send those messages to p6l or just to me?
they haven't shown up there yet, is all
(haven't really had time to think about them yet)
likewise lunch, still about on Mountain Time biologically...
note that .perl returns the name without ()
or should
I dunno, there's always the French anthem...
$*IN.pick.say
well, there's only maybe six or seven college songs in the U.S., melodywise...
my highschool song was actually to the tune of Anchors Aweigh
but then, Bremerton is a navy town, so it made sense
masak: we have a phrase, "pick your poison"  :)
most anthems are pretty poisonous, in my experience :)
jnthn: I dunno, it's not like we can't huffmanize on the Shift key occasionally when there's no conflict with a native type...
eh?  but binds tighter than ,
it gets coerced back to an item in any case
special syntax, I think
yeah
or not
not entirely clear if .list and .List mean the same thing yet
might be a de jure vs de facto distinction there
like the difference between interpolation of @$foo vs $foo non-interpolation
context is not strictly OO in perl
contextual return is not a panacaea if it involves cloning a bunch of closures that will go unused
well, but (1,2,3) would give you a collision like (True,False)
maybe you should try Edelweiss instead and see if it works better...
I note, however that STD doesn't actually parse 'but' as a special form
but that's just a coercion of 42 to Foo
which is why I was thinking of using Foo{42} instead
yes, but how do you tell it was a coercion and set of rw?
vs a bare Foo literal, whatever that is...
how do we distinguish Int(42) from 42
not if it's not a special form
but Int{42} could be lazy coercion
well, that's a possibility, but there could be other uses for Int{42}
not to mention List{1,2,3}
no, just other places where a positional WHENCE makes some kind of sense
night
never happens to me.. ;)
well, something to think about, anyhoo
and simplifies the run-time decision to "is it defined yet"
if not defined, is rw, if is defined, is ro
is undefined, so adds SomeProtoObject slot with undef value, which happens to also have the type SumeProtoObject
for same speeling or other
but Foo turns into but Foo[Foo]
Foo{Foo} rather
if we end up with the WHENCE solution
Foo is already a role, so we just use it
ah, well, we take an immutable snapshot, is what I've said in the past
point is that $x is defined, so uses value override only
and value override doesn't affect the type of "hello"
well, all of these short names are presumably lexically aliased to the long name
its .perl should know it, I think
it's to avoid confusing data with metadata, basically
and it happens that if you eval "Int()", you end up with Int anyway
since empty coercion is defined to return the type object undefined
Nil coerced to Anything is Anything, I guess you might say
just postcircum
what's a protoobject?  :P
however, but MyInt{$x} is potentially a different matter
since it's a proto^Wtype object with a WHENCE
so we might do something more official with the type mixin
something more like MI
or like official composition
anyway, it may be one of those "doctor it hurts when I do this" sort of things, at least until we think of something more consistent
sure, but what's the identity of a mixin then?
would be simple if we weren't doing MI and multiple dispatch :)
yes, it's a valid and strong point, but I don't think any of us are smart enough to figure it out tonight. :)
do don't do that.  :)
*so even
gah, blow my own punchline...
junctional types, here we come...
unless someone has hidden it. :)
jnthn: you're tellin' me...
yes, well, if we solve it, we probably solve world hunger at the same time, not to mention global warming
we'll just have to evolve it as we go on, assuming we haven't boxed ourselves into a corner
and that depends on which people run into which pain points first, and loudest, I suppose
but changing the semantics of 'but Int(42)' to junctional or MI or whatever is a possible danger point
if it ignores the Int type initially and people depend on it
eventually, something more like a real mixin
where there's a new anon type that *does* Int but isa something else that does Str
question is how $x then dispatches to ambig Int vs Str
well, Int might be considered exact match because it's via does, while Str might be inexact since it's via isa
from the viewpoint of the new anon type
yes, it just mixed in the method without the role
well, with an anon role that isn't related to Int
so it *might* just fall out of what we're already doing
and the actual downstream tweaks are how we calculate type distance
which will be painful regardless
hmm, both Int and Str presumably supply a .Num coercion, which is ambiguous by composition, but with the extra isa of a mixin, isn't
any way I argue it, it seems to me that +("foo" but Int(42)) should probably call Int's .Num rather than Str's .Num
at that point it's just single dispatch
it's just the Any version that does it
but if the type is neither strictly Int nor Str, Any is what we get
and it delegates to .Num
that's nonstandard OO.
should call the most-derived
yes, which with a mixin will be Int rather than Str
so +$x will tend to produce 42.0
which I like a bit better than 0
but only if we say Int{42} rather than 42, by current reckoning
since the "but" is implying that the override is also the type, not just the value
but 42 could still just be .Int mixin without implying type
or we could say it mixes in the type as well as the value, I suppose
and just write an anonymous role explicitly if you want the other
but role { method Int () { 42 } } is not onorous
we could still mix in the type and ro interface without mixing in the storage
/e
they're there, but behind the front legs
you realize this means that Perl 6 can never be fully debugged...
Perl 6 will be beautiful, but not perfect. :)
it's buried down in http://perlcabal.org/syn/S32/IO.html, but mentioned elsewhere in the synopses
http://perlcabal.org/syn is the overview of the specs
they live in pugs/docs/Perl6/Spec, so if you have the repo, you can grep it
but this particular thing only changed a couple weeks ago, so is still non-obvious
don't need the @, it just confuses lambdabot
and also suppresses irssi hilighting, as it happens
the @ just marks channel ops
there's no failover from methods to functions, or vice versa
if that's what you're asking...
wrt prompt, generally there's only one sensible place to prompt anyway...
I suspect that's why there's only the function
my $input = prompt("name: ")
or print 'name: '; my $input = $*IN.get;
good night
zzz &amp;
it was not the original intent that a proto allow unmarked subs to default to multi rather than only
though that is more like what proto does on variables, I suppose
but that's the other way around, scopewise
or more to the point, timewise, causewise, something like that
the two roles are written before the class that integrates them
whereas the proto is written before, and the calls put later
before temporally, I mean
well, I probably decided that and forgot :)
one tends to slip back to one's original conceptions
btw, is there really a need to expose a Multi type?
there isn't one specced...
but there's a test for it
($x)|(), which is a multisig
std: sub foo ($x) | () {...}
I don't follow your other arg
doesn't hold how so?
why shouldn't any &amp;foo be able to hand back a list of candidates, where only subs have only one candidate?
wrapping turns a singuler into a plural in place
if wrapping is going to respond to callnext like other dispatchers
well, wrapped routines have their own subdispatcher in either case, I expect
since all the candidates present the same interface, presumably
masak: this seems like something that belongs in the definition of event handling, not the language itself, offhand
except, of course, to the extent that event handling *is* part of the language :)
but if you do that, then &amp;foo acquires more than one candidate
when you wrap
so a singular/plural unification seems in order there
&amp;foo is just a callable abstraction, and how it handles the call is probably best encapsulated
like any object, they're singular on the outside, but potentially plural inside
that's because you're implementing them, not calling them :)
I don't think &amp;foo should change its outside type just because someone implemented differently
&amp;foo is just the name of whatever foo does in the current namespace
Code, I think
let me think about it some more; maybe I can persuade myself not to care
jnthn: it just feels like a leaky abstraction if that matters to the user
yes
to go with lines()
to the implementor
I would think the Perl way would be to allow either, if you can name them
if I &amp;foo.wrap, it uses the current namespaces idea of &amp;foo
's
and then they can say &amp;SomeModule::foo:(Int,Str).wrap instead to be more specifi
why would they want to know that?
I would think they want to *not* know that most of the time
and when they do want to know it, they can introspect &amp;foo via some method
okay, here's the thing that bothers me.  I don't mind if &amp;foo does Multi, but the spec test is testing to see if it isa Multi, and I think that's over-orthogonalizing the space in a classish way
at the end of t//spec/S06-multi/syntax.t
I thought you'd be :)
that's why I mentioned it...
though I think the marked case should actually be Only, from an optmization point of view
well, even Only can become plural through wrapping
maybe the optimizer wants Inlineable instead. :)
well, I still see wrapping and multiple dispatch as basically the same thing
and the point of is inline is to disable wrapping, mostly
though there's something going on here like closing and finalizing classes, from a pessimization point of view
sure, just trying to make the possible common, to the extent possible :)
well, but making a hard type distinction is another form of entanglement, which is what I'm carping about
but we can let it go for now, if we s/isa/does
the whole point of formats was to keep the picture consistent on columns, so {&lt;} is 3 by that reckoning
wasn't a problem for p5 formats :)
since we had @ and @&lt; and @&gt;
if you want your columns to not line up, that's what sprintf is for :)
I don't think "is Scalar" means anything anymore
the idea was to evaluate each argument in scalar context
we'll have to think about how that notion fits into the world of Captures
it's possible this is simply binding to *@@ these days
but maybe not
probably not, or slices will break when you say @x[1, @data, 3]
I'm in two TZ at once :)
std: sub foo(*@data, $bar) { say $bar }; my @data = 1,2,3; foo(@data, 'OH HAI')
masak: see ^
rakudo is being overly accepting here
will likely be put off till STD runs on rakudo :)
rakudo: say Int.defined; say Int::.defined
should be 0 1 if :: gets to the package for Int
trying to figure out how to write tests like UNIT::OUTER:: === CORE:: and such
but I need to know how to get the identity of a lexical symbol table from a typename
yo
the mutable/immutable distinction is close to the mystery of time; we can only perceive the immutable scrollback, not the future mutable scrollforward
masak: I knew you were going to say that :P
std: my @a = &lt;foo bar baz&gt;; .=uc for @a; say @a.perl
I don't feel any great need to support that form...
already did that one above
'yes' xx *
[] is supposed to generate a new array
but X doesn't guarantee to re-eval
rakudo: my %x = map { $_, [], }, &lt;a b c d&gt;; %x&lt;a&gt; = 2;  %x.perl.say
rakudo: my %x = map { $_, [,], }, &lt;a b c d&gt;; %x&lt;a&gt; = 2;  %x.perl.say
rakudo: my %x = map { $_, [ ], }, &lt;a b c d&gt;; %x&lt;a&gt; = 2;  %x.perl.say
it should not be parsing that as a reduce
rakudo: my %x = map { $_, [()], }, &lt;a b c d&gt;; %x&lt;a&gt; = 2;  %x.perl.say
rakudo: my %x = map { $_, [ () ], }, &lt;a b c d&gt;; %x&lt;a&gt; = 2;  %x.perl.say
actually, it seems like something in .perl
rakudo: my %x = map { $_, [ () ], }, &lt;a b c d&gt;; %x&lt;a&gt; = 2;  %x.say
rakudo: my %x = map { $_, [], }, &lt;a b c d&gt;; %x&lt;a&gt; = 2;  %x.say
rakudo: say []
rakudo: say [[]]
rakudo: say [[]].perl
there you go
in both cases there's only one empty list
rakudo: say ().perl
rakudo: say Nil.perl
rakudo: map {42}, ()
rakudo: say map {42}, ()
say [~]()
rakudo say [~]()
rakudo: say [~]()
rakudo: say ().reduce(&amp;infix:&lt;~&gt;)
rakudo: say ().reduce(&amp;[~])
why use reduce when you can use recursive lambdas :)
well, there's always *named* lambdas...
or even my $x = { ... $x()... }
you're putting me to sleep ...
yeah, I should get me one of those some day...
meanwhile, it's off to Fry's &amp;
g'day @mates
that's confusing bytes with characters
well, I suppose not really
but matching &lt;[A..Z]&gt; could be matching EBCDIC underneath, as long as it preserves unicode semantics
but for now most any implementation is likely to simply transliterate EBCDIC into unicode chars internally
I need to make rules just a bit smarter about whitespace, so I don't have to write strange things like:
rule trait_verb:handles {&lt;sym&gt; &lt;noun&gt; }
whenever I use a syntactic category like trait_verb:, I never want the initial whitespace
I've only wanted to suppress the leading
but really only for rules that are used in alternations that want to do LTM
basically, any LTM alternation wants to pull &lt;.ws&gt; out front somehow
(but only if any of the alternatives need it)
it's almost certainly assigning to :a
remember std doesn't really do semantics
and whether something is a valid lvalue is semantics
std: 42 = 42 + 1
@tell masak no, p6 doesn't guarantee timely destruction, so you have to close a file explicitly if you want to know it's closed right now and not at the next GC run
currently defined, 'is leave {.close}', but nobody implements that yet, that I know of
the ideas was to say my $fh is leave {.close} = open $file;
*idea
but we haven't thought about it in a long time
some platforms may guarantee it, but programs that rely on it aren't going to be portable
maybe there's room for another declarator that destroys at leave time
kaboom
std: constant C'ish = 42;
I don't think C is underage
but C is closer to 42 than 21
I think C is even eligible to be president of the united states
to liberal to get elected, I suspect
*too
"I am not now, nor have I ever been, a member of the Lisp Party."
fg
grr
blurg
LadyLunacy: ich weiss nicht was sol es bedeutet
I don't know what it means
that's okay, brought back fond memories of studying German 35 years ago
well, closer to 40 now...
jnthn: re pick, see S32-setting-library/Containers.pod:215
get
or lines, if you want 'em all
rakudo: say +$*IN.lines
rakudo: say +$*IN.lines.reverse
rakudo: say +$*IN.lines.flip
o_O
rakudo: say (+$*IN.lines).flip
ruoso: lines is documentation, we can certainly provide owtdi
not in standard p6
it was too huffmanized, actually
we don't actually want to encourage people to process their iterators one element at a time if there's a way to do it as a list
lazy lists for lazy people :)
lichtkind: why would you think that R was forced?  it was just an obvious generalization of some specific things we were struggling with earlier
and thus chosen willingly
jnthn: S04:1122 discusses the semantics of LAST
grep is your friend
groceries &amp;
jdlugosz: welcome!
I believe jnthn is doing most of his rakudo devel on windows
many of us with flakey connections tend to use ssh to some more stable machine
then you can detach and reattach to the same session
prefix:&lt;=&gt; was deemed too ugly to teach to newbies, and dehuffmanized to .get
term:&lt;?&gt; would cause parsing ambiguity with prefix:&lt;?&gt;
yes, if you're client is set to utf-8
but we're trying to avoid things outside Latin-1 range for standard p6
it's fine if libraries bring those in though
"use Set" is likely to bring in set ops, for instance
oh we never joke here... ;)
have you seen the periodic table of the operators?
yes
there's a link to it from http://perl6-projects.org
correct
and intentionally named as a noun rather than a verb
so that people will think of the set of lines as something to work with
we're doing all sorts of subtle things to encourage list processing over scalar processing
.lines(42) works
so my ($a,$b,$c) = $*IN.lines(3)
yes
but lines() is lazy, so if you want to just throw the rest away, that's fine
yes, it's intended to refer to the whole collection
uh, it's up to the filehandle to keep state on that, I expect
so .lines(3) would give you the next three lines
but that's just a shortcut for get;get;get really
it modifies a mutable view of the collection
that would thrown all the rest away, I think
that could be made to work, possibly
except, of course, that $*IN in a list context doesn't do anything
that's all of 'em
but @list can do it lazily
if it decides .lines is potentially infinite
we don't enforce strict laziness
the implementation of an iterator is allowed to work ahead in batches
it's turtles down however far you like it to be :)
$*IN isn't the iterator; it contains the iterator
$foo is always one level of indirection from the "naked" object
not invisible in list context
so in fact, you can say @$*IN to get the same effect as .lines
but .lines is deemed to be good documentation
never was implicit, really
it was just = before
the latter is now illegal
std: @ $x
to catch when people say:
std: my ($a, $, @x) = 1,2,3
but leave out the my
std: ($a, $, @x) = 1,2,3
ooh, wrong message :)
but you get the idea
std: ($a, $ , @x) = 1,2,3
I'll have to de-emphasize the $, message
it wasn't
it was replaced with *
std: ($a, *, $c) = 1,2,3
errands, back in about .5 hour
&amp;
feel free to ask questions, I'll backlog
sjohnson: the answer to your earlier question is simply sub foo (%array, $int) {...}
you use signatures instead of all that fancy shifting
it's always too late for me
except when it's too early
but then you can simply call it foo(@x, 42)
no need for \@x anymore
rakudo: @a = 1..10; @a.=pick(*); say @a
rakudo: my @a = 1..10; @a.=pick(*); say @a
there's your mutator
@array
rakudo: sub foo (@array, $int) { say @array[$int] }; foo('a'..'z', 15)
Perl 6 is trying to turn all the other books into doorstops; Perl 5 isn't special that way :)
use #{.....}
or #(...) or #[....] etc
or #&lt;&lt;&lt;...&gt;&gt;&gt;
no
maybe your brother should program in Python
rakudo: say qx/uname -a/
yes, too unreadable
also, reserved for user-defined syntax
case (in)sensitivity?
space not allowed before that (, by the way
you
split( not split (
unless you want it parsed as a listop
solves the p5 problem with print (1+2)*3
IO specs still developing; ask wayland76
you keep saying that
that's p5
p6 doesn't, so you can write list comprehensions
huh?
it switches to pulling slurpy terms out of the positions when it's done binding mandatory and optional
there is no list context until slurpy-binding starts
the meaning of Nil is not precisely driven by item/list, I think
binding Nil to @y should still bind ()
Nil is really just (), and undef is only if forced to mean something non-arrayish
if it is at all possible to interpret Nil as as (), it does so
sjohnson: how many times do you need to be told before you believe it?
way to shuffle
more like "being used as a list/Positional" than list context, but yes
certainly a lot of the Any methods are in a similar state
you're using the invocant as a particular type, but this is implied by the method itself, as part of the langauge
item/list context are not the only kinds of context
but yes, basically, which is why a Positional interpretation of Nil should result in () even in "item" context
rakudo: say "foo".join
join is not a method of Str
nevertheless, we use it as a list
and it treats it as a list of 1 elem
you need .=
correct
the Any version of join makes it a language feature, not just an OO feature :)
yes, but it would be redundant to reinvent Smalltalk
I use vim, though I think its API beyond the vi bits are rather ad hoc
for some def or other
but usually in Mountain View, CA
* means the operator gets to pick a "globby" default answer
sjohnson: many of the uses of * actually indicate an indefinite/infinite number of elements
so 1..* is an infinite range
and "yes" xx * is an infinite number of "yes" list elements
but to other operations it can mean "all the elements" or "the number of elements"
no
I answered policy on that somewhere...
okay to incr for typos but not necessary
I have a pretty good notion how it sounds, if you pronounce it the olde way :)
the initial consonant cluster will, of course, stump most native English speakers
well, laterals are always a liitle of both
I prefer to unify with the other mutating assignment operators
and reserve ! for factorial :)
rakudo: sub postfix:&lt;!&gt; ($n) { [*] 1..$n }; say 5!
so I think the Ruby notation is a dead end
it's supposed to work the same as eval join but without the eval or the join
you can' t hang bare operators out there as terms
cmp is non associative
that would be a bug
utf-8 is pretty much a necessity on this channel
can't have a space before a postfix!!!
rakudo: say &lt;a b c&gt;&gt;&gt;.uc
rakudo: my $x = "uc"; say &lt;a b c&gt;&gt;&gt;."$x"
rakudo: my $x = "uc"; my @x = &lt;a b c&gt;; @a&gt;&gt;.="$x"; say @a
rakudo: my $x = "uc"; my @a = &lt;a b c&gt;; @a&gt;&gt;.="$x"; say @a
there's one reason to use .= instead of !
the ! would get lost after the quote
that changes the types
you really shouldn't be calling a method with such different semantics invisibly
it is much more extensible
most of the places where Ruby has "cute" syntax tend to interfere badly with extensibility
the spots where Perl 6 looks slightly klunkier are that way for a good reason, in general
nah, the bullets slow down too fast in water
not nearly as much as dynamite
my wife is sure that game exists already embedded in some other game
I'll never tell
pugs: my $x = do if 1 { 5 } else { 10 }; print $x
the () syntax is more recent
do you mean symbol to be a string?
%hash&lt;symbol&gt; if so
%hash{symbol} would always call the symbol function
there's no ${} anymore
or @{} %{}
since the .&lt;&gt; subscript is based on qw, it automatically gives you slices
%hash&lt;foo bar&gt; is %hash{'foo','bar'}
that only works if there's a foo method
to do which?
no, you never need the dot except on alphanumeric methods
on all other postfixes it's optional
%hash&lt;foo&gt;&lt;bar&gt; if they're strings
what method?
{'foo'} has to be quoted to be equivalent
yes
well, everything else is longer
%hash.postcircumfix:&lt;{ }&gt;('foo') or some such also works
why would that be overkill?
it makes the autoquoting very visible
well, a real &lt;foo&gt; as a qw would generally not be distinguishable from a 'foo'
so there's no point, unlike with subscripts
but you can't say %hash'foo'
the qw form is defined as equivalent to ('foo')
the subscript form is defined as equivalent to {'foo'}
all you have to remember is that rakuda is "camel" in Japanese
that's what I said
we might be able to support something like that someday
it kinda depends on whether we can make this thing called NFG work out
My eyes!  I should go to be for real
*bed
gotta get up in 6 hrs...
zzz &amp;
but really, there ought to be a link from "rot13" to caesar somewhere that can teach these folks
we're hoping to have a distribution model that bundles these things in ready-to-use packages
but it's not the job of "kernel" p6 to provide these distributions
one of these distributions should be "what any ISP should install"
certainly, we want eventually to have organizations supporting distributions like RedHat, Ubuntu do for linux
or Microsoft does for Windows :)
for some value of "supporting"...
yes, that's been the plan for years
it scales better than the p5 model
perhaps CPAN6 should be viewed as a "distribution" in this sense
or a bunch of distributions
but certainly the current CPAN model has its limitations
yes, but one group supplies gcc, while another supplies glib
it's only novel to navel gazers :)
well, arguably cygwin kinda works that way
unitxt: ditto
that wasn't an I
as soon as you move into Latin-1, POSIX is not your friend
anything that is a shell meta tends to be a problem
well, just inside {}
and I use , for a history char, but that's idiosyncratic
you have to shift !, but not ,
so it's easier :)
limiting the module names to ASCII is p6-user-hostile
we need to drag unix systems kicking and screaming into the 21st century
screw the shell :)
interfaces that don't support Unicode properly should be made to suffer :)
the loss *won't* be in limiting Perl 6 module names to some least-common-denominator, if I can help it
at least from the viewpoint within P6
I don't think any of those characters are particularly simplified...
much though it gives them heartburn
same in Japan
but it was gratifying to be able to read most of the Japanese signs, nonetheless
troo
some of that was the olympics
yeah, well, gnome-term isn't exactly using pango...
but does ChatZilla run under screen? :)
yeah, right
that runs slow even here on my lan
ah well, google will just turn it all into a wave
as long as they're not libelous
or violate community standards of decency...
wait, I could use some donations...
tis an idea
do they do mugs too?
filling corporate america with a million camelia mugs would be my idea of a cultural hack :)
yes, and corpulent Europe too
maybe even Antarctica, if you can find any corpuscular entities there
funny how the continental congress was not on the same continent as most continentals
they can change anything a BEGIN block can change, but they can't add variables to a completed lexical scope
there's really no such thing as a public instance variable in p6
it's an illusion
the only real instance variable is $!name, and that is of course private
$.name is the name of a rw accessor
so you can use the accessor as if it were a variable
we don't separate getter from setter at that level
and accessor establishes *identity*, not lvalue vs rvalue
reach "it" means two different things here
$!name reaches a concrete storage location
$.name reaches an abstract storage location that a derived class could override
my answer was to you
package variables aren't lexical, so what I said doesn't apply
rindolf: at least in Perl 6, we could name it G-d  :)
well, more people expect the spanish inquisition than the japanese inquisition...
rindolf: nope, I show my reverence in (hopefully) more productive ways, like being a creator created in God's image
lichtkind: yes
one whose block has finished parsing the closing }, or equiv
this tends to be more of an issue for eval than for macros though
lichtkind: no, that wouldn't work at all, a macro must either return a string or an AST
so you could say macro a4 { '$a = 4' } though that wouldn't be hygienic
or you could say macro a4 { quasi:COMPILING { $a = 4 } } and that would be hygienic
yes
in either case
but setting outer vars like that is not good practice
usually it's better to use state vars if you can
note that by default a4 would likely parse as a listop
you can force it differently with macro term:&lt;a4&gt; and such
or with "is parsed"
not that anyone really implements that yet
pochi: you should rakudobug that
pugs: say :2&lt;1.1&gt;
pugs: say +":2&lt;1.1&gt;"
pugs has the opposite problem :)
throw in a few rands, and one of them will probabl give the right answer eventually
use MONKEY_TYPING
that's funnier than MONKEY_PATCHING, so we should change it
and it's supposed to be a joke on DUCK_TYPING anyway
but then how does + do it?
rakudo: say e() - pi
there's your bug
e is a sub, not a value
not suposed to look for arguments
rakudo: say pi()
that should fail, really
say 3.14()
rakudo: say 3.14()
rakudo: say e(pi)
rakudo: say e(-pi)
say e("what is the signature of e?")
rakudo: say e("what is the signature of e?")
still, pi should parse as a listop even if it's a sub ()
perl 6 doesn't play parsing tricks on normal subs like perl 5 does
sub foo ($) isn't a unary prefix like it is in p5
anyway, pi and e should be parsing as terms, not function calls
or you want a P5hash to share with P5
or a PyDict, or whatever
or a Cstruct
we're trying to avoid the P5 difficulty of having to translate objects back and forth
yes, but if you're going to delegate to another object that's identical in the abstract, why not just *be* that object?
as long as the accessors all work as expected from the outside
me too, which is why p6 is different :)
masak: there are a couple of bugs noted about an hour ago, if you're in bug submission withdrawal
rakudo: say :2&lt;1.1&gt;
rakudo: say pi("wtf")
rakudo: say e("twf")
that one
yes, vs
rakudo: say +":2&lt;1.1&gt;"
which is correct
neither pi nor e should really be looking for arguments
both, really
but e seems to have a sig of ($) or some such
rakudo: say e(1,2)
actually, probably no sig
so *@_, but that's wrong too
rakudo: say e - pi
thanks
yes
they need to parse as a simple term, like type names
only they happen to be defined
yes, brainrot carried over from p5 :)
rakudo: say True - True
they should work like enums too
rakudo: say True()
good
so basically pi is a singleton enum
rakudo: constant Foo = 3; Foo = 4; say Foo
anyway, these are all implemented differently, and they should tend to converge
all named constant values should pretty much work the same
not since we got into Aquarius
"No applicable methods" could be a lot more forthcoming in what it thought it was doing and why it failed
slurpy!?!
so maybe you should just register pi the way you register True
rakudo: say +1i
rakudo: say Num(1i)
well, but if + is coercing to Num, how does it make a complex?
some people are never happy unless they have something to be unhappy about
sbp: that's what 'use *' is for
1\00
something cheating on the bytes
types, who needs 'em...
no, not heathen, just infidel
you shouldn't parrot Parrot
looks like it should be docs/Pugs/01Overview.html
that's not how macros work
nothing ever substitutes the macro body
a macro returns only a string or an AST
a string is inlined (in its own scope) and reparsed
if you have { 3+4 } it would be stringified to '3+4' and reparsed
an AST is just inserted
run time doesn't change this, but assumes a sub {} around the AST (which, for a string return, would have to be compiled)
there are only two possibilities, AST and everything else
and everything else is assumed to be stringified
has nothing to do with whether a string is returned, but what the supplied rule is expected to parse
the first one has %h in list context, so it flattens
now {%h} is a closure
rakudo: my %h=&lt;a b c&gt; Z 1,2,3; my %x=&lt;p q r&gt; Z (item(%h), {}, {}); %x.perl.say
rakudo: my %h=&lt;a b c&gt; Z 1,2,3; my %x=&lt;p q r&gt; Z (\%h, {}, {}); %x.perl.say
hmm, I guess the inside of item() is also a list
that looks right to me
the hash returned by hash() is in list context, so flattens for Z
so I believe that's correct according to current semantics
try \hash
rakudo: my %x=&lt;a b c&gt; Z $(hash(&lt;q w r&gt; Z (9,8,7))) ,{},{}; %x.perl.say
hmm, looks like inside of $() is list context too
I guess the \ isn't entirely useless yet
rakudo: my $h = hash(&lt;q w r&gt; Z (9,8,7)); my %x=&lt;a b c&gt; Z $h ,{},{}; %x.perl.say
rakudo: my $h := hash(&lt;q w r&gt; Z (9,8,7)); my %x=&lt;a b c&gt; Z $h ,{},{}; %x.perl.say
I don't like that $h interpolates the hash there
multicore
darn, you beat me to it
I had to go looking :)
you're twice the man you thought you were...
would be really funny if the second one said FakeIntel
don't think you'd have got all of 174% with hyperthreading
hyperthreading isn't normally a huge win
oh, hyperthreading is genuine Intel, all right...
it's just fake threading :)
rakudo: @a = do for 1..3 { .Str }; @a.say;
rakudo: my @a = do for 1..3 { .Str }; @a.say;
rakudo: my @a = map { .Str }, 1..3; @a.say;
o_O
yes, I think so
or at least doing the same thing...
rakudo: my @a = map -&gt; $_ { .Str }, 1..3; @a.say;
rakudo: my @a = map &lt;-&gt; $_ { .Str }, 1..3; @a.say;
not that
rakudo: my @a = map { $^a.Str }, 1..3; @a.say;
rakudo: my @a = map { my $x = $_+0; $x.Str }, 1..3; @a.say;
rakudo: my @a = map { my $x = $_+0; $x }, 1..3; @a.say;
obviously a problem in .Str
yep
parrot confusion between typenames and strings, perhaps?
should probably just carp about no Str method
I suspect the conversion done by print/say is even lower than Str
and that's where an object without a Str method would Dog()ify
that's where junctions also stringify, I think
since $junction.Str should autothread
so Object::Str is really pretty bogus
I think print/say call last_ditch_stringify() or some such :)
please do :) * .1
hmm "last ditch" is seemingly a WW1 metaphor...
nope, was apparently coined in 1715
but was indeed about battlements
you can never have too many
the ditch pitch
ruoso: why use split instead of comb?
or .words
since .comb defaults to chars now
JPL discovers all sorts of unidentified flying objects
and then gives them names
ruoso: I can't be answerable for a stupid spec :)
well, I could tell you, but then they'd turn off my brain implant
conspiracy nuts continually insult the integrity of the vast majority of scientists; I include young earth creationists in this category
it does not please me
someone merely fishing to feed their confirmation bias is not a challenge, but a pain in the butt
now all you have to do is classify everyone who disagrees with you as having heavy preconceptions, and then it's easier to ignore your own.  :)
mix in Code with Whatever, perhaps
or have a Whatever with an arithy
*arity
if it returned something that was also Whatever, it could rewrap
bare * has arity 0, if it has an arity
maybe not *
but * + 1 could be a mixin
or some predefined type that is both Code and Whatever
good enough for now
still have to keep it distinct typewise, or .[*] can't turn into a range
yes, it's a bit like our Int vs Int:D vs Int:U
sometimes you want the subset, and sometimes you don't
in any case, we probably want to distinguish by type and not just by arity
something MMD can get fast on
since it should just return a list object of some sort that .say can handle
look at it this way, if you go in and fix the code, you'll be even more insane, which makes the JAPH more insane too
it's after work hours
for lines() {...} is supposed to do that
or for (lines) {...}
unfortunately you can't say for lines {...}
std: for lines {...}
std: for lines {...}; 42
supposed to, so if you know @ARGS is empty, then you can use lines() instead of $*IN.lines
rakudo: say False.WHAT.Str
say False.int
rakudo say False.int
rakudo: say False.int
geh
rakudo: say False.int ~~ 0
rakudo: say False.Str
that's wrong
rakudo say ~False
rakudo: say ~False
that's better, but they ought to be the same
rakudo: say False.name
unimpl, i guess
viklund++
biab &amp;
S02 mentions Bool
well, see src/perl6/CORE.pmc for the names that STD knows
line 977
sorry, CORE.pad
rakudo: say **.WHAT
it's not (yet) generated, though presumably reflects (part of) what a compiler would spit out
I don't think rakudo knows about the ** term yet
rakudo: say WHAT(**)
no, it doesn't
std: **2
it shouldn't
well, ruby's not the only language where that's true
but perhaps ruby put on a bit more pressure than the other languages
yes
why only one? :)
can you think of anything else?
twigils, kinda
ruby uses sigils for what p6 uses twigils for
to indicate weird scoping
but the problem with using sigils for that is you quickly run out of keys on the keyboard
and @@
another one, the *idea* of marking mutators, but not the specific syntax
and if it starts with i,j,k,l...
I remember being astounded the first time I looked at a Fortran program, and saw:
i=x
x=i
nope
yes, unless you changed your IMPLICIT declaration  :/
think of what fortran means
Formula Translator
mathematicians know that i is an integer :)
lichtkind: mncharity is one of my "hares"; blaze of speed for several days, then a several week snooze till the next sprint.
that woudl be a torty
*would
sjohnson: not really, wasn't raised playing cards much
there's a single mention of Proxy in S06
don't have flash
that's what grep is for :)
or ack
buubot: spack Proxy
er, wrong bot
phenny: spack Proxy
oh, I killed it
ack is a recursive grep
if you have a pubs repo, it's just in docs/Perl6/Spec
I just leave a window parked there, so I don't have to remember
doesn't help with the grep though...
sjohnson: mostly I try to have a glass of wine every day because my family history of heart disease
also have to be careful with beer, since some of it is wheat based, and I'm allergic to wheat
(nice thing about German beer is that it must be labelled as wheat beer if it is.)
but around here you have to be careful
I've had enough of them to know that there's a difference between a good amount of hops and too many :)
no, too bitter
I like the bitter to balance with the rest of the flavor, not dominate it
araujo: if I do, I review the next morning before sending it off :)
there are parts of the world where you'd better expect to get acquainted with the local microfauna before you can appreciate the local water... :)
people don't value cheap software much either :)
it removes a discontinuity, and a source of bugs
and it falls out of the meaning of * naturally
:by is not yet implemented in rakudo, I think
I don't think rakudo's parser knows what to do with :by
STD parses it, however
std: for 1..5 :by(2) -&gt; $i { say $i }
though eventually you'll probably just say
std: for 1,3,5...* -&gt; $i { say $i }
if you want the whole series
that relies on laziness, which parrot does not yet provide
std: for 1,2,3, { say $_ }
rakudo: say 'Yes'if .flip eq$_ for $*IN.get
{} has its own $/ maybe?
azawawi: rakudo hasn't been worrying about error messages much because the plan is to eventually run STD directly
you want eqv for deep comparison
rakudo: say 'value identity is same' if [1,2,3] eqv [1,2,3]
rakudo: say 'value identity is same' if 42 eqv 42
nyi I guess
errands &amp;
rakudo: 1,2,...&amp;[+]
rakudo: 1,2,...&amp;infix:&lt;+&gt;
rakudo: 1,2...&amp;infix:&lt;+&gt;
rakudo: say 1,2...&amp;infix:&lt;+&gt;
rakudo: say 1,2...{ (state $i)++ &lt; 100 ?? $^a + $^b !! () }
lisppaste3?
lisppaste3: uri?
http://irclog.perlgeek.de/perl6/2009-06-26#i_1268441
have the appropriate amount of fun...
std: 72
I didn't quite get to the point of teaching use how to pull the .pm's .yml back in, however
that's for tomorrow's airplane ride, I guess, and then I can kick Test and DEBUG out of CORE.setting
it has it's ups and downs
it's not done yet :P
KyleHa: a capture containing a single item will behave as that single item in scalar context
std: 72
they're kinda described all over the place
I recommend a recursive grep of the Spec dir
well, I'm only going to get 4 hrs of sleep now, so I'd better try to zzz off
stupid how you have to get up early to fly west to a later time zone...
std: 72
std: Num::pi
std: pi
strange that it exports pi and not Num::pi
oh well, something else for tomorrow
zzz &amp; # thunk
hmm, I'm thinking constant wants to be "our" rather than "my", actually
otherwise, after class Num { constant pi is export = 3; }, you can get to pi but can't get to Num::pi
std: Num::pi
std: pi
std: Num::pi
std: Num::pi
std: Num::pi
hmm, need to force recompile of setting before that'll work
well, they're boarding, so I'll have to shut down soon
bbl &amp;
strange day when I write for the chatterbox before I even backlog #perl6 :)
s/write/write spec/
that's more or less what the importer in Cursor does, with an attached symbol GLOBALish that has the module'd idea of GLOBAL
's
exports come from MY::EXPORT::DEFAULT and such
so I think it should work
phone
in Cursor I don't get the top symbol from GLOBAL:: at all, I get it from the lexical scope's alias of whatever the module name is, so 'my module Sense' works okay (at least for that purpose)
and certainly CORE.setting starts out as 'my module CORE'
I
I'm sure that what S11 has will need some fine tuning, yes
feel free to tweak it closer to what you think the primitives are
presumably
unless :ALL really means :DEFAULT :NONDEFAULT
or "just check the symbol itself to see if it's marked 'export'"
which is how Cursor currently implements it
I don't really do :ALL yet though
dunno, in Cursor the package is curently complete passive, so STD's model is a bit suspect that way as well
*currently
but that's partly because everything is passive in STD so far
everything STD does so far is without any BEGINish semantics
so things like enums and import lists are just faked
seems fair to provide that chance, especially if we want to have policy modules
roger
hmm, seems to have change from functional to procedural :)
*changed
I will glare at it a while and see how it works out in Cursor, then we'll refine it s'more
but for now, shower &amp;
except I didn't name them sigils.  I think it was MJD that came up with that.
I called them "funny characters"
funny strange
'course, strange things make me laugh, but that's neither here nor there
so is Victoria Winters
ruoso: re S11, it's probably going to take me the rest of the day to figure out how it really works
but there are certainly problems with the present formulation
it's not well-typed
the current Cursor approach abandons the $name ~ '::' hack
it should be more multi-dispatched, probably
and it ignores the distinction between shortnames and longnames
among other things :)
in STD/Cursor, types are always just barewords in the symbol table, pointing to a stab object which contains a stash
and the :: postfix will essentially just call .stash on the type object to get the hash
bbl &amp;
S06-signature, I'd guess
since implicit @_ is really a (*@_) sig in disguise
bloat away
rakudo: :()
rakudo: :$a
rakudo: :$_
std: use Test; ok
I don't know what you mean by "treats"
yes, but why would this be a problem?
pmichaud: perhaps, after verifying that we have an opener of some sort, we just parse a term there to pick up circumfix: and quote:
or we go as far as to reclassify &lt;&gt;-style quotes as circumfixes, and just call &lt;circumfix&gt;, maybe
pmichaud: note that 'is foo[]' is also affected, since that :foo[] in disguise
*that's
I feel conflicted
with s/post// we do lose &lt;a b c&gt; as a type contraint, oh well :)
syntactically, any "value", and quotes are values, so you should be glad &lt;&gt; are going to be circumfixes now
which are not very value-ish
I'm trying to think of the name of the type that is more general than Capture :)
(1,@a,:b).elems == 3
yes, I've had various names for the syntactic list type
in Perl 4 Camel it was called LIST
but that's confusing
I've been hashing over names with Gloria
linguistically, it's a Series, but that's a word that doesn't have a good plural
and most other terms are badly overloaded.
yes, that's one of my options
and basically a Seq mutates into a Capture when used as an arglist
it's one of the 3 big design issues I've been working on :)
well, when the compiler notices an arglist, it wants to pull out nameds at compile time
so that type has some name, at least internally
we could finesse it, yes, but then it wouldn't be a Seq anymore :)
I'm not terribly excited about Series though
I've called them variously Group, OO, XX, SX...
even though about renaming Object as O at one point, but decided that would be too confusing with 0
though O would be a great name for "undef" :)
yeah, except we've still rather overloaded the meaning of "list context" there
does it, or does it not, include the nameds?
that's coercion to capture
coercion to flat list might do the other thing
but it doesn't quite fly that way either
but yes, fundamentally there's a raw syntactic list floating around that represents a sequence of objects
and the meaning of that is more contextual even than captures
and that's what parens create
at least the distinction is maintained until the Series is resolved
into capture or not
maybe they're Raw and Cooked :)
sunny-side up or scrambled
maybe you'd better go on your errand :)
argh, I actually thought of that one yesterday
Obviously we should name tham Jacquards then  :)
pmichaud: at the moment I'm thinking "Parcel", for paren cell, or some misspelling like Parsel, for paren selection, or parse list, or parse morsel, or some such
anyway, something that is an item that you don't know what's inside till you unwrap it
for sure, if it's a bomb
I think people will think of a different kind of catbox
the kind with litter in it
that's what it is after it's bound :)
#perl6 is the land of seeing accurately, and sometimes that makes one feel like crap
do autoquoting with &lt;parrot&gt; instead of {parrot} in p6
well, that's an odd way to say it
by default, hash keys still are strings
but the autoquoting rules are revised
you still get autoquoting on =&gt;, as in parrot =&gt; 'miago'
but not inside {}
we use separate syntax for string keys now %pet_list&lt;parrot&gt;
&lt;stuff&gt; splits on whitespace too
&lt;&lt;stuff&gt;&gt; also allows shell-style quoting and interpolation
yes, to the first approximation
but &lt;&lt; foo "bar baz" "$x" &gt;&gt; will certain have exactly three elements
regardless of how many words are in $x
well, that would work
but often people use autoincrement
which is $value++
all of which work as in C
rakudo: my $value = 0; say ++$value
showoff :)
which ends up with 'miagp' :)
or do you want miago to have a number that  you increment?
%pet_list&lt;parrot&gt;&lt;miago&gt;++
it means that's the current value of %list&lt;parrot&gt;
as seen by the 'say' command
it's possible it pays attention to PERL6LIB
if it works :)
what are you imagining when you say "pull out"?
the whole point of associative arrays is to avoid dealing with all the elements
rakudo: my %votes; my $pet = 'parrot'; %votes{$pet}++; %votes{$pet}++; say %votes.perl
rakudo: my %votes; my $pet = 'parrot'; %votes{$pet}++; %votes{$pet}++; say %votes.perl
hmm, probably recompiling
but yes, any time you find yourself iterating over the keys of a hash to find a particular entry, you're misusing hashes
it would be like looking at all the indexes of an array to see which one is 5 when you already know you want @array[5] directly
it changest the value corresponding to the key
*changes
it doesn't change the key, which is still 'dog'
that is how we prefer to say it
rakudo: my %votes; my $pet = 'parrot'; %votes{$pet}++; %votes{$pet}++; say %votes.perl
which won't work at all
because &lt;&gt; *quotes*
use {} for normal subscripting with a variable
but I don't understand why you're trying to subscript using $value anyway
what do you think it refers to?
and why are you using a value as a key?
you need to think about these things clearly; you can't just type random code and hope it works
the value is the destination, it's not the path to the destination
all you have to do to find the destination is talk about the path to the destination
the value will automatically be there at the end of the path
so %votes{$pet} is all you need to get to the number of votes for that particular key
rakudo: my %votes; for &lt;parrot dog fish dog cat dog parrot&gt; -&gt; $pet { %votes{$pet}++; }; say %votes.perl
rakudo: my %votes; for &lt;parrot dog fish dog cat dog parrot&gt; -&gt; $pet { %votes{$pet}++; }; say %votes&lt;dog&gt;
rakudo: my %votes; for &lt;parrot dog fish dog cat dog parrot&gt; -&gt; $pet { %votes{$pet}++; }; say %votes{'dog'} # same thing
have the appropriate amount of fun :)
howdy
sorry, had to go out and watch the ISS fly over :)
STASH is the object representing a symbol table
either lexical or package
davef: no, there isn't
I think it's a sign of overreliance on exceptions as an API control mechanism
we're trying to go the other direction, and make exceptions *more* exceptional
because they mess up implicit threading badly
you can't hyperize an operator that randomly throws exceptions on one of its elements
it blows all the other parallel calculations out of the water unnecessarily
so we're moving more toward inband failure propagation via "unthrown" exceptions
but those should not generally be used as normal values either in a good API, especially to indicate "no more data"
&lt;/end_of_diatribe&gt;
well, this was one of the reasons the Javafolk didn't want to add an instruction that could call a method they didn't know the name of in advance
dynamic languages are so, well, dynamic...
there's also a lot to be said for not reinventing an existing language :)
which is why we at least insist that the candidate list for multiple dispatch is static
STD is pretty much only checking syntax, not semantics, so it could also be a semantic error that rakudo is just giving a dumb message for
but currently the best bet is usually a rakudobug or parrotbug :)
I don't particularaly like that name anyway
especially now that we have buf types that aren't related
likely to turn into Stat, or some such
but that seems like it could interfere with statistics
Fstat is too specific, maybe Rstat
resource
or maybe we should unify with IO more that way ingy originally used IO
er, oops
I guess the fundamental question is how lazy IO('filename') is
and how hard to we work to prevent race conditions
*do
o/
I've got some DP in my outdoor fridge...
funny how I think of the garage as outdoors
well, out one door, anyway
I think I'm just gonna delete Statbuf and hope the IO role is sufficient for now
pmurias: lately I've been hating :Trig
so I'd be happy if it made a noise like a hoop and rolled away
so there!
you have to put ; after the {}
if it's on the same line
std: class A {} class B { has %.foo{A} }
std: class A {}; class B { has %.foo{A} }
(I don't think rakudo supports [] or {} on declarations yet, though)
perl6: say ~[\*] 1..10
n
like .repr in python, except we think there's more than one possible representation :)
it is not guaranteed :)
or we'd have to write test cases for python, ruby, lisp, bf, tcl, etc.  :)
why do you need the indirection?
why did the module need the indirection?
short answer is using Captures
which S08 will theoretically be about
but basically you're talking about a list of one element, one way or another
some container that happens to hold only one element
you can do it with a Capture, but it's different from P5 in that it automatically derefs it for you
the most general container may end up being something called a Parcel though
hasn't hit the spec yet though
and, of course, you can always define an object that contains a single attribute
you can blame the persistence of Juerd++ for &lt;-&gt;
in case there are two arrays
std: @a &gt;&gt;* 2
yeah, parsed it as @a &gt; &gt;
std: @a &gt;&gt; 42
hmm
std: @a &gt;&gt;42
curious
std: @a &gt;&gt;|| 42
something like that
but it ought to have reset the high-water mark somewhere
there are still times when it really ought to just say "I'm really confused here"
greetin's
not currently
at the moment you'd declare your variables with 'int' type to do something similar
a little harder, but less likely to get you into accidental trouble
the second is wrong
Wiley Codey
not yet
finanalyst: traits mix in methods to an object at compile time, so once the variable is declared, it's introspection is like the introspection of any other object, and "I came from a trait" is not known.
*its
rakudo: my @x is readonly; say @x.readonly
std: asdf
zzz &amp;
consecutively
you can tell it to operate in parallel however, if the 'for' is in hyper context
my @result = hyper for &lt; 1 2 3 &gt; -&gt; $number { do_something($number) }
that tells the for it can run them in parallel
currently specced, but I'm sure not implemented
is do_something not idempotent?
should be doing them sequentially
possibly a scoping problem?
so you're starting over somehow?
how does the second iteration learn of the first iteration's results?
what is your board stored in?
declared where and how?
how is the board declared, in in what scope?
which declarator are you using?
you might print out .WHICH on the two iterations to see if you're really modifying the same object
with 'has', I presume
if you're sure you're dealing with the same Board each time through, then the problem would be on the setting and sticking end, I suppose
I doubt that rakudo would be trying to do any concurrency
asciiville: a class name has to be predeclared before you can use it, but you can put class Foo {...} with the ... stub
that would serve as a forward declaration
alternately, you can say ::Foo for a not-yet-defined ref
(though not in a declarative context, alas)
we should probably separate those concepts...
but currently, if you need sub foo (::Foo $bar) you have to use class Foo {...} instead
since the ::Foo would mean to capture the type of the $bar parameter en passant
rakudo probably needs "is also" on the real definition to suppress warnings
and "is also" will change to "augment" in rakudo someday
but you shouldn't need either if the original was a stub
== is numeric
jaldhar++ for making progress
@karma jaldhar
jaldhar++ for having the courage to ask questions too
@karma jaldhar
the == ought to have been giving you warnings, I think
but perhaps not, depending on if we think '' is a valid representation of 0
maybe it's something the compiler could notice
ENOKLOO # not a PIR expert
ah yes, one of the many SWA "hubs" :)
always fun landing over the hill in SD
oh, were you in the new terminal B?
peddle hard
as a statement separator, it's a very good spot to figure out that someone didn't terminate their regex properly
and it was already an "unrecognized metacharacter"
this just let's us give a more useful message in the case that they actually did leave off the terminator
*lets
I can probably give a better message for /;/ though
I take it the ${$var} is done by something else, because it's certainly no legal Perl 6
*not
and to switch to a syntax where you could add modifiers easily
such as to determine what will or will not interpolate
that's already handled by default in p6
since @example won't interpolate without a [] afte rit
after it
it's really the sum total of lots of little killer features that adds up
it's becoming more of a priority as time goes on
but hasn't been till now
you'll have to be very careful then, because hacking on this stuff is highly addictive
you could use the webpage apparatus that was built for pugs
see the smoke target in pugs/Makefile
assuming you have the pugs repo handy
that's also where we store all the spec tests
so if you want to whack on those, a commit bit is very easy to acquire
all the specs are in the pugs repo as well
if you want a pugs commit bit, we can get you one in about a minute
oh, where's your sense of adventure :P
oops
as far as I know, I don't have an invite yet
you already have it
std: :$^bar
std: :$*bar
unless you declare ($self:)
hoelzro: do you have a pugs commit bit?
do you still have a repo image?
I can resend the commit bit if you've forgotten your password
looks like KyleHa++ tweaked it some
do svn up and you'll find out :)
rehi
wayland76: it's difficult to have answers at 3:40am mental time, even if the sun is shining here
we're still trying to fugure that out
*figure
we thought we might do that too at some point, bu tmay be no ttoday
we want to do a bit of sightseeing, but when we do that depends on when peopel decide to hackathon on what
*people even
and we did see the earlier version of Gabor's tutorial
one of the reasons prefix:&lt;=&gt; went away :)
we were thinking of walking up there soon
masak: did you say you were at the alif?
yeah, prolly doesn't make sense
we're next to the bullfighting ring in Campo Pequeno
er, yeah :)
nothing other than http://yapceurope2009.org/ye2009/wiki?node=VenueLocation that I can see
once you're in the right building you can just shout
.uc.say
this notion of Any methods is kind of a way to define part of Perl the Language
nice thing about Any methods/multis is they're automatically just defaults, found only if something more specifc doesn't apply
people were discussing the 1s yesterday
the first arg to a .HOW should be a dup of the normal object
3.^methods turns into 3.HOW.methods(3) or some such
if people will get frustrated by it not being there, why not?
"Any" verbs are just bits of the language that we havent' baked in as keywords
I think well just need to take it on a case-by-case basis, but most of the common IO ones seem like a set
and warn does IO :)
then we *maybe* put it into Any :P
to jet-lagged to do make any real decisions...
it can be both
IO &lt;: Any
Liskov isn't designing Perl 6 :)
it's in the other order
well, we're heading out now to do some walking and sightseeing
masak: we'll be poking around a little south of you
bbl &amp;
hey, charlotte airport has free wifi
well, better go find our gate...
bbl &amp;
evalfile
rakudo is still working out the kinks in their lexicals
wayland76: I really dislike IO::FSNode as a name.  Is there any reason it the notion can't be combined with IO
ah, so I see.
I just have an irrational hatred for names containing the (usually) meaningless word Node
and I think IO::FSNode is popping out all over, and ought to huffmanize to IO
"Beware the Turing Tarpit, where everything is possible, and nothing is easy."
thought I suspect that is referring more to oversimplified designs than to overcomplexified
yes, but that almost certainly means you should be parsing the string left-to-right instead :)
anything with an implied .*? isn't really parsing, in my book
but you can get away with it if there are no other escapes
as soon as you introduce, say, quotes, you're hosed
gotta run
afk &amp;
that probably fits into my definition of parsing then
masak's looks like an infinite regress to me
generally a new method should call bless
if you want to do that really, then use nextwith()
std: if 0 but true { say ^a }
std: if 0 but True { say ^a }
known bug, I believe
rakudo: 0 but Bool::True
but true is a listop
which is why it ate the block in std
decommuting &amp;
@karma indirection)
shouldn't it have a karma of undef?
stress timing vs syllable timing sometimes gives people trouble
the funny thing is, stress timers think syllable timers are talking impossibly fast, and syllable timers think stress timers are talking impossibly fast :)
Spanish sounds fast to English speakers because Spanish is syllable timed, while English sounds fast to Spanish speakers because English is stress timed
Japanese and Korean are more like Spanish in that regard
where are the types defined?  they blew up std, needless to say :)
is perl5 still changing?
ooh, shot yourself in the back with tab completion :)
that's called the waterfall model, and we don't
the problem with the waterfall model is that you have to be smart, and none of us are that smart
so we merely attempt to converge
you can know when it's good enough, however
in that sense, perl 5 hasn't "ended" either, hence my original question
jaffa8: we're pretty happy with what we have now, so it's mostly just tweaks
I know a nice scripting language that works on Windows too
was thinking teco, actually
but the standard language is never going to allow two terms in a row
those aren't terms, by definition :)
it's an ancient programmable text editor
Text Editor and COrrector
though what the difference is, I'm not sure
someone wrote a fortran compiler in it once
wow, whitespace
you must have a lot of memory
people used to type in their names to see what teco would do
depends on your name
mine wasn't very interesting
I think it moved left one character and then appended rry or some such
but I could be misremembering
that was ancient history
yes, it was much better than what it replaced
but I haven't used it for real since before most of you were born
the original emacs was based on teco rather than lisp
I never used that emacs, though
dunno
didn't come up that route
I only ever used bare teco on a PDP-11 running RSTS/E
back in the dark ages where if you really wanted to see what your program looked like, you had to print it out on the line printer
well, except for the BASIC interpreter, which could list your program on the screen
really high tech stuff
not in the least
I'm missing the future, not the past...
that didn't look like a sledgehammer to me
I believe my current editor is Andy Oram.  :)
Su-Shee: I prefer Uncharted Territory by Connie Willis :)
so we're giving jnthn a ticket for speeding
and maybe for texting while driving
jnthn: you should know there's no fine; we're still in the intermezzo.
std: if ( $filenamelist ~~ /,/ ) {}
std: if $filenamelist ~~ /','/ {}
picky, picky
the standard parser
you may use \ if you like
std: my $filenamelist; if ( $filenamelist ~~ /\,/ ) {}
nothing is wrong with it, assuming you're asking about syntax
but most folks here think ',' is more readable
however, it would be wrong if you left out the space before the paren
jaffa8: so did most of us
the goal of perl 6 is not to continue with our accustomed ways
nothing the matter with custom, except when it prevents progress
and Perl 5 tends to value custom over progress, so we started Perl 6 to make the opposite mistake
it will be popular with me, at least
and I might be able to persuade a few other people to like it too
it's a deprecation
and will probably break silently in another month or two
kinda like /c in p5, continues at the specified position
moritz_ is out sailing till Sunday, I believe
why not?
certainly for integral powers it should work
rakudo: say 1i ** 0.3
o_O
funny it thinks &lt;&lt;**&gt;&gt; is non dwimmy
rakudo: say (1..10) &lt;&lt;**&gt;&gt; 2
I'll bet there's a copy-paste error somewhere
you also have to be nice, most of the time
tylerni7: lots of ways to help out, depending
tylerni7: at minimum, you can tell us where our documentation sucks :)
mostly we don't try to put people in boxes, so you can do whatever tickles your fancy
as you can see, some people just like to torment rakudo in-channel
same as me
well, you probably want http://rakudo.org/how-to-get-rakudo first
if you want to hack on tests or specs, you'll want a pugs commit bit (for the pugs repo, which holds a lot of stuff in addition to the pugs implementation)
most of the web pages are stored there too
in fact, if you /msg me your email and preferred svn nick, I can give you a commit bit now
you have to understand that for some of us, our idea of fun is rather...masochistic...  :)
okay, pugs commit bit sent
takes a little more work to get a rakudo commit bit, 'cause they require a signed agreement
on the line before the test
see t/spec/README for more
or it can treat a block of tests as one thing
if it parses okay
right
you can still mark it todo, and it will "unexpectedly succeed"
though autounfudge may delete the todo
decommuting &amp;
however, the converse does not hold
you know, when someone clicks 'download', it takes them to a github page that simultaneously manages to provide too much information and too little information
yes
also, it's not clear how to get the head revision, only releases
clown
I work for a chip design company
help them design chips, and the software that interfaces to them
we are not making perl chips
Su-Shee: one could put an intermediate instruction page with generic instructions; "go to this page and click the first download in the top box"
the intermediate page could also point off to http://rakudo.org/how-to-get-rakud
o
which is complementary
just looking for ways to help the new folks a bit more...
cool
looking forward to it
mostly just wiggling my fingers over the keyboard waiting for the coffee to hit
+1
that seems reasonable to me
maybe add a sentence to rakudo's page saying "But if you want a released version, go to &lt;a&gt;github&lt;/a&gt;"
'kay, missed that
I'd put that up in front, s/also//, and then say, 'However, since rakudo is under active development...'
it would appear that pugs_svn is hosed
Su-Shee++, pmichaud++  # I'm not a bot, but I play one on IRC
payload: rakudo doesn't really parse indirect objects correctly, I suspect
but yes, what you have there should be equivalent to (-1, -Inf).min
I do wish that chromatic wouldn't hold out the hope of someone "fixing" perl.org merely by volunteering when that is not in fact the dynamics of the situation :)
howdy
how did you hear that, when (as far as I know) it wasn't recorded?
also as far as I know, I didn't say anything about my health
so my guess is that it's an older SOTO that is being referenced
I have no idea what you're talking about :)
ah, right, I had put it out of my memory
rindolf: do you twitter?
it was just a twitterish microblog about the backup etc. :)
I think the page now looks drab; maybe we should have two top-level pages: the Kansas version, and the Oz version, and people can bookmark whichever one they want
.5 * :-)
I know, we'll tweek the colors depending on whether they say perl6.org, perl6.com, perl.info, etc :)
well, Camelia can change the colors of her wings at will
also, one other quibble I have is that people keep using the "patches welcome" meme, but this is true only to a certain extent
Camelia is fairly non-negotiable by now
Editorial policy can't easily be decided by committee
troo
any twin of Groo's would be clever by comparison
pugs/misc/camelia.txt was a start on that
another thing that should be pointed out is that this is just the Perl 6 logo, not necessarily the logo of any distribution of Perl 6.
Red Hat and Ubuntu don't use Tux.
also, the complaint that it looks juvenile is quite accurate, because it's *intended* to look that way as a sign of renewed youth
someone needs to start Perl6 University so we can get perl6.edu.  :)
[particle]: I was thinking that would likely be part of Su-Shee's redesign
the text still says PDF
ah, I see
hopefully that can also be dealt with in Su-Shee's redesign
for all their problems, tables do a better job of keeping the text in the boxes
then make perl6.info accessible :)
let's throw 361 RFCs at Su-Shee and see if she takes six months to recover like I did :)
it would be nice to have context-sensitive floating elements that know how they got floated and change things that don't influence how the float was calculated, such as color
I wouldn't mind the 3-blocks to 2-blocks problem nearly so much if the blocks could change their color
frettled: I remind myself that CSS also could stand for Cross Site Scripting
well, js is okay by me, but flash is too far
you need div
see most recent change to S03
I decided Rats pretending to be Nums was probably a bad idea
just last week
is more consistent with the use of 3/7 as a Rat literal too.
and we didn't have a way to get at the integer division primitive
"include" is ill defined
we need to come up with a set of roles that describe behaviors, but I think those are a higher level than Int, Num, and Rat
fixing
Flt
Int, Num, and Rat are Storage Types (abstract)
I repeat, define the math roles at a higher level than that, please
Imaginary ~~ Numeric is fine
Float is ugly
that's why it's Num
and Real can be Rat|Num
that is, both Rat and Num does Real
Int, Num, and Rat are like the intermediate layer of a neural net that crossbars the inputs to the outputs
that is, pragmatic abstractions like Rat are mediating between the mathematical abstractions and the machine types
so the third layer is appropriate
just keep your mits off my TLTs
define "silly letter"
Three Letter Types
the roles should be spelled out, but we can make it easy to get the symbols, as with Sets
I think this should probably be general policy
maybe a pragma saying "whenever you have the choice of importing Unicode symbols, do so"
it's been considered in the past
but none of them look very good
R_I  :)
ruoso: no, the dimensions are wonky :)
from a vector-space point of view
I have enough trouble with one
yes, the pragmatic types imply something about slots, without overspecifying the slots
that seems like a good way to look at it
but I do think the math folk would rather write Complex and have it pun into a class with a default implementation of R_I, as it were
but also a relationship between the slots
some of them are considered native
but there are potentially many implementation types that look more like objects
gets fuzzy
native more or less means the hardware will get upset if you try to add slots to this
derivation is constrained not to change representation
augment int32 { has $.foo } # kaboom
cultural wonkiness is one of the invariants
that makes Perl 6 the same as Perl 5
and the fact is, we *are* aiming to impress 6-year-olds
and these days, toons are big business :)
and so far, I haven't seen anyone jolted by Camelia that couldn't use a little jolting
to the pure, all things are pure :)
it's all circular at some level or other
axioms circle themselves
almost all cultural fights involve someone assuming something is axiomatic that someone else wants to take a circularity saw to
I personally want to take a circularity saw to corporate logo culture
'coure not, that's what time is for
*course
well, maybe next time around
one could probably figure out a sequence of logic from that premise that indicates the world doesn't revolve around you
since, obviously, revolution cannot occur without time :)
what color is it?
I think I've figured out the refactor of 'is context'
in a nutshell, any var declared as $*foo is contextual
so my $*answer = 42
yes
then there's the readonly question
I think there's a new declarator
for which I've looked at what seems like several hundred names
but for now, call it 'def'
which is a declaration of a readonly of any sort
def $x = 42;  $x = 43; # boom
too bad :)
constant evaluates = at compile tim
*time
this evaluates at run time
so combining, you get def $*answer = 42
and then any subroutine gets $*answer as readonly 42
but other threads might be running with different answers
it represents the same semantics that parameters get by default
my $x := 42; $x := 43; # non-boom
def $x := 42; $x := 43; # boom
that was one of many words I considered
it might or might not even be the best one
too ong
*long
yes, the thesaurus has many words in those categories
I would really like both
since this is likely to replace 'my' in single assignment contexts
I rather liked 'posit', but even that is a bit long
&lt;-&gt; fixed point
so $x = 42;  # :-)
there are also lots of possible variants that change the = instead of the declarator
one could even force 'my $x == 42;' to work
then == is out :)
so what operator means 'posit'?
my $x &lt;- 42
it means 'suppose for now'
yes, but we've used that
unless we kill both temp and let
that's why Juerd is hiding
so &lt;- should ro the $x :)
and, of course, there's all sorts of arrows in unicode
of course, CS folks who use arrow to mean assignment will be confused :)
if we made declarations at the end of feed operators readonly, then my $x &lt;== 42 would work
$x &lt;- 42;  assign and set readonly
it means bind to this with readonly semantics in both cases
and the ends of &lt;-&gt; just cancel :)
why wouldn't you just say fix %foo = eval ...
or my %foo &lt;-- eval...
that's what do blocks are for :)
FP is your friend (sometimes)
I have a soft spot in my heart for imperative programming, but I'd rather encourage FP where not inconvenient
it really is pretty much identical to the semantics we want parameters to default to
I suppose we could steal := for this, at some expense
it would be more of a unification with sig binding
rebinding would still be possble with an appropriate declarator
this is all very Hmm-y
basically, we want a light container bind, and a heavier container/contents bind and make readonly
could also be stolen
when one gets tired of writing BEGIN { ... := ... }  :)
my STD is already written that way, and works :)
thinking hard about stealing ::= to mean bind and lock
chow
I think we still have the context trait, but $*foo variables automatically get it set, along with $_, $/, and $!
&lt;xyz=$var&gt; more typically
&lt;$var&gt;
any foo= prefix inside &lt;&gt; is just recursive back to &lt;&gt;
no, haven't bled yet
waiting for coffee...
but in that sense I suspect all dynamic variables are unsafe, when you don't know who is going to use your module and fail to init them at every entry point
you can get privilege escalation with sandboxen too
nod
I've just been trying to break myself of thinking that the Unix process model was forever
so I've tended to look at internal feeds as pipes, etc.
and generally think of subprocesses within a program as much as possible like subprocesses outside of programs
anyway, will think on it more when the caffeine hits
std: sub { "hello" #`(test) }.()
just doublechecking something that confused rakudo when JimmyZ tried it earlier
rakudo: sub { "hello" #`(test) }.()
but rakudo will presumably get less confused after converging on STD
yes, but not necessarily one I'd expect to be fixed before convergence
k
the intent has been that . after {} treats the {} as terminating an arglist, but it might actually be broken at the moment in STD
it's a bare block, so executes immediately
rakudo: &lt;3 1 4 1 5 9 6 2 5&gt;.sort: { +$_ }.say
the intent was to support something like that
but it might be a bad idea
it would be better to have something that turns the entire statement into a term for the .say
I have at times ponder introducing a ;. operator
*pondered
used to be that truncation policy was a performance win to avoid doing division, but maybe it isn't so much anymore
ooh, I think I might have it.  we can already say $foo\i to disambiguate a postfix, so maybe \\ could do that and whack the precedence back down to term level too
that would make it &lt;3 1 4 1 5 9 6 2 5&gt;.sort: { +$_ }\\.say
with sort of a visual picture of the .say dominating the left side
&amp;say is a function, not a method
just trying to make a way to keep a string of methods flowing in a rubyescque way
but yeah, maybe it's ==&gt; *.say or some such
or @(*).say
don't remember offheand
*hand
kinda klunky though
and strange for single objects
otoh it is more visual than &lt;3 1 4 1 5 9 6 2 5&gt;.sort: { +$_ };.say
and ;. suffers under golfing out newlines
if the intent was $_.say
but basically a backwards statement prefix of some sort :)
I guess that would be a statement postfix...
like "done", "gatethed", "tried", "voided"  :)
*gathered
well, parens are usually better, and already there :)
pmichaud: I don't see your $*XYZ comment anywhere in the log
but yeah, we should probably make the user explicitly say our $*XYZ = %*ENV&lt;XYZ&gt; in GLOBAL, which is pretty easy since UNIT starts in GLOBAL
or rather our $XYZ, if we drop * in packages
pmichaud++
which reminds me, does rakudo have a story on tainting yet?
afk &amp;
donri: two reasons, mainly
first, we wanted to steal bare [...] for grouping without capturing, which I felt was more important
we have that in Perl 5, but it's really ugly:  (?:...)
that's just [...] in p6
second
character classes are getting to be "wronger" these days
it was already wrong in the age of Latin-1 to say [a-z]
now that we have unicode
you should almost always be using a named character class like &lt;alpha&gt;
so it was basically a matter of huffman coding the more common feature to use [...], and discouraging character classes by demoting them to &lt;[...]&gt;
on the other hand
it's also a feature
because it gives us a composition notation
&lt;+[a..z]-[aeiou]&gt; and such
so you can build up character classes with set operations inside the &lt;&gt;
which wouldn't work outside as well, since + means something else there
basically, lets you rough in the set of characters, and then define exceptions or extensions to the character class
so things like &lt;+alpha-vowels&gt; become possible
anyway, that's why it's &lt;[ a .. z ]&gt; now
note that ranges are now .. instead of -
since there's no reason to ever use .. it's obviously "meta"
and it's consistent with ranges elsewhere in Perl 6
also whitespace is allowed for clarity
so that's probably a longer answer than you wanted :)
but most of the design features of p6 have complicated answers like that, with multiple reasons contributing
because we almost never changed anything for a single reason
because a character class only needs each character listed once
if you were wanting to match . then there's no reason to add another .
so it's naturally out-of-band, as it were
unlike -, which you might actually want to match
anyway, S05 discusses a lot of this, if you're interested
decommuting &amp;
well, for one, the 2nd won't work, since $x is already redefined by the time it hits the =
and temp will change $x in whatever scope it already exists, while my $x makes a new $x in the current scope
(you'd have to say "my $x = OUTER::&lt;$x&gt;" or some such
but nobody implements temp yet, actually
we've tended to move more to contextual variables from temp, because they're safer for threading
though if you use temp on a context var, it actually declares a new var in the current scope, because that's how contextuals work
so "temp %*ENV;" for instance makes a local copy of the global environment, and anything in the current dynamic scope will see that %*ENV instead
whereas "my %*ENV;" would make a new environment with nothing in it, rather than copying in the outer environment
so "temp %*ENV" is more or less what every Unix process does
I will be offline most of today; driving to SoCal
you can close a handle with a 'will leave' trait on the declaration
does getContents break into lines?
okay, but it's a string represented as a list, right?
we don't have lazy strings in Perl 5, but if you want to read a file char by char, that could be done lazily
lines() is lazy
and I think .comb on a filehandle should be lazy eventually
though I doubt rakudo does that
my $fh will leave {.close} = open $file;
is equiv to
my $fh = open $file;
LEAVE { $fh.close }
S04 is where these are discussed
always executes on leaving the current block
there are many variants
see the section labelled "Closure traits"
if you don't do anything with a filehandle, and don't care exactly when it closes, it we close when the filehandle is garbage collected
you only have to close it explicitly if you care about the exact timing
well, you might have race conditions if you want to reopen the file
what are your skills and interests?
have you downloaded Perl 6 yet?
I'd suggest visiting perl6.org and following the download button first
what kind of machine/OS are you on?
people have done it on windows, though I'm running linux myself
which Perl are you using on windows?
people have been having the best luck with Strawberry Perl, I think
&lt;crickets&gt;
well, yes, but you'd better want ... to return something numeric
yes, unlike P5
usually it's sufficient to put { ... ; }
well, a ~ would work for a string
and that shouldn't make a hash in any case, I think
rakudo: my %x=&lt;a b c&gt;Z 1,'a',3; say (map { %x{$_} },&lt;a b c&gt;).join(' ')
don't need anything
maybe it's an accidental feature
rakudo: class A {method unself {undefine self}}; my $a = A.new; my $b = $a; $b.undefine; say $a
rakudo: class A {method unself {undefine self}}; my $a = A.new; my $b = $a; $b.=Object; say $a
rakudo: class A {method unself {undefine self}}; my $a = A.new; my $b = $a; undefine(Var($b)); say $a
rakudo: class A {method unself {undefine self}}; my $a = A.new; my $b = $a; undefine(VAR($b)); say $a
rakudo: class A {method unself {undefine self}}; my $a = A.new; my $b = $a; undefine(($b)[0]); say $a
rakudo: class A {method unself {undefine self}}; my $a = A.new; my $b = $a; undefine([$b][0]); say $a
rakudo: class A {method unself {undefine self}}; my $a = A.new; my $b = $a; undefine([$b][0]); say $a
Ow, who turned on the morning so early?!?
sounds like line-buffering vs no buffering
or possibly two different line bufferings
is there anything that would make such bugs easier to locate?
sometimes a compiler-writer with precognition is sufficient...
non compos momenti
(1) I always thought of it as a bit vector managed by the BUILD, but it's purposefully unspecced as implementation dependent, though if we need meta-api for it...
(2) would presumably be supplied by some kind of mixin these days
(presuming I even remember what self:&lt;sort&gt; did... :)
that part was just a bit confusing :)
let me glare at the context a bit more
hmm, okay, it was for something other than I remembered.  it's syntax for responding to .= directly, rather than being constructed out of the non-mutator
not sure self: is the right way to mark that though
'course, then someone would write =sort(@array) and confuse POD completely...
maybe self:sort isn't so bad
mutate:sort rw:sort inplace:sort
feels like something that wants to be de-huffmanized in any case
but if it's only ever a method, then method =sort would be fine
and .= is the only way to invoke it (without introspection)
seem like undefine ought to be no-op on something that's already officially undefined...
rakudo: class A {method unself {undefine self}}; my $a = A.new; my $b = $a; $b.unself; say $a
rakudo: class A {method unself {undefine self}}; my $a = A.new; my $b = $a; undefine $b; say $a
that's the pair of cases quietfanatic found last night
perhaps undefine should only be a method, and we can only request that an object undefine itself
then VAR($x).undefine would be distinguishable from $x.undefine
rakudo doesn't do the check at the correct time
yes, though STD is out of spec in making it a mere warning
but yes, it should fail at CHECK time
std: caffeine(); { my sub caffeine {...} }
that's a fun one to catch
std: caffeine(); my sub caffeine {...}
yow, I'm not sure I want to guarantee that one...
since it depends on not dereffing $caffeine as a variable till the call
55
the question is whether invoke($routine,@args) passes $routine as a value or as a variable
or $routine.invoke(@args)
I would argue that invoke doesn't see the varaible
ia
hugme: hug sageb1
it's an EXPR
M_o_C: I doubt that anything is going to autovivify into a sub, more likely it'll try to call .() on Object, which would be a no-op coercion
sageb1: you're being boring, which is a no-no on an entertainment channel like this
no problem, I assure you!
std: undefine sageb1;
ah well, we shouldn't make fun of the insane
I interpreted it as someone who thinks unabated free association is funny
btw, why isn't hugme marked with a +?
hugme++
ENOBOT
well, Perl 6 has lambdas too, so we could have a lambdabot of our own
hopefully one that doesn't use such a common first character...
or that at least shuts up on things it doesn't recognize
I think ` would be a good opening character, at least on my keyboard
ENOBOTAGAIN
maybe it should be sort:dirty
then we could have method talk:dirty
which changes yourself for the worse
I was going to suggest just "does Mutation", but it really wants to be part of the name so you can write both versions if you want
the deep end
I just use --gen-parrot and make install
seems to work everywhere
dur!
read them in the order of the side bar
moritz_: why aren't 5-to-6 articles more obvious on perl6.org?
well, except in pugs
depending on what you mean by "practical" :)
night carlin
moritz_: bad link in your blog, see the comment there
rakudo: multi x ($x) {$x.say}; say &amp;x.WHAT
O_O
rakudo: sub x ($x) {$x.say}; say &amp;x.WHAT
&amp;x should be of type Sub regardless
rakudo: multi x ($x) {$x.say}; say &amp;x.(42)
rakudo: multi x ($x) {$x.say}; say &amp;x.PARROT
it's a leaky concretion
perhaps we should undefine undefine
how 'bout we just make sure .defined is rw instead so people can say .defined = 0
and then implement undefine as sub ($obj) { $obj.defined = 0 }
I think I'd better drag quietfanatic away from this cesspool of destruction
I'll have to make make_undefinable definable first...
++diakopter for finding a way to make people feel good without giving them karma :)
@karma ++diakopter
for a bot written by geniuses, lambdabot can be amazingly stupid at times
moritz_: lesson 15, Twigils has a missing twigil on $a: my $block = { say "$^c $a $^b" };
std: sub foo {...}; sub foo {42}
ENOTYET
decommuting while I wait &amp;
std: sub foo {...}; sub foo {42}
masak: on VMs without continuations, laziness must be emulated with closures, as STD does on Perl 5.
just implement Haskell on the VM, and then finish pugs :P
that's because I like to keep my laziness orthogonal to sub cals
*calls
and I very much don't like co-routines that change their signature depending on whether they're initting or continuing, though making yield return new arguments is a sop to fix that
I thought those were just "web continuations"
well, basically, lazy lists are our continuation syntax primitive
lazy lists are also a poor-man's monad
making sure time happens in the right order :)
prophetic past tense is tricky
continuations are like naked singularities, but the event horizon is a lazy list
moritz_: in blog s/If found/I've found/
moritz_: re proto regexen, they participate fully in LTM as alternatives, so they do speed things up in the general case, assuming you have LTM as STD has it
moritz_: yes, or some fast form of parallel NFA matching
STD currently fakes DFA with a trie on constant strings and brute force otherwise, but the semantics are right
certainly
see src/perl6/lex/STD/foo to see the LTM table for foo (in an active STD dir)
where is there a ?? prefix?
std: say ?? $x
it can detect that reasonably since ? ? $x is non-sensical
likewise, there's still a + twigil
std: $+foo
and that's why
jnthn: Array[Int](...) looks like a perfectly good cercion to me, assuming Array partakes of the role nature
*coercion
arguably, of course, you can't coerce to a role in any case
there's some punning/delegation going on there, I expect
to the class it's just a part of its name, kinda
your intelligence is worse today :)
g'night
std: sub foo($a = $default, :$default = 42) {}
it's even better than that
because it only matched all the alternatives at statement, and determined a fate
so it already has its fate determined by the time it reaches the statement_control rule
speaking of which, I see I have a bug, since lex/STD/statement_02 doesn't include all the termish prefixes
oh, it won't change anything visible to sprixel
it's just trying all the statement_controls before it tries EXPR, but the structure is the same
pmichaud: I don't see any problem with that approach, since every rule also has to work standalone when the Fates are off visiting Mt Olympus
phone
std: sub f($x) { $x &gt; 255 ?? 0 :: $x; }
perhaps defined it in terms of something that things + is more primitive?
*thinks
lanny: and do you want your svn nick to be lanny?
you were at lan3ny
you want that addr instead?
or the new one?
I mean the Lanny.Ripple addr
I can resend the commitbit if you don't remember your password
okay
welcome back aboard :)
I particularly hate spitwads.
would :(Int ::T $x, T $y) be tighter than that?
we just have to say that an en passant type also captures the nominal type
en passant is English, as of 1070
er, 1066
seems right
what about :(Int ::T $x where *.odd, T $y)?
that seems to argue for carrying wheres over
indeed, what if you want ::T to be *only* the nominal type
and appy a different constraint?
:(Odd ::T $x, T where Even)
until a tighter type is bound
then it's actual type
s/tighter/derived/
en passant is supposed to mean the actual type of the argument
suppose you derive MyInt from Int
if you pass in a MyInt, T is MyInt, not Int
but you said it was only the nominal type, which that ain't
if you say :(Int ::T $x, T $y), then the nominal type is Int, but actual is MyInt
nominal isn't bad at all if you're thinking about "name equiv" vs "structural equiv"
that's the storage type
no, $x's storage type may have no name at all
a storage type is what the subset type is actually stored as
the WHAT type
but that's not what I've been calling nominal type at all
I only mean the declared type in the sig
yes
we already know the nominal type, so no need to capture it
$x.WHAT can very easily give you a nameless type
not much nominal about that
but fine for the declared type, as in the meaning of nominal: "that which we assume"
as in "Larry is nominally a linguist" :)
why t/spec/S05-grammar/std.t was coredumping
sorry if you have to download XS
XS is a bit faster, actually
hah
maybe that's why cursor could load using Syck :)
well, probably not
make clean
perl -d:NYTProf tryfile STD.pm, I think
I don
I don't know of any such
it would be difficult to bypass the lexer without a source filter
that's one of the reasons Perl 6 does it differently :)
alas, we brainwashed people too thoroughly about the righteousness of Perl 5's sigil system
unfortunately, to change the sigils, you have to change how the slices work, and when you do that, there are ramifications on how context must be applied lazily rather than eagerly
the stmts are the cool part
bbl &amp;
agh, p{} must die, I think
uses up a common letter, unlike q
qp is okay
well, apparently I am too, insofar as STD is being used :)
and viv
yes, well, I patched the spec because I was backlogging and didn't remember about { %stuff }
and noticed I hadn't hacked in the new no-placeholders policy that fixes map
most of the changes are simplifications, and the only casualty I can see is the proviso about embedded @_ not seeing the outer @_
which seems like a small loss
since we'll be encouraging people to translate to real signatures anyway
and most existing uses of @_ in P5 are not embedded in an inner block anyway
and we're immune to the backwards compatibility argument that plagues p5l :)
In fact, we *have* to break a few eggs to prove we're making an omelet.
Fortunately, being allergic to eggs doesn't make you allergic to egg metaphors.  Or maybe unfortunately...
Or maybe not maybe.
well, everyone knows that a backend has no soul, unless maybe you're a dinosaur with a hindbrain
diakopter: I'm much happier with the type structure of viv now with respect to --p5, thanks for the attitude adjustments :)
22:47 TimToady1    what you don't see there is that std actually succeeded in parsing it, since that was just a warning
/names
STD tends to use {} instead of :: because :: ends up requiring backtracking in order to fail backtracking :(
and I'm not particularly attached to the current rule ordering
a correct impl should declare my %seen{Object} and then %seen{$_}++
but rakudo doesn't do Object hashes yet
note that Object hashes essentially do === comparison on keys
not eqv
so maybe %seen{$_.WHICH}++  :)
uniq shouldn't reorder either
just throw away dups
unless you know your list is already ordered
returns the identity of an object, which for value types is the value itself
so it turns out that $a === $b is the same as $a.WHICH eqv $b.WHICH
rakudo: say [1,2,3].WHICH
that's an insoluable problem, unless values have an identity that is marked VAL(3) or some such
well, if an object address has a unique type
that would work
oh, yeah, strings
$_.WHICH.perl would include the type
but Int() is wrong in any case
addresses ought to be opaque, to the first approximation
or you'll have people peeking and poking all over the place :)
return them in base 13, without the :13 on the front :)
my inbox has 9292
MTA doesn't quite work...
A is sort of like infinity
STD has such routines as ordinary service methods down at the end
since symbol-tableness is actually important to parsing
rakudo: say 2.5.WHAT
hmm, I thought someone already fixed that...oh wait, it was just the .t I saw, I think
2.5 is specced to return Rat
preserve precision of literals
not at all
want it where?  in storage, or just as a literal?
2.5e0 works for that
but generally it shouldn't matter
and certainly, if the optimizer detects that 2.5 can only be used as Num, it can convert at compile time
alternately, literals cache various interpretations of themselves
this feature isn't aimed at smart people lik eyou
it's aimed at people who want to add up a large number of dollars and cents and get an exact amount
at people who will ask why 0 ... * + 0.10, 10 doesn't stop exactly on 10
your job is now to make the feature as transparent as possible :)
along with it, default Rat is limited to rat64 semantics
so we don't get geometric explosions accidentally
&lt;pmichaud&gt; colomon: :a&lt;3&gt;  is the same as :a('3')
actually, with the recent change it now means something more like :a(3 but Str('3'))
np, just doing attitude adjustment with a 2x4  :)
which doesn't much matter for an Integer, make makes more of a difference with :a&lt;1/2&gt;
dhaivat: if it does replace perl, it's required to emulate
basically, though, if you meantion '6' anywhere, it doesn't have to assume Perl5 :)
depends on the implementation
std: say(3 and 4)
seems like a design smell to me
you sure you're not doing an XY here?
jnthn: is there a reliable way in rakudo to get from a class to its associated package?
that's still the package of the object, not the package of the current class
if there were a $?PACKAGE then you could just $?PKGAGE::&lt;$myvar&gt; or some such in an rw accessor
yes, lexically
er, no
nevermind, that won't work either
what we need is in $fido.MAMMAL::speak() to find out MAMMAL
and that's neither the type of $fido nor the lexical type
it's the effective type as seen by submethods
$fido.MAMMAL::myvar = 42;  # set $MAMMAL's $myvar, not $fido's
when you do a BUILDALL, it's calling BUILD submethods on the actual "current" type
how does the default BUILD work if a class doesn't define one?
if it calls Object::BUILD, the way that Object::BUILD knows it's in Foo:: rather than Baz or Object is the kind of magic we're looking for
if *that* piece of info can be traced to Foo's package, then we can store quietfanatic's class variables in it
and have a single accessor in the base class that knows which class it was invoked on behalf of
a contextual would be sufficient for this, I suspect
what's the name of it?
something on the order of effective class...
ECLASS maybe
like egid etc
presumably the dispatcher, but maybe only the .* dispatcher
or the .? dispatcher...
the dispatcher has to know which parent class it's poking around in anyway
not which class I found it in
or you have to write the same method in all the classes
it's the class I'm looking in
assuming I can inherit one method to do it for every class
that might be a bad assumption, of course
unless you say B.A::foo()
and then it's A
but maybe we're talking about a replicated submethod rather than normal inheritance here
or some role that mixes into each child class
which makes a little more sense, since roles are more about implementation, and use of inheritance to share implementation is kinda bogus anyhow
yes
that feels a lot cleaner to me somehow
nodnod
or maybe it's a different declaration, supermethod or some such instead of submethod
clubmethods :)
as in 'join the club!'
or I'll club you
troonuff
/msg your email and preferred svn nick
me works
sent
it's customary to add yourself to AUTHORS as a first commit to test it
in the top dir
I don't remember mine...
CAN NOT HAZ UPDATE
you'd think feather2 would be able to update from feather...
what is this plain english of which you speak?  :)
we may need to hunt down someone with feather2 access
well, S05 was half written by an Aussie...
and the other half is just random notes to ourselves...
a rule defaults to :sigspace, a token doesn't
both rules and tokens default to :ratchet, but a regex doesn't do either of those
makes whitespace to smart matching instead of being ignored
Juerd: I saw it show up here
under svn
docs/feather/index.html
lost cron entry, perhaps
was it setup before feather split up?
maybe it was a symlink once upon a time, and got duped?
did you look at audreyt's crontab?
yes
say "crontab -l"
you can make one with crontab -e
Wolfman2000: you can set VISUAL or EDITOR to something else
well, ZZ works fine too
if you have to remember one
Juerd: I think it only does that if you start it without arguments
I used to use emacs, but my pinky finger wore out
actually, I type CAPSLOCK-[ for that, Juerd
that's right menu key for me :)
thorn makes a great tongue
this *is* a laptop...
I've used that in the past
Wolfman2000: you will also learn linguistics, probably
I just wish I could get my windows-waving-flag button to do something sane
this might be one situation where it would make sense to read the original Apocalypse first, since regex change was fairly radical
that would be http://dev.perl.org/perl6/doc/design/apo/A05.htm
er, html
but the closure actually executes code, so the braceless form is better for constants
or call .parse with an arg that says where to start
to avoid confusion with MAIN
to avoid confusion with TOP :P
sleep on it!
mainly
he didn't say you had to be that competent, just feel that competent :)
another thing we usually point out when handing out commit bits is that we run on Forgiveness Rather Than Permission here
that's why it's under svn :)
std: my $str = "moose";  if $str ~~ m/^{^se}/ { print "good"; }
sjohnson: you're looking for &lt;-[se]&gt; I think
sure, it match beginning of string followed by 'se'
that's what &lt;-[se]&gt; means
sjohnson: that's almost backportable to Perl 5, if you don't mind matching | too :)
um **{1} is a no-op
try ?
? means **0..1
probably wants ** 0..1
no spaces around the ..
otherwise it thinks you're trying to match two dots
S05:1718
std: /\p/
beats me
it's not written clearly, it's trying to point out that p5's \pL is like &lt;alpha&gt;
niteynite
rakudo: say "123abc456" ~~ /&lt;alpha&gt;+/
but, of course, that's in the previous section that you didn't read yet :P
if you want to write grammars, I'd suggest at least skimming the first half of S05 completely
in perl 5
not in perl 6
Wolfman2000: if you're using &lt;alpha&gt; you probably want &lt;digit&gt; just for consistency
there isn't a \whatever for alpha in Perl 6
in any case &lt;alpha&gt;&lt;digit&gt;&lt;alpha&gt; reads better, I think
stylistically, it's a bit top-heavy
I'd probably make a &lt;us&gt; and a &lt;ca&gt; rule
for $handle.lines -&gt; $thing {...}
I think someone left a loopback on the phoneline...
maybe we could get them in a recursive loop
still upgrading my ubuntu...
which actually pulls in STD.pmc
note also that the line number you get is really in STD.pmc, not STD.pm
STD.pm5 is the readable version of that
that's probably getting pretty ancient
if he bundled a STD, it has to be an old snapshot
why is there a literal \r\n\r\n in the file?
well, p6 can't parse that
the warning is unrelated to the parsefail
there's some failure of understand of abstraction levels here...
*understanding
the problem is that after you take a text and turn CRLF into \r\n, it's no longer Perl 6
you should be parsing whatever you had before CRLF turned into \r\n
that's why it's saying there's no 'r' subroutine
that's not Perl 6 either
depending on what you mean by ENTER
do you mean the user typed ENTER?
I don't understand "HTML converted"
then you need to make sure the text string ends up with a real newline in it at that point
not some meta-representation of it
P6 isn't going to guess when you're changing meta-levels
some language processors like shells give the impression of guessing, but they're just confused, usually :)
that sounds too late to me
something should be producing the CRLF earlier in the process, or be told not to translate to \\r\\n
argh, no, it's almost always wrong to try to undo what something earlier did wrong
information is lost
what if the program contains a real \r\n?
much better to fix it at the source
you need to capture control someplace where whatever represents newline really represents newline, not just a meta-representation of newline
arguably, .perl could spit out 5.25 to mean a Rat
1/3 :)
well, the question is what the user expects
it's certainly correct to return either 1/3 or 5.25 by current spec
rakudo: say 3.14159265.perl
I think 3.14159265 preserves understanding
though it could be argued the Rat preserves a different understanding :)
well, obviously non-repeating is one criterion
but there could be some kind of relative length criterion
it would be nice to figure out which denominators work and which ones don't without actually doing it
I think I figured out how to identify denominators that would work well as decimals for .perl
it has to have only factors of 2 and 5
so basically you shift off all the low 0 bits, and if the remaining number is a power of 5, it works
basically, you're constructing a new denominator that is a power of 10
so you multiply excess 2's by 5 and excess 5's by 2
once you have a power of 10, you can use its size to place a dot into the numerator
so can probably be done without any division at all, I think, if you allow table lookup of powers of 5 and powers of 10
which it might, if we ever converge on a spec
they're just Captures that haven't been sorted into sheep and goats yet
it did just start to rain, and the forecast was for 'clear'
one could imagine Perl 6 as a kind of arcology :)
so maybe we should have a KitchetSkink
that too
no, we have that too
std: KitchenSkink
Excess Flood!?!?
well, dalek is in .nl, so it'll be the first to go
not sure if you can characterize horrible pun wars as "nice"....
.oO( single-to-nice ratio )
I don't know if we could stand it
alas, with Unix folks, niceness is a negative priority
ah, good old st pancreas...
we stayed in a hotel about 2 blocks from there once
for a whole week, so we got used to the look of that station
kinda
mathw: we were there ~6 years ago, I think
obviously if there's a jeremiah1 there's a jeremiah0...
last I checked, there were 137 Larry Walls in the U.S. and two of them were me.
only about half the time
I'm sorry, masak.
std: class R {...}; class I { }; class R {}
hmm, thought I fixed that one
std: my class R {...}; my class I { }; my class R {}
I use the whole test suite for regression tests :)
std: sub foo {...}; sub foo {}
huh
I think +^ probably implies coercion to Int
colomon: pong?
'bout to do dinner, but I'll be around off and on
shore
yeah, though Range should flatten in a real list context, I think
but Str shouldn't be in the business of supplying one, I suspect
so maybe a direct Str should just $n..$m it
yeah, basically, just return what it originally was, since Ranges are immutable
or what it would have been had it ever been written :)
2,yeah
is just 0..^4.5
so 0..4
np
it's *possible* that we want to leave + returning the Range
if all the numeric transformations are trying to emulate interval arithmatic
in which case you'd have to use .elems on it
I suspect .elems is one of those Any methods that coerces to something with elements if possible :)
and returns 1 if not
so don't worry about it
except you probably want to optimize it anyway eventually
should set $!
also, return of qx should be undef if it failed
we haven't really documented what's in $! for exit codes though
assume $! is the same as $? in Perl 5, but it's also an object that has methods to pull exitcode, signal, etc
iirc, exec failure tends to return 255
I could be misremembering
I can see where I might confuse 255 with 127 :)
carlin: mostly for attributes.  if methods expected args without : or (), then Rat.nu / Rat.de would not parse, but would take / as starting a regex
why do you want to?
why do you want a junction?
why does it have to return a junction?
this sounds more like a range or interval
what is better, an apple or an orangutan
you got it
precisely because they are autothreading on comparisons and such, they *can't* be used as sets, because the operators are all wrong
$set1 === $set2 should only be true if the sets are the same
with $junk1 === $junk2 it depends on the internal structure of the junctions
arguably all() is the only junction remotely resembling a set
because a set contains all of its elements, but not any of them, or one of them, or none of them
but even all doesn't work as a set
rakudo: say all(1,2,3) == all(1,2,3)
rakudo: say "true" if all(1,2,3) == all(1,2,3)
rakudo: say "true" if all(1,2,3) === all(1,2,3)
rakudo: say "true" if all(1,2,3) === any(1,2,3)
that one shoulda worked
that one is impossible, since there is no value that can be all of 1, 2, *and* 3
pugs: say "true" if all(1,2,3) === any(1,2,3)
pugs has it right
ng: say "true" if all(1,2,3) === any(1,2,3)
ng: say "true" if 1 &amp; 2 &amp; 3 === 1 | 2 | 3
ng: if 1 &amp; 2 &amp; 3 === 1 | 2 | 3 { say 'true' }
gah, I read that as "needs wonk"
rakudo: say "true" if all(1,2,3) == any(1,2,3)
ah, I know what's going on
rakudo isn't threading ===
rakudo: say "true" if 2 === any(1,2,3)  # will fail
it's treating === as a primitive
because junctions are implemented in terms of === in rakudo
sort of American Gothic Horror...
or maybe I'm thinking of Green Acres...
Wolfman2000: more of a design issue; rakudo needs a primitive === that doesn't autothread, but Perl 6 needs a === that autothreads
well, we need to change rakudo's implementation of object equivalence testing to be immune to autothreading recursively forever
that is, not use ===, or lexically scope a different operator that acts the same without autothreading
the junction module needs to see infix:&lt;===&gt;:(Object,Object) when everyone else sees infix:&lt;===&gt;:(Any,Any)
jnthn: see ^^^
my wife tells me that that was Eva pretending to be Zha Zha
Any is tighter than Object, which is the loosest
junctions are outside of Any so that dispatcher automatically catches things that need autothreading
yes
sure, but why would you want to?
usually you'd rather just have a Matcher of some sort that includes junctions, ranges, values, and closures for smartmatching
why are you assigning to $a?
why are you assigning?
$a = is an assignment
now you're doing numeric comparison
those wheres are always true
rakudo: say 'true' if 237483 ~~ any(*)
rakudo: say 'true' if Failure ~~ any(*)
if you really want to limit it to junctions, just declare the parameters to be of junction type
but I don't see any use for that
no, junctions wants the version where the arguments aren't junctions
or more precisely, where they don't care if the objects are junctoins
which is what I said earlier, :(Object,Object)
then === will compare the two objects even if one or both of them is a junction
iow junction wants to use a primitive form of === that is not availabe normally
*ble
it probably really just needs to say my &amp;sameobj := &amp;infix:&lt;===&gt;:(Object,Object) and then use sameobj($x,$y) as its primitive
hmm, except Object's version is presumably what is catching the junctions and autothreading, so maybe that won't work either
so Object's === isn't that primitive either
I think we need to rename rakudo's current === to &amp;sameobj, and then define a new === that autothreads and is unused by the junction implementatoin
*io
ca'nt tyep toady
rakudo: say true any(1,2,3) eqv any(1,2,3)
rakudo: say true any(1,2,3) === any(1,2,3)
rakudo: sub infix:&lt;primeq&gt; { $^x.WHICH === $^y.WHICH }; say true any(1,2,3) primeq any(1,2,3)
rakudo: sub infix:&lt;primeq&gt;(Object $x, Object $y) { $x.WHICH === $y.WHICH }; say true any(1,2,3) primeq any(1,2,3)
there's your primitive object equality
rakudo: sub infix:&lt;primeq&gt;(Object $x, Object $y) { $x.WHICH eqv $y.WHICH }; say true any(1,2,3) primeq any(1,2,3)
that also works, since WHICH always returns a value type
say any(1,2,3).WHICH
rakudo: say any(1,2,3).WHICH
say any(1,2,3).WHICH, ' ', any(1,2,3).WHICH
rakudo: say any(1,2,3).WHICH, ' ', any(1,2,3).WHICH
maybe p6eval should recognize lines starting with 'say'  :)
give everyone a shot at it :)
including ng, and std
thanks
I thought that was what blitzkost already was
pugs was starting to get pretty good at intermixing p5 and p6 when development stalled
and part of the reason I'm writing a p5ish grammar in p6 is so that we can parse intermixed p5 and p6, even if the p5 bits are handed off to a different interpreter
well, so are we, and have been for years now, with great (im)patience :)
masak: hmm, then you want to look at the transformations that gimme5 does to a p6 grammar to end up with p5 code
and probably glare some at the Cursor.pmc code having to do with cursors, esp forky things like * and +
and at some point you have to understand lazymap, which is where the real continuation processing happens
but since it's so slow to emulate in p5, we try to avoid lazymap for anything ratchety, if possible
and then just Have the Appropriate Amount of Fun :)
or just look through STD.pm5, and compare the comments with the original code to the derived code
I thought it had a real p5 interpreter inside it
if so, it oughta be able to do XS
I would guess that it's probably just some configuration issue, unless blizkost is using miniperl
but a real embedded Perl 5 ought to be able to load XS fairly easily
fairly easily meaning that P5 code can see the XS modules, not that P6 necessarily can
print out the embedded %ENV and see if parrot is interfering with it
he might not have put that up yet
nap &amp;  # I get my beauty rest at night, but my ugly rest in the afternoon.
:10($ack)
:16($ack)
didn't want to use hex and oct like Perl 5, since those are backwards; you'd think hex would *produce* a hex number
jnthn++ for pesteration
"undefined" is not meant to be a restrictive adjective :)
$x can Haz[Cheezburger]
yes, I think it was a mistake to confuse enums directly with roles
distinguishing them allows us to distinguish things that do Boolean with their own .Bool method from things that get a .Bool method via mixin of a $.Bool attribute
so now most of the type behavior more or less falls out naturally
making an enum function as a subset is perhaps still a bit forced
but I think Day.ACCEPTS just does a $arg ~~ Day.mapping.values.any
or some such
yes, I thought does/but could stant to be that one level of dwimmy
as long as the arg comes in with sufficient type info
does Enumeration maybe
the duck typing answer is that .WHAT.mapping returns something :)
yeah, tried not to put anything in that I could at least think of an implementation story
and adding .mapping really simplifies a lot of other things
unless someone says 'use DUCK_TYPING;' and then we all duck
well, we need something to keep our collective back-patting arm from going out of joint :)
You too could be an IT engineer!
.oO(so much for working on LTM this weekend... :)
my eventual goal is to have *everything* written in Perl 6...but you knew that already...
mberends: yes, verilog better watch out :)
not to mention QM...
funny that we have a reality inversion in Perl 6.  quantum operations are high-level, while low-level ones like .Bool are classical...
lunch &amp;
still is
seems to me it oughta look like a space :)
perhaps it's a font issue
yes, we outlawed $_ in the { a =&gt; 2 } form
romanhunt: curlies have gained power by *reducing* the number of uses from what Perl 5 does, actually :)
(and cuts many of the apron strings tying current rakudo to parrot)
they've been separated for several years now
diakopter: cats can't herd other cats either
everything is important, if only as a lesson  :)
in other words, we're still groping our way forward, but we're getting much faster at it.  :)
we're hoping each redesign takes half the time of the previous
eventually Zeno loses :)
name a VM
it's been thunka
and the 3rd will be 1/2 that, then 1/4, 1/8.... :)
the problem with the second will be discovering all the place we assumed how the circularity saw worked that were wrong
*places
right now we're exploring abstract vs concrete versions of the same operation, hoping that will be an obvious place to saw
so .Str conversion might be in the VM, while ~ conversion is in P6
(and crossing our fingers that we don't end up with the too-many-levels-of-indirection problem)
pugs had a CL backend at one point, iirc
or maybe it was one of the other parsers
jnthn: my guess is that eventually parrot scraps it's internal system and bases everything off the Perl 6 types :)
*its
not exactly
it'd be a VM that happens to be written in P6
but we need to get the native types going better first
basically, I see the nqp-rx phenomenon happening all over again once we have full P6.
the first would be scratching your head?
"The origins of this VM are lost (purposefully) in the mists of time."
gotta cross the Jordan first...
well, I know who gets left behind at the Jordon, and trying not to think about that... :)
ciao
std: undef $/
std: $/ = ""
necessary when replacing with a different $/
pugs: use v5; print "howdy\n"
heh
p5 == security breach to pugs :)
sjbot: p5eval: system 'rm -rf /'
STD doesn't understant 'use v5' yet
*stand
I probably wouldn't, but diakopter might :)
and maybe run in a chroot jail
and maybe use Safe, fwiw
only takes 13 seconds on my machine
to parse all those $'s
Anonymous variable requires declarator at (eval) line 1:
and a couple deep recursion warnings :)
probably tickles lazymap too hard
funny that it kills p6eval
wow, that was fast
recompiled, still takes ~14 seconds
I think I'm probably running a 32-bit kernel
Linux edo 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:54:29 UTC 2009 i686 GNU/Linux
oh, heh, I had the debug log turned on :)
&lt; 1sec now
because Perl isn't even getting into the NFA on that one
Perl 5 goes to great lengths to *avoid* calling into the regex matcher
and the ab$ is special cased to fail fast
it would fail not quite so fast with just ab
but still faster than the regex would figure it out, but it'd have to scan for the constant string
and ab doesn't buy you much with boyer-moore
it'd fail abcdefg a lot faster
I'll never tell :)
make the second a a*
no, that won't work either, since your end matter can match null string
that one will be pretty slow
no, but it'll probably run a bit under 300 hours
because it's not what people want
I deny it--I've never had mono...
though, of course, there's a good chance I'd test positive for EBV
I'm not particularly interested in playing with mono yet.  Maybe after I get done with Perl 6...
yes, well, one diakopter can only go so far in emulating a flooding algorithm
too, for that matter
well, you are one the cats I don't try to herd :)
so does git :)
decommuting &amp;
seems a bit odd to index a hash by a decimal number
as in The Emperor's New Science  :)
I'd make sure the keys of the hash aren't actually like '101'
wrong keys would certainly get you uninits
likewise if it's really returning @ instead of %
though you'd think in that case it'd complain "I'm not a hash."
also, stylistically, you don't need parens on the for loop args
and the final conditional could simply return the result of the comparison, since that's already a Bool
well, you'd have to negate it
&lt;= maybe
and the pod has a syntax error :)
std: while($ca.next()) { }
in theory
that's because P5 doesn't support that
you need a regex engine that can ask the input system for more string for that to work
you didn't have to guess; the documents say as much :P
how big is the input?
if it's smaller than your memory, just slurp the whole thing in and split
otherwise you're likely to end up with buffer-wrap errors
1k each?
then by all means, just slurp in entire files; it's much more straightforward that way
is built-in to P6, fortunately
@karma lambdabot
so anything lambdabot says, you have to multiply by -1
what was the problem?
yes, well, sometimes they know better than we do :)
well, fortunately, you don't have to be an expert in everybody's kids, just your own
unfortunately, you're not an expert in your own kids till they're grown up  :)
no, that's why we let you pick your own quotes
of course, if you're generating code, you probably shouldn't assume that, but be ready to do proper escaping for pathological cases
but usually you can be lazy and get away with it
sometimes I run through a list of delimiters to pick one that doesn't occur in the text, just to avoid backslashes
doing that right is difficult; you basically have to parse left-to-right, and not make guesses about what came before
well, the snowman is cute enough that someone might use it.  maybe you should go for something uglier
something that's usually used only in drawings vertically is unlikely to occur in a title
sjohnson: yes, well, scattering frowny faces all over your code might not impress your boss
don't think there's a tarantula symbol...
well, that's not actually the Nazi swastika...
no bug, I think
LTA message
yeah
std: say "hihi" =~ 5
hugme: hug STD 
hmm, that didn't work
hugme: hug STD .pm
that didn't work either, hmm
trying to get hugme to split on something invisible
as opposed to not splitting on something visible
sure
syntactically it's just a variable
and $ varibles don't follow the bracket rule
*ia
"It is a comfort not to be mistaken in all things."
std: say "{}#{}";
std: say "{ my $a; }#{ $a; }";
std: say "{ our $a; }#{ $a; }";
hmm
std: say "{ our $a; }#{ our $a; }";
std: say exp
.oO(they're smart because they read the docs)
mene, mene, tekel, upharsin
std: my $x = "1234"; my @ar = $x ~~ m:g/(0-9)/; @ar&gt;&gt;.say;
that's the real problem
std: my $x = "1234"; my @ar = $x ~~ m:g/&lt;[0..9]&gt;/; @ar&gt;&gt;.say;
rakudo: my $x = "1234"; my @ar = $x ~~ m:g/&lt;[0..9]&gt;/; @ar&gt;&gt;.say;
rakudo: my $x = "1234"; my @ar = $x ~~ m:g /&lt;[0..9]&gt;/; @ar&gt;&gt;.say;
rakudo: my $x = "1234"; my @ar = $x ~~ m :g /&lt;[0..9]&gt;/; @ar&gt;&gt;.say;
rakudo: my $x = "1234"; my @ar = $x ~~ m :g [&lt;[0..9]&gt;]; @ar&gt;&gt;.say;
that is bizarre
at least :i could be put inside the regex
rakudo: my $x = "1234"; my @ar = $x.comb(/\d/); @ar&gt;&gt;.say;
but don't rely on the order of &gt;&gt;.say like that :)
hyerpoperators are allowed to run in any order
*hyper
pugs: my $x = "1234"; my @ar = $x.comb(/\d/); @ar&gt;&gt;.say;
pugs: my @ar = &lt;1 2 3 4&gt;; @ar&gt;&gt;.say;
pugs: my @ar = &lt;1 2 3 4&gt;; @ar&gt;&gt;.say;
pugs: my @ar = 1..20; @ar&gt;&gt;.say;
heh, I think it does puts the first last just to keep people honest
s/does //
either that, or Haskell's thread scheduler isn't very equitable on small tasks
ng: my $x = "1234"; my @ar = $x ~~ m :g [&lt;[0..9]&gt;]; @ar&gt;&gt;.say;
self isn't a routine, it's just a term
they all came out grey here
I have more of a hard time forgiving xkcd for not realizing you can end a Perl program with a right parenthesis
asynchronicity++ too
in the language, yes
hmm, precedence failure
rakudo's parser still doesn't believe in list infixes, I guess
hmm, you may be right, lemme look
rakudo: say 1,2,3 X 4,5,6
that one is right
so you're right, rakudo does know about list infix, but &gt;&gt;+&lt;&lt; isn't one
(yet)
colomon: actually, pugs did implement the multithreaded hypers at one point
holli: also, we have feed operators ==&gt; and &lt;== that work like pipelines for cell architectures
but those aren't implemented yet either
but basically any lazy lists could be constructed by a separate processor, as long as there aren't bad dependencies (side effects)
holli: sure, but lazy lists have to keep ordering, even if calculated out of order; clouds tend to be better for map/reducey things
as opposed to ComplexPerl? :)
ImaginaryPerl is a bit long to type
but I'd like both Perl 5 and Perl 6 to be real, so maybe NumPerl vs RatPerl
botrot
I thought llvm didn't really support C++ yet...
the ones in STD.pm are, more or less
to the extent that STD.pm is spec..
sprixel: $_ = 'foo { 1 + 2 } bar'; say $_.eval
sprixel: say 'foo { 1 + 2 } bar'
'is supposed to' is not, strictly speaking, a defined phrase in Standardese... :)
but yeah, more or less :)
thanks...I think...
I'll have to figure out someplace to put the couch, though...
I like the ^X^Cvi emacs command, myself  :P
in what way would this not be possible in a Perl 6 module?
or is it some other exotic language, like English?
hmm
and 'su' could be any of various things
cognominal: ~~ does not force its right hand argument to be a regex, so ~~ '\v
would be a string match
but \n should be matched by \v, oui
radkudo: say ?("\n" ~~ /\v/)
rakudo: say ?("\n" ~~ /\v/)
I don't think rakudo knows \x inside of character classes though
forgot the masak++  :)
bbl &amp;
std: my Int constant pi of Num = 3;
std: sub foo returns Rat returns Cat {...}
forgot to remove the &lt;typename&gt;* from :constant...
std: my Int of Int sub foo returns Blob {...}
those aren't initializers
remember declarators aren't statements
and initializers are deemed to be initializers at reduction time of binding/assignment
if the left side is a declarator
that should carp about redeclaring Foo, I suspect
std: our constant Foo = 1; our constant Foo = 2;
hmm, so much for that theory
std: constant Foo = 1; constant Foo = 2;
hmm, works there
std: my constant Foo = 1; my constant Foo = 2;
std: our constant Foo = 1; our constant Foo = 2;
ah, rev change
before, Foo was considered a valid type
std: our Int constant Foo = our Int constant Foo = Foo;
declarators don't generally care whether the word they're declaring is a keyword
std: sub sub {...}
I don't recall every doing a distclean
*ever
testing a fix
that should fix it
so I can understand all the eu folks staying bundled up in their beds, but what's the excuse of all those hardy usians?  all out snowmobiling or somethin'?  :)
maybe they're all too busy hacking to waste time on irc :)
well, taking care of yourself is also important; we're in this for the long haul
the author of elf is a hare rather than a tortoise, and he's been haring off for a while now
only roles
but roles used as classes will attempt to pun themselves into a class
however...
std: class Foo[Int] {...}
std: rle Foo[Int] {...}
std: role Foo[Int] {...}
yes, Foo of Int is basically the same thing
yes, that could all be better written, but it sounds like you have it straight in your head
sigils are part of the name, and anonymous KeyHashes don't have a % in their name
except insofar as they are named by whatever the Hash key is
it's not like in Perl 5 where you have to play %{} tricks
well, it's coercion to Associative, really
we're still feeling out this business of coercing to a role, which tends to be dwimmy
unary + and ~ also turn out to be coercion to Numeric and Stringy, it seems
and in the case of Numeric, probably calls into the parser to figure out which kind of numeric to return
other role coercions might use a list of handlers, or some such
or maybe it can degenerate to a multi dispatch of some sort
"who most wants to turn this into something Foo-ish?"
it's probably only the from-string ones that are mediated by the parser
and coercion to Stringy is probably just coercion to Str for now, unless we want to make some things coerce to Buf
it is not clear how that pecking order should work
correct
but that is a bit of a bogus statement
that is a Hash that returns KetSets
*KeySets
makes more sense with $
or you can do 'my %foo is KeySet;'
or 'my %foo := KeySet.new;'
well, the $foo&lt;TimToady&gt;++ itself wouldn't return true the first time
but $foo&lt;TimToady&gt; would be true after that
since it's a postincrement
p6 specs NFG format, which naturally maps to arrays of integers, either unsigned if there are no strange characters, or signed if there are
where "strange" is defined as any grapheme not having a precomposed form
but Array[int32] and Array[uint32] can easily be optimized to smaller native types when the string is known to contain smallish characters
google for 'perl nfg' and you'll find a bunch of stuff
but it stands for Normalization Form G
which you won't find in the Unicode standard
it uses positive ints for any grapheme representable by a precomposed codepoint, and negative ints to represent lookup in a table for non-reducable graphemes with multiple codepoints
our original conception had a single process-wide lookup table, but I think parrot currently specs per-string
more work when you hit a negative "codepoint", but less vulnerable to DOS attack
but the idea is that Str is never represented internally in a variable-width format
those belong out in Buf types
so you can write all your Str algorithms with simple array indexing
that's the goal
which says UTF-32 is a good spot to start
or think of it as UCS-4
downgradeable to UCS-2 if there are no plane 1 characters
downgradeable to UCS-1 if there are no non-latin-1 characters :)
in the abstract, NFG is just a sequence of integers
it's really just NFC plus inventing more precomposed graphemes on the fly as necessary
and making sure they get translated back to the appropriate sequence of codepoints on output
the negative codepoints are allocated from -1 on down to keep the wordsize small if possible
but that's why your computer has multiple cores :)
yeah, always seems to me that it would be really easy to steal the unicore tables from Perl 5
but there seems to be a mental block against that
maybe we should take Perl 5's mktables and get it to emit P6 code that implements NFG
especially if done in a small additional CPU  :)
funny if our first feed operators actually come from an IO layer
was the 6502 named after the number of trannies on it?
was always partial to Z80s meself
never actualy owned a Z80 though; first personal computer was an Amiga 1000
my work computers were always sufficient to my needs up till then
still have that Amiga, btw
still, 4000 cores will be somethin'
only if you say make -J 4000, otherwise most of them are probably turned off
'course, if you do a make like that, you'll certainly discover your I/O bottlenecks  :)
now thinking about the scheduler built into recursive hyperoperators...
roles may do other roles, in theory
lists of lists are a joke in Perl 5
wow, judging by the silence, musta been a wild Friday night for everyone...
oh, sorry, I'll turn the light back off.
rakudo: say [min]()
rakudo: say [min]().perl
ng: say 1 min 2
earlier, even...
that goes without saying...
ash_: if you know of something you worked on, you might svn log it
then you just have to remember your password
sjohnson: wasn't foresight, just experience that once spam attacks start, they usually continue :/
and also laziness in not figuring out any other options :)
did I mention it will be impossible to do evil programming in Perl 6?  :)
test what, whether I mentioned it?
it was kinda sad, the day PHP took over from Perl as the language of choice for network abuse...
more like teletubbies, I think
sjohnson: nope, not something I've ever aspired to
or a Parcel
well, if you work ahead some, you have to track the generated but not yet consumed values
so I don't think the view is entirely inaccurate
to the first approximation, lists are not generally user-accessed
as in Perl 5, they're internal thingies
I'd argue Parcel, I think.
maybe, still waffling :)
btw, I think whatever else we decide @$x and @($x) have to do the same thing
I think that case is handled by the autoreduction of item Parcels
if $x contains, say [1,2,3], @$x derefs, but @($x, 3) doesn't, since the $x is embedded in a Parcel with 2 elements
but @($x) is a Parcel with one element, and therefore [1,2,3] derefs
yes
LaVolta: that would be another way to say it, but yes
say rather that @$x is shorthand for @($x)
pmichaud: I could almost argue that $x = is contextless, while $x := is item context
but no, then $x = (1,2,3) would interpolate $x into a list, which is a bit of a nono
alternately, just take the list, poke it into the Array's generator spec, and then tell it to reify mostly eagerly
why copy twice?
I think assignment is to a new $b and a new @c, and those are rebound to the variables upon completion, maybe
well, somehow we have to take a transactional view, and commit the change after creating the new values for $b and @c
but after using the old values eagerly
sure, I guess I don't see a problem
it's only immutable in the abstract
you can throw away values that can't be gotten back to
iterated externally, since a List is, to the first approximation, an iterator of iterators
we might want to do like with Range and distinguish List from ListIterator
the only time you need the whole list is in situations like (4,5,1..100,42)[@ix]
where @x can visit the elements in any order
in that case, it presumably promotes to Array
I don't think List can be Positional, or you always have to remember it all
that's bogus
yes, but on syntactic elements
(1,2,1..1000,42) has 4 elements
just in the sense that a given list, once you've determined the value of the nth element, will never determine a different value for it
that doesn't mean it's accessible
0..* is 0,1,2,3,4,5, and the values are always those values
but 'for 0..* {...}' doesn't have to store all the values
because we iterate the list, and iterating is forgetting
all iterators are mutable in that sense
yes
the subscript must autopromote it to something Positional
could do like Perl 5 and index the stack directly though
or whatever is functioning as the temporary value
could perhaps even be handled by Cool.[]
well, that would be an optimization
pretend to be an Array for a moment
$list.[] doesn't have to mutate the type of $list
it might, however, consume as much of the list as it likes to get to the biggest index
well, that argues that $x = (1,2,3) promotes to Array immediately
like we used to  :)
which is probably okay, given that Arrays can auto-extend lazily
because Array's are for remembering positions
translation, can a List just behave like an Array?
we've already built the autogen into Array semantics, so it seems redundant to also try to make List work both ways
I think lists are not positional
and then we wonder when we can GC the used values of the list
not sure List is a useful type
Array ~~ IterableByClonedIterator
in the sense that the Iterator is not an Array
any you might have several pointing to the same Array
*and
presumably, depending on how fancy we get
a Parcel is a list of iterators
yes, but that's dynamically determined in the general case
though we can recognize where to transmute to Capture most of the time
$x = \(1, 2, 1..1000, 42); say $x.[2].WHAT   # Range
well, list context is what iterates iterators in Perl, generally
but in Perl 5 the iterators can't be stored into $x
I think we should probably make it difficult in Perl 6 as well, though possible
since for $iterator {...} isn't going to do what people expect, one way or another
pmichaud: I think we promote an item Iterator to Seq, and define Seq to be extensible like Array, but readonly in the reified bits
also thinking that Iterate is the role that does .get, while Iterable means you can create an object that does Iterate
so an Array does Iterable, but not Iterate
either that, or iterators are Iterable, and other things are Iterableable
colomon: nodnod
a list-flattening iterator will throw away an embedded Nil so that the user never sees it
a slice iterator can return a Nil as an element, so something else will have to signal the end
either that, or a slice iterator promotes Nil to []
I think Nil can be okay, given list vs slice semantics
decommuting &amp;
probably just means that .list works
Cool.list is a fallback, not a role-supplied method
Iterable means you can ask it for an iterator
yes, but that's also because of Cool's .elems, not because everything does Positional
well, if that worries us, we can put that one into Any :)
the listy ones might still be in Any rather than Cool
but maybe not
but not always for the same reason
it's a role, it means "I implement list" rather than relying on some fallback
it means "I care about visitation and can visit more than one thing"
the default is self-visitation, is all
yes, "now" is what transactions are all about defining
you can still get at the underlying iterator if you need to
yes, and .get on one advances everyone's view
(in that case)
not saying that's necessarily good
biab &amp;
I have no idea what that means on a lazy iterator
nodnod
probably more like: I do/don't know whether I'm finite/infinite
or .estimate_available that can return a number, or Inf, or *
where the estimate might or might not be terribly accurate, but would be good for an initial allocation in the destination
so a filehandle might guess at the number of lines in a file
but a RangeIterator knows exactly how many it has
cono: a reduce operator is a list operator, and therefore requires a space before the first argument
std: [/]&lt;1,2,3&gt;
that's parsing as ([/])&lt;1,2,3&gt;
not that , makes sense inside a &lt;&gt; subscript
std: [/] 1,2,3  # this is better
perl6: say [/] 1,2,3
because a Rat stringifies via Num
perl6: say ([/] 1,2,3).perl
there's your 1/6
rakudo: for &lt;1 2 3&gt; { .WHAT.say }
that's specced to return Int Int Int someday
std: ([/]1,2,3).perl.say
std: ([/] 1,2,3).perl.say
STD requires the space there
std: [/]
rakudo: [/]
STD is correct there too
rakudo: say [/]()
rakudo: say [*]()
rakudo: say [+]()
[/] without a space or () is parsed as not having any args
(in STD)
std: print
std: print()
could force reduction ops to follow a similar policy
no
I presume cono wishes to alternate operators
(also doc EMPTY exceptions)
it's huffmanized by capitalization :)
vertical huffman coding...
it's also potentially a metaop
like Z might be someday, if we do zipwith as Z+
decommuting &amp;
I'm fine with Seq being considered immutable (but lazy), and adding a SeqIterator or whatever
can't do it myself at the moment, have to go out tonight.
bbl &amp;
pmichaud: I don't see how a List type can work.  Each iterator has to decide parameter by parameter how it's bound and whether it's flattening; a sig intermixes those demands.
hence the new methods in S07, get is flattening, but getitem is not.
getitem returns the next parcel, which is what you want either for positional parameters or slice elements
(assuming non-parcels to be degenerate parcels)
slice parcels are different from positionals primarily by coming in the variadic region.
but I think they're more or less the same from the iterator's perspective.
(method names are negotiable, of course)
argument lists *switch* to list context partway through
based on slurpy demands
okay, maybe. seems like an extra iterator, if the context knows which method to call
but I can see how that could be made to work, assuming we never switch back to itemizing parcels
it also bothers me in the context of nextsame a bit
since the subsig might have a different idea, and the Capture might switch prematurely to list iteration from the standpoint of the subcall
'kay
it just seems to me we probably shouldn't commit to flattening more than one parcel at a time, in case we get fancier with signatures that can intermix listy/slicey things someday
though certainly there are some lists we can know will stay lists at compile time
if all iterators support pushback, then parcel flattening can simply be pulling the parcels contents up into the not-gotten-yet list and then looking at the front again
I'm not sure they shoudn't...
anyway, with that approach, you never have to commit to flattening more than one (top-level) parcel at a time
and one could conceivably have sigs that alternated flattening bindings with non-flattening, somehow
well, substituting an iterator for one parcel is isomorphic to hoisting it into the todo
well, maybe they don't have to, if pushback is just substituting a different iterator whose tail continues with the original iterator
I don't like to call that List, I guess
maybe just use .get from parent class/role
if it can do the wrapper iterator to schedule todo
or to do pushback
as usual, I'd like to have my cake and eat it too :)
that seems like a no-op to me, if @ already implies .list
depends on the signature of the block
map/grep signatures are like the repeating groups in a variadic section of a signature
it would throw away the parcels returned by each map, at least
flatten, rather
yes, that doesn't commit its result to flattening
a .list contains no parcels
depends on whether the person reading it use .get or .getitem
*uses
well, no differnce in the list case
since the parcels are gone
.get is always flattening, but .list never gives it any parcels to flatten
which is what binding to a positional or a slice does
and I'd like the sig of map/grep to be able to indicate which method to call
default is .get, since we're assuming flattening
but we need a way to indicate a parameter that is a "slice" element
it's like map and grep sigs are really subsigs of a larger repeating variadic sig
currently -&gt; $x {...} treats $x as positional, but map really wants that to use .get, not .getitem
yes, the sig of the block is really implicitly slurpy in a way
and goes with the business of returning a partial match cursor in the iterator
if you pass a parcel to a normal positional, it binds as a single item
that is not your indicate expectation for map's $x
*indicated
you expected (1,2,3 Z 4,5,6).map to flatten
so we need some way of marking such a sig as implicitly variadic
yes, which I've been mulling very hard.  :)
and realizing that map/grep signatures aren't the same beasts as normal sigs
but more like a *$x *$x *$x ... in a normal sig
except called repeatedly
so we don't have to worry about the fact that $x means different things
so it's a bit like subrule matching
which works differently from matching a complete regex
it's anchored to a position, and implicitly quantified externally, and returns its final position for the cursor
in my current view, yes, though derived support is fine
yes, where getitem returns the actual next object, even if it's a parcel
what you'd bind a positional to, normally
yes, they become identical, presumably
yes, the parcel boundaries have disappeared
sure
could naturally, though perhaps not efficiently, be done with gather/take on the underlying
I am leary of flags that have to be introspected these days  :)
it would seem that pushback should fall out naturally somehow, though if you want to push back a parcel, and the outer is assuming list, you could have a problem
as long as getitem can tell its caller that its iterator has mutated to one that supports pushback somehow
which kinda argues that they all should, so you don't have to have that as a requirement
that might be useful
well iterators are mutating anyway, so switch implementations on the fly could be okayish
*switching
with perhaps a hot-track for unpushed, non flattening iterators
but that's an optimizaiton
well, if it's good enough for getc  :)
switch vtables, and all that
maybe produce and producesome
and I'm still officially worried about serial assumptions :)
anyway, "gen" is too close to "get" visually
and as private-ish methods they want dehuffmanization
wonder how 'hyper' gets passed in
it seems to influence 'generate' more than 'getitem'
it's the generate that wants to distribute
that's .generatesome(n)
well, that's for another day, I expect
which isn't for another 17 minutes here
currently specced as EMTPY
only spelled right
is fine for now
I have to think about map sigs more, but that just shows up in to the iterator in which of those two are called
my engrish is rotting
still planning the demise of @@ in there as well, somehow
thanks for you patients
*your
the two are not mutually exclusive
well, my sole criterion is whether it's converging, not how fast
*I* didn't promise anything in April  :)
well, ** might indicate slurpy slice
really ought mean hyperflatten
*oughta
gha gotta goto bde sonn
well, |$x is availabe, and maybe ($x)
nighty night
yeah, if it doesn't interfer with what we have already there in sigs
zzz &amp; # thunk
Um
diakopter: don't index your hope meter to the 3rd derivative  :P
I'd like -Iter to be a productive suffix
hmm, we could even do Range-Iter, Seq-Iter and avoid Camel-Case
is fine
just didn't like that MyTypeIterator kept causing column overflow
yes, though it was kinda woggly there for a bit :)
had it as Iter for a while, then changed back
maybe not, but I wanted to name a role
something that hides an intrinsically flattenable object
it's pretty much a no-op
might go away
Parcel does
well, that one might go back the other way
was thinking of it more like Scalar[Seq], so maybe the Scalar container is in need of a handier name
what are you calling it currently
well, Ref is available :)
but maybe it means AntiIterable
comes back as ($x)
well, that's why we're splitting .list from .flat
$x.list wouldn't flatten now
that seems right
well, that's why .list is slightly different from a no-op, when there's only one thing
list($x) likewise
depends on $x
but should be same as $x.list by new def
yes
yes, list is no-op on a list :)
well, strictly, on a Parcel
correct
map {...}, $x
item($x).map
why wouldn't it?
I see what you're saing
y
the latter wants to be something more like $x.iterable seems like
or $x.unwrap, or some such
but I'd like to keep the notion of lists as orthogonal to the flattening decision as possible now
so .list is probably bad for that
don't see why we need an array
well, maybe list should do that, even for list($x), which would be a no-op
and we unwrap a $x elsewise
list would always be lazy context, flattening agnostic
the choice depends on the map's block's sig
likewise for for
list($x) wouldn't be a nop-op, it would be a trivial list
a Parcel, perhaps
kinda like (\($x)).foo
well, any item that isn't a Parcel is degenerate parcel
sounds good to a brane that is short on nutriments...
a non-degenerate Parcel sounds like a Ref
a Parcel that pretends it has multiple elements when it only has one
a way to defeat the auto-deref that usually happens
munchings and crunchings &amp;
and \$x creates a Parcel
captures are very minor in my mental picture, a last-minute optimization of parcels where we know we might want named params
inserts the pairs into the parcel, which might or might not promote to capture
I think it's supposed to, currently
making lunch, so distracted
$x could be a capture and do both
or a match
I think I like non-degenerate parcels
the fact that we're having to invent them to get around the degeneracy..
lunch &amp;
pmichaud: \$x can't be just parcel, or it won't protect from flattening, so that's gotta be a different indirection
ng: say Bool ~~ Int
that should be 1, since Bool is an enum
ng: enum X &lt;A B C&gt;; say A ~~ Int
ah :)
still, seems to me that Bool.Bool were missing, and properly a subset of Int, then it would have defaulted to Int.Bool rather than Mu.Bool
and Int.Bool would consider 1 to be true
and 0 false
but maybe that would break the circularity saw on booleans
no
vim syntax highlighting is cheating all over the place
masak: that would take a registry of all existing precedence levels to detect collisions, including any imported ones.
and I'm not sure it woudl DW most people M.
well, we could always add 'is tighterer' if it becomes and issue
but most people are simply going to alias to an existing level
so they can tell themselves "This is just like addition"
slight social stigmas a Perl culture speciality
TMTOWTDIWrong
ng: say Match.WHAT.perl
so to make diakopter's implicit question explicit, why is there a Regex:: on the front?
well, it's specced as just Match, and I'm wondering what the reasoning is.  we'll have to ask pm when he comes back
me2
rakudo: enum X &lt;a b c&gt;; say a ~~ Int; say True ~~ Int   # buglet
rakudo: say SAME ~~ Int
rakudo: say Same ~~ Int
rakudo: say Increasing ~~ Int
Increase is fine
I just couldn't remember the spec :)
enums are integers, generally
so it's a bit like asking Int ~~ Int
depending on how real you think the subtype is
yeah
well in any case, that was depending on a low level self == 0 test that can decode any integer including a boolean, which is unlikely (hence the circularity saw business)
somehow conditionals have to break the Bool.Bool returns a Bool problem
one way would be to return an int rather than an Int, maybe, assuming that conditionals can test a native int without calling .Bool
rakudo: say Finding ~~ Fixing
hmm
rakudo: say 2.Bool
rakudo: say Bool(2)
rakudo: say Order(1)
was just thinking Order() is potentially the same as sign()
jnthn: yes, one of the reasons we want to know all typenames in advance
indeed :)
is self.to -1 on a non-match?
rakudo: 'a' ~~ /b/; say $/.to
no, it's not -1 :)
rakudo: 'a' ~~ /b/; say $/.from
not gonna touch that one...
the meter limps
there is a distinct lack of grammatical parallelism between Increase and Same though
though as I recall, we picked Increase because it couldn't be read the other way: a is bigger than b
a mumble b --&gt; Increase is obviously b &gt; a
Downward,Same,Upward maybe
can be misready as a 'is more than' b
misread, even
Trend::Upward
if 2 values can make a trend...
but the graphical slope is a good way to disambiguate the metaphor, anyway
I doubt .isa should be in the business of anything other than introspection
.does really
since .does is supposed to encompass .is
at least I think it's still specced that way
it's a more specific test than ~~, so perhaps faster
and ~~ has to dispatch to ACCEPTS(Any:U:) before it can decide to do .does
though again, we know that types are types at compile time
so it could be optimized away
colomon: just pointing out that + and ~ are casts to roles, and maybe ? is similar
except there aren't a lot of Bool types
jnthn: I would expect it to return a Parcel, like pretty much anything else that can return a list
get 'em while they're young
also, to discourage curmudgeons who are too set in their ways to adapt.  :)
we're trying to discourage the formation of the type of high-priesthood that has developed in other communities
and it's not just 2 to 6 year old demographic, but the half of the population that aren't into chest thumping games
teletubbies are ugly
basically, in anthropological terms, we want to fix some of the bugs in current hacker culture too
we want to move away from being a Vulnerability as Weakness culture into more of a Vulnerability as Strength culture.
but that's what everyone else is doing. :)
simple is okay; we don't need flashy
anyway, we want to communicate simplicity
there's already far too much slick in the world
we'll do okay :)
nah, the ghost of Tolkien claims that large sequels only take 14 years
though the ghost of Moses keeps saying "I thought you said 40 years"
well, Perl 6 will be 16 in 2016, which is the usual age for a coming-out party...
though perhaps we could schedule a bat mitzvah in 2012
well, just mark it all as "post 6.0"
er, S11, actually
fired off those old octal neurons, did it? :)
other way around
the night is yet young
some people are easily amused
we can give you some great deals on S09!
only if you do it with the credit card we give you
(my %) % %3 probably
er
my *is* a declarator...
oh, it's the second one
er, third?
depending on how you count
presumably something like %($3)
well, STD doesn't actually care
it just assumes \d+ is a legal name to go after a sigil
well, it gives you a parse tree, but those don't ircify very well
you can get the parse tree if you run STD yerself
interesting, it returns the 3 as 'index'
yes, but you declared it as anonymous, so you have to declare it again
std: my &amp; &amp; my &amp;
fnerk
wow, a real STD buglette
so are taps, at the end of the day
std: my ($)
std: my ( $ where $ )
that message could be improved
actually, it couldn't find an existent sub
or it found a non-existent sub
but I'd settle for a simple "Couldn't find &amp;split"
std: $
std: my (IS $)
std: my ($ where $)
std: my &amp; &amp;&amp; my &amp;
it's possible that Inf should not be in any of Int/Num/Rat, but be a subtype of Numeric
it's currently Num for historical reasons having to do with IEEE floaters
but p6 is supposed to extend the idea of Inf to all numeric types (that aren't native)
mostly, we need to put it where it can be dispatched sanely without having a lot of strange 'if' statements here and there
but there's an argument that any values are allomorphic
42 is an integer, a real, a rational, etc.
don't want slick, I want cute :P
we can also dispatch on specific values
otoh, values are consider an extra constraint, so doesn't dispatch only on the nominal type
(whatever that type is)
just thinking maybe the nominal type of a constant might be possibly be a role like Numeric without committing to a storage type, as long as all such values are distinguishable without consulting the storage type
a variable must have a storage type
but these are constants
I don't have any fixed ideas on this, but it seems like something worth considering
is Inf-time sometime?
as for the bucket, NaNtucket.
the lunch bucket, that is
of course, if IEEE floaters do the right thing with these NaNnies, then maybe we can just go ahead and use Num for mixed-mode operations when it's needed
and then we dont have to write anything special for 'em
yes, Rats
ng: say (1/3).perl
ng: say 9 * 1/9
ng: say "yes" if 1/3 * 3 == 1
don't try that one in Perl 5
bet it doesn't work for other fractions
we don't have an IrRat type
powers of 2 should always work
maybe someone installed a fuzz onto == comparisons since I last looked
maybe they got tired of that FAQ :)
my brane is in sideways today due to a sinus infection, but it seems to me that a reducecheck is conservative, and can be generalized later if desired
It's not clear to me that 'my' returns a signature
though you still have :() =
returns Parcel, I think
I'm not sure we have to support assignment to any possible signature
I don't see why we have to support list assignment to a fancy signature
list assignment shouldn't have to worry about named parameters *at all*
yes
yes
reducecheck sez "Too fancy to assign to"
binding should work consistently, modulo rw concerns
same as parameter binding
as in, "oops, I got a Parcel, need a Capture, so .Capture it"
how the heck to you assign to a signature object?
*do you
if $sig = ... it replaces the sig
I suspect we can just outlaw that for now
we can do anything conservative we like, as long as it doesn't admit possiblities that will have to be outlawed later
pmichaud: I think that's different
sure, but it's probably declaring a $a and $b inside the sig and then throwning them away
I think that's even specced somewhere
it's the declarator that says *where* you're installing the new symbols
no declarator, no install
but sigs declare new variables, not referring to externals
so it all follows
probably the only weird thing left is actually ($a,$b) := ($b,$a) # no : on front
it's liek we need a way to promote a list of lvalues to a sig
*like
probably can be done at compile time
but it's also got to defeat the declaring of a new $a and $b
I think so
$foo := ($b,$a) is always going to clobber $foo itself, regardless of what's in $foo
well, it would be good to know at compile time that you can't say ($a,1,$b) := ($b,$a)
certainly Perl 5 takes the lvalue checks rather seriously
and knowing something's an lvalue has got to be good info for an optimizer
it promotes to something else then
an "lvalue parcel"
supersede ($a, $b) := ... should make for an explicit override of an existing declaration, maybe
std: supersede ($a, $b) := ...
arguably, that should complain that $a and $b are missing
std: supersede Foo
std: supersede $foo
hmm
well, maybe not supersede, we're mixing up composition-time declarations with other stuff
phenny: tell masak Note that TTAGGG is not generally rendered into amino acids, but "TTAGGG" x $n is the definition of a telomere.
well, vertebrates, anyway, plus some fungussesses
I don't think Parcel should promote to Capture in a scalar
it should promote when it's used as a parameter list in a binding
er, argument list
I've been digging them out whenever I've seen them, but they're a common as trilobytes
caveat implementor: I probably shouldn't be speccing while my cheekbone sinus is threatening to explode.
re pi, CORE.setting uses 3.14159_26535_89793_238, which limits the denominator to 1 quintillion for a Rat64 (not that we have those yet either)
you can set up your own FatRat pi then.
when the pie was opened, the rats began to sing...
look for "four and twenty blackbirds baked in a pie"
actually, it starts "Sing a song of sixpence, a pocket full of rye"
well, as far as I'm concerned, the first thing to do to all the Temporal type names is s/Temporal::/
that works too
and use O'clock for the time of day :)
it's just a civil time with less precision than Time
in p6, we can has Time == civil time
Instant means atomic time
O'clocks are actually durations from midnight
(relative to a timezone)
but anything common enough to be specced doesn't want to fall into the Give::Everything::A::Long::Name trap
oh, O'clock is a joke
but think about 3.O'clock.pm  :)
If you're gonna use Oclock, I'd rather have the apostrophe :)
ends up a Seq
sure
unlike Perl, we don't throw info away willy nilly
Perl 5
scalar assignment is more or less the same as binding to a scalar in type semantics, as far as the argument is contextualized
well, technically, a Match is supposed to behave more like a Capture than a Parcel
a common failing wrt retroprojects :P
colomon: see latest change to S02 wrt allomorphism of rat literals
s/change/changes/
need :
std: anon $myname = 42;
std: my $sub = anon sub Myself {...}
std: my $sub = anon sub myself {...}; myself();
no, it would not work for recursion
use $?ROUTINE for that
it's really for doc and errors
the name is in the object itself, if it cares
or you can't give run-time error messages
(with the name)
the name is not in the symbol table even at runtime
see myself above
the name is not in the symbol table even at compile time, I meant
we don't want people overriding metaoperators
anything that looks like a hyperoperator should be derived from the base operator by the standard metaop
well, technically you want a *$head
or an initial (1,2,3) won't flatten
oh, didn't see the []
that's okay then
though it'd work without the [] if you use *$
and then you could take foo(@a,@b)
which won't work with yours
.fmt('%x')
ng: say 52.fmt('%x')
aww
no beer for you
I got carded once when I was about 40
don't think would happen now though
no
have to use : form for that
otherwise too ambig with methods
what if you have a D4 method you want to call?
which reminds me, we should put a deadbeef method into Num :)
beats me, I'm just the language designer; I don't tell people how to use it
ng: say 0xdeadbeef.deadbeef
say Mu
ng: say 0xdeadbeef.?deadbeef
ng: my $result = 0xdeadbeef.?deadbeef; say $result
rakudo: my $result = 0xdeadbeef.?deadbeef; say $result
another case where rakudo returns a Failure that should probably just return Nil
I told it the call was optional
rakudo: my $result = 0xdeadbeef.*deadbeef; say $result
sure, though we could distinguish those in slice context, presumably
I prefer exceptions to be reserved for unexpected things
use of Failure as a normal return value is a design smell
basically, .* and by extension .? should return something sliceable to get the number of successful returns as subparcels
presumably
Parcel(Nil) is a real returned Nil, whille Nil is no parcels
masak: nodnod
I said it just for you :)
okay, we're both lousy liars.
the next best thing to being zero...
only for continuous functions; fortunately, Heisenberg seems to have solve that for the physical world, so that physicists can cancel their dx's and dy's
*solved
rakudo: say True !and True
rakudo: say True !&amp;&amp; True
rakudo: say True !?&amp; True
anyway, the ! metop is supposed to get you that already
*metaop
well, that's suboptimal :)
ng: say 1 !&amp;&amp; 1
we shouldn't generate on spec, mostly we should just do higher-order function calls
funny that % is considered iffy enough, but &amp;&amp; isn't
no, | is supposed to snapshot the current CaptureCursor, so you can have params before that advance the cursor
I suppose we could allow params after too if | is considered a zero-width parameter
we have to have the ability to have multiple CaptureCursors anyway
in theory, CaptureCursors would make that trivial
and also enable the correct binding semantics for grep etc
where correct means "non-introspectively"
that's what Pm-19 was all about
though it's only an approximation
but basically we have a way of binding that the incoming cursor knows that it's a submatch, and returns a new cursor somehow
you can tell how many things were bound by comparing before/after on cursors
ruoso and I were discussing this the other day too
http://irclog.perlgeek.de/search.pl?channel=perl6&amp;nick=&amp;q=CaptureCursor
I should probably update Pm-19 with something in terms of CaptureCursor
what do you mean by 'grammar tool'?
um, what do you think it's doing now?
STD.pm already uses operator precedence to parse Perl 6
sure, but somewhere you have to have a bottom-up parser installed in your grammar that can make use of it
that's EXPR in STD
precedence is just annotations on subrules that function as a lexer
any bottom-up parser or parser-generator could examine those precedence annotations and do something reasonable with 'em
though a parser-generator isn't very flexible
which is why STD doesn't
it's currently set by &lt;O()&gt; assertions in the respective operator rules
usually by reference to a set of predefined precedence hashes defined earlier
ash__: and metaoperators either pass through the precedence of the base operator, or impose a new precedence of their own
most parser generators would have difficulty dealing with such dynamic precedence, which is why we stick with simple operator precedence.
and because parser generators tend to give lousy error messages
the default is addition prec, which is left associative
see also S06:1791
ash__: most of the operator definitions in STD don't actually belong there, and will eventually move to CORE
yes
CORE.setting has stubs in the current STD directory
mostly to declare known type names, currently
STD implements the setting as an outer lexical scope, though rakudo hasn't got there yet
colomon: um, spec tests shouldn't be using implementation dependent features such as pir::
colomon: that's fine, it just needs to go at some point
Str.succ is not intended to produce values in lexicographic order, which is relatively useless in real life.  So we steal .succ (and ++) for "counting with carry" in customary ranges
but see S03:431 and following
actually, that section implies that .succ is not used for ++ on strings, hmm...
that's specced, though
see S03:2029
why would you want to in increment kana?
it's not like the codepoints follow the a,i,u,e,o song...  :)
you can still use it as a Range, as in testing cmp its endpoints
but cmp has nothing to do with .succ, really
yes, and then if you do something non-sensical, you get a lot of nonsense :)
the test is supposed to be !after, which matches eqv
or the other way around
anyway, a direct hit is suppose to stop it
if you increment Z, yes
but not if you use 'after'
S03:2051 is talking about you, the Astute Reader
oh wait, my lines are off, hang on
that may take a while to propagate through
after it does, the irclog will link to the line in the spec
the log is at http://irclog.perlgeek.de/perl6/today
for the moment you'll have to back up a page to find the paragraph with "astute reader"
dinner &amp;
you wanting hex?
looks like the S links have caught up with reality
LTA
setting
lexotic
phasers
unspace
feeds
sigspace, ratchet
captures, parcels
roles
junctions
shortnames/longnames
Christmas
but that's also Haskell
just like p5 list assignment
std: my $a; my @b; ($a, *@b) = &lt;1 2 3&gt;; say @b.perl
but it's an array
oh, wait, that's inside the french quotes
so yes
alpha is right
I was reading the [...] as OUTPUT delims
I'll learn this language someday...
party because [] used to be the OUTPUT delims, iirc
which is why we changed it
yeah, one dot is not enough to do that differently :)
though it's enough to do autoreversing
n8
but that won't work, since it uses 3 values
that is, 90, 100, 200 is going to confuse it
or maybe not, depend on whether the 2nd ... can actually see the earlier values
which in turn depends on whether it's right or left associative
and ... is defined as list associative, which doesn't help us :)
but it does mean we could probably force it to work with just 2 nums between the ...s
and you could force it the other way with parens
(1,2...9), 10, 20 ... 90  # second ... sees all lefthand numbers inluding 9
otoh, 9,10,20 is probably going to die if it can't intuit a function
I always like thos...
e
.oO(guess the next letter in the sequence...)
funny when a typo turns out self-referential
in the table, X operators are only right associative if the operator changes
otherwise it's like zip
dotdotdot(1,2; 10,20; 100,200; 900)
and the function can evaluate the lists however it sees fit
each of the sublists is independently lazy
which is good, since we can't evaluate a list on the left till we've evaluated at least one value of the next list to the right
and, of course, zip itself does them all in parallel
I'm almost getting to like this language
I have no idea why rakudo doesn't parse that
unless it's messed up on unicode
hah, groks arrows but not french hypers
.oO(doubtless implemented by a Texan...)
we are trying to keep Perl 6 in the latin-1 range
there will be modules, of course
\o/
that's techinically incorrect
that's how it's incorrect
according to S03:2040
maybe that one goes on forever :)
rakudo: say (5..'V').batch(50)
rakudo: say (5..'V').iterator.batch(50)
rakudo: say 'Z'...'Z'
rakudo: say 'Z'...'A'
('a'..'z').backflip
maybe that should invert the letters :)
pugs won't know about flip
that's Perl 5 semantics, but not Pelr 6
or Perl 6 either
snerk
if you want to confuse 'em...
rakudo: say 5....1
.1 is funner
beetchya
anyway, looks like rakudo doesn't grok 'when' as a statement mod, or doesn't allow if inside while
rakudo: say 42 if 43 while 0
rakudo: say 42 if 43 for 1..2
parsebug
another one of those p5isms...
can't do list comprehensions till we can nest ifs inside of fors
but that means python is better than perl...
rakudo: my $p = True; ($p and !$p) ~~ True ? say "The Explosion Theory has been proven by Perl6!" !! say "Darn";
rakudo: my $p = True; ($p and !$p) ~~ True ?? say "The Explosion Theory has been proven by Perl6!" !! say "Darn";
there you go
rakudo: our $queen is !amused;
std: our $queen is !amused;
ow
std: our $queen :!amused;
rakudo: say 1.ACCEPTS(False)
rakudo: say True.ACCEPTS(False)
rakudo: say True.ACCEPTS(0)
rakudo: say True.WHAT
rakudo: say Bool.ACCEPTS(42)
rakudo: say Bool.ACCEPTS(1)
very odd
rakudo: say False ~~ 42
rakudo: say (True and !True)
say 0 ~~ 42
rakudo: say 0 ~~ 42
there will be modules
modules are the answer
augment
seems like ~~ isn't autothreading right
did someone make its left arg a Mu?
unless ~~ is willing to handle junctions internally, it should be Any
or maybe it thinks it handles junctions internally, but Junction.Num doesn't autothread right
rakudo: say :1&lt;0000&gt;
rakudo: say :2&lt;0000&gt;
alpha: say :2&lt;0000&gt;
alpha: say :1&lt;0000&gt;
aww
rakudo: say "\x[40,40,40]"
you'd think it was friday night or somethin'
rakudo: say time.WHAT
spec says Rat, actually
troo
I'm not all, but hey back :)
'bout 3.2 meters
point being, you haven't specified your unit
just so
we mostly deal in fractions of a century here
oh, if Tolkien is any indication, 2014
but the parts that are already written are fun to read
he took 14 years to do his big sequel
rakudo: say (if $_ { 'fred' } else { 'bill' }) for 0..1
alpha: say (if $_ { 'fred' } else { 'bill' }) for 0..1
but we hope to have a usable Rakudo * out this spring
if not full-blown Perl 6
note inconsistencies or missing bits of the specs
write tests
write docs
just write something in Perl 6 and see what breaks, and report that
or if something doesn't feel right
watching how people do the learning curve is useful to us
if you're willing to report your difficulties
(other than that aren't really any good tutorials yet)
that's a known problem
well, the "Texas" versions are a concession to people who haven't figured out their compose key yet, or ^K in vim
but the little ones are generally construed as more readable
you can always increase the font size, like most of us do as we get older :)
or ; and :
or maybe it's a font issue
maybe your brain is hardwired for ASCII :)
maybe it's the size choice for constant width
because it's ugly
not for most of us
if you set up your UTF-8 locale okay
what kind of box are you running?
we have some OSX experts around here, but I'm not one of 'em
but seems to me it should be Unicode-awarable, at least
linux has little problem with UTF-8 locales
and certainly firefox seems to deal with unicode fine
anyway, eventually everything will be unicode-ish, but that's why we have &lt;&lt; and &gt;&gt; too
but especially in quoting things with &lt; and &gt;, you want something else
well, I suppose someone does, but it ain't me...
rakudo: my Any $chr = True &amp; False;
rakudo: my Mu $chr = True &amp; False;
rakudo: my $p=(True and !True); my $q=True|False; say $p ?^ $q
alpha: my $p=(True and !True); my $q=True|False; say $p ?^ $q
alpha: my $p=(True and !True); my $q=True|False; say $p ^^ $q
rakudo: my $p=(True and !True); my $q=True|False; say $p ^^ $q
rakudo: say 794243384928000/9192631770.nude&gt;&gt;.WHAT
rakudo: say 794243384928000/9192631770.perl
rakudo: 794243384928000/9192631770
the basic problem is that 794243384928000 is likely too big for rakudo to make a Rat out of
since it doesn't do bignum Int yet
rakudo: say 794243384928000.WHAT
say 794243384928000+1
rakudo say 794243384928000+1
rakudo: say 794243384928000+1
grr
rakudo: say (794243384928000+1).WHAT
see, it's complaining that it can't find Num div Int
because it's faking bigints with Num
well, it's specced to work right
and pugs still does better in that particular regard
rakudo: say time.WHAT
that's also not according to spec
Num is float, basically
though now that I glare at it, it appears someone took the types off of the definition of time(), grr
oh, there it is, it returns an Instant, as it should
and Instant is supposed to be a FatRat, if it needs the precision
or maybe internally it's a year's Int TAI seconds plus a Rat64 for offset within the year
last one looks right to me
hmm, thinking about 12.%x as an abbreviation
wouldn't interpolate though
$x.%x() seems odd
we want real printf formats
rakudo: say 12.fmt('%04x')
alpha: say 12.fmt('%04x')
you almost always want leading 0's
STD refuses to believe in Temporal::
readout?
the problem seems underspecified...
hmm
alpha: say localtime()
the Standard Perl 6 grammar
it's more or less part of the specs
yes, it can be used as a parser when translated gimme5
that's what std: is running
lemme know when you can run STD :)
Camelia doesn't believe in patronization...
Hey, no spoilers!!!!!
malfing
well, maybe some community with even less real life than ours has shut it down...
if we /kb dalek, does that ban everyone on feather?
dhaivat_: depends on what you're producing
maybe someone dropped a NOT somewhere
perhaps dalek's life is flashing before its eyes as it dies...
std: say 1.+(2)
std: say 1. + (2)
std: say 1.(2)
rakudo: say 1.(2)
this is why we don't allow 1. anymore
well, python doesn't have .+ methods
dalek went nuts last night, and has likely been discouraged
yes, xyz&lt;a b c&gt; is a bogus test
std: say ('"te ~st"' ~~ /&lt;["]&gt;[&lt;[\ ..~]-[\\"]&gt; | '\b'|'\a'|'\q'|'\g'|'\h'|'\s']+&lt;["]&gt;/) ?? 'got' !! 'not'
how can .Array and .Hash go away?  we have coercions to any type, and those are real types...
nod
Maybe we should rename Iterable to CanHazIterator
we don't want anyone spelling that word
in general, anything that hyperable probably wants to be represented internally as more-or-less balanced trees, according to Guy Steele
if you're gonna get anything out of hypering...
well, positional works too
but only with .elems
well, he's been working on a PGE clone, which isn't exactly perl6...
lejon: what do you want to know?
not quite
though we haven't tried recently :)
STD parsed nearly all the test suite, it just doesn't run it
rakudo parses less of it, but runs much of what it does parse
well, they call it grammar.pm
well, even STD.pm is only 5700 lines, and that's with a bunch of ops that should be in CORE instead
(which is what I'm working on currently btw)
pmichaud: Junction.Str is *not* supposed to autothread
pmichaud: if you bind an iterator to @, it should become something Positional with the iterator as its "extender"
interesting Q whether it should become Seq or Array though
depends on how rw distributes
but maybe rw is what we want
(to make an Array)
std: say (10.).WHAT
the "extender" part of a Seq or Array is still lazy
then it shifts them
I am vaguely here
well, if Int were really bigint...
it's always supposed to make a rat
unless there an e
spec says Rat64, but with a .Str that allows the whole thing, including conversion to FatRat
S02:3181
literals don't have to be fast
why?
they're our friends
there is no pecking order here
maybe Seqs are mutable/immutable in the same sense as Strs
so you could shift one, but the identity changes
perhaps we should stick with more of a p5ish model of mutability until we find the optimizer needs Seq and immutable Strs
then negotiate
maybe we somehow need to unify arrays and iterators, such that getarg is the same as shift
and since arrays track known/unknown
you don't get positional elements till you request them
and any shift on a pure iterator just pulls straight from the queue
haven't backlogged
it wouldn't, if that's considered a reifying operation
only shift consumes it
+@a would only copy the internal extender iterator into reified values, logically
evey array is a reified section plus an iterator
either of which can be empty
it is if you shift it
fundamentally unifies shift and getarg
so there is not getarg anymore
or getarg is shift, and get can unpack a 'sub-shift'
if everything is using the Array interface, it becomes simple again
@a is a lazy iterator thing returned by gather that knows the Array interface already
an iterator is just an array with no reified part (yet)
well, we still probably need the concept of getting an iterator from an iterable, but in this case it would present an Array interface as soon as it's an iterator
but I think shift is really getarg, and get can pull stuff out of @a[0]
maybe
could be the other way
I guess p5 is more get == shift
i.e. flattening
well, any binding of immutable to mutable either has to fail or copy somehow
maybe such a binding turns into assignment?
but you want to poke a RangeIterator into the Array imaginary bit
I think that's what we're being driven toward currently
and a Str is an Array of NFG chars, probably
presumably compact
I think it's okay to have intermediate lazy iterator types, as long as they're only ever hidden in the imaginary part of an array
from the standpoint of human engineering, I think that would be a win too
I shudder every time .WHAT returns GatherIterator
let's trying unifying them, then, and if it's the right decision, other things should get simpler, though Array itself has to always know both parts
same way?
yeah
we need to take the best parts about Arrays and Iterators and smush them together
and people who use +@array to mean ?@array will need to learn that ?@array doesn't have to count all the elements
whiel +@array does
*while
well, it's still the case that you usually just want to do what you're doing and check for Empty afterwards
and we haven't really solved the get vs getarg problem yet
don't think it can be that simple
param binding is currently defined in terms of get vs getarg on the same sequence
colomon: no, it tells that the array isn't empty
an empty array is defined
but false
have to go shower, but will think about shift vs flat/slice semantics
afk &amp;
no, if shift == get, then we don't have a problem with arrays keeping stuff around
no, we don't
unfortunately, can't talk right now...
we all already know where Perl 5 ought to be different :)
course, there are still parts of Perl 6 that ought to be different (I'm looking at you IO.pod)
do you still have a mail account at veradox?
% or !%
rakudo: say 15 !% 2
alpha: say 15 !% 2
class foo is visible only inside baz
std: package bar { class baz { class foo { }; say foo; }; say baz::foo; }
std: package bar { class baz { class foo { }; say foo; }; say bar::baz::foo; }
it's quite ironic that when an Olympic skier falls on the course, it's called DNF
I have to get up at 5am to see if I'm in a panel discussion...
not like that
you have to work harder to do symbolic lookups in Perl 6
but then there's no strict refs anymore
eval is never ideal :)
well, it was a killer feature in Perl 3 or so
but usually it's an escape valve indicating a missing feature elsewhere
we treat BEGIN the same say
and eval, in general, opens you up to all sorts of security problems, just like SQL injection
http://xkcd.com/327/
PerlJam: we don't, just the good ones.
don't photoshop the chess board, just photoshop me into xkcd :)
no, it's trapped in $!
how much memory do you have?
no need
0..^4 is already there
and doesn't use up two (count 'em *two*) brackets
mathematicians do many unforgiveable things as far as computers are concerned, and that's one of 'em
rakudo: say (0..Inf).batch(10)
rakudo: say (0..Inf).iterator.batch(10)
oughta do that automatically, methinks
rakudo: say (0...*).batch(10)
that one works
no
good morning
who's winning?
hah, I beat pmichaud
OH HAI PEEPS!!!
hah, beat pmichaud++ again on !!!
aww
but correctly, that's another matter...
Perl 6 is trying to beat everyone to everything, more or less...
jnthn++ is always scary
rakudo: say "scary" but True
alpha: say "scary" but True
well, at least it's a different error now...
or, maybe, it was a different error then...
uh, no
only 'foo' is aliased
looks like it's getting the wrong $a to me
($a isn't a parameter though)
it does at that
std: sub foo() { my $a = 2; our sub bar($x where $a) { say $x } }; bar(2);
STD might actually be looking up $a starting inside the inner sub's scope
in fact, it has to, in case it's an earlier parameter
std: sub foo() { my $a = 2; our sub bar($x where $x) { say $a } }; bar(2);
so it sounds like it's splitting a hair that doesn't need splitting
I don't have a parameter block, I just use the one that will end up inside {}
scared me, thought it was christmas already
*++
rakudo: say grep *++, 1,2,3
rakudo: my @foo = 1,2,3; say grep *++, @foo
maybe not
rakudo: say (*++).WHAT
I think the answer is no
alpha: say (*++).WHAT
alpha: my @foo = 1,2,3; say grep *++, @foo
alpha: my @foo = 1,2,3; say grep ++*, @foo
alpha: my @foo = 1,2,3; say map ++*, @foo
er...
alpha: my @foo = 1,2,3; say map +*, @foo
well, gee, the spec generalized it to all unaries and binaries, what, a whole week ago.  why isn't it done yet?  esp in alpha, that had a month head start...
but not to ternery  :)
all ops except those that declare they will do it themselves
which Range will
proto infix:&lt;..&gt; ($min, $max) is like(Whatever-and-stuff) {...}
where "stuff" is WhateverCode
:)
S02:936
to cause jan to fall :)
which might still be related to "fallen" if you go back
where's my AmHer...
felon was "yellow" or "bile" in I-E
good question
I dunno
'course, 'round here people pronounce it Vietnamese, which doesn't rhyme
if we did, we'd probably have to make Whatever a kind of junctional, outside-of-any type
but instead of autothreading, autocurry
yes, but without writing out the actual subs
hm!
hm?
.(3) oughta autothread over that, ya'd think
what's my brane doing all over the room in bits?
#= is already dead, as far as I'm concerned
hmm
the presence of {*} almost always indicates the need to refactor
STD hasn't used {*} for months
well, we can still have an action call, but {*} #= won't be it, I suspect
see &lt;O()&gt;
oh, I had a problem with &lt;O()&gt; last night, thinking about default parse rules
suppose we make the body of a proto be the default
we get
proto token infix is binary is defequiv(%additive) { &lt;sym&gt; &lt;O(|%additive)&gt; }
but then the O is wrong if they 'is equiv' it
that's redundant, if we put the &lt;O&gt;
proto token infix is binary { &lt;sym&gt; &lt;O(|%additive)&gt; }
or
proto token infix is binary is defequiv(%additive) { &lt;sym&gt; &lt;O(*)&gt; }
but still not sure that the body of the proto is the right place for a default "is parsed"
it's a *handy* place tho
s/new/newish/
my problem on the proto body is that we also currently write the &lt;infix&gt; dispatch using the same name, so we'd essentially be ignoring the given body and substituting the dispatcher, and only using the proto body for the generic 'is parsed'
jnthn++ has a fail fail
does that make it a fail fail fail?
cheezburgerz
speaking of which, the sky is starting to get light here
yeah, I saw they took the slot for something else
ISFINE
was planning to spend the weekend several TZ to the east of here anyway, so as not to miss all the hackathon
luv 2 scare dey little newbies way
yes, well, I can read Russian till the time comes to understand it
I'm only playing for one, but I play twice as loud, since I'm the drummer.
I'd be terrified if I met a butterfly with a 3 meter wingspan...
or was it 5?
mebbe she grew
she's young, after all
colomon: just play it like a conga
my boy don't take much watchin' anymore
he'll proably sleep the night through, and then some...
b
rakudo: use Test; my @a = 2,3; is(@a, [2,3])
probably from back when lists promoted to arrays
yeah, unless we change our minds again :)
S03:3105
grr
S02:3105
sb Seq
WHAT!
no, that one is ++jnthn
now fix the rest of 'em before we ask :P
I think it has to be a spec error
--gen-parrot
um
std: try { more perfect }; say "see?"
well, now, whose fault is that?
oh, okay
chroolie
o\
that's what the metaop is supposed to do
S03:3927
rakudo: say 1,2 X 3,4
rakudo: say 1,2 Z 3,4
odd that X isn't there but Z is
rakudo: say 1,2 X+ 3,4
what, for implementing Z
:
:)
we all have our faults
rakudo: my $a = 3; say (~$a).WHAT
interestingly, had the same bug in Perl 5 once upon a time
you implement interpolation with infix:&lt;~&gt;, but forget the degenerate case
er, not Perl 5, Perl 1 or so... :)
um, are any of those coding tools?
depending on your location, the main thing you need for this hackathon might be an alarm clock :)
lue: there are no .even/.odd methods
there are already lots of ways to spell even and odd in Perl
$x % 2, $x +&amp; 1
rakudo: say 3 % 2, 3 +&amp; 1
there's two different odd functions
!% 2 is even
rakudo: 3 !% 2
but nyri
alpha 3 !% 2
alpha: 3 !% 2
alpha: say 3 !% 2
!% means "is not indivisibly by"
s/y/e/
or "does not have a remainder"
it means "is divisible by!"
not exactly
it's a higher-order function
so they don't need to be generated, just composed with 'not'
likewise (we hope) for all the other metaops
we can't generate XRS[!%]= in advance
(and we might add a Z for zipwith)
so anyway, the code emitter just has to turn the base op into &amp;infix:&lt;op&gt; or whatever, and then pass it to the right higher-order function (reduce, zip, not, whatever)
put STD's metaop parsing into rakudo
(just kidding...kinda)
alpha: say 3 R/ 30
R/ is pronounced "goes into"  :)
it's handled specially in STD, actually, at the end of infixish
line 3172 or so
but it's the only one that is handled after the fact
for the others, see things like     token infix_prefix_meta_operator:sym&lt;!&gt; {
i've never had trouble with ff on perlcabal, fyi...
memory issue?
hibot!
couldn't you just be m*bot or some such
oh, I was going to suggest one here
OH HAI OH
OH HAI OH GOES EYE MOOSE
Grimnir_: mostly just made sure that it's easy to express various sorts of parallelism naturally, and then let the computer figure it out
various constructs make various promises about not-caring about interactions
hyperops are basically vector ops
feed operators are pipes
junctional logic can be evaluated in any order
Grimnir_: your parens were not function call parens, unlike in perl 5
yes
it's strange, but it's one of the most used functions in p6
yes
rakudo: print "foo"
rakudo: say "foo"
should be a little NL or some such
if your terminal does utf-8 right
that's what?
lol
masak: it seems to me that it's a binding, not an assignment
so no, it's not unreasonable :)
otoh, jnthn may be right about the OO semantics :)
otgh, maybe it copies in values but [...] is an object, so gets the same one
no, usually it's cooler :P
picnic cooler, even
without looking, I assume it's taking hte first elem as the pivot
we could .pick a random pivot though, which would work better for a presorted list on average
or .pick(3).mid
rakudo: say [max](1..5)
wants a closure first
there is no mid
but if there were, it would be between min and max :)
rakudo: (1..5).minmax
rakudo: (1..5).minmax.say
rakudo: (1..5).minmax.average  :)
rakudo: (1..5).minmax.sum.say
if it's bleeding, it might be a red herring
the scales would be in tuna, I suppose
they make me sing bass, but I'm really a barracuda
er
put it on ice, and ship it
well of course you couldn't find it--it's non-existent, duh!
you should look for an existent sub
std: 1 !&amp;&amp; 3
hmm, thought that one was too fiddly
or not iffy enough
std: multi sub infix:&lt; &gt;($a,$b){say "oh hello $a and $b";}; say 5 4;
it means there's no such thing as a null infix operator in Perl 6
it won't let you
it if it could, I wouldn't tell you how
because it's very, very, very, very important to Perl 6 to know whether it's expecting a term or an infix
so it can catch most errors
except for the double negative :)
maybe we could add in a "noway, nohow"
I'm just gonna keep carping till someone does...
diakopter: I'm ignoring you.  :)
japanese input, yum
quick, talk about lue
or make a cheese pun
yes, well, add_macro is all chewing gum and bailing wire, and I don't feel obligated to make it a real thing just yet
and I'm not /ignoring him, just ignoring him.  :)
okay, it's kleenex and scotch tape then.
that's more like rakudo of wind
wind's rakudo
is an etha like a metha or a propa?
maybe it prevents insecure people from using it
lessee, if I'm really about 3 or 4 TZ east of here, I should take a geezer nap now.
zzz &amp;
baest: actually, qw// should also still work; &lt;&gt; is just the shortcut, like '' and q// still both work
rakudo: say qw/foo bar/
std: say qw/foo bar/
define blazing
with a decent jit it might go fast, but parrot's jit has suffered repeated bitrot
yes, well, you're talking NCI there, not parrot, currently
NCI is an API, not an engine
it's like asking what's faster, an elevator, or an elevator door?
has nothing to do with p6
it's a category error
APIs and oranges
in any case, that's a severe architecture dependency
APIs and O()-ranges
&lt;O&gt; sets the actual precedence on the token we're returning
the arg to EXPR is a cap on how tight we require the precedence to be
in this subexpressoin
ion
that's how we stop on the comma when you say my $a = 1, 2
k23z__: but feel free to work on it yourself :D
for permuting integers, that'll likely be faster than anything you could write in p6
at least, until rakudo gets native ints
I hope p6's mechanism is far, far better than XSW
XS
and it should be possible to specify APIs from the Perl side, so you don't have to write grotty glue code
(see XS)
the hard work is getting the arguments in and out
for any two well-defined languages, we should be able to come up with a well-defined implementation-independent interface
and the fact is, when I hooked Perl 5 up to Java, I found Java supplied sufficient type info to do that, even though Perl didn't.
and that's one of the reasons Perl now has better type info
perl6: say "hi, k23z__!"
there's at last three
but not mildew or sprixel
doesn't mean someone won't pick it up again and run with it either
now he'll probably brag he got kicked out of #perl6 :)
I think k23z__ isn't sure himself
masak didn't say he thought you said that.  :P
ain't communication wunnerful
now you tell us
no, you just said you thought he wasn't, you didn't say he'd convinced you of it :)
hi, k23z__
nuclear blackmail? then stay away, by all means
take your marbles and run while you can
actually, I think moritz++ has the right idea
people who paint a target on their backs usually turn out to be poisonous
or acted hurt
yes, but you have puppy eyes, so it's easy
diakopter: it's a possibility
but I was serious in suggesting that some people have aspects of both t*-ness and non-t*ness simultaneously
and may not have it all sorted out
every community has to include helpful people, and exclude destructive people, and the really, really hard part of that is a given person can be both
lue: Camelia tells us we have to know how to be nice to all kinds of people.  She very carefully doesn't say we always have to be.  :)
where's hugme when you need it
sometimes Camelia is subtle :)
sigh, there seems to be a pervasive assumption on the part of test suite writers that undefined types and functions are merely run-time errors...
they keep testing it with dies_ok
\o
well, best we can do at the moment is eval_dies_ok
to do better would either require separate files that are tested to destruction, or more cooperation from the parser to tell it that, say, the following line shouldn't compile, but start up again on the line after
one problem with eval is that it can't test that something fails in the same scope
rakudo: say 1i * 1i
rakudo: say sqrt(1i * 1i)
rakudo: say sqrt(-1)
rakudo: say sqrt(-1+0i)**2
rakudo: multi sub sqrt(Real $x) { return sqrt($x+0i) }; say sqrt(-1)
rakudo: multi sub sqrt(Num $x) { return sqrt($x+0i) }; say sqrt(-1)
rakudo: multi sub sqrt(Int $x) { return sqrt($x+0i) }; say sqrt(-1)
rakudo: multi sub sqrt(Num $x) { return sqrt($x+0i) }; say sqrt(-1e0)
oughta work
alpha: multi sub sqrt(Num $x) { return sqrt($x+0i) }; say sqrt(-1e0)
just a regression
but the point is, the default behavior is easy to override
if you want sqrt to promote reals to complex
** is only approximate; probably done with logs
usually math packages trap **Int and just optimize to multiplication, but obviously not here
if it did that optimizaiton, it'd get the exact result:
rakudo: say sqrt(1i * 1i)
rakudo: say 1i * 1i
like that
rakudo: say (1i * 1i) ** 0.5
same problem in reverse
we try to keep reals real, and complexes complex, to preserve sanity of people with poor imaginations
'course, just having negatives would drive your average Roman nuts
the flip side of easy type widening is having to decide when it's reasonable to unwiden, which is a much harder issue
my Num $x = (0+1i)**2;  # does this throw away the tiny imaginary part?
so generally better to stick to complex consistently once you get there, and try not to go there accidentally
likewise for FatRat
rakudo: say (1+0i).WHAT
hence we can have sqrt do mind reading based on the input type
lue:  not if it means action at a distance
it's okay in a lexical scope though
sure
use .re and .im
yeah, well, it's a tradeoff; the fact that we're talking to you means we're not actually working on it...
rakudo: say (1,1,{$^a+$^b}...*)[10]
rakudo: say (1,2,4...*)[10]
rakudo: say (1,2,4...*).batch(10)
rakudo: say ~(1,2,4...*).batch(10)
rakudo: say ~(1,1, {$^a+$^b}...*).batch(10)
though colomon did arity-2 from remarks earlier
*thought
ah
rakudo: say [(1,2,4...*).batch(10)][9]
rakudo: say [(1,2,4...*).batch(11)][10]
there we go :)
but bare [10] should work
methinks
meaning a subscript should promote an iterator to a Seq
rakudo: say ~[\+] (1,2,4...*).batch(10)
alpha: say ~[\+] (1,2,4...1024)
hmm
alpha: say ~[\+] (1,2,4,*...1024)
alpha: say ~[+] (1,2,4...1024)
std: say ~[\+] (1,2,4...*).batch(10)
std sez you *can* backslash that :)
alpha: say ~[\+] 1,2,4,8,16,32
pugs: say ~[\+] 1,2,4,8,16,32
pugs: say ~[\+] 1,3,5,7,9,11.13
pugs: say ~[\+] 1,3,5,7,9,11,13
pugs likes it...
alpha: say [+] 1,2,3
I thought alpha did reductions alreaqdy
alpha: say [*] 1,2,3
alpha: say [\*] 1,2,3,4,5
returns all the intermediate result
which usually makes it look like a triangle :)
hence the visual metaphor of |\
0
rakudo: say [*] ^5
rakudo doesn't parse reduce yet, so it thinks its an array of Whatever
alpha: say [*] ^5  # 0
0 times anything is 0
rakudo won't parse any reduce yet
alpha will parse some of htem
*them even
std will parse all of them, but not do them :)
perl6: say [\*] 1,2,3,4,5
pugs ftw
that's more or less equivalent to 'core dump'
but less friendly, since you don't actually get a core dump
if it's trivial we might already have it, but the volleyball principle says better too many going for the ball than too few
masak usually just copy/pastes some trials from the evalbot on irc
if you can reproduce it here as a one-liner
rakudo: say Foo::x
hmm
std: say Foo::x
odd, maybe server is overloaded
odd, maybe server is overloaded
std: say Foo::x
rakudo: say Foo::x
rakudo: say Foo
rakudo: say Int::x
I daresay someone didn't check a return value for error somewhere
maybe they should rewrite rakudo in Perl 6  :)
std: say Int::x
std: class Foo {}; say Foo::x
you can file it
std: class Foo {}; say Foo::&lt;$x&gt;
std: class Foo {}; say Foo::&lt;&amp;x&gt;
looks up &amp;x in the Foo package
but it doesn't reject it because Foo is modifiable at run-time, so someone might add a &amp;f to it
Foo::&lt;$x&gt; is the same as $Foo::x in p5
you can also use that syntax in p6
std: class Foo {}; say $Foo::x
no
package vars are basically run-time lookups
we only complain about lexical vars, types, and functions at compile time
but unlike in p5 foo() is always compile-time lookup
if there's no foo defined lexically by the end of the file, it fails
std: foo 1,2,3; sub foo {...}
std: foo 1,2,3;
or in the terms masak was using earlier today, we know the $Foo::x symbol, but we don't necessarily no the container or value at compile time
*know
o/
std: our $y; { { GLOBAL::&lt;$y&gt; }; my $y }
std: our $y; { { UNIT::&lt;$y&gt; }; my $y }
std: our $y; { { $y }; my $y }
std: my $y; { { $y }; my $y }
if you sent to rakudobug it should be fine
hmm
um, at least three of the last four shoulda failed...
ah, caught rakudo doing run-time lookups on things known at compile time
well, bedtime
zzz &amp;
hmm
STD doesn't care about that yet
it will eventually
\o/
rakudo: (1,2,4...*)[10]
rakudo: say (1,2,4...*)[10]
rakudo: say ~(1,2,4...*).batch(10)[^10]
rakudo: say ~(1,2,4...*)[^10]
maybe that's trying to eagerify the list
rakudo: say ~(1,2,4...*).Array.[^10]
rakudo: say ~(1,2,4...*).Seq.[^10]
nope
rakudo: say ~[(1,2,4...*)][^10]
S03:1814
more specifically, S03:1896
and yes, it was considered whether to intuit more serieseses than that, and we decided not to
eventually fibonacci is just:
rakudo: say ~(1,1,*+*...*).batch(10)
but I don't think rakudo turns the 2nd * into $^b yet
rakudo doesn't parse reduce ops yet
so it's parsing it like this:
std: say [1] ("' ello " xx 5)
obviously not a kitten from her majesty's commonwealth...
unless british lolcat misspells words americanly...  :)
you can also haz Aermicanization fail
I noticed
you mean a mixture of the three
str: y///
std: y///
ETOOIMPATIENT
leaky abstraction...
std: y///
std: tr!a-z!A-Z!
just make it capricious and arbitrary, and no one will know the difference
	Global
`s`	Focus search bar
`?`	Bring up this help dialog
	GitHub
`g` `p`	Go to pull requests
`g` `i`	go to github issues (only if github is preferred repository)
	POD
`g` `a`	Go to author
`g` `c`	Go to changes
`g` `i`	Go to issues
`g` `d`	Go to dist
`g` `r`	Go to repository/SCM
`g` `s`	Go to source
`g` `b`	Go to file browse
	Search terms
module: (e.g. module:Plugin)
distribution: (e.g. distribution:Dancer auth)
author: (e.g. author:SONGMU Redis)
version: (e.g. version:1.00)