>>>>>> "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


Reply via email to