»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'p6: say 3;' or rakudo:, std:, or /msg camelia p6: ... | irclog: irc.perl6.org | UTF-8 is our friend!
Set by moritz on 25 December 2014.
japhb lizmat: re: p6weekly, The low-level concurrency test that crashes does so on *nqp-j*, not *nqp-p*. 00:01
On nqp-p, all of the concurrency tests should gracefully exit with a skip message. 00:02
vendethiel masak: Shen is going BSD :-) 00:17
masak vendethiel: "Shen"?
vendethiel masak: lisp with incredibly nice type system :p 00:18
masak oh, rings a weak bell.
vendethiel masak: org
well.
masak what does "going BSD" mean in this context? gains BSD support?
vendethiel masak: www.shenlanguage.org/ better with full link
masak: open-source license ahead. code source and all
masak ooh! 00:19
right. licensing.
what was it before? closed?
vendethiel masak: the source code was very, very old, back when it was called Qi
masak oh, Shen === Qi. got it. 00:20
vendethiel masak: groups.google.com/forum/#!msg/qila...LaUdEFwXAJ
00:20 jack_rabbit joined
masak I was just thinking of macros, in a 007 context. 00:20
I think I've discovered an important phenomenon, which I've provisionally called "stuttering".
it doesn't happen in Lisp, because Lisp doesn't really have grammatical categories like Perl 6 and 007 do. 00:21
vendethiel my keyboard does that as well :)
masak reason it happen is this: say `foo()` is a macro call. it expands to a statement. that means a statement just expanded into the slot of an expression. 00:22
in 007, that means Something Bad Happened.
because statements can contain expressions, but statements cannot (arbitrarily) contain statements.
so I think some part of the macro expansion has to go "ok, this came out a little wrongish, but we can fix this if we're just a wee bit lenient..." 00:23
moritz why does the macro call expand to a statement?
masak because a quasi block evaluates to an actual block is a statement.
(sorry for writing using chaining verbs. it's late.) 00:24
moritz in p6, blocks are expressions, right?
so it's a 007-only problem, I hope 00:25
masak I suspect this is one of those cases where it depends on your definition of "are".
anyway, it might be 007-specific in this case, but I think it's worth investigating.
007 is a small, closed universe, which might give clues about how to lay out macros in Perl 6. 00:26
vendethiel doesn't really follow
007 is your perl6 macro thing?
masak oh, it's a little language sergot++ and I built over Christmas.
masak.github.io/007/
vendethiel found it :)
vendethiel had a cat on his lap with a nice chair yesterday, felt like a bond villain 00:27
masak I should add that 007 hasn't really reached its full potential yet. I feel about a dozen commits away from that.
moritz masak: well, in p6 we even have a syntax thingy for turning statements into expressions, so the distinction seems to be syntax-only
vendethiel okay, looking at what 007 does 00:28
masak moritz: I think we're heading in a direction where in macros we need to care more about what the thing is we're inserting, and what the slot is we're inserting it into. at least the parser will want to care a lot. 00:29
moritz masak: that's possible
masak moritz: the trick is how to do this without it feeling restrictive/draconian to the user. grammar category stuttering sort of explores that a bit.
it'll *definitly* be possible to insert a program fragment that doesn't fit. the compiler should complain in that case. 00:30
like, what if you did `foo() + foo()`, with the `foo` macro expanding to a statement? 00:31
now you have an expression with a binary operator adding two statements. bzzt.
adu r: @("a", "b").join()
vendethiel masak: so, it's "only" to try your Q:: AST you described me earlier? amazing!
camelia ( no output )
adu r: say @("a", "b").join()
camelia rakudo-{parrot,moar} 80b912: OUTPUT«ab␤»
masak vendethiel: yes! 00:32
vendethiel okay, very glad that comes into form
masak vendethiel: it's one big laboratory for playing with Q::
vendethiel s/form/shape. pardon my french
masak patches awesome^Wwelcome
00:33 adu left
masak another piece of terminology that has fallen out of 007 (but that I sort of mentioned on the channel while 007 was still secret): parsed ASTs versus synthetic ASTs. 00:34
a parsed AST is one that comes from parsing code. like, with a quasi, or parsed as a macro parameter.
00:35 sirdancealot joined
masak a synthetic AST is one that you painstakingly put together by calling constructors on Q:: things. 00:35
vendethiel
.oO( syntactic AST )
^ which is why you want quoting :P
00:35 gfldex left
masak the distinction is important, because some checks happen at parsing, and presumably synthetic ASTs will have to do those checks "later". like, at insertion time. 00:35
00:36 gfldex joined
masak from what I can see with my limited, not-standing-on-giants'-shoulders vision, synthetic ASTs also don't carry around an environment. 00:36
(because you built them, and you didn't supply one.) 00:37
vendethiel masak: you need some kind of environment for certain types of check, like type checking and other stuff 00:38
masak oh, I'm not disputing that one bit.
I'm just saying that synthetic ASTs are (sadly) born without them. so it goes. 00:39
moritz I guess synthetic ASTs get their environments from the macro call site
vendethiel well, you *need* to "pass" them somehow ;-)
masak they have to be *given* an environment ALAP as they are inserted in some place.
what moritz++ said.
vendethiel scala macros carry around an "universe"
moritz so that a Q::Var(:name<$blerg>) is like COMPILING::<$blerg>
masak yeah, seems so. 00:40
interesting.
moritz is there a Q::Scope or so that introduces a new scope? 00:41
masak (wanted: a verb describing the process of carrying out all the checks that the parser usually does, such as variable/type/function consistency, but that was never done one a synthetic AST until now.)
moritz: in 007? nope.
moritz I'm thinking of ways to create macro-private variables in synthetic ASTs without resolving to gensymming 00:42
"deferred checks"?
well, more like "deferred checking"
masak ok, provisionally accepted. 00:43
00:44 araujo left 00:45 araujo joined
masak I was thinking of something like "temper" or "toughen". the problem with arbitrary synthetic ASTs is that they are too "soft". 00:47
interestingly, we have this problem in the 007 test suite, completely orthogonally from macros.
right now parsing is responsible for creating static lexpads -- the deferred checks process would need to do that, too. 00:48
moritz note that rakudo also only catches some form of undeclared symbol usages in the optimizer 00:49
masak that's news to me but I'm not surprised.
moritz usage of undeclared subroutines, iirc 00:50
hm, nope
vendethiel is too tired to follow
masak thank blog for backlogs :)
masak will likely backlog this tomorrow
moritz tried to sleep, without much success :( 00:51
masak aww
actually, "checking" is probably the ideal term for what we're doing with the synthetic ASTs. because it ties in very well with the CHECK parser. 01:16
Mouq masak: [007] "There is a difference, though: subroutines can return values, and blocks can't." does this mean that, unlike subs, blocks should return the last value by default? 01:18
masak Mouq: no. 01:19
Mouq: blocks always "return" None.
Mouq So how do you write a map? 01:20
masak Mouq: but (borrowing terminology from Perl 6 here) blocks don't really have a "return" operation at all. they just "leave". and in 007, they always "leave" None.
Mouq: you pass the map a sub.
Mouq: the only reason we have blocks in the first place is that they show up all over the place anyway. in `if`, `for`, `while`, etc. 01:21
Mouq: but note that we don't expect any of those to have their own `return` operation.
01:21 adu joined
masak when they do (as with loops), they are called other things, with other keywords. 01:21
vendethiel how hard would it be to implement "leave" :-)?
masak vendethiel: hard. 007 doesn't expose control flow. 01:22
vendethiel in perl6, I mean
.oO( did I mention you have to decrypt what I'm saying, for once? )
masak I think Niecza might have it.
n: say "OH HAI"
camelia niecza v24-109-g48a8de3: OUTPUT«(signal ABRT)Stacktrace:␤␤ at <unknown> <0xffffffff>␤ at (wrapper managed-to-native) object.__icall_wrapper_mono_gc_alloc_string (intptr,intptr,int) <0xffffffff>␤ at (wrapper alloc) object.AllocString (intptr,int) <0xffffffff>␤ at string…»
masak o.O
moritz vendethiel: just a bit of codegen
masak: so return() from a block in 007 returns from the outer routine? 01:23
masak yep.
that's even mentioned in masak.github.io/007/
which also means you can have the "stale subroutine" issue in 007.
Mouq masak: K, well, just saying that ATM, you can't do, e.g., `map(sub { return 42 }, range(0, 20))` because sub is statement-level. Also because they can't be anonymous 01:24
masak (subroutine returns an inner block, inner block contains a `return`, gets called, `return` has to fail because subroutine already exited)
Mouq: all part of the plan.
Mouq k
masak Mouq: the invoncenience is there because 007 is not Perl 6. :)
Mouq: Perl 6 goes out of its way to be convenient to the user. 01:25
007 is convenient to the person thinking about ASTs. :)
Mouq masak: Fair lol, I just expected it to be more FP-oriented for some reason
masak it is, but it has its own sort of harsh austerity to it.
Mouq Gotcha :) 01:26
masak I think the strict distinction between statement and expr will serve us well in the end.
it will force us to consider certain boundaries sooner than if the language were more lax.
Mouq masak: I have a lot of nit-picky questions I could spam you with :9 But one thing I'm not sure I totally get is why are there so many Q:: classes? 01:34
01:35 yeahnoob joined
Mouq masak: For example, with whatever syntax is come up with for it, when a user adds an infix (I assume such a thing would eventually be possible) do they have to create a Q::Infix::* class as well? 01:35
masak they don't have to. 01:36
this is where macros and slangs diverge, IMHO.
Mouq okay 01:37
masak as a Perl 6 end user, you just want to declare your awesome operator and get on with life. you decidedly don't want to mess with declaring new Q:: types.
which means you get some kind of default under the hood. probably a generic Q::Infix of some kind. 01:38
but as a slang author, you emphatically *do* care about Q:: types, and about creating your own.
why? because you're probably gonna grep for them a lot in your own slang analysis code. 01:39
adu Mouq: also, I noticed you're following C::Parser
masak Mouq: you're correct in observing that the more specialized operator Q:: classes are strictly unnecessary.
Mouq: the (unproven) idea behing that is that they're good handles for grepping. 01:40
Mouq: i.e. it's more conenient to grep for `Q::Infix::Concat` than it is to grep for `Q::Infix where { .type eq '~' }` 01:41
01:41 Hor|zon joined
lue masak: I have to say, I think that's the first time I've heard of a language feature being designed with external utilities in mind :P . 01:44
masak not really "external". 01:45
remember, we're changing our Perl 6 program from within Perl 6 here.
that's what macros are, basically.
if they aren't that, then they're really no better than functions. 01:46
lue I was referring to <masak> Mouq: the (unproven) idea behing that is that they're good handles for grepping.
01:46 Hor|zon left
masak aye. 01:46
I mean grepping from inside of a macro in Perl 6 code. 01:47
sorry if that was unclear :)
well, s/Perl 6/007/ in this case.
but the same principle applies for both languages.
adu masak: I personally divide the world of programming into 4 distinctions: run-time expressions, declarations for run-time expressions, compile-time expressions, and declarations for compile-time expressions. 01:48
Mouq I was going to suggest something like Q::Infix['~'] being the Q::Infix role/trait implemented for '~', but I was confusing my object systems :P
masak adu: curious. I'll have to mull over that, I think.
Mouq: also, that's not gonna cut it if you have two different infix:<~> operators defined in different scopes. 01:49
lue To me, where { .type eq '~' } feels like you're doing something underhanded somehow, not so with ::Concat
adu masak: they correspond roughly to expressions, declarations, macros, and macro-transformers respectively
masak Mouq: the symbol is not a unique-enough distinguisher for the operator.
Mouq masak: Yeah
moritz masak: the usual lookup rules apply, no?
masak lue: indeed -- see my last point to Mouq.
moritz: well, the problem (as usual) is that you're in two places at once: in the macro, and in the code being analyzed by the macro. the "default" lookup is from the macro itself, which is probably not what you want. 01:50
lue But with Q::Infix::Concat, how would user-defined operators be referred to? Would have to make Q::Infix::Foo yourself?
masak adu: interesting.
lue s/Would have/Would you have/ 01:51
Mouq adu: Though "compile time" is even more divided here between "parse time" and "ast-building time"
masak lue: yeah. haven't really thought that through.
adu Mouq: oOo
masak lue: the "logical" place to introduce the Q:: type would be with the definition of the new operator. but I'm not sure if that's a great idea.
lue: also, funnily, 007 can't declare new types yet. 01:52
adu Mouq: theoretically, any time a representation of a program is "touched" could be a chance to attach actions
01:53 tinyblak left
lue Q::Infix<~> may not be unique enough, but that doesn't seem any worse than sub operator:infix<~> on the surface. 01:53
masak Mouq: currently in 007, AST building (and macro calls with their own AST building) happens as part of the parsing, not as a separate step. 01:54
Mouq adu: True. C, for example, has it's Preprocessor stage as well
01:54 tinyblak joined
masak lue: the problem, as I mentioned to moritz, is that you're not *in* the environment you're analyzing. so lookup doesn't necessarily go to the right place. 01:54
adu Mouq: Scheme and Rust both have excellent macro transformers 01:55
masak lue: put differently, doing `&infix:<~>` in the program that the macro analyzes might give a different operator than doing `&infix:<~>` from the macro code.
adu Mouq: C has a pretty bad macro transformer 01:56
lue masak: Yeah. That suggests to me that things like operators may naturally require more information, unless there was some sane way of generating a default name (perhaps Q::Infix::Foo.pm6::L42 ??)
Mouq masak: Maybe <~> wants to be namespaced, in that case
masak lue: the name isn't necessary. there will always be a long way, like `Q::Infix where { ... }` 01:57
lue: it's just that we provide convenient hooks for the operators that we know are there in the core language.
moritz masak: I wonder how well you get along with the current model, and if at some point you'll have to stick a pointer to the environment into the Q:: nodes 01:58
masak lue: of course, as always, we like to make it possible for the library author to feel that they are playing by the same rules as the language authors.
lue admittedly hasn't looked at 007 and related all that closely yet, she's just working from what's been mentioned so far :P .
masak moritz: yes. that's what the `check` discussion was about.
moritz masak: so that you can do a $q.scope.lookup('infix:<~>')
lue Hearing that the where {...} will be available anyway makes me feel better about the various names the builtins would get :) .
masak moritz: the main insight in the past few days is that synthetic ASTs were not created biologically, so they need to have an environment inseminated into them by artificial means. 01:59
moritz: a ghost in the shell, if you will.
adu masak: one of the reasons why I don't distinguish between expressions and statements is that there are too many places to "draw the line", for example, do you draw the line in the fact that statements have no return value? or the fact that expressions can be pure of side effects? or that statements generally require access to variable names, or at least mutable variables, but if the object is changing and not the variable, then statements 02:00
are equivalent to lambda calculus...
moritz cells without connective tissue
masak yeah.
adu: all very good points. 007 is unapologetic in its opinions there.
it strikes a balance that makes it easy to implement and do AST manipulations. 02:01
adu masak: but decls are funky, you can't wrap up the universe in a lambda 02:03
masak can I ask you to be more concrete? how is this a problem? 02:04
adu so, when you declare something, you are creating a binding to an identifier, and the scope of that identifier is usually everywhere (minus all of the package/module stuff) 02:05
with lambdas, the scope identifiers for the parameters are bound to is the lambda body 02:06
dalek ecs: 48af140 | TimToady++ | S02-bits.pod:
Mention unspace disallowed in regex (except \#)

The current engine disallows unspace in regexex as too ambiguous. This is fine for actual whitespace, but is counterintuitive when people try to backslash the # character. So \# is now specifically allowed to match a literal # character.
adu masak: hence, you can't wrap up the universe in a lambda
Mouq TimToady: Ooo
dalek p: b0a2372 | TimToady++ | src/QRegex/P6Regex/Grammar.nqp:
Allow \# in regex to match '#'
 02:07
ast: b108dab | TimToady++ | S02-lexical-conventions/unspace.t:
Test that \# is allowed in regex, and means '#'
masak adu: ok, I'll have to mull over that, too.
:) 02:08
'night, #perl6
adu :)
Mouq 'night masak
vendethiel 'night!
dalek kudo/nom: 2165a69 | TimToady++ | tools/build/NQP_REVISION:
bump nqp
adu anyways, classes and modules are examples 02:09
lue ♞ masak o/ 02:10
02:18 chenryn joined 02:23 rmgk_ joined, rmgk left, rmgk_ is now known as rmgk
moritz TimToady++ 02:23
it always felt weird that you could backslash non-word characters n regexes, except # 02:24
02:51 kurahaupo1 joined 02:57 kurahaupo1 left 02:58 yeahnoob left 03:09 raiph left 03:11 yeahnoob joined, yeahnoob left 03:12 yeahnoob joined, yeahnoob left, yeahnoob joined 03:13 yeahnoob left, yeahnoob joined, yeahnoob left 03:14 yeahnoob joined, yeahnoob left, yeahnoob joined 03:15 yeahnoob left, yeahnoob joined, yeahnoob left 03:16 yeahnoob joined, yeahnoob left, yeahnoob joined, yeahnoob left 03:17 yeahnoob joined, yeahnoob left, yeahnoob joined, yeahnoob left 03:18 yeahnoob joined, yeahnoob left, yeahnoob joined 03:19 yeahnoob left, yeahnoob joined, yeahnoob left, yeahnoob joined 03:20 yeahnoob left, yeahnoob joined, yeahnoob left 03:21 yeahnoob joined, yeahnoob left, yeahnoob joined 03:22 yeahnoob left, yeahnoob joined, yeahnoob left, yeahnoob joined 03:23 yeahnoob left 03:30 Hor|zon joined 03:34 Hor|zon left 03:36 noganex_ joined 03:39 noganex left 03:40 fhelmberger joined 03:42 tinyblak left 03:43 tinyblak joined 03:44 fhelmberger left 03:48 konsolebox joined 03:50 adu left 03:56 kurahaupo1 joined 04:06 anaeem1_ joined, anaeem1_ left 04:07 ssutch joined, anaeem1_ joined 04:10 Rounin joined, raiph joined 04:17 kaleem joined 04:51 vendethiel left 04:52 Rounin left 04:56 hersoncr joined 04:58 hersoncr left 05:01 kaleem left 05:03 adu joined, chenryn left 05:06 tinyblak_ joined 05:08 tinyblak_ left, tinyblak_ joined 05:09 tinyblak left 05:10 tinyblak joined 05:13 tinyblak left, tinyblak joined 05:14 tinyblak_ left 05:19 Hor|zon joined, tinyblak_ joined 05:20 tinyblak_ left, tinyblak_ joined 05:22 tinyblak left 05:23 Hor|zon left 05:26 chenryn joined 05:33 raiph left 05:47 sirdancealot left 05:56 Rounin joined 06:10 adu left 06:12 sirdancealot joined 06:40 adu joined 06:49 mr-foobar left
FROGGS adu: v5 has a lot (about 500) packages as Perl5::* because these are Perl 5 core modules, like List::Util and so on... most of them are just stubs though atm 06:50
adu FROGGS: ok 06:51
FROGGS the slang itself is Perl5.pm (for registering a module loader, grammar and actions), Perl5/Grammar.pm, */Actions.pm, */ModuleLoader.pm and */World.pm 06:52
adu what is the purpose of World? 06:53
oh "class Perl5::World;"
I can do that
FROGGS it mostly acts as a collection of helper functions... finding lexical variables, declaring these, merging symbols etc
adu github.com/rakudo-p5/v5/blob/maste...5/World.pm 06:54
FROGGS normally you just need the Foo.pm, Foo/Grammar.pm and Foo/Actions.pm, at least for a start
adu FROGGS: ah, I call those modules {...}Utils
well, I would if I were to write one 06:55
my current Perl6 code probably has the God class anti-pattern
FROGGS adu: it also keeps some values, so it builds up our worlds (that architecture is taken from Perl6/rakudo directly)
adu so I got stuck on my C parser 06:57
it now parses about 25% of glib/gbytes.c, but it gets stuck on "struct _GArray { ... } GArray", but then when I put that declaration in a separate file with the appropriate typedefs, then it parses correctly, and so I ran the whole file again and it got stuck again, I'm so confused 06:59
it's almost like it's a buffer overflow problem
07:02 kaleem joined
FROGGS well, that's the problem of one pass parsing... probably this statement has several rules that could parse them, and the wrong one is picked 07:03
adu possible 07:05
07:08 Hor|zon joined
adu FROGGS: I think I've done a pretty good job 07:11
07:12 Hor|zon left 07:16 Mouq left
adu FROGGS: what is p6-Inline-C? 07:21
b2gills I think that most of the stub Perl5::* modules should just be removed, and have v5 try to load the ones that are actually written in Perl5 as a way of finding bugs ( at least initially ) 07:29
07:30 xfix joined
FROGGS b2gills: sort of, it helped having the stubs in place, to be able to run more of the spectest to get basic functionality in place 07:33
adu: it compiles a string of C to a dll, and makes it available via a perl 6 level subroutine
07:33 Sqirrel left
FROGGS adu: it passes it off to cc 07:33
adu hmm 07:34
b2gills The biggest problem I encountered was most Perl5 modules don't start with `use v5;`
07:34 Mouq joined
adu FROGGS: I wonder if it would be of any use to combine it with my C parser 07:34
FROGGS well, I can fudge them... or we recognize the semicolon form pf package declarators
of*
adu: it would be very sweet to not have to put the C code in a string, so yeah, that'd be awesome 07:35
brb
07:35 FROGGS left 07:41 FROGGS[mobile] joined
moritz \o 07:47
07:48 tinyblak_ left, rurban joined, tinyblak joined 07:54 FROGGS joined
FROGGS hi moritz 08:04
08:04 zakharyas joined 08:07 adu left 08:08 vendethiel joined 08:13 [Sno] left
moritz 4 hours of sleep is not enough for me :( 08:16
FROGGS :o( 08:19
08:19 darutoko joined
FROGGS I slept six hours on a beanbag chair, that's also not ideal as it turns out 08:20
08:27 yeahnoob joined 08:33 Mouq left 08:36 tinyblak left 08:38 Hor|zon joined
dalek c: ec60a18 | moritz++ | lib/Type/Supply.pod:
Supply: explain on-demand vs. live supplies

partially taken directly from S17		 08:42
08:43 Hor|zon left 08:44 tinyblak joined 08:46 avalenn joined
arnsholt adu 08:53
Derp. Wifi hiccup 08:54
09:01 [Sno] joined
FROGGS pr0n 09:01
Ohh damn wigi hiccup :o) 09:02
wifi*
09:02 virtualsue joined 09:03 mvuets joined
lizmat japhb++ for pointing out nqp-j crashes concurrency tests, rather than nqp-p 09:04
09:08 Hor|zon joined, tinyblak left, tinyblak joined 09:19 molaf_ joined 09:23 molaf__ left 09:27 vendethiel left 09:29 sirdancealot left 09:32 vendethiel joined, yeahnoob left, dakkar joined 09:34 xinming_ left, xinming joined 09:37 xfix left 09:40 telex left, telex joined 09:47 rindolf joined 09:49 vendethiel left 09:50 bjz joined, tinyblak left, tinyblak joined 09:53 tinyblak left, tinyblak joined 09:55 bjz left 09:58 JimmyZ joined
btyler_ answering my own question from yesterday: the problem I was having with Inline::Perl5 not finding libperl.so was -actually- libperl.so being from a perl version that was too old (5.14.2). hooking everything up with 5.18.2 and I::P5 worked perfectly out of the panda-box. 09:58
10:00 tinyblak_ joined
btyler_ in particular, I::P5 looks for an identifier that's absent from 5.14's headers (av_top_index) but present in 5.18 10:00
10:02 tinyblak left 10:09 tinyblak_ left, tinyblak joined 10:18 bjz joined 10:28 Psyche^ joined, tinyblak left 10:29 tinyblak joined 10:32 cognominal left, Patterner left, cognominal joined 10:33 chenryn left 10:38 cognominal left 10:47 denis_boyun_ joined 10:49 chenryn joined 10:52 andreoss joined
andreoss grep {}, ... seems broken in latest build 10:54
m: my @x = grep {$_ < 5}, 1...100; say @x.perl;
camelia rakudo-moar 80b912: OUTPUT«Array.new()␤»
andreoss meanwhile 10:56
m: my @x = grep {$_ < 5}, @(1...100); say @x.perl;
camelia rakudo-moar 80b912: OUTPUT«Array.new(1, 2, 3, 4)␤»
psch m: my @x = grep {$_ < 5}, 1..100; say @x.perl 10:57
camelia rakudo-moar 80b912: OUTPUT«Array.new(1, 2, 3, 4)␤»
psch infix:<...> is lazy i think
although grep should probably reify that
m: say (1...100).grep: {$_ < 5}
camelia rakudo-moar 80b912: OUTPUT«1 2 3 4␤»
andreoss psch: i think it worked some time ago
FROGGS star-m: my @x = grep {$_ < 5}, 1...100; say @x.perl; 10:58
camelia star-m 2014.12: OUTPUT«Array.new()␤»
psch m: my @x = grep {$_ < 5}, eager 1...100; say @x.perl 11:04
camelia rakudo-moar 80b912: OUTPUT«Array.new(1, 2, 3, 4)␤»
FROGGS m: say grep * < 5, 1...100; say grep * < 5, eager 1...100 11:05
camelia rakudo-moar 80b912: OUTPUT«␤1 2 3 4␤»
andreoss why operations on lazy lists produce empty lists? 11:06
FROGGS andreoss: because it is a bug
and the bug is in grep somewhere...
11:06 Alina-malina left
FROGGS m: say map { $_ }, 1...100 # that's also funny 11:08
camelia rakudo-moar 80b912: OUTPUT«Cannot call 'map'; none of these signatures match:␤:(&code, *@values)␤:(Whatever, Any \a)␤:(&code, Whatever)␤ in block <unit> at /tmp/sbAzBgGIk1:1␤␤»
FROGGS m: say map { $_ }, 1..100 # but this works
camelia rakudo-moar 80b912: OUTPUT«1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 8…»
FROGGS very strange
I wonder
m: say map { $_ }, (1...100)
camelia rakudo-moar 80b912: OUTPUT«1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 8…»
FROGGS ahh!
precedence
m: my @x = grep {$_ < 5}, (1...100); say @x.perl; 11:09
camelia rakudo-moar 80b912: OUTPUT«Array.new(1, 2, 3, 4)␤»
FROGGS andreoss: so, it is not a bug, just surprising
the ',' has a higher precedence than '...', to allow: 1, 2, 4 ... 32 11:10
so grep {$_ < 5}, 1...100 ended up as: (grep {$_ < 5}, 1)...100
11:11 Alina-malina joined
FROGGS m: my @x = (grep {$_ < 5}, 1...100); say @x.perl; 11:11
camelia rakudo-moar 80b912: OUTPUT«Array.new()␤»
FROGGS m: say (grep {$_ < 5}, 1)...100
camelia rakudo-moar 80b912: OUTPUT«1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 8…»
FROGGS but then I'd expected this ---^
I guess it ends up being: grep (({$_ < 5}, 1)...100) 11:13
psch m: say grep { $_ < 5 }, 1
camelia rakudo-moar 80b912: OUTPUT«1␤»
FROGGS m: say grep 1...2 11:14
camelia rakudo-moar 80b912: OUTPUT«␤»
FROGGS what should that do?
psch m: say eager grep { $_ < 5 }, 1 ... 100
camelia rakudo-moar 80b912: OUTPUT«␤»
Rounin m: sub lol{eval("lol();");}; lol();
camelia rakudo-moar 80b912: OUTPUT«===SORRY!=== Error while compiling /tmp/UAlFwxFW6y␤Undeclared routine:␤ eval used at line 1␤␤»
Rounin Aw
FROGGS Rounin: use single quotes? 11:15
Rounin m: sub lol{eval('lol();');}; lol();
camelia rakudo-moar 80b912: OUTPUT«===SORRY!=== Error while compiling /tmp/SUPfyfALMN␤Undeclared routine:␤ eval used at line 1␤␤»
psch EVAL
FROGGS err, EVAL
Rounin It doesn't like eval it seems
m: sub lol{EVAL('lol();');}; lol();
Something seems to be happening
FROGGS a timeout
11:15 tinyblak_ joined
camelia rakudo-moar 80b912: OUTPUT«(timeout)» 11:16
Rounin Ah :)
Thanks, both of you
11:16 andreoss left, andreoss joined
FROGGS m: sub foo { say 42 }; "foo()" # <--- that will call it, and will interpolate the result of foo() into the string 11:17
camelia ( no output )
FROGGS err
m: sub foo { say 42 }; say "foo()" # <--- that will call it, and will interpolate the result of foo() into the string
camelia rakudo-moar 80b912: OUTPUT«foo()␤»
FROGGS O.o
Rounin :D
FROGGS ohh, we need a block there, my bad :D
m: sub foo { say 42 }; say "{foo()}"
camelia rakudo-moar 80b912: OUTPUT«42␤True␤»
11:17 andreoss left
FROGGS weird, I was (for unkown reasons) under the impression that ident+parens would be enough 11:18
11:19 tinyblak left
psch m: sub foo { say 42 }; "&foo()" 11:22
camelia rakudo-moar 80b912: OUTPUT«42␤»
psch m: sub foo { say 42 }; "&foo"
camelia ( no output )
FROGGS[mobile] ahh 11:24
11:41 kaleem left
arnsholt Anyone happen to know if a QAST::Var with :scope<package> will also be found by a ::Var with :scope<lexical>? 11:44
FROGGS we have scope<package>? 11:48
arnsholt: do that: perl6-m --target=ast -e 'our $foo'
and look at the bind at the top 11:49
arnsholt Thought we had. Maybe we don't
FROGGS bbiab
arnsholt Aha. We don't! 11:50
There's a top-level package object that stores it
So I'll probably have to do something similar to get Python's "global" to work properly 11:51
11:54 Ugator joined, bjz left, bjz joined 11:58 darutoko left 12:10 sirdancealot joined 12:13 eternaleye joined 12:16 colomon left, chenryn left 12:23 bjz left
masak good afternoon, #perl6 12:25
moritz good noon, masak 12:26
masak moritz: thinking one more turn about synthetic ASTs and COMPILING::
moritz: I think that kind of dishygiene is the wrong default.
moritz: better to say that a synthetic AST has *no* outer.
and then we could very well provide an .attach (magic) method on synthetic ASTs, that you could call *once* and it'd get the caller's outer. 12:27
or, in Harry Potter terms, you can only apparate to places you've been. 12:28
moritz :-)
masak (which is still very powerful a notion, when you multiply in passing ASTs to closures)
moritz or supply a :scope on the outer-most Q::Thingy.new() 12:29
*to
masak I don't immediately like that alternative better. 12:31
scopes aren't first-class, so one'd have to pass in a callable or something.