skids

ok 364 - RT #99942
ok 365 - reduce with X
    1..2
    ok 1 - '[leg] <a b c>' died
    ok 2 - right exception type (X::Syntax::CannotMeta)
ok 366 - non-associative operator "[leg]" can not be used as reduction operator
ok 367 - does  [:a] parse ok and give the right value
ok 368 - does [:a,] parse ok and give the right value
ok 369 - does [:!a] parse ok and give the right value
# Looks like you failed 7 tests of 369

skids

Be careful not to accidentally commit this.

$ perl6 -e 'my $a = (1,2,3).values;  sub a { $a.iterator }; a(); $a.iterator;'
This Seq has already been iterated, and its values consumed
  in sub a at -e:1
  in block <unit> at -e:1

Actually thrown at:
  in any  at src/gen/m-Metamodel.nqp:2867

skids

Also... jerry-rig sprintf to work for most purposes

diff --git a/src/core/Cool.pm b/src/core/Cool.pm
index e3e3a29..2c975ce 100644
--- a/src/core/Cool.pm
+++ b/src/core/Cool.pm
@@ -343,10 +343,10 @@ sub sprintf(Cool $format, *@args) {
         $sprintfHandlerInitialized = True;
     }

skids

use v6;
class A {
has $!a;
method a is rw {
Proxy.new(
FETCH => -> $self { $!a },
STORE => -> $self, $v { $!a = $v }
);
}
}

skids

I did a bit of a dive into IRC logs on "implicit *%_".

I hope the following is a fair representation of arguments
for and against a spec-change.


TL;DR:  Keeping or removing implicit *%_ will not prevent
people who prefer to do things "the other way" from doing so
anyway, though it may have a cultural impact and may affect

skids

On the subject of whether methods should have implicit *%_ or not I figured
some side-by-side examples would be useful to help the community come to
a decision.

Note that Mu.new will still have a prototype of *%_.  So banning
unknown named parameters will require custom constructors in either case,
so we'll use them in the examples.

EXAMPLE: Only allow one optional/default argument to a method

skids

# This file can be run to compare current rakudo behavior with
# that of the PR.  The expected results with the PR applied
# are in the comments.  Also this is fodder for new spectests.

Exception.new.say;        # Unexplained error (Exception)
Exception.new.gist.say;   # Unexplained error (Exception)
Exception.new.Str.say;    # Inchoate error of class Exception
Exception.new.perl.say;   # Exception.new
X::AdHoc.new.say;         # Unexplained error

skids

# At http://irclog.perlgeek.de/perl6/2015-06-27#i_10814220 I mentioned
# the concept of a rule that matches strings contained in a baggy thing
# only as many times as they appear in the bag as a litmus test for
# the current limitations of using Cursor and/or dynamic state inside
# grammars.

# On more examination the limitations are not as bad as I initially thought,
# but they are still prohibitive to making something like that work.

# First, here's why I thought Cursor was a bit broken:

skids

# POC second approximation to .assuming
#
# Try to break it (probably won't be too hard to at present.)
#
# This implements things like &foo.assuming(1,*,2,Nil,3) according
# to the special meanings specced for Nil and *.
#
# It also does something else which is not specced:
#

skids

Further investigation of RT#117043.

1) It is specced (via STD and from there RT#116607 and from there
S32-exceptions/misc.t) that sigilless my variables must have an
initializer.  I could not find an explanation as to why.

$ perl6 -e 'my (\a);'      # no error
$ perl6 -e 'my \a;'        # intended error
===SORRY!=== Error while compiling -e
Term definition requires an initializer