>>>>>> "m" == moritz <mor...@casella.faui2k3.org> writes:
>
> m> S02 says:
>
> m> "To get a Perlish representation of any object, use the .perl method.
> Like
> m> the Data::Dumper module in Perl 5, the .perl method will put quotes
> around
> m> strings, square brackets around list values,"
>
> m> So according to this, Rakudo has it right.
> m> But I think that a .perl()ification as ("blue", "light", "hayard",)
> would
> m> make much more sense, because simple thing like
>
> m> @a.push eval(@b.perl)
>
> m> would then DWIM.
>
> for your def of DWIM. i can see wanting an anon array to be pushed onto
> @a building up a structure.
DWIM in the sense that "eval($stuff.perl)" should behave the same as
$stuff itself.
since @a.push(@b) flattens @b into @a, why should I expect something
different from @a.push(eval(@b.perl))?
> your example is too simple to really cover
> this as you could just push @b or a ref to @b (damn, i need to learn
> more basic p6 syntax! :).
If people want @a.push(\...@b) or @a.push([...@b]), they can just write that -
and if the want to use eval + perl, they can include the brackets or
backslash just as well.
> a more useful example would be serializing data trees. if you dump @b
> with .perl do you want the current dumper output of a anon array or your
> list of values? when serializing a tree, you must get the ref version so
> that is the common and default usage. your version isn't DWIMmy there at
> all.
Maybe we can construct something magic with slice context and captures
instead?
Cheers,
Moritz
