view release on metacpan or  search on metacpan

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

well, I have to run off for most of the day.
As an option, though, a Latin-1 would work along with ". ".
ta &
something that wouldn't be wanted for infix!!!!
really &
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 <|> 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 [ <simple_space> | <comment> ]* 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 <%.foo|%.bar> 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 <%foo|%bar> 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 <%.foo|%.bar>.
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?
*<%foo>
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 <%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 <=> 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 &
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.