[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposed features for branching logic + minimal implementation

From: Liam Quinlan
Subject: Re: proposed features for branching logic + minimal implementation
Date: Fri, 9 Oct 2020 02:55:09 -0400

(assignment form follows)

The strictly shorthand commands (j/J) are sugar, and if they seem
unnecessary that's perfectly fine.  They do, however, significantly
declutter things in incremental patterns (ones that test often, but not
after *every* replace).  For instance:
    [ clear condition ];  s/more_work_case/handled?/;  [ test for branch ];
You might repeat a pattern like this often while building up your logic.
And at each [ clear condition ] step, the flag must be reset, or it will be
in unknown state.
As far as I'm aware, the best existing mechanism is currently ':n;tn;'.
Which works, but feels kludgey and ugly... especially when, a handful or so
in, you start hunting around the keyboard for label names. *laugh*
I find I appreciate the readability difference, especially for keeping my
labels straight in my head.
   '...;  ...;  j;  ...;   t2;  ...;  j;  ...;  @{ ...;  j;  ...;  t2;
 ...;  } ...;  t3;  '                                             (2 names
to think about)
   '...;  ...;  :4; t4;  ...;   t2;  ...;  :5; t5;  /.../{ ,,,;  :6; t6;
 ...;  :7; t7;  ...;  t2;  ...;  } ...;  t3;  '   (the good-case equivalent)

Note that due to needing the (possibly long af) pattern written out only
once, the test-address style also gains on tidiness... that's not what I
meant by good-case equivalent.  This is the good case (for the existing
style) because accomplishing it is relatively straightforward to actually
accomplish.  This is not true in other cases.
For instance, you may need a sequence where, instead of clearing the flag
immediately beforehand, you *want* to "or together" the results from
several match/replace steps.  For those cases, you can hopefully decompose
things enough to disentangle your sub-cases and handle them seperately...
but maybe not.  Replaces are inherently destructive.  Working against that
gets noisy and hard to coordinate.

Speculative and probably irrelevant, but there is also a part of me that
can't help see ":x;tx;" as "function call; branch miss, go parse another
one."  Which is... well, eh.  Sets thing to zero.  Feel how you feel about
it ;)

The "complement" command is a little more obscure, but it is interesting
when you are tracking state along several logical branches and wish to keep
them distinguishable.  Its value lies in giving you a knob to turn when
setting up your comparison that *doesn't* clobber any information.
It's bitwise not.  You know what I'm saying, right?

I would find it kind of exhausting to describe the minutia, but one of the
bigger things that prompted this was a (couple shots at at) "parse cpp -E,
extract arbitrary function definition" script with some sort of robustness.



[What is the name of the program or package you're contributing to?]

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]

[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]

[For the copyright registration, what country are you a citizen of?]

[What year were you born?]

[Please write your email address here.]

[Please write your postal address here.]
unit 1
205 Weber Street East
Ontario, Canada
N2H 1E5

[Which files have you changed so far, and which new files have you written
so far?]
files touched (relative to project root):
Sounds like more than it is.  No new files.

On Thu, Oct 8, 2020 at 12:05 AM Assaf Gordon <> wrote:

> Hello,
> On 2020-10-06 4:47 p.m., Liam Quinlan wrote:
> > I would like to propose four related additions to the sed toolbox
> > (represented below, arbitrarily, as '@', 'k', 'j', and 'J').  In my
> > opinion, these additions improve sed's usability near one of its
> > weaknesses (restricted branching logic), and represent a solid value
> > proposition in light of their minor code change requirements.
> Thank you for this suggestion and for providing the code - that's an
> excellent start.
> For any contribution to be incorporated into GNU sed
> (or even evaluated / considered), we first ask the contributor to assign
> copyright of the code to the FSF.
> You can read more about it here:
> To start the process, please fill and send the following form:
> ---
> Now to the actual patch:
> Looks interested, but may I ask for some specific use cases where each
> short-hand command would be used, and be a clear improvement over the
> existing commands ?
> regards,
>   - assaf

reply via email to

[Prev in Thread] Current Thread [Next in Thread]