Camelia, the Perl 6 bug

IRC log for #perl6, 2007-01-24

Perl 6 | Reference Documentation | Rakudo | Niecza | Specs

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:23 Limbic_Region joined perl6
00:24 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:29 pjcj joined perl6
00:59 explorer joined perl6
00:59 devogon joined perl6
01:05 lyokato joined perl6
01:05 b00t joined perl6
01:17 ashelyb_ joined perl6
01:20 Teratogen I use rot13
01:35 bonesss joined perl6
01:42 reZo joined perl6
01:47 rashakil joined perl6
02:10 stevan_ joined perl6
02:15 mncharity joined perl6
02:15 mncharity is now known as putter
02:16 putter fglock: ping?
02:20 putter 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:21 ingy hi mcharity
02:21 ingy :P
02:21 Teratogen ingy Ingy INGY!
02:21 putter hi ingy
02:21 ingy hihihi
02:24 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 putter Existing implementations taking that approach have been parrot, one of fglock's creations (lrep??), and redsix.
02:26 putter 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:33 putter 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:34 putter they are quite fast.
02:42 Ziggy6 putter: thanks for the pointers
02:43 luqui joined perl6
02:53 kanru joined perl6
02:53 putter np.  nice to see @fglock forming :)
02:54 neonse left perl6
03:03 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:04 putter 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:05 putter eg e = e|e rather than e = e_with_no_| '|' e
03:06 putter or something vaguely like that
03:15 putter 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:18 luqui putter, re: p6 rules spec as a "general parser"
03:18 luqui where is this specced?
03:18 luqui I thought it was specced as LL
03:24 SamB joined perl6
03:26 Ziggy6 hmm, yes, maybe it's easier to fix pugs to run kp6
03:45 weinig is now known as weinig|zZz
03:51 vel joined perl6
03:52 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:53 luqui okay, but I'm asking about spec
03:53 luqui I mean, that may be hell
03:53 luqui but how do we implement a left-recursive grammar in a predictive engine?
03:54 Ziggy6 i think left-recursion can be automatically eliminated
03:54 luqui if all you have is a pure context-free grammar, then yes
03:54 luqui but if you have data-dependent rules, then you cannot
03:55 Ziggy6 what do you mean by "data dependent?"
03:55 vel joined perl6
03:55 luqui <somerule> <someotherrule: $<somerule>>
03:55 luqui for example
03:56 putter I almost pointed Ziggy6 at this earlier today.  It's the kind of thing I envision p6 getting:  http://jp.franz.com/base/sem​inar/2004-06-10/Franz-e1.pdf
03:56 luqui looking
03:57 luqui (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:58 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:59 luqui it'd be neat to look into the optimizations that that presentation mentions more
04:00 luqui again, you can only do data-dependent grammars top-down
04:01 luqui it is definitely desirable to decouple policy from implementation
04:01 luqui but we lose a lot of freedom by doing that
04:01 putter what "freedom"?
04:01 luqui for the third time, data-dependent grammars
04:02 luqui 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.
04:02 putter the key being that
04:03 putter the entire grammar does not have to be treated homogenously
04:03 luqui I believe the rule: rule foo { <foo> <{ f($<foo>) }> }
04:04 luqui (oh, add an | something at the end of that)
04:04 luqui is essentially undecidable
04:04 luqui hmm, an earley parser could do it
04:04 luqui so I suppose i am wrong
04:04 lambdabot joined perl6
04:05 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.
04:05 luqui so, be the regexp compiler for a sec, and do foo
04:08 luqui ooh yes, an earley parser can't even do this one:  rule foo { <foo> <{ f($<foo>) }> | <null> }
04:09 mako132_ joined perl6
04:13 Ziggy6 that's not context-free...
04:14 luqui of course not, that's the point
04:15 luqui 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?
04:16 putter s/the call is/the universe of the call is/
04:16 nipra joined perl6
04:16 putter I suppose one might sometimes be able to do special case analysis of f.  but not in general obviously.
04:17 luqui nobody is solving the halting problem :-)
04:17 luqui so treat f as a black box :-)
04:18 luqui if there is no | <null> then the grammar cannot scan and <foo> will never be matched
04:19 luqui 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.
04:20 putter though a constraint satisfaction engine is perhaps a little beyond what I was thinking of for a GP domain...
04:20 putter ;)
04:22 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:23 luqui 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?
04:24 luqui I don't know what this canonical guarantee is
04:24 putter "The closure is guaranteed to be run at the canonical time."
04:24 luqui which is defined as what?
04:24 putter well, for example, pos is constrained to be non-arbitrary.
04:25 luqui (but I realize that my example, can, again, in fact, be done by an earley parser ;-)
04:25 luqui I'm still not quite sure what you mean.
04:25 luqui So by that you mean that .pos must be accessible and actually represent something when f() is called
04:25 putter can it...? (be done by an earley)
04:25 luqui yeah
04:26 luqui oh, as long as | <null> is there
04:27 luqui 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 luqui then proceed, and as long as f($<null>) can be matched, we will finish
04:27 justatheory joined perl6
04:28 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 perl6
04:30 luqui without null, I don't believe you can do anything
04:30 luqui but I can't prove that just yet
04:31 * putter erases example of f which with constraint satisfaction yada yada
04:32 putter but this is all rather OT, no?
04:32 luqui well, not entirely
04:32 Ziggy6 OT = ?
04:32 luqui it is a proof that there are some grammars which you can't transform to something matchable
04:32 Ziggy6 offtopic?
04:32 luqui Ziggy6, yes
04:33 * luqui finds it interesting that OT could also me on-topic
04:33 luqui *main
04:33 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.
04:33 luqui *mean
04:33 luqui oh, that's a good point.  if you wanted to parse C with perl, you'd have to do some trickiness
04:33 luqui because the BNF the spec provides wouldn't run
04:34 putter (actually with backtracking you don't need trickiness, but that's beside the point...:)
04:34 luqui how so?
04:34 luqui how can you do a left-recursive grammar with backtracking?
04:35 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
04:36 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...
04:36 putter s/can/can't/
04:37 luqui in the general case, that is
04:37 * putter goes to remind himself how early works... parser theory, blech....
04:37 luqui earley is a very cool algorithm
04:37 luqui quite simple
04:37 * luqui wrote the wikipedia page on it ;-)
04:38 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 :)
04:40 putter is someone saying you can...?
04:40 Khisanth ?eval @a = (1, 2); @b = (@a, 3, 4);
04:40 luqui Ziggy6, top-down algorithms usually have straightforward generalizations to certain non-context-free grammars (context-dependence is defined differently)
04:40 evalbot_r15138 [1, 2, 3, 4]
04:40 luqui context-dependence is when you can have multiple nonterminals on the left side of ::=
04:40 luqui which we're not talking about ...
04:42 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:43 putter 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:44 Khisanth ?eval @a = (1, 2); @b = (@a; 3, 4);
04:44 evalbot_r15138 Error: ␤Unexpected ";"␤expecting "::", term postfix, operator or ")"
04:44 luqui that's true.  packrat isn't in my "working vocabulary" of parsers
04:44 luqui but I do know how it works
04:44 luqui you make a good point...
04:44 luqui so if we want to do this, we have to be *very* precise about semantics in the spec
04:45 putter yes
04:45 luqui handwaving and saying "the compiler will make it work" won't suffice with multiple backends
04:45 luqui and we have to double-check that the semantics we specify are, in fact, possible
04:45 luqui (and reasonable)
04:46 luqui 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);
04:46 evalbot_r15138 Error: ␤Unexpected ";"␤expecting "::", term postfix, operator or ")"
04:46 luqui because I dig writing parsers :-)
04:46 Khisanth hrm
04:46 putter lol
04:46 putter :)
04:46 putter though you raise an interesting question.  to what extent should performance be spec'ed.
04:47 luqui it's reasonable to think that a fast grammar in one place should be a fast one elsewhere, too
04:47 luqui but I'm usually in the camp of performance should not be specced
04:47 Ziggy6 Perl6 itself is context-free?
04:48 luqui Ziggy6, definitely not
04:48 luqui perl 6 is undecidable at compile time :-)
04:48 luqui (something that other compilers run screaming away from, but we take in stride)
04:49 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" :)
04:49 putter lol
04:49 Ziggy6 ah, by undecidable you mean the fact that you can change the grammar?
04:49 luqui putter, uh, I think so, but I wouldn't be surprised if something in the spec presently violates that
04:50 putter Ziggy6: I think that's right
04:50 luqui Ziggy6, no, I mean that it might never finish compiling
04:51 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
04:51 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.
04:52 putter s/LR(1)/single token lookahead/
04:52 luqui LL(1) probably
04:53 putter s/cases/cases where more was needed/
04:53 luqui are they just trying to remove all the trys from Parser.hs
04:53 luqui or reimplement the grammar elsewhere?
04:53 putter trys
04:53 luqui cool
04:53 luqui that will improve error messages vastly as well
04:54 putter this was months ago.  i've no idea current state, or if things have changed, or...
04:55 putter 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:56 putter the opp is serves as a tokenizer, and thus doesn't affect the grammar.
04:56 putter my statement:frobnitz ...;  could however.
04:56 luqui oh, so @@ would come in as a nonterminal like OPERATOR o rsomething...
04:57 luqui and then the opp specifies precedence, too, by pseudo OPEN and CLOSE tokens or something?
04:57 luqui (I'm not really sure how the opp can be considered a tokenizer, but I admit the possibility)
04:57 putter the top-down grammar just sees an incoming <expr>.  the opp eats input text until its happy.
04:58 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.
04:59 luqui suffice to say that perl 6 is "piecewise context-free", if you admit my infix:<@@>
04:59 putter umm....
05:01 * luqui travels home &
05:02 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:03 putter s/the expr and other tokens/the tokens (for expr or not)/
05:04 leed joined perl6
05:04 Ziggy6 why isn't the opp CF?
05:05 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:06 putter Ziggy6: re OT, yes.  re BEGIN loop, indeed.  I myself am greatly looking forward to  ... { use CommonLisp::Instead; (defun foo ...) } ... { use NowHowsaboutSomeRuby;  ... }
05:08 Ziggy6 :)
05:08 Ziggy6 perl6 will become the borg of languages :)
05:10 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 putter rather than simply causing a parsefail.
05:10 putter but we'll see whether it actually turns out to be a problem.
05:11 putter re borg, oh yeah.
05:15 putter 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 putter but better to took at something simpler someplace first.
05:16 Ziggy6 pugs has opp?
05:16 putter no
05:17 Ziggy6 what's wrong with it's parser?
05:17 putter pugs?
05:17 Ziggy6 yes
05:17 putter i don't understand.  "what's wrong with"?
05:17 putter luqui wrote http://en.wikipedia.org/wiki​/Operator-precedence_parser
05:17 reZo joined perl6
05:18 Ziggy6 i've seen some criticism (i don't remember where) that pugs' parser isn't flexible enough
05:19 Ziggy6 s/flexible/mainanable/
05:19 Ziggy6 maintainable*
05:21 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 putter s/is oo/its oo/
05:22 putter pugs is always either a head of, in sync with, or behind the spec of the moment.  <-- content free sentence :)
05:23 putter 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:24 putter pugs's parser is sort of the haskell magic version of yacc+lex.
05:25 Ziggy6 i'm still undecided what should i learn/hack first... too many interesting things in this project :)
05:27 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 putter If you can support audreyt, financially or otherwise, *that's* critical path.
05:28 putter other than that... fglock's ealier list seemed plausible...
05:30 putter 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:31 putter though it tends to generate throw-away code
05:33 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:35 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:36 putter a p6 runtime and prelude (basic classes) is probably something which can be worked on right now.
05:37 putter 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:39 putter 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 putter the mop is, like the oo ast, still a work in progress.
05:42 putter 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 putter s/right/write/
05:43 putter one could do a regex engine in p6
05:45 putter 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:46 putter much of the PIL1 handling would be throw-away.
05:46 putter but, it would work...
05:47 putter 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 jamhed joined perl6
05:48 * 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:49 wolverian putter, graphviz?
05:49 Ziggy6 is there any book on compilers for dynamic languages?
05:50 putter re graphvis, I really want to have subgraphs, whose nodes are shared with the supergraph, which have their own layout policies.
05:51 putter re dynamic languages...
05:51 miyagawa joined perl6
05:51 putter hmm, have you seen the READmumble files in pugs/ ?
05:52 putter Ziggy6: you know lambdatheultimate?
05:53 putter http://lambda-the-ultimate.org/  would be a good place to grovel around.
05:53 lambdabot Title: Lambda the Ultimate | Programming Languages Weblog
05:54 putter both for papers, and pointers to books
05:54 putter could add ones you find helpful to READTOO
06:00 putter searching LtU for "compilers" is fun.   here is one hit http://lambda-the-ultimate.org/node/1752
06:00 lambdabot Title: An Incremental Approach to Compiler Construction | Lambda the Ultimate
06:02 Ziggy6 nice :)
06:03 Ziggy6 almost makes me anbandon perl6 and get back to lisp
06:06 putter { use Language::Scheme::DialectX::Here; .... }
06:07 Southen joined perl6
06:07 putter it dialect support ends up being good, p6 might be the easiest place to do scheme development...
06:07 putter be a while before we can compete with SBCL for CL though.
06:09 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:12 Ziggy6 is now known as ZiggyAway
06:14 BooK_ joined perl6
06:15 miyagawa joined perl6
06:23 putter Inline::Guile?  Guile?
06:23 putter http://search.cpan.org/~ms​trout/Guile-0.002/Guile.pm
06:23 lambdabot Title: Guile - Perl interface to the Guile Scheme interpreter. - search.cpan.org
06:23 putter http://search.cpan.org/~samtreg​ar/Inline-Guile-0.001/Guile.pm
06:23 lambdabot Title: Inline::Guile - Inline module for the GNU Guile Scheme interpreter - search.cpan ...
06:25 putter if you were looking for a scheme task, it might be feasible to convert http://www.ccs.neu.edu/home/​dorai/scmxlate/scmxlate.html 's scm2cl  to create a scm2pl5 or scm2pl6.
06:25 lambdabot Title: scmxlate
06:27 miyagawa joined perl6
06:39 miyagawa joined perl6
06:41 putter good night &
06:41 svnbot6 r15139 | putter++ | Unfinished smoke support for redsix.
06:41 svnbot6 r15139 | putter++ | I find myself vaguely considering using redsix.  And any p6 implementation someone is considering using, should be wired up for testing.
06:41 svnbot6 r15139 | putter++ | This patch adds -Bredsix support to pugs, and makefile support for test-redsix and smoke-redsix.
06:41 svnbot6 r15139 | putter++ | Remaining to be done is run-smoke.pl support, and getting redsix to load its custom Test.pm.
06:41 svnbot6 r15139 | putter++ | Once you install ruby 1.9 head... you can watch redsix... crash it. :/
06:41 svnbot6 r15139 | putter++ | Perhaps I'll finish up later, when it can actually be run.
06:41 svnbot6 r15139 | putter++ | Perhaps by digging up an old ruby 1.9 snapshot from svn.
06:46 jamessan tpope: /join #vim
06:46 jamessan bah
06:51 lisppaste3 joined perl6
07:12 marmic joined perl6
07:16 bsb left perl6
07:17 nipra joined perl6
07:42 ZiggyAway is now known as Ziggy6
07:59 drrho joined perl6
08:10 iblechbot joined perl6
08:15 luqui joined perl6
08:16 * Ziggy6 started re-learning haskell
08:18 * luqui had to learn it about three times to get comfortable with it
08:20 * allbery_b has not had any trouble adapting to it
08:20 allbery_b of course I had my brain warped by APL in 1981 and J in 1985/6
08:20 luqui allbery_b, had you done pure (or almost pure) functional programming before?
08:21 araujo joined perl6
08:21 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:
08:21 luqui (1) learning to think functionally
08:21 luqui which I had done before, but only minimally, using lisp
08:21 luqui (2) learning to use monads
08:21 allbery_b purity wasn't anything.  laziness took some getting used t
08:22 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
08:22 allbery_b @go you could have invented monads
08:22 lambdabot http://sigfpe.blogspot.com/2006/08/yo​u-could-have-invented-monads-and.html
08:22 lambdabot Title: A Neighborhood of Infinity: You Could Have Invented Monads! (And Maybe You Alrea ...
08:22 Ziggy6 how does @go work?
08:23 allbery_b short for @google
08:23 allbery_b @help google
08:23 lambdabot google <expr>. Search google and show url of first hit
08:23 Ziggy6 nice
08:24 Ziggy6 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:25 luqui Ziggy6, you mean with the list monad?
08:25 Ziggy6 yes
08:25 luqui backtracking in the list monad is an effect of both the workings of the list monad and the laziness of the language
08:25 luqui if you were to implement the list monad in a strict language
08:25 luqui it would try all possibilities in parallel, not backtracking
08:26 luqui but the list monad is a great example; I recommend trying to wrap your head around it
08:26 luqui (from its definition)
08:26 luqui try not to think about laziness for now
08:27 luqui (it's much simpler, at least in my opinion, than the state monad, which is used often in introductions)
08:33 Ziggy6 as a side question: what tools do you use when you work on pugs?
08:33 Ziggy6 make fast, ghci, hugs?
08:33 luqui no, just make
08:33 luqui it's usually fast enough for me
08:33 luqui (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)
08:33 luqui at the first pugs hackathon I was in this state
08:33 luqui and it was not very productive
08:33 luqui make + vim + hasktags
08:33 Ziggy6_ joined perl6
08:33 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?
08:33 Ziggy6_ sorry, power failure
08:33 Ziggy6_ ah
08:33 Ziggy6_ i can see it in the logs now :)
08:39 Ziggy6_ is now known as Ziggy
08:39 Ziggy is now known as Ziggy6
08:41 devogon joined perl6
08:52 Debolaz2 GAH
08:53 Debolaz2 pugs got the wrong install prefix. :-(
08:53 * Debolaz2 will have to do a lot of manual cleanup now.
08:54 * Debolaz2 really wish it didn't default to wherever perl is installed.
08:55 luqui where do you wish it defaulted to
08:55 Debolaz2 /usr/local is what most people assume is the default installation directory.
08:56 * Ziggy6 agrees
08:56 luqui seems reasonable
08:57 luqui maybe it's a windows compat thing, er...
08:59 elmex joined perl6
09:08 Debolaz2 Hrmm, still not possible to set a custom prefix with pugs. :-(
09:13 andara joined perl6
10:07 chris2 joined perl6
10:12 ruoso joined perl6
10:25 cdfh_ joined perl6
10:25 fglock joined perl6
10:32 avar joined perl6
10:32 avar joined perl6
10:32 pasteling "fglock" at 201.35.169.13 pasted "syntax proposal: longest token matching with hash/pair notation" (14 lines, 343B) at http://sial.org/pbot/22596
10:33 fglock TimToady: please check http://sial.org/pbot/22596
10:33 lambdabot Title: Paste #22596 from "fglock" at 201.35.169.13
10:35 luqui a way to specify what part of a rule you consider a token?
10:37 fglock luqui: yes
10:37 luqui what happens when you don't have a => in an alt?
10:37 luqui it's all a token, none of it's a token, or it dwims?
10:38 luqui (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>
10:39 luqui ohk
10:39 fglock or a syntax error
10:40 fglock hmm - token => null is more useful
10:40 luqui oh I see where you're going with this
10:40 luqui kind of a local thing, rather than a solution to the longest token issue on the table at the moment
10:41 luqui (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
10:42 fglock longest token in the hash keys
10:43 luqui shorthand for <%foo> notation,  instead of <%(...)>, I suppose
10:44 fglock like the old <%h1|%h2>
10:44 * luqui wasn't around for that ket notation
10:45 fglock it was the previous proposal before <%h1> | <%h2>
10:45 luqui ahh
10:59 marcususesthis joined perl6
11:56 fglock wolverian: re POD - please do - documents marked with POD actually have no formatting
12:17 DebolazX joined perl6
12:18 kanru joined perl6
12:25 explorer joined perl6
12:26 tifo joined perl6
12:31 tifo joined perl6
12:32 tifo \bye
12:33 buetow joined perl6
12:33 capixaba joined perl6
12:35 bonesss joined perl6
12:41 rafl joined perl6
12:56 nipra joined perl6
12:57 diakopter joined perl6
13:01 BooK joined perl6
13:02 spo0nman joined perl6
13:21 Limbic_Region joined perl6
13:22 iblechbot joined perl6
13:36 VanilleBert joined perl6
13:46 weinig|zZz is now known as weinig|away
13:53 ofer0 joined perl6
13:57 dduncan left perl6
13:59 ofer0 joined perl6
14:02 ruoso joined perl6
14:12 kisu joined perl6
14:20 VanilleBert left perl6
14:24 spinclad joined perl6
14:43 vel joined perl6
14:46 stevan__ joined perl6
14:52 GabrielVieira joined perl6
14:57 stevan__ is now known as stevan
15:07 c6rbon joined perl6
15:15 fglock joined perl6
15:20 TimToady joined perl6
15:38 cdpruden joined perl6
15:45 hexmode joined perl6
15:47 shafire joined perl6
15:49 shafire left perl6
15:54 weinig|away is now known as weinig
16:00 nipra joined perl6
16:05 lisppaste3 joined perl6
16:08 rindolf joined perl6
16:10 spinclad joined perl6
16:23 cognominal joined perl6
16:26 Limbic_Region joined perl6
16:27 TimToady fglock: your => seems identical to my ::
16:33 fglock TimToady: yes, I noticed just after I wrote it
16:35 * 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
16:37 TimToady unfortunately = is not a reserved char
16:37 * [particle] thinks :: looks more at home in a regex
16:38 TimToady part of why we use := for named captures
16:47 Ziggy6 left perl6
16:53 nipra joined perl6
16:53 avar joined perl6
16:57 andara left perl6
17:21 nipra joined perl6
17:55 xinming_ joined perl6
18:00 Limbic_Region joined perl6
18:01 bernhard joined perl6
18:05 nipra joined perl6
18:06 justatheory joined perl6
18:07 neonse joined perl6
18:41 VanilleBert joined perl6
18:42 VanilleBert hmm, das mit PM-für-Datenschutztag-schreiben ist ja kein großer Renner: 16 abrufe... 3-4 von mir :D
18:42 VanilleBert sry, wrong chat
18:43 VanilleBert oO
18:43 ludan joined perl6
19:09 VanilleBert left perl6
19:35 nipra joined perl6
19:47 rindolf joined perl6
19:47 rindolf Hi all.
20:09 weinig is now known as weinig|bbl
20:21 justatheory joined perl6
20:29 mugwump joined perl6
20:49 pjcj joined perl6
21:02 _bernhard joined perl6
21:03 justatheory joined perl6
21:05 Aankhen`` joined perl6
21:06 lambdabot joined perl6
21:14 weinig|bbl is now known as weinig
21:37 GabrielVieira2 joined perl6
21:38 __Ace__ joined perl6
21:38 __Ace__ I just come to think about this XS... what is going to happen with that in Perl6?
21:38 __Ace__ anything easier?
21:40 Ziggy6 joined perl6
21:42 [particle] parrot has nci, which is much easier than xs
21:42 [particle] as far as perl 6 is concerned, there hasn't been a spec yet
21:42 __Ace__ time to wiki nci then..
21:43 __Ace__ hmm. en.wikipedia.org/wiki/National_Cancer_Institute
21:43 __Ace__ cant be right
21:43 [particle] try googling for parrot nci or native call interface
22:26 devogon joined perl6
22:37 pjcj joined perl6
22:41 devogon joined perl6
22:44 AStorm joined perl6
22:44 AStorm left perl6
22:46 nipra joined perl6
22:47 dduncan joined perl6
22:49 ingy joined perl6
23:11 Psyche^ joined perl6
23:18 Limbic_Region joined perl6
23:25 mako132_ joined perl6
23:25 Psyche^ is now known as Patterner
23:27 jdv79 joined perl6
23:30 Ziggy6 ?eval {random_name => 1}
23:30 evalbot_r15138 is now known as evalbot_r15139
23:30 evalbot_r15139 ("random_name" => 1)
23:30 Ziggy6 ?eval {state => 1}
23:30 evalbot_r15139 Error: ␤Unexpected "=>"␤expecting formal parameter, context or "("
23:30 Ziggy6 is this a bug, or a feature?
23:31 [particle] state declares a type of variable, like my
23:32 [particle] ?eval state $foo = 1
23:32 evalbot_r15139 \1
23:32 [particle] so it's a reserved word, and you'll have to quote it
23:33 ruz joined perl6
23:35 Ziggy6 ah, thanks :)
23:35 TimToady that is a bug in pugs
23:36 TimToady => is supposed to quote even reserved words
23:37 [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 perl6
23:39 jdv79 what happened to the pugs blog?  its gettin stale:(
23:39 justatheory joined perl6
23:44 TimToady I believe that what happened was a combination of relocation, earthquake, family emergency and ADD. :)
23:45 [particle] don't forget christmas
23:45 [particle] (but not that christmas)
23:45 diakopter and cocooning
23:45 TimToady That's the ghost of Chrismas future...
23:45 jdv79 oh, that sucks.  thanks for the 411 though.
23:46 TimToady but we all ebb and flow, and the tide will come in again...
23:46 diakopter perhaps the tsunami is building
23:46 [particle] hrmm... those sound like good names for perl 6 ops
23:47 Schwern joined perl6
23:47 [particle] $tide.ebb
23:47 [particle] schwern?!?!
23:47 Aankh|Clone joined perl6
23:47 TimToady maybe it was an accident?
23:48 Schwern What
23:48 TimToady or maybe we did something nekulturny
23:48 [particle] your presence has been noticed
23:48 TimToady or maybe he was just caught lurqueing
23:48 Schwern Great, what do I win?
23:49 [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.
23:49 PerlJam TimToady: Did your brain gurgitate enough on the smooth or chunky thread?
23:49 TimToady still gurgling
23:50 TimToady it won't be ];[, I can assure you.  :)
23:50 PerlJam heh, that's good to know  :)
23:50 TimToady that's one I actually though of myself and didn't bother to put...
23:50 [particle] thanks for avoiding the butterfly effect
23:50 TimToady *thought
23:51 [particle] how about using :ebb and :flow ??
23:51 TimToady both of those sound kinda smooth to me
23:51 TimToady more like :aa vs :pahoihoi
23:51 jdv79 some p6's got nuts, some don't?
23:52 [particle] :almond_joy vs :mounds ?
23:52 [particle] timtoady: it's more deep vs shallow, donchathink?
23:52 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.
23:52 TimToady one could go scatalogical, since English provides both mass and count nouns...
23:52 PerlJam (but what do I know, I'm not a language designer :-)
23:54 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.
23:55 TimToady since it just ignores []ness at the top level
23:56 mncharity joined perl6
23:56 mncharity is now known as putter
23:57 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:58 TimToady and we're trying to deal with dimensional syntax and multiple pipes and various related things
23:59 TimToady and we'd like to be able to multislice with infix:<;>

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

Perl 6 | Reference Documentation | Rakudo | Niecza | Specs