Backtracking syntax
Me
:, ::, :::, <commit>, <cut>
I like the way the ':' looks in patterns. But I noticed I have
several niggles about a number of other aspects of the
above syntax. All the niggles are minor, individually, but
they added up to enough that I thought I'd see what the
bikeshed might look like in another color.
First, the niggles:
1. It's nice how the ':', '::', and ':::' progression indicates
progressively wider scope. But I would be surprised if
newbies don't say to themselves, "now just how wide a
scope am I backtracking when there's three colons?".
2. Typo-trap: I can imagine it being fairly easy for some
people to miss, during debugging, both the visual and
behavioral distinction between '::' and ':::'.
3. It seemed odd how the <commit> and <cut> assertions
switch to the general <...> syntax. I felt like it would be better
if they avoided the general syntax, and preferably had some
family resemblance with the first three backtracking controls.
So, how about something like:
: # lock in current atom, ie as now
:] # lock in surrounding group, currently ::
:> # lock in surrounding rule, currently :::
:/ # lock in top level rule, currently <commit>
:// # cut
Thus, redoing a couple examples from synopsis 5:
m:w/ [ if :] <expr> <block>
| for :] <list> <block>
| loop :] <loop_controls>? <block>
]
rule subname {
([<alpha>|_] \w*) :/ { fail if %reserved{$1} }
}
m:w/ sub <subname>? <block> /
--
ralph
Simon Cozens
> 1. It's nice how the ':', '::', and ':::' progression indicates
> progressively wider scope. But I would be surprised if
> newbies don't say to themselves, "now just how wide a
> scope am I backtracking when there's three colons?".
Why would newbies be writing three-colon regexes?
--
<dhd> even though I know what a 'one time pad' is, it still sounds like
a feminine hygiene product.
Me
> > 1. It's nice how the ':', '::', and ':::' progression indicates
> > progressively wider scope. But I would be surprised if
> > newbies don't say to themselves, "now just how wide a
> > scope am I backtracking when there's three colons?".
>
> Why would newbies be writing three-colon regexes?
By "newbie" I meant it in a relative sense, ie. someone who
is learning those particular features. The newbie could be
an expert in Prolog and Perl 5.
And I'm more concerned about when they are reading some
existing patterns than when they are writing one.
--
ralph
Markus Laire
>
> :, ::, :::, <commit>, <cut>
>
> progressively wider scope. But I would be surprised if
> newbies don't say to themselves, "now just how wide a
> scope am I backtracking when there's three colons?".
What problem there is? Scopes are atom/group/rule - I don't see any
possible misunderstanding there as these scopes are so natural.
> 2. Typo-trap: I can imagine it being fairly easy for some
> people to miss, during debugging, both the visual and
> behavioral distinction between '::' and ':::'.
If that really is big problem, it can be solved easily by using
proper editor which supports high-lighting.
::: could be shown with different color or bold while :: uses some
other syntax.
> 3. It seemed odd how the <commit> and <cut> assertions
> switch to the general <...> syntax. I felt like it would be better if
> they avoided the general syntax, and preferably had some family
> resemblance with the first three backtracking controls.
>
> So, how about something like:
>
> : # lock in current atom, ie as now
> :] # lock in surrounding group, currently ::
> :> # lock in surrounding rule, currently :::
> :/ # lock in top level rule, currently <commit>
> :// # cut
I find :,::,::: to be a lot easier to remember than :,:],:> - and
also easier to type.
While <commit> and <cut> don't follow same syntax, I don't really see
any better solutions. Better solution should IMHO keep :,::,::: and
offer better alternative only to <commit>.
<cut> doesn't really belong to this serie as it's different
backtracking-operation and so it can and should have different
syntax.
I wonder if :::: might be usefull instead of <commit> with proper
syntax-highlighting.
--
Markus Laire 'malaire' <markus...@nic.fi>
Simon Cozens
> While <commit> and <cut> don't follow same syntax, I don't really see
> any better solutions.
<commit> is sufficiently "hard" that it musn't be confused with the
colon series.
> I wonder if :::: might be usefull instead of <commit> with proper
> syntax-highlighting.
Yeah. :: should show up in bold, ::: in bold with a red background, and
:::: should blink.
--
I would imagine most of the readers of this group would support abortion
as long as fifty or sixty years after conception for certain individuals
- Michael Stevens
Markus Laire
> markus...@nic.fi (Markus Laire) writes:
> > While <commit> and <cut> don't follow same syntax, I don't really see
> > any better solutions.
>
> <commit> is sufficiently "hard" that it musn't be confused with the
> colon series.
Yes, I didn't think that enough.
:,::,::: only affects current rule while <commit> goes further to
possibly affect other rules also, so it must have different syntax.
Steve Fink
> So, how about something like:
>
> : # lock in current atom, ie as now
> :] # lock in surrounding group, currently ::
> :> # lock in surrounding rule, currently :::
> :/ # lock in top level rule, currently <commit>
> :// # cut
I kinda like it, since :: and ::: look very similar to me, too. (I
don't buy the syntax highlighting argument, partly because I often
encounter code in b&w printouts, perlmonks, or wherever.) Though I'd
probably prefer <cut> stayed <cut>. And those mismatched brackets
bother me, too. What about
: -> :
:: -> :[] or [:]
::: -> :<> or <:>
<commit> -> :// or /:/
<cut> -> :<cut> or :cut or <:cut> or just stay <cut>
Then again, I've never been convinced of the similarity between : and
::. To me, a single colon is modifying another operation, so it's like
the ? non-greedy modifier. Is that incorrect? Everything else does
something when backtracked over; the only thing : has in common with
them is that it has something to do with backtracking.
Btw, is /:/ ambiguous? I can't remember if there's any way a /pattern/
can be followed by a colon.
Staring at the third column above, I can't help wondering if [:cut],
<:cut>, and /:cut/ would all be useful. But not enough to really think
about it and figure out what they would mean, exactly -- my brain and
<cut> are still having some marital difficulties.
> Thus, redoing a couple examples from synopsis 5:
>
> m:w/ [ if :] <expr> <block>
> | for :] <list> <block>
> | loop :] <loop_controls>? <block>
> ]
>
> rule subname {
> ([<alpha>|_] \w*) :/ { fail if %reserved{$1} }
> }
> m:w/ sub <subname>? <block> /
m:w/ [ if :[] <expr> <block>
| for :[] <list> <block>
| loop :[] <loop_controls>? <block>
]
rule subname {
([<alpha>|_] \w*) :// { fail if %reserved{$1} }
}
m:w/ sub <subname>? <block> /
or
m:w/ [ if [:] <expr> <block>
| for [:] <list> <block>
| loop [:] <loop_controls>? <block>
]
rule subname {
([<alpha>|_] \w*) /:/ { fail if %reserved{$1} }