Damian Conway <[EMAIL PROTECTED]> writes:
> Austin Hastings wrote:
>
>> But what's the vision for p6? My expectation is that the
>> type-checking stuff will be heavily used
>> for:
>> 1- Large scale projects.
>> 2- CPAN modules.
>> I expect that the folks who want to do one-liners will still want to
>> be
>> able to say C<perl6 -MCPAN whatever>
>> So the "strict" bits have to be forgiving of the "non-strict"
>> callers.
>
> To me that's a contradiction in terms. Strictness can't be "forgiving".
> At the risk of stating the obvious, that's the whole point of strictness:
> to be strict.
>
> What we're suggesting is that if you want to be non-strict, don't use types.
> After all, they're optional.
>
> "But," (I hear you say), "I may not have a choice! If the Cruel Module
> Author chose to use types, then I'm forced to do so too. That's not
> Lazy."
>
> And you're right. The module author gets to determine the interface of
> their module. And if they determine that that interface will provide
> type-safety, then you have to respect that. Just as if they decided
> that it would have an OO interface, or would set PRE and POST
> conditions on calls, or would only take named arguments.
>
> Because the author of the module is *relying* on that interface to
> ensure the correctness of their code; to prevent inappropriate data
> being passed to their subroutines. Typing is yet another way in which
> they can relax, knowing that the wrong type of data will be headed off
> at the (compiler) pass.
>
>
>> To me, the way around this is NOT to force interface contracts down to
>> some lowest common denominator, but rather to document what is
>> expected, and then allow the developer to accept responsibility for
>> stepping on his crank.
>
> Yep. And the way for the client of some module to accept that
> responsibility is to put in an explicit conversion.
Of course, a module author could always layer on a 'non strict'
version of the interface that did the type conversions itself before
passing them into the more stringent internals.
>> But at the bottom, the C++ problem is a problem of its own making --
>> people want coercion. Just like me. I want coercion. I want the ability
>> to take advantage of the really nifty, carefully written code available
>> from dedicated, rigorous hackers like this Conway fellow. But I want to
>> do it as a slap-dash hack with no thought given to type stuff. How?
>
> By distinguishing a parameter that *requires* a particular type, from
> a parameter that *ensures* a particular type (by coercion if
> necessary). I've suggested that using C<is copy> semantics should
> indicate "make whatever I'm actually given into one of these, if you
> can", whereas reference semantics say "this must already be one of
> these" (by their very nature, since an aliased parameter *is* the
> argument).
>
> Alternatively, one might imagine a separate and explicit trait that
> specifies that a parameter is allowed to coerce its corresponding
> argument to it's own type.
But this would be better. And implementable relatively easily as a
macro if it weren't availabe in the core I would have
thought. Hm... it might be interesting/useful to implement a set of
macros to allow developers to define and export their own traits:
trait foo (...) is ParameterTrait {
COMPILATION_CHECK {...}
RUNTIME_CHECK {...}
}
(There's almost certainly a better syntax available mind).
--
Piers
