view release on metacpan or  search on metacpan

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

Sure, and @$x is appealing to the ref.  :)
another ident lookahead for :<  or :{ maybe?  Hmm..
basically infix:<+> 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 => rule to \h* if unlimited lookahead is problematic
the latter
the :< :{ 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&
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 <space>{ 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&
the bottom-up parse has to parameterizable for terminators.  <expectop>{ is just the terminator
I mean <space>{
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 <ws> 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<> 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.

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

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 &
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 ...
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<Fido> } 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.