Moritz observed:
> And here the problem already starts. Signatures with where-blocks can't
> by compared by a Turing machine. At least we know which signatures we
> can compare and which we can't. So we need to think about that case too.
Indeed. Although it's not as bad as it might be. A where-bl
Carl (>>), Damian (>):
>> class A {
>> method foo($x) {
>> PRE { $x < 10 }
>> # ...
>> }
>> }
>>
>> class B is A {
>> method foo($a, $b, $c) {
>> PRE { [>] $a, $b, $c }
>> # ...
>> }
>> }
>>
>> When C is called, are
On 03/11/2012 02:11 PM, Moritz Lenz wrote:
> Just a small syntax nit: I think your example of 'will require BLOCK' is
> a violation of the rule that we shouldn't have two terms in a row.
Never mind, trait_mod:will is special-cased to allow that:
token trait_mod:will {
:s
}
I
On 03/11/2012 03:21 AM, Damian Conway wrote:
> Carl asked:
>
>>class A {
>>method foo($x) {
>>PRE { $x < 10 }
>># ...
>>}
>>}
>>
>>class B is A {
>>method foo($a, $b, $c) {
>>PRE { [>] $a, $b, $c }
>># ...
>>
Carl asked:
>class A {
>method foo($x) {
>PRE { $x < 10 }
># ...
>}
>}
>
>class B is A {
>method foo($a, $b, $c) {
>PRE { [>] $a, $b, $c }
># ...
>}
>}
>
> When C is called, are both C blocks meant to b
We've made great leaps in phaser technology from S04 in Rakudo in the
past week. We used to have C, C, C, and C.
Now we also have C, C, C, C, and (for C
loops) C, C, and C. In his latest blog post [1]
jnthn++ says he'll move on to C and C but that he'll "need
some spec clarifications first".
This
