[perl #112276] [TODO] Implement 0-arg slurp in Rakudo
# New Ticket Created by Carl Mäsak # Please include the string: [perl #112276] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=112276 moritz p6: say $*IN.slurp.comb(/e/).elems p6eval rakudo 4373f0, niecza v15-6-gefda208: OUTPUT«88» masak r: say slurp.comb(/e/).elems p6eval rakudo 4373f0: OUTPUT«===SORRY!===CHECK FAILED:Calling 'slurp' will never work with no arguments (line 1)Expected any of: :(Any $filename)» masak how come lines() defaults to $*IN, but slurp() doesn't? moritz not $*IN, $*ARGFILES moritz ... and I don't know masak they feel somehow analogous. moritz agreed * masak patches the spec masak oh, and S32/IO already has it that way. it's just that Rakudo doesn't implement it. * masak submits rakudo todo-ticket moritz masak: now spectesting a fix masak moritz++
[perl #112288] [BUG] Non-deducible sequence ending in a Whatever star fails to give an error in Rakudo
# New Ticket Created by Carl Mäsak # Please include the string: [perl #112288] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=112288 moritz r: say 1, 2, 6 ... * p6eval rakudo 4373f0: OUTPUT«...» moritz r: say 1, 2, 6 ... 10 p6eval rakudo 4373f0: OUTPUT«unable to deduce sequence [...] masak moritz: what was that first one? masak is this something out of RT? moritz it is masak oh good :) it belongs there :) moritz r: say ~(1, 2, 6 ... *)[10] p6eval rakudo 4373f0: OUTPUT«» moritz eeks moritz no, that particular thing isn't in RT * masak submits rakudobug
Re: [perl #112288] [BUG] Non-deducible sequence ending in a Whatever star fails to give an error in Rakudo
On Thu, Apr 05, 2012 at 01:46:53PM -0700, Carl Mäsak wrote: moritz r: say ~(1, 2, 6 ... *)[10] p6eval rakudo 4373f0: OUTPUT«» moritz eeks moritz no, that particular thing isn't in RT * masak submits rakudobug For the moment, I'm going to argue Rakudo's behavior here as correct, or at least consistent with the spec. The sequence (1, 2, 6 ... *) produces a list with four elements: 1, 2, 6, and a Failure object containing unable to deduce sequence. This list is then asked for its tenth element, which is Nil (because it's beyond the end of the list), which is what is stringified and printed. Since the Failure object is never used, its associated exception is never thrown. I suppose one could argue that a ... * sequence should produce a non-terminating list of Failure objects; I may see if that works out. Along similar lines, the other mostly eager forms of trying to obtain the Failure end up not working because the ... * part of the sequence signals treat as potentially infinite at this point, which pre-empts the mostly-eagerness. I agree that in most cases a mostly eager operation on a infinite list should probably go ahead and reify a few terms from the sequence first, rather than stopping immediately (e.g. with '...') upon encountering it. But I haven't found a good bright-line rule for handling this in the general case, nor do the Synopses have any good hints about it yet. Pm
