svn switch --relocate svn.openfoundry.org/pugs svn.pugscode.org/pugs/ | run.pugscode.org | spec.pugscode.org | paste: sial.org/pbot/perl6 | pugs.blogs.com
Set by avar on 16 November 2006.
00:23 Limbic_Region joined
wolverian is v6-KindaPerl6/docs/FAQ.pod supposed to be, uh, POD? I can translate it to POD if so, or rename it to something else if not 00:24
00:29 pjcj joined 00:59 explorer joined, devogon joined 01:05 lyokato joined, b00t joined 01:17 ashelyb_ joined
Teratogen I use rot13 01:20
01:35 bonesss joined 01:42 reZo joined 01:47 rashakil joined 02:10 stevan_ joined 02:15 mncharity joined, mncharity is now known as putter
putter fglock: ping? 02:16
Ziggy6: re "i will probably commit the whole thing when it's good enough to replace v6-MiniPerl6 or nothing at all", I note the official religion has been "commit early, commit often", and that my own experience, repeatedly deviating from that, is that I always regret it afterward... 02:20
ingy hi mcharity 02:21
:P
Teratogen ingy Ingy INGY!
putter hi ingy
ingy hihihi
putter Ziggy6: re parsing, spec is (or was the last time I looked) that p6 has a sandwich parser - top-down down to expressions (and statements?), then an operator precedence parser, which assembles terms, where the terms are top down. So top-down, bottom-up, and top-down again. 02:24
Existing implementations taking that approach have been parrot, one of fglock's creations (lrep??), and redsix.
pugs's parsing predates this story, so it's due of a bit of overhaul after the next major rev. (the next rev is oo, the one after that rules and such). 02:26
re creating a new emitter for the regexp compiler, you might look at misc/pX/Common/Regexp-Engine-Reentrant/ , especially Backtrack.pm, or perhaps at misc/pX/Common/Regexp-Parser-ReentrantEngine/ . 02:33
they are quite fast. 02:34
Ziggy6 putter: thanks for the pointers 02:42
02:43 luqui joined 02:53 kanru joined
putter np. nice to see @fglock forming :) 02:53
02:54 neonse left
putter fglock: re left-recursion, yes - the spec p6 rules engine is a "general parser", so both left and right recursive grammars should work fine. 03:03
I expect trie optimization will also end up spec, so people don't feel obliged to hand rewrite top-down grammars into LR grammars. 03:04
eg e = e|e rather than e = e_with_no_| '|' e 03:05
or something vaguely like that 03:06
Ziggy6: re mp6 parsing speed, the real objective is to run kp6 fast. fglock said he thought kp6 might be capable of running on pugs, not just mp6. it might be worth trying.... 03:15
luqui putter, re: p6 rules spec as a "general parser" 03:18
where is this specced?
I thought it was specced as LL
03:24 SamB joined
Ziggy6 hmm, yes, maybe it's easier to fix pugs to run kp6 03:26
03:45 weinig is now known as weinig|zZz 03:51 vel joined
putter luqui: re LL, good god I hope not. I've had quite enough decades now of "rewrite the grammar to match the parser engine" hell. 03:52
luqui okay, but I'm asking about spec 03:53
I mean, that may be hell
but how do we implement a left-recursive grammar in a predictive engine?
Ziggy6 i think left-recursion can be automatically eliminated 03:54
luqui if all you have is a pure context-free grammar, then yes
but if you have data-dependent rules, then you cannot
Ziggy6 what do you mean by "data dependent?" 03:55
03:55 vel joined
luqui <somerule> <someotherrule: $<somerule>> 03:55
for example
putter I almost pointed Ziggy6 at this earlier today. It's the kind of thing I envision p6 getting: jp.franz.com/base/seminar/2004-06-1...anz-e1.pdf 03:56
luqui looking
(however, the left-associative lambda transform is something that is worth including as a convenience feature, to make writing grammars which are essentially left-recursive easier) 03:57
putter GP are now well understood tech. you decouple grammar ("policy") from engine ("implementation"). Engine's choice of parser tech, for any particular part of the requested grammar, it its own business. And purely an optimization issue. 03:58
luqui it'd be neat to look into the optimizations that that presentation mentions more 03:59
again, you can only do data-dependent grammars top-down 04:00
it is definitely desirable to decouple policy from implementation 04:01
but we lose a lot of freedom by doing that
putter what "freedom"?
luqui for the third time, data-dependent grammars
unless you're saying "we'll look, and if it is essentially context-free, then we can compile to LR" 04:02
putter I do not believe "you can only do data-dependent grammars top-down" is correct.
the key being that
the entire grammar does not have to be treated homogenously 04:03
luqui I believe the rule: rule foo { <foo> <{ f($<foo>) }> }
(oh, add an | something at the end of that) 04:04
is essentially undecidable
hmm, an earley parser could do it
so I suppose i am wrong
04:04 lambdabot joined
luqui however, in the absence of an earley parser, how would you transform that rule into something parsable? 04:05
putter it is the regexp compiler's task to recognize DFA, LL, LR, packrat, etc, etc, subparts of the requested regexp/grammar, and optimize them accordingly.
luqui so, be the regexp compiler for a sec, and do foo
ooh yes, an earley parser can't even do this one: rule foo { <foo> <{ f($<foo>) }> | <null> } 04:08
04:09 mako132_ joined
Ziggy6 that's not context-free... 04:13
luqui of course not, that's the point 04:14
if perl 6 rules were strictly context-free, then putters comments would be spot-on 04:15
putter hmm, is <foo> <{ f($<foo>) }> well defined? "The closure is guaranteed to be run at the canonical time.". with |<null> one could use pos=0. but without it, can one legally call f? not even a junction pos would be sufficient. maybe one could modify the guarentee that it is called in the cannonical place, or STM-wise (software transaction memory), the call is guarenteed to be later aborted?
s/the call is/the universe of the call is/ 04:16
04:16 nipra joined
putter I suppose one might sometimes be able to do special case analysis of f. but not in general obviously. 04:16
luqui nobody is solving the halting problem :-) 04:17
so treat f as a black box :-)
if there is no | <null> then the grammar cannot scan and <foo> will never be matched 04:18
but I beleive that that is a "bad grammar" in some sense 04:19
putter well, if one relaxes the guarantee, then it's just a constraint satisfaction problem.
though a constraint satisfaction engine is perhaps a little beyond what I was thinking of for a GP domain... 04:20
;)
luqui I think we should stick to predictive LL (with longest-token semantics, hopefully sane ones (crosses fingers)), and optimize on top of that 04:22
allowing engines not to optimize if they don't wish to 04:23
putter actually, that's not a bad grammar, as long as... hmm... (1) f can't tell how deep the rule call is, and (2) f can't modify the running grammar. after all, in the absence of constraint satisfaction, the <null> branch would eventually have to be taken (forced by the "canonical" guarantee). no?
luqui I don't know what this canonical guarantee is 04:24
putter "The closure is guaranteed to be run at the canonical time."
luqui which is defined as what?
putter well, for example, pos is constrained to be non-arbitrary.
luqui (but I realize that my example, can, again, in fact, be done by an earley parser ;-) 04:25
I'm still not quite sure what you mean.
So by that you mean that .pos must be accessible and actually represent something when f() is called
putter can it...? (be done by an earley)
luqui yeah
oh, as long as | <null> is there 04:26
the set is: foo ::= * foo f($<foo>) ; foo ::= * null ; scan to: foo ::= * null ; complete to: foo ::= foo * f($<foo>) ; then hand f the set of values from the completion, namely <null> 04:27
then proceed, and as long as f($<null>) can be matched, we will finish
04:27 justatheory joined
putter the pos f sees at call time must define a substring (pos at foo start to pos at f call) for which f would return a regexp which succeeds. (I'm dealing with the no-<null> case). can one do that without analysis of f? 04:28
luqui er, the scan to clause sould be: foo ::= null *
04:29 justatheory joined
luqui without null, I don't believe you can do anything 04:30
but I can't prove that just yet
putter erases example of f which with constraint satisfaction yada yada 04:31
but this is all rather OT, no? 04:32
luqui well, not entirely
Ziggy6 OT = ?
luqui it is a proof that there are some grammars which you can't transform to something matchable
Ziggy6 offtopic?
luqui Ziggy6, yes
luqui finds it interesting that OT could also me on-topic 04:33
*main
putter the point is the universe is full of very nice well defined LL and LR and lots of other grammars already written. it would be a continuation of great sillyness to require people to hand edit them in order for them to be used with the p6 engine.
luqui *mean
oh, that's a good point. if you wanted to parse C with perl, you'd have to do some trickiness
because the BNF the spec provides wouldn't run
putter (actually with backtracking you don't need trickiness, but that's beside the point...:) 04:34
luqui how so?
how can you do a left-recursive grammar with backtracking?
putter if nothing else, depth constraints. if a token follows the recursion, by token occurance counting. 04:35
luqui oh, depth constraints. incredibly, incredibly slow, but indeed doable
putter C isn't actually ambiguous in the identifier/type choice. you just can decide LR. 04:36
luqui I think your "token occurance counting" will end up reducing to earley...
putter s/can/can't/
luqui in the general case, that is 04:37
putter goes to remind himself how early works... parser theory, blech....
luqui earley is a very cool algorithm
quite simple
luqui wrote the wikipedia page on it ;-)
Ziggy6 i'm still unclear how can you parse context-dependent grammars with an algorithm that need a context-free one 04:38
putter just read :)
is someone saying you can...? 04:40
Khisanth ?eval @a = (1, 2); @b = (@a, 3, 4);
luqui Ziggy6, top-down algorithms usually have straightforward generalizations to certain non-context-free grammars (context-dependence is defined differently)
evalbot_r15138 [1, 2, 3, 4]
luqui context-dependence is when you can have multiple nonterminals on the left side of ::=
which we're not talking about ...
putter re "incredibly, incredibly slow, but indeed doable", not with a packrat parser. or indeed, any parser bright enough to memoize its work. no? 04:42
besides which, from a user standpoint, the difference between "runs slowly" and "doesn't run, so study parser theory and carefully edit, or find yourself another tool" is really really big. 04:43
Khisanth ?eval @a = (1, 2); @b = (@a; 3, 4); 04:44
evalbot_r15138 Error: ā¤Unexpected ";"ā¤expecting "::", term postfix, operator or ")"
luqui that's true. packrat isn't in my "working vocabulary" of parsers
but I do know how it works
you make a good point...
so if we want to do this, we have to be *very* precise about semantics in the spec
putter yes 04:45
luqui handwaving and saying "the compiler will make it work" won't suffice with multiple backends
and we have to double-check that the semantics we specify are, in fact, possible
(and reasonable)
but I would be totally down with doing that part in p6-on-p6 04:46
Khisanth ?eval @a = (1, 2); @@b = (@a; 3, 4);
evalbot_r15138 Error: ā¤Unexpected ";"ā¤expecting "::", term postfix, operator or ")"
luqui because I dig writing parsers :-)
Khisanth hrm
putter lol
:)
though you raise an interesting question. to what extent should performance be spec'ed.
luqui it's reasonable to think that a fast grammar in one place should be a fast one elsewhere, too 04:47
but I'm usually in the camp of performance should not be specced
Ziggy6 Perl6 itself is context-free?
luqui Ziggy6, definitely not 04:48
perl 6 is undecidable at compile time :-)
(something that other compilers run screaming away from, but we take in stride)
putter well, but the core language grammar itself, if the user does not modify it, is indeed intended to be single token lookahead, no? 04:49
Khisanth putter: "must not be slower than p5" :)
putter lol
Ziggy6 ah, by undecidable you mean the fact that you can change the grammar?
luqui putter, uh, I think so, but I wouldn't be surprised if something in the spec presently violates that
putter Ziggy6: I think that's right 04:50
luqui Ziggy6, no, I mean that it might never finish compiling
Ziggy6 you could write an infinite loop in a begin block... :) 04:51
luqui but the fact that you can change the grammar (even by such innocuous things like my infix:<@@> (...) {...}) makes it non-context-free
putter audreyt would know the current state of the LR(1) effort. the pugs parser was being used to drive it. my fuzzy recollection, at least of a while ago, was it was down to just a couple of cases.
s/LR(1)/single token lookahead/ 04:52
luqui LL(1) probably
putter s/cases/cases where more was needed/ 04:53
luqui are they just trying to remove all the trys from Parser.hs
or reimplement the grammar elsewhere?
putter trys
luqui cool
that will improve error messages vastly as well
putter this was months ago. i've no idea current state, or if things have changed, or... 04:54
luqui: actually, the example you gave wouldn't change context-free-ness would it? expressions, to which infix:<@@> would apply, are already an operator precedence parser. 04:55
the opp is serves as a tokenizer, and thus doesn't affect the grammar. 04:56
my statement:frobnitz ...; could however.
luqui oh, so @@ would come in as a nonterminal like OPERATOR o rsomething...
and then the opp specifies precedence, too, by pseudo OPEN and CLOSE tokens or something? 04:57
(I'm not really sure how the opp can be considered a tokenizer, but I admit the possibility)
putter the top-down grammar just sees an incoming <expr>. the opp eats input text until its happy.
luqui i'm not sure whether you can use "eats input text until its happy" as an argument for perl 6 being a context-free language 04:58
putter the top half of the sandwich sees the opp as part of its lexer.
luqui suffice to say that perl 6 is "piecewise context-free", if you admit my infix:<@@> 04:59
putter umm....
luqui travels home & 05:01
putter the top half of the sandwich, the main top down parser, which we are trying to make XX(1), doesn't care what operators get defined. it just sees an EXPR token. the opp sandwich filler is never context-free. and the bottom layer of the sandwich, the expr and other tokens, are unaffected by a new token being introduced. so infix:foo just doesnt affect CF-ness. no? 05:02
s/the expr and other tokens/the tokens (for expr or not)/ 05:03
05:04 leed joined
Ziggy6 why isn't the opp CF? 05:04
putter err, because operator precedence parsers are the ultimate in "you don't necessarily know what you've got until you hit the end of the input stream"? ;) 05:05
Ziggy6: re OT, yes. re BEGIN loop, indeed. I myself am greatly looking forward to ... { use CommonLisp::Instead; (defun foo ...) } ... { use NowHowsaboutSomeRuby; ... } 05:06
Ziggy6 :) 05:08
perl6 will become the borg of languages :)
putter one thing I'm concerned about vis opp, is that without backtracking being allowed (the opp, last I heard, was specced as eat as much as possible), one has to take care in creating operators that you don't create ambiguity regards the "end of expr, now back to the top-down grammar". I think I'd be happier if ambiguities were permitted to be backtracked over. 05:10
rather than simply causing a parsefail.
but we'll see whether it actually turns out to be a problem.
re borg, oh yeah. 05:11
the OperatorPrecedenceParser in redsix.... ah, well, not that readable. though in part because we have a rather complex opp concept. tokens which can only appear following whitespace, or can't, or etc. 05:15
but better to took at something simpler someplace first.
Ziggy6 pugs has opp? 05:16
putter no
Ziggy6 what's wrong with it's parser? 05:17
putter pugs?
Ziggy6 yes
putter i don't understand. "what's wrong with"?
luqui wrote en.wikipedia.org/wiki/Operator-precedence_parser
05:17 reZo joined
Ziggy6 i've seen some criticism (i don't remember where) that pugs' parser isn't flexible enough 05:18
s/flexible/mainanable/ 05:19
maintainable*
putter pugs, in a great many respects, not just parsing, is the prototype which drove the spec. it's now a bit behind the spec on how parsing works. updating it is the major rev after next. just as this major rev is updating is oo. 05:21
s/is oo/its oo/
pugs is always either a head of, in sync with, or behind the spec of the moment. <-- content free sentence :) 05:22
there might be an approximation like "big components" start out ahead, and eventually fall behind, until they get overhauled, but small stuff can stay in sync. 05:23
pugs's parser is sort of the haskell magic version of yacc+lex. 05:24
Ziggy6 i'm still undecided what should i learn/hack first... too many interesting things in this project :) 05:25
putter yeah. I started drawing my project graph in the hope of figuring out what the critical path was... I'm afraid I still don't think I have a handle on it. 05:27
If you can support audreyt, financially or otherwise, *that's* critical path.
other than that... fglock's ealier list seemed plausible... 05:28
writing in p6, on pugs, to flesh out kp6 or get to work on chuncks of 6-on-6, could be a way to go. 05:30
though it tends to generate throw-away code 05:31
Ziggy6 i guess it's okay, because i can learn faster perl6 and understand the challenges involved... it will take a while before i can contribuite something usefull to the critical path 05:33
putter once the oo ast is speced, even before pugs actually uses it, parts of the critical path become p6 ast classes, yaml io for them, a compiler framework (kp6?), and emiters. 05:35
a p6 runtime and prelude (basic classes) is probably something which can be worked on right now. 05:36
getting pugs to _use_ such a prelude is difficult, but simply writing it to run _on_ pugs, and by asking questions, drive the specification, is defintiely something to consider working on 05:37
at least some parts of it. some parts are tied to the mop (metaobject protocol), or require digging into pugs primitives (doable, but less straightforward).. 05:39
the mop is, like the oo ast, still a work in progress.
part the project's current difficulty is that unless you take on parsing, which is very nontrivial to do broadly, until pugs can provide oo ast instead of the current non-oo ast, it's hard to right the downstream stuff because there's not much to exercise it. 05:42
s/right/write/
one could do a regex engine in p6 05:43
if one believes the oo ast won't be along for a while, one could do a p6 version of PIL2JS. much of pil2js is already p6. so one could convert its js and p5 to p6. done well, that would be the foundation for p6-on-p6. 05:45
much of the PIL1 handling would be throw-away. 05:46
but, it would work...
it might be interesting to spend a day looking a pil2js internals. it's rather nicely done. could use fixing the mising 'cond', which currently has it broken, as a motivator 05:47
05:47 jamhed joined
putter is still looking for a graph visualization package which can handle the complexity of pugs project planing...:) tulip is kind of nice, but buggy, and still not quite what's needed. :/ 05:48
wolverian putter, graphviz? 05:49
Ziggy6 is there any book on compilers for dynamic languages?
putter re graphvis, I really want to have subgraphs, whose nodes are shared with the supergraph, which have their own layout policies. 05:50
re dynamic languages... 05:51
05:51 miyagawa joined
putter hmm, have you seen the READmumble files in pugs/ ? 05:51
Ziggy6: you know lambdatheultimate? 05:52
lambda-the-ultimate.org/ would be a good place to grovel around. 05:53
lambdabot Title: Lambda the Ultimate | Programming Languages Weblog
putter both for papers, and pointers to books 05:54
could add ones you find helpful to READTOO
searching LtU for "compilers" is fun. here is one hit lambda-the-ultimate.org/node/1752 06:00
lambdabot Title: An Incremental Approach to Compiler Construction | Lambda the Ultimate
Ziggy6 nice :) 06:02
almost makes me anbandon perl6 and get back to lisp 06:03
putter { use Language::Scheme::DialectX::Here; .... } 06:06
06:07 Southen joined
putter it dialect support ends up being good, p6 might be the easiest place to do scheme development... 06:07
be a while before we can compete with SBCL for CL though.
Ziggy6 i don't like clisp, it has a lot of weird functions and types. if i could access perl's classes from scheme... :) 06:09
06:12 Ziggy6 is now known as ZiggyAway 06:14 BooK_ joined 06:15 miyagawa joined
putter Inline::Guile? Guile? 06:23
search.cpan.org/~mstrout/Guile-0.002/Guile.pm
lambdabot Title: Guile - Perl interface to the Guile Scheme interpreter. - search.cpan.org
putter search.cpan.org/~samtregar/Inline-G...1/Guile.pm
lambdabot Title: Inline::Guile - Inline module for the GNU Guile Scheme interpreter - search.cpan ...
putter if you were looking for a scheme task, it might be feasible to convert www.ccs.neu.edu/home/dorai/scmxlate...xlate.html 's scm2cl to create a scm2pl5 or scm2pl6. 06:25
lambdabot Title: scmxlate
06:27 miyagawa joined 06:39 miyagawa joined
putter good night & 06:41
svnbot6 r15139 | putter++ | Unfinished smoke support for redsix.
r15139 | putter++ | I find myself vaguely considering using redsix. And any p6 implementation someone is considering using, should be wired up for testing.
r15139 | putter++ | This patch adds -Bredsix support to pugs, and makefile support for test-redsix and smoke-redsix.
r15139 | putter++ | Remaining to be done is run-smoke.pl support, and getting redsix to load its custom Test.pm.
r15139 | putter++ | Once you install ruby 1.9 head... you can watch redsix... crash it. :/
r15139 | putter++ | Perhaps I'll finish up later, when it can actually be run.
r15139 | putter++ | Perhaps by digging up an old ruby 1.9 snapshot from svn.
jamessan tpope: /join #vim 06:46
bah
06:51 lisppaste3 joined 07:12 marmic joined 07:16 bsb left 07:17 nipra joined 07:42 ZiggyAway is now known as Ziggy6 07:59 drrho joined 08:10 iblechbot joined 08:15 luqui joined
Ziggy6 started re-learning haskell 08:16
luqui had to learn it about three times to get comfortable with it 08:18
allbery_b has not had any trouble adapting to it 08:20
of course I had my brain warped by APL in 1981 and J in 1985/6
luqui allbery_b, had you done pure (or almost pure) functional programming before?
08:21 araujo joined
allbery_b (neither of which is pue but bth of which can be used functionally) 08:21
luqui there are two big hurdles in haskell:
(1) learning to think functionally
which I had done before, but only minimally, using lisp
(2) learning to use monads
allbery_b purity wasn't anything. laziness took some getting used t
luqui the lazy aspect came pretty naturally to me 08:22
allbery_b monads were a problem for me until I (a) worked out how things actually worked with >>= / return instead of do; (b) read
@go you could have invented monads
lambdabot sigfpe.blogspot.com/2006/08/you-cou...s-and.html
Title: A Neighborhood of Infinity: You Could Have Invented Monads! (And Maybe You Alrea ...
Ziggy6 how does @go work?
allbery_b short for @google 08:23
@help google
lambdabot google <expr>. Search google and show url of first hit
Ziggy6 nice
i've read something about monads, even used them a little, but still couldn't understand the magic that makes things like backtracking work 08:24
luqui Ziggy6, you mean with the list monad? 08:25
Ziggy6 yes
luqui backtracking in the list monad is an effect of both the workings of the list monad and the laziness of the language
if you were to implement the list monad in a strict language
it would try all possibilities in parallel, not backtracking
but the list monad is a great example; I recommend trying to wrap your head around it 08:26
(from its definition)
try not to think about laziness for now
(it's much simpler, at least in my opinion, than the state monad, which is used often in introductions) 08:27
Ziggy6 as a side question: what tools do you use when you work on pugs? 08:33
make fast, ghci, hugs?
luqui no, just make
it's usually fast enough for me
(though when you're not so familiar with haskell, and nine in ten changes gives you a type error, maybe it's not fast enough)
at the first pugs hackathon I was in this state
and it was not very productive
make + vim + hasktags
08:33 Ziggy6_ joined
Ziggy6_ when you hack on pugs, which tools do you use? hugs or ghci or make fast && ./pugs? 08:33
luqui did you miss my response?
Ziggy6_ sorry, power failure
ah
i can see it in the logs now :)
08:39 Ziggy6_ is now known as Ziggy, Ziggy is now known as Ziggy6 08:41 devogon joined
Debolaz2 GAH 08:52
pugs got the wrong install prefix. :-( 08:53
Debolaz2 will have to do a lot of manual cleanup now.
Debolaz2 really wish it didn't default to wherever perl is installed. 08:54
luqui where do you wish it defaulted to 08:55
Debolaz2 /usr/local is what most people assume is the default installation directory.
Ziggy6 agrees 08:56
luqui seems reasonable
maybe it's a windows compat thing, er... 08:57
08:59 elmex joined
Debolaz2 Hrmm, still not possible to set a custom prefix with pugs. :-( 09:08
09:13 andara joined 10:07 chris2 joined 10:12 ruoso joined 10:25 cdfh_ joined, fglock joined 10:32 avar joined
pasteling "fglock" at 201.35.169.13 pasted "syntax proposal: longest token matching with hash/pair notation" (14 lines, 343B) at sial.org/pbot/22596 10:32
fglock TimToady: please check sial.org/pbot/22596 10:33
lambdabot Title: Paste #22596 from "fglock" at 201.35.169.13
luqui a way to specify what part of a rule you consider a token? 10:35
fglock luqui: yes 10:37
luqui what happens when you don't have a => in an alt?
it's all a token, none of it's a token, or it dwims?
(hmm, the second one seems unlikely :-) 10:38
fglock the same as if it were a hash constructor, I think - it is read as <token> => <null>
luqui ohk 10:39
fglock or a syntax error
hmm - token => null is more useful 10:40
luqui oh I see where you're going with this
kind of a local thing, rather than a solution to the longest token issue on the table at the moment
(maybe it's only on my table) 10:41
fglock each alternation is first compiled as a hash - then you have an algorithm that chooses the longest token in the hashes
longest token in the hash keys 10:42
luqui shorthand for <%foo> notation, instead of <%(...)>, I suppose 10:43
fglock like the old <%h1|%h2> 10:44
luqui wasn't around for that ket notation
fglock it was the previous proposal before <%h1> | <%h2> 10:45
luqui ahh
10:59 marcususesthis joined
fglock wolverian: re POD - please do - documents marked with POD actually have no formatting 11:56
12:17 DebolazX joined 12:18 kanru joined 12:25 explorer joined 12:26 tifo joined 12:31 tifo joined
tifo \bye 12:32
12:33 buetow joined, capixaba joined 12:35 bonesss joined 12:41 rafl joined 12:56 nipra joined 12:57 diakopter joined 13:01 BooK joined 13:02 spo0nman joined 13:21 Limbic_Region joined 13:22 iblechbot joined 13:36 VanilleBert joined 13:46 weinig|zZz is now known as weinig|away 13:53 ofer0 joined 13:57 dduncan left 13:59 ofer0 joined 14:02 ruoso joined 14:12 kisu joined 14:20 VanilleBert left 14:24 spinclad joined 14:43 vel joined 14:46 stevan__ joined 14:52 GabrielVieira joined 14:57 stevan__ is now known as stevan 15:07 c6rbon joined 15:15 fglock joined 15:20 TimToady joined 15:38 cdpruden joined 15:45 hexmode joined 15:47 shafire joined 15:49 shafire left 15:54 weinig|away is now known as weinig 16:00 nipra joined 16:05 lisppaste3 joined 16:08 rindolf joined 16:10 spinclad joined 16:23 cognominal joined 16:26 Limbic_Region joined
TimToady fglock: your => seems identical to my :: 16:27
fglock TimToady: yes, I noticed just after I wrote it 16:33
allbery_b thinks :: used fglock's way looks rather Haskell-ish, you may take that as positive or negative as you wish :) 16:35
fglock I liked it because it resembles hash x pair
TimToady unfortunately = is not a reserved char 16:37
[particle] thinks :: looks more at home in a regex
TimToady part of why we use := for named captures 16:38
16:47 Ziggy6 left 16:53 nipra joined, avar joined 16:57 andara left 17:21 nipra joined 17:55 xinming_ joined 18:00 Limbic_Region joined 18:01 bernhard joined 18:05 nipra joined 18:06 justatheory joined 18:07 neonse joined 18:41 VanilleBert joined
VanilleBert hmm, das mit PM-fĆ¼r-Datenschutztag-schreiben ist ja kein groƟer Renner: 16 abrufe... 3-4 von mir :D 18:42
sry, wrong chat
oO 18:43
18:43 ludan joined 19:09 VanilleBert left 19:35 nipra joined 19:47 rindolf joined
rindolf Hi all. 19:47
20:09 weinig is now known as weinig|bbl 20:21 justatheory joined 20:29 mugwump joined 20:49 pjcj joined 21:02 _bernhard joined 21:03 justatheory joined 21:05 Aankhen`` joined 21:06 lambdabot joined 21:14 weinig|bbl is now known as weinig 21:37 GabrielVieira2 joined 21:38 __Ace__ joined
__Ace__ I just come to think about this XS... what is going to happen with that in Perl6? 21:38
anything easier?
21:40 Ziggy6 joined
[particle] parrot has nci, which is much easier than xs 21:42
as far as perl 6 is concerned, there hasn't been a spec yet
__Ace__ time to wiki nci then..
hmm. en.wikipedia.org/wiki/National_Cancer_Institute 21:43
cant be right
[particle] try googling for parrot nci or native call interface
22:26 devogon joined 22:37 pjcj joined 22:41 devogon joined 22:44 AStorm joined, AStorm left 22:46 nipra joined 22:47 dduncan joined 22:49 ingy joined 23:11 Psyche^ joined 23:18 Limbic_Region joined 23:25 mako132_ joined, Psyche^ is now known as Patterner 23:27 jdv79 joined
Ziggy6 ?eval {random_name => 1} 23:30
23:30 evalbot_r15138 is now known as evalbot_r15139
evalbot_r15139 ("random_name" => 1) 23:30
Ziggy6 ?eval {state => 1}
evalbot_r15139 Error: ā¤Unexpected "=>"ā¤expecting formal parameter, context or "("
Ziggy6 is this a bug, or a feature?
[particle] state declares a type of variable, like my 23:31
?eval state $foo = 1 23:32
evalbot_r15139 \1
[particle] so it's a reserved word, and you'll have to quote it
23:33 ruz joined
Ziggy6 ah, thanks :) 23:35
TimToady that is a bug in pugs
=> is supposed to quote even reserved words 23:36
[particle] oh? nice. 23:37
TimToady but it's admitedly problematic to find a solution that doesn't involve strewing => after every possible keyword
23:39 luqui joined
jdv79 what happened to the pugs blog? its gettin stale:( 23:39
23:39 justatheory joined
TimToady I believe that what happened was a combination of relocation, earthquake, family emergency and ADD. :) 23:44
[particle] don't forget christmas 23:45
(but not that christmas)
diakopter and cocooning
TimToady That's the ghost of Chrismas future...
jdv79 oh, that sucks. thanks for the 411 though.
TimToady but we all ebb and flow, and the tide will come in again... 23:46
diakopter perhaps the tsunami is building
[particle] hrmm... those sound like good names for perl 6 ops
23:47 Schwern joined
[particle] $tide.ebb 23:47
schwern?!?!
23:47 Aankh|Clone joined
TimToady maybe it was an accident? 23:47
Schwern What 23:48
TimToady or maybe we did something nekulturny
[particle] your presence has been noticed
TimToady or maybe he was just caught lurqueing
Schwern Great, what do I win?
[particle] socks with bananas on 'em. got any? 23:49
Schwern As a matter of fact I do. I'll take the cash prize instead.
PerlJam TimToady: Did your brain gurgitate enough on the smooth or chunky thread?
TimToady still gurgling
it won't be ];[, I can assure you. :) 23:50
PerlJam heh, that's good to know :)
TimToady that's one I actually though of myself and didn't bother to put...
[particle] thanks for avoiding the butterfly effect
TimToady *thought
[particle] how about using :ebb and :flow ?? 23:51
TimToady both of those sound kinda smooth to me
more like :aa vs :pahoihoi
jdv79 some p6's got nuts, some don't?
[particle] :almond_joy vs :mounds ? 23:52
timtoady: it's more deep vs shallow, donchathink?
PerlJam Well, it's a lot easier to smooth out chunks if you have them than to magically know what chunking is appropriate when you've been given somethign smooth. So, if we can somehow make chunking the default with a smoothing op, that seems like it should work.
TimToady one could go scatalogical, since English provides both mass and count nouns...
PerlJam (but what do I know, I'm not a language designer :-)
TimToady more like deep and not-quite-as-deep 23:54
PerlJam The only reason I mention it is that people seem to be focusing on a "chunking op" in that thread.
TimToady since it just ignores []ness at the top level 23:55
23:56 mncharity joined, mncharity is now known as putter
TimToady as I said, most languages would just always return chunky, but Perlers are used to their autoflattening of the top level, and would probably rebel at having to specify it explicitly. 23:57
and we're trying to deal with dimensional syntax and multiple pipes and various related things 23:58
and we'd like to be able to multislice with infix:<;> 23:59

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!