view release on metacpan or  search on metacpan

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

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 &
will try it here.
removing if x -> $y {...} seems to have made no difference at all.
@tell audreyt removing if x -> $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 &
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<foo>, :no<bar>
import to nowhere...
does Mammal[:no<placenta>]
: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 <%foo|%bar|%baz> 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.  &
*will
have the appropriate amount of fun...
have a smooth sequence...
&
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.