view release on metacpan or  search on metacpan

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

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:<..>(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 &
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.
==> and <== 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 &
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 &
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 &
: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

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

afk &
I doubt there's anything not related to Perl 6.
lichtkind: maybe--we could define { => } 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 => $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 => $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 { $_ => 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 &
@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 wi...
@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:
------> "$" ";"
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:
------>     my @arr[-->Num] = <1 2.1 3.2>;
and -->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 n...
sub postfix:<!> 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:<!> in its own definition
a related interesting problem is that if we introduce infix:<foo> 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:<x> 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 declaratio...
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=<1 2 3 4 5>; say @a;
Limbic_Region: pong
well, pugs actually has it right :)
but in general, :foo<bar baz> is short for :foo{'bar', 'baz'}
or maybe :foo['bar', 'baz'] really
but the question is whether the [] is constructed by the infix:<,>, which I suspect it is