On Wed, Dec 08, 2004 at 11:09:30AM -0700, Patrick R. Michaud wrote:
: On Wed, Dec 08, 2004 at 08:19:17AM -0800, Larry Wall wrote:
: > And people would have to get used to seeing ? as non-capturing assertions:
: > <?before ...>
: > <?after ...>
: > <?ws>
: > <?sp>
: > <?null>
: > This has a rather Ruby-esque "I am a boolean" feeling to it. I think
: > I like it. It's pretty easy to type, at least on my keyboard.
:
: FWIW, for some reason in rule contexts I tend to conflate
: "I am a boolean" feelings with "zero-width assertion", so that each
: of those look vaguely to me as though I'm testing a zero-width
: proposition and not consuming any text. And I still tend to think of
: '?' in it's "zero or one matches" or "minimal match" connotations.
: Oh well, I suppose I could get used to that.
Yes, there are those interferences, which was one of the reasons for
removing ? the last time we had it in that position (albeit on the
captures rather than the non-captures). I think we'll have to let
it set a while to see how it feels in this role. For the purpose of
being a non-alpha no-op, any other non-alpha character would do as well,
so maybe the "I am a boolean" feeling is not that useful.
: > Now suppose that we extend that "I am a boolean" feeling to
: > <?{ code }>
: > which might take the place of the confusing <(...)>, and make consistent
: > the notion that we always use {...} to invoke "real" code.
:
: Hmm, this is nice, however.
In some ways, and not so nice in others, as Luke pointed out.
: > Another problem we've run into is naming if there are multiple assertions
: > of the same name. If the capture name is just the alpha part of the
: > assertion, then we could allow an optional number, and still recognize
: > it as a "ws":
: > <ws1> <ws2> <ws3>
: > Except I can well imagine people wanting numbered rules. Drat. Could
: > force people to say <ws_1> if they want that, I suppose.
:
: I had been thinking that
:
: /<ws> <foo> <ws> <bar>/
:
: would simply cause $<ws> to be a list of captured elements, similar to
: what might happen for $1 in
:
: / [ (.*?) , ]* /
That's what happens by default whenever there is a name conflict. This
would just be a way of giving a rule a "long name" as well as a short one,
much like &abs<complex> is the long name of &abs when dispatched on a
complex number, whereas &abs is just the set of all abs() multis, if
there is such a beastie.
: If someone really needs the contents of the first and second <ws>, they
: could do
:
: (<ws>) <foo> (<ws>)
:
: and get them as $1 and $2. But, seeing this tells me that perhaps
: <(rule)> should be used for capturing rules, analogous to the
: capturing parens, and leave <rule> to be the non-capturing version.
: But maybe that's anti-Huffman overall. Maybe the parens could also
: help for disambiguating
:
: <(ws)> <foo> <(ws)>
:
: so that we end up with $/<ws>[1], $/<ws>[2], etc. But then we might
: have to always subscript our named captures, which is icky, or maybe
: we'd only make $/<ws> act like list when there's more than one
: capturing <(ws)> in the rule.
:
: I dunno. I kinda like <(rule)> for capturing, but maybe it just
: doesn't work.
I thought about that a long time, which was part of the reason I also
thought about freeing up <(...)>. But it just seems a little icky
to mix together the named captures and numbered captures visually if
not semantically. It starts not being at all clear which parentheses
count and which ones not. Which is perhaps another reason for changing
current <(...)> to <?{...}>.
We could, I suppose use a subscript inside:
<ws[0]> <foo> <ws[1]>
<ws«first»> <foo> <ws«second»>
but then you'd reference it as
$<ws>[0]
$<ws><first>
which is a gratuitous difference, and suffers the same problem as
the parenthese in confusing real arrays/hashes with sorta fake ones.
So I think we'll stick with the hyphen names for now, which have the
benefit of looking the same and not sending us to bracket heaven.
<ws-1> <foo> <ws-2>
<ws-first> <foo> <ws-second>
$<ws-1>
$<ws-first>
Larry
