view release on metacpan or  search on metacpan

t/lib/Hailo/Test/TimToady.trn  view on Meta::CPAN

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:<===>.
I think infix:<===> 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:<as> 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:<as> 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 <@list>, of course, but the eventual plan is not to use <@list> at all, but exclusively magical <%hash>, or at least to the extent possible.
.oO(That was almost English...)
Basically, a good <%hash> 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 categori...
one way or other.
gotta run&
gabor529_: eventually <a a b c>.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