In the test suite and on IRC there was quite some confusion about how
list builtins are specced, and how they should behave in corner cases.
One is join():
our Str multi method join ( @values: Str $separator = ' ' )
our Str multi join ( Str $separator = ' ', [EMAIL PROTECTED] )
It is quite clear that the perl 5-style
join 'sep', $value, $value2;
invocation remains valid, and
@list.join($sep)
is the new method form.
The confusion arises what to do with
'str'.join('other_str')
should be.
Fallback semantics in S12 suggest that since no matching multi method is
found, subs are tried - that is, the expression is interpreted as
join('str', 'other_str')
yielding 'other_str'. t/spec/S29-list/join.t disagrees, and wants the
result to be 'str'.
Daniel Ruoso argued in favour of the tested behaviour, suggesting that
perhaps the specs should be updated accordingly, mostly because
('str').join('other_str')
would be confusing otherwise.
Patrick Michaud argued in favour of the specced behaviour, and I agree.
Mostly because nobody sane will write things like
'str'.join('other_str') with a literal string as the invocant in first
place. And if it's not a literal, and you want it to behave as list, the
invocant is either something that returns a list, or a variable with the
'@' sigil. We just need to be careful that everything that should return
really does that, even if it contains a single list.
Currently both pugs and rakudo make <a b> return a list (pugs actually
an array, but that's a different problem), but <a> is a Str.
If we'd just be more consistent and always return a list, I don't see a
problem with the spec. If not, it would be rather weird to have <a
b>.join('c') return 'abc', but <a>.join('c') return 'c'.
Consider
my $x = A.new();
$x.y = <a>;
say $x.y.join('b')
The output is different for the two possible declarations of class A:
class A { has $y is rw } # -> b
class A { has @y is rw } # -> a
not pretty IMHO.
So I see the following options:
1) be more consistent with what returns a list
2) Add a method with invocant Any for each list builtin
3) drop method fallback, thus disallowing Str.join(Str) outright
4) be lisp, make everything a list *g* (not serious)
I haven't thought a lot about the third option, and what it would mean
to the language as a whole, so I have no idea if it's a viable alternative.
Any thoughts on the topic are welcome. I hope I didn't confuse too much
here ;-)
Cheers,
Moritz
--
Moritz Lenz
http://moritz.faui2k3.org/ | http://perl-6.de/
