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
