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