Camelia, the Perl 6 bug

IRC log for #moe, 2013-04-02

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

All times shown according to UTC.

Time Nick Message
00:00 tobyink joined #moe
00:06 jnap joined #moe
00:36 jnap joined #moe
01:23 jnap joined #moe
05:32 hiratara joined #moe
07:21 tobyink joined #moe
08:08 celogeek joined #moe
09:40 am0c joined #moe
10:21 stevan joined #moe
10:53 hiratara joined #moe
12:23 jnap joined #moe
12:46 jhannah joined #moe
12:57 stevan joined #moe
13:12 gizmomathboy joined #moe
13:15 bluescreen joined #moe
13:57 stevan joined #moe
14:10 prammer stevan: no, I'm not prakashk
14:16 jnap I wonder how must of that conversation yesterday about -> was stevan's little april fools joke….
14:16 jnap if so, he must have been terribly amused
14:26 hiratara joined #moe
14:30 * sartak votes `shell invocation` -1. make shit secure by default please!
14:31 doy yes, that too
14:31 doy `` and single-arg system are kind of terrible from a security perspective
14:38 jnap1 joined #moe
14:42 melo joined #moe
14:45 melo1 joined #moe
14:50 * sahadev == prakashk
14:52 * masak .oO( I'M prakashkus! )
15:07 stevan joined #moe
15:24 sahadev moe> [1..3, 42] => [[1, 2, 3], 42]   # do we not want to flatten the list here?
15:29 doy i'd say yes, but getting flattening right is something that's going to require a whole lot of thought
15:31 phaylon that reminds me, does foo(@bar) flatten the array and pass many args in moe, or does it go the p6 way of the sigil being a type restriction (assuming I understood the p6 part right)?
15:34 phaylon I think I saw a my (@foo, $bar) = ... somewhere, but it's hard to get the full picture
15:34 tobyink joined #moe
15:35 masak it would be great to have a discussion about flattening across #perl6-#moe borders.
15:35 masak it's tricky to get right. we're *still* figuring it out.
15:35 masak but I'd like to think we've learned a thing or two, as well.
15:39 phaylon yea, it also depends on the rest of the language semantics, so the reasons are probably just as important as the spec :)
15:41 masak indeed.
15:42 masak in some sense, the main thing is that you're able to express both all three thoughts of "pass these arguments as separate parameters", "split this one argument into separate parameters", and "pass these arguments as one parameter".
15:42 phaylon right
15:44 phaylon while off-topic for $a..$b, hashes and named vs. positional arguments when splicing parameters is also one of the possible complications
15:47 masak in Perl 6, slurpy hashes pick up loose named parameters just like slurpy arrays pick up loose positional parameters.
15:47 phaylon right, I meant more on the calling side :)
15:48 phaylon e.g. foo(%bar)
15:48 masak oh, ok. yes, it's the same there. hashes flatten into named arguments. but never automatically in Perl 6. you have to believe it for it to be true.
15:48 masak the syntax is foo(|%bar)
15:48 phaylon ah, so it's basically a separate splice operator?
15:49 phaylon or "flatten" or whatever
15:49 masak yes, prefix:<|> flattens both arrays and hashes.
15:50 phaylon huh, so I went the same way as p6. interesting :) except my syntax is way less smart of course
15:50 masak ;)
15:51 masak in some distant past we used the same prefix operator for slurpiness and flattening. but they turned out to be two different things, deserving two different operators.
15:52 phaylon right. I use the same op, but it gets a lot more simple when you don't have first class signatures or captures or moldable syntax
15:52 masak guess so.
15:54 phaylon it also helps to only have scalar vars :)
15:56 masak funny, I made the same decision in my language. :) and no sigils.
15:56 phaylon ah, I did keep the $ for lexicals :)
15:57 masak I didn't, even knowing full well the advantages of sigils.
15:58 masak so far the only drawback of the decision is that I have no easy way to indicate dynamicals.
15:58 jnap joined #moe
15:59 phaylon I mostly just went for it because of the visual cues
16:00 phaylon I'm not even sure I'm gonna do dynamic scoping. some system vars ($*FOO) will have it, but you'll be able to localize lexicals
16:01 masak yes, I'm not sore I need dynamic scoping either.
16:01 phaylon well, the lexicals are going to be localizable in a dynamic scope, so I guess I will indeed have dynamics
16:02 masak hm. how, given some occurrence of a lexical, will you know whether it has been (dynamically) localized? seems the only way to check is at runtime.
16:02 phaylon I do like it for system $*IN and $*OUT vars
16:03 phaylon the current plan is to basically do local $x = 23 { ... } as let { my $tmp; on enter { $x = 23 }; on leave { $x = $tmp } }
16:04 phaylon with the ... in the let of course :)
16:05 doy joined #moe
16:05 masak and $tmp saving the original $x, of course.
16:05 phaylon oh, yea :)
16:05 masak that's what 'temp' does in Perl 6.
16:05 phaylon ah
16:05 masak 'let' does the same, but it only does the rollback is the block is unsuccessful.
16:05 * phaylon writes that down :)
16:06 phaylon oh, so it has a transactional env somehow? that is kinda neat
16:06 phaylon does that only do lexicals or object states as well?
16:08 phaylon damn. "let" is surprisingly hard to google
16:08 masak it's in only lexicals, as far as I know. though that's a an interesting question.
16:09 masak hold on, I'll give you the reference.
16:09 phaylon I guess it would be nice if objects could be asked for state when they are inside a scope and are able to roll back on a failure
16:10 phaylon though it's p6, so I assume one can simply add that in as a library :)
16:10 masak http://perlcabal.org/syn/S04.html#The_R​elationship_of_Blocks_and_Declarations
16:11 phaylon thanks
16:11 masak yes, I'm also assuming functionality could be provided through a module.
16:21 phaylon ooh, I do like repeat { ... } until instead of do, I totally forgot about that
16:22 phaylon actually, I like repeat until $x { ... } even more
16:22 masak yeah. I stole that one, too ;)
16:22 phaylon I was losing hairs trying to figure out a syntax for that :D
16:23 masak "Solved in Perl 6" :P
16:23 phaylon hey, I did look at their stuff, just didn't think about that one :)
16:25 awwaiid joined #moe
16:27 phaylon masak: have you thought about labels for loop control yet? my current plan is to have them objects in lexical vars that carry continuations
16:29 masak I only allow labels on loops. basically, they can always be compiled down to anonymous boolean variables and if statements.
16:30 masak though I'm toying a little with various CPS transform ideas.
16:30 phaylon heh
16:31 masak mostly because I found the long-lost fourth cousin of 'next', 'redo', and 'last'. :)
16:31 masak it's called 'slip', and semantically it's like a 'next' minus a 'redo'.
16:32 phaylon so you're skipping one?
16:32 masak that is, stay in the same place in the code, but go to the next iteration.
16:32 phaylon aah
16:32 masak requires a CPS transform during compilation.
16:33 masak especially with 'skip LABEL', it can be quite handy.
16:33 phaylon that seems quite powerful, first thought of using it would be ['key', $value, 'key2', $value2] lists :)
16:33 masak aye.
16:33 arnsholt masak: So for slip, you keep the state of lexicals interior to the loop, but update the loop variable?
16:33 masak arnsholt: right.
16:33 phaylon I was going with lexicals since then I can reuse it for $list.map-with-control(=> ($item, $loop) { ... }) and have $loop.inject(...) and stuff
16:33 arnsholt Neat!
16:34 phaylon since I don't have contexts :)
16:34 masak arnsholt: with 'skip LABEL', *outer* loops can iterate while the inner ones stay the same!
16:35 masak phaylon: those parens around ($item, $loop) look a little redunant to me... :)
16:35 masak redundant*
16:35 arnsholt masak: That's a very good point! Also potentially very useful
16:36 phaylon masak: actually, the current syntax would be => ($x, $y) $x + $y # no {}, single expression and -> $_ * 2 # no {}, single expr, single req arg in $_
16:37 phaylon they are basically shortcuts because I require returns, so the long form would be lambda ($_) { return $_ * 2 }
16:37 masak phaylon: ah.
16:38 phaylon I was only going to require explicit returns in named lambda declarations (sub, function, method), but that seemed inconsistent
16:39 masak I'm still very much on the fence on explicit returns. basically, wearing the language designer hat and the user hat makes me want too different things.
16:39 masak (sorry for stealing the #moe channel for this -- switching back to lurking...)
16:40 phaylon well, I basically a language to do some api prototyping in. and being able to tell from the code if something wanted to return something or just does is important in my personal use case :)
16:40 masak I see :)
16:40 phaylon don't think anyone's gonna be insane enough to use it besides me :)
17:42 gizmomathboy joined #moe
18:15 melo joined #moe
18:40 tobyink joined #moe
19:23 gizmomathboy joined #moe
19:32 jnap joined #moe
19:33 melo joined #moe
20:56 am0c joined #moe
21:21 jnap joined #moe
22:09 gizmomathboy joined #moe
22:21 stevan joined #moe
23:19 stevan joined #moe
23:45 gizmomathboy joined #moe

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