On Fri, Sep 17, 2004 at 05:15:58PM +0200, Juerd wrote:
: Jonathan Scott Duff skribis 2004-09-17 9:57 (-0500):
: > [foo]~5 # match exactly 5 times
: > [foo]~{0...} # verbose [foo]*
: > [foo]~{1...} # verbose [foo]+
: > [foo]~{1..5} # match from 1 to 5 times
: > [foo]~{[1,3,5]} # match exactly 1, 3, or 5 times
: > [EMAIL PROTECTED] # treat each element of @foo as a
: > # number and only match that
: > # many times. (same as previous
: > # basically)
: > [foo]~{&foo} # match based on the return value of &foo
: > [foo]~{%foo} # ???
: > And surely these can be made to work:
: > [foo]~[0...] # [foo]:[0...]
: > [foo]~[1,3,5] # [foo]:[1,3,5]
: > [EMAIL PROTECTED] # [foo]:@foo
:
: Easier:
:
: Variable Literal
:
: \d~$foo \d~5, \d~1..5 # Range object or integer.
:
: [EMAIL PROTECTED] \d~[...] # \d~any(...)
:
: \d~&foo \d~{...} # Depending on what the closure returns.
:
: Obviously, $foo can also be an arrayref or coderef.
:
: I think whitespace around the ~ can be made valid without making
: anything ambiguous. The expression at its right side should not have
: whitespace in it. If it does have whitespace, [] or {} is needed to
: disambiguate.
Sigh. It's easy to make random suggestions. It's hard to actually
design a language in which easy things are easy and hard things
are possible. Generalized quantification is one of those things
that should merely be possible. It doesn't rate dangling syntax.
It doesn't rate a bunch of optional syntaxes. It doesn't rate a new
bunch of whitespace dependencies. It especially doesn't rate a new
metacharacter! I'm not just picking on you--everyone on this list
should be trying to pick up some of these basic underlying design
principles as we go along, and reminding each other of the design
principles rather than just going off on non-productive tangents.
Otherwise I'll just end up wasting more of my breath in the future
justifying what seem to me to be fairly obvious decisions. Mind you,
it's kind of fun to shoot down bad ideas, but it's probably bad
for me spiritually.
Larry
