quotable6

query

‘empty block’

result-#moarvm.md

wat, an empty block is slower? o.O :) Can't wait to see the code-gen on this one :P
and sub b {} empty block is 0.97 too
A million empty blocks does 170 million opcode dispatches in moar's interp.c loop. 170 ops per loop seems like quite a lot.

result-#p6dev.md

Found nothing!

result-#perl6-dev.md

that would work similarly to “last” but would imply an empty block that just returns True
Oh, something to pass nqp::if? Did you try just passing in an empty block?
I mean, the analysis for the empty block case is easy, but also not so useful in reality ;)

result-#perl6.md

while we are talking about signatures: yesterday I commented out some code and ended up with an empty block in a Lock.protect:
the error message confused me, but lizmat helpfully pointed out that this isn't an empty block, but a hash. great so far
Basically threads it through an empty block constrained to Regex, which will explode if anything ain't a regex (giving failed typecheck) or pass and give True from the `where`
Voldenet: we usually spell an empty block as {;}, which won't create a spurious state variable as {$} does
And even if I just add an empty block after the `use` of slang module, then it works: `use Recomment; {}`
{ } will be interpreted as a hash rather than an empty block
(and the empty block {} is there to update the $/ variable so that $<n> capture would be in it)
pmurias: you need to insert an empty block ^ I was told this is a bug
what should an empty block return? ()?
if I change empty blocks to return Empty instead of Nil, surprisingly few spectests fail
DrForr: replace the semicolon at line 3 and 5 with an empty block, and remove the unit and its block entirely
lizmat: Yeah, just set it to an empty block or so
How do you make the empty block?
rakudo/qast_restructure: Fix is_clearly_returnless for empty block case.
because inside the {} is an empty block, and empty blocks are Nil
jnthn: I was thinking more along the lines of "empty block needs to be () in list context"
sorear: Well, that's why I was asking what current spec says about what empty block means...
because empty blocks still return Nil
so... empty blocks were changed to return () instead of Nil ?
"empty block return value"
is the empty block still supposed to return Nil?
timotimo: the {} is an empty block that limits LTM
An empty block would do it
I'll probably slow Rakudo down a bit since it doesn't optimize away empty blocks.
*It'll ... otherwise ... jnthn is a meenie ... punnishing poor rakudo for not optimizing away empty blocks.
nqp/toqast: Fix empty blocks.
also, empty block isn't always right; depends on the arguments passed.
ah, I had an empty block in my for loop
oh, well, yes -- if your for loop has an empty block, then the loop takes up 90% of the execution time :)
ah. the error i was getting was actually from somewhere else - i was trying to set an empty block to &debug with &debug = {}, but of course that's an empty hash, not an empty block
but the thing is, there are many places where {} is perfectly fine for an empty block, so we probably also need to treat it as one when binding to Callable
(looking at the code the above is actually not true: void is only returned for empty blocks)
why do you pass % and @ to an empty block?
oh, so it's an empty block, but it has to take parameters
TimToady: if somebody lexically redefines Nil should empty blocks return the value from CORE or the one defined by the user?
btw, for with empty block is allocating quite a lot of memory
mind, that'd have roughly the same effect, if you put an empty block afgter
r31713 | moritz++ | [t/spec] test for RT #76234, interpolating empty block into a string
well, someone might write { ; } if they explicitly wanted an empty block instead of a hash
It'd actually work fine with just an empty block too.
r30869 | pmurias++ | [mildew] converting an empty block to SSA form works
r29643 | fixed AST::Seq->jumps for empty blocks
r29053 | pmurias++ | [mildew-js] empty blocks have a value (TODO make it Nil)
r29056 | lwall++ | [S04] clarify Nil semantics of empty blocks and missing branches, pmurias++
rakudo: Fix NULL PMC accesses in various cases where we have empty blocks. Resolves RT#61034.
masak: probably some stringfication of some value of undef, which the empty block returns
moritz_: how does one write an empty block nowadays?
or was it just empty block elements?
ayrnieu: empty blocks are not allowed any more iirc
hmm, or maybe it just works if you add an empty block after:
agentzh: no. you are evalling an empty block
r11728 | clkao++ | Don't emit empty block for class Foo {}, which causes a warning.
clkao: maybe empty blocks are not defined - I will check
thus the {;} for empty block. which seems the right huffman too. and {,} wouldn't work to go the other way, so... I'm wondering if the test needs to be overruled
Parsing tests for empty strings, empty blocks, extra punctuation that "shouldn't" make a difference, and so on