This started out some weeks ago as a user in #perl6 confused by an error
that gofled down to:
[28 19:01:37] <geekosaur> m: my Bool $x = False; $x()
[28 19:01:38] <camelia> rakudo-moar 0dc6f7: OUTPUT«No such method 'CALL-ME'
for invocant of type 'Bool'
This is, at the very least, LTA. But it also got me thinking about the spec.
The obvious way to clean up the above, and some more complicated things of
the same sort, is to hide the obviously-internal CALL-ME behind a role,
which arguably should be part of the spec as well to let implementations
provide a stable interface while doing whatever is necessary for the
backend in its implementation. The obvious name for this role is Callable.
But, we already have a role Callable which is a mixin that adds
functionality to things that are callable, and is part of 6.c's spec. This
seems like a design flaw, and looks like it's going to be hard to fix, or
at least to make rational when other roles describe things that *are*
something instead of describing what they *modify*.
Is there a way forward on this that makes any sense?
(for the record, the proposed wrapper role looks something like
role OughtToBeCallable { # bikeshed pending paint job...
method CALL(|c) {...}; # CALL-ME happens here
}
and the 4 places that currently build a CALL-ME in nqp would have a type
OughtToBeCallable added so that the runtime CALL-ME error becomes a
compile-time failed OughtToBeCallable constraint with a user-comprehensible
error.)
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
