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-block on a parameter
can be viewed as an implied 'requires', while an where-block on a return type
is like an implied 'ensures'.
So if you have a base-class method with a 'where' on its parameter and a
derived-class method without a 'where' on the corresponding parameter,
you're okay.
And likewise, if a base-class method has no a 'where' on its return type
and the return type of the corresponding derived-class method does have
a 'where', your still okay.
On the other hand the other four cases:
* method Base::foo($x) {...}
vs
method Der::foo($x where {something}) {...}
* method Base::foo(--> Type where {something}) {...}
vs
method Der::foo(--> Type) {...}
* method Base::foo($x where {something}) {...}
vs
method Der::foo($x where {something_else}) {...}
* method Base::foo(--> Type where {something}) {...}
vs
method Der::foo(--> Type where {something_else) {...}
could all quite reasonably be presumed to be (at least potential) Liskov
violations and loudly complained about:
Possible Liskov violation on Der::foo() parameter $x at Der.pm line 42
(The 'where' makes it potentially more restrictive than in the base
class method it overrides. Bad programmer! No DbC for you!!!)
As long as we can support decidable cases and report undecidable cases,
I think that's enough.
> Though of course then we need a mechanism to silence that warning.
no warnings :DbC;
or perhaps:
no warnings 'Liskov? Hah! I guffaw at your primitive Earth
superstitions!!!' => 1;
>> And, yes, this does indeed imply a syntax for optionally naming the
>> return value in a signature (which syntax seems to fall out quite
>> naturally in any case).
>
> Or we simply reuse the convention from POST and CATCH that the
> interesting value (either exception or return value) is passed in as $_.
But that's less explicit and obvious than named return values! :-(
Not to mention much less "Nyah, nyah, Haskell...look what we've got!!!". ;-)
Damian
