Jonathan Lang writes:
> Larry Wall wrote:
> > So far we've only allowed "is parsed" on the macro itself, not on
> > individual arguments. Still, that's an interesting idea.
>
> Forgive me if this has already been addressed, but this could have some
> useful applications:
>
> So far, everything I've read about macro parsing concentrates on parsing
> the positional arguments; I haven't seen anything about how to go about
> defining a custom parse rule for the list arguments. In particular, I'm
> thinking about something along the lines of:
>
> macro element(name, [EMAIL PROTECTED] is parsed /\s+/)
> is parsed / \< /? (<QName>) \s* (.*?) /? \> /
> {...}
>
> where the "is parsed" trait of the list parameter defines a rule used to
> split the string fed into it into a list of arguments.
You can only "split" what is passed in as much as you can split a parse
tree. The best one can do here is grab text, split, and reparse each of
the segments. That's not hard to do manually, and I think it best be
done manually. There's only so much complexity you can pack into a
signature and still make it thinkable.
> I could see something similar being done for named parameters, but you'd
> need to define both a "split" rule and a name-vs-value parse rule, and
> you'd have to address if (and if so, how) a named parameter can be
> inserted between positional and/or list parameters.
Again, too much complexity for the payoff. Code it manually. (Which
might mean using a proxy sub to do the parsing, which forwards the call
along to the "content", so you can get Perl's semantics with your
syntax).
As much as I do like adding useful features to the language, I do think
we have to solve our own problems *sometimes*.
Luke
