Killing Off Historical "SKIP" in PARSE

SKIP suggests you're not using the result. Yet historical SKIP doesn't really do that:

rebol2> parse [1] [set x skip]
rebol2> x
== 1  ; How was this "skipped" exactly?

After contemplation of many possibilities for what this might be (including *, or <*>, or ?, or just plain period (.), I settled on <any>.

>> parse [1] [x: <any>]
>> x
== 1

I'm quite happy with it--especially in light of removing ANY as a looping combinator from the default combinator set. It brings ANY to its coherent systemic meaning of ANY-ONE-OF... as opposed to ANY-NUMBER-OF.

But @IngoHohmann suggested that SKIP might be related to ELIDE. So I tried:

>> uparse "ab" ["a" skip]
== "a"

This would make SKIP equivalent to ELIDE <any>.

But SKIP as ELIDE <ANY> IS RARELY USEFUL, AND CONFUSING

If you want ELIDE <ANY> just write that.

The general skip takes an argument of how much to skip, and having a PARSE analog to SKIP that takes no argument is just confusing.

It may be that SKIP taking an argument is worth having:

>> uparse "aaab" [skip (3) "b"]
== "b"

But then we have to decide what SKIP returns:

>> uparse "aaab" [skip (3)]
== ???

And you can say that particular case with 3 <any> and it's shorter.

Either Way, the Historical Use Is Pointless

So SKIP is not in UPARSE. Maybe it will have a reinvention some day with a new meaning.

Seems to me, that skip would be the natural name for your elide.

2 posts were split to a new topic: OMIT vs ELIDE

Since I'm making a new bootstrap executable to facilitate FENCE!, I'm patching it to modern behaviors for PARSE3. This includes the behavior of SKIP as being arity-1 and taking how much to skip.

I'm quite pleased with most UPARSE redesigns, including that one. But the substitute for "match any single item" being the <any> tag gave me pause to ask "does this feel right, in light of modern understandings?"

I think I've come to believe that TAG! combinators are all arity-0, which <any> is. But most other tag combinators synthesize things from midair without advancing the input. Not advancing the input might be a good rule for a tag combinator?. Perhaps that's over-restrictive.

Might it be better if it were just one?

>> parse [1020] [x: one]
>> x
== 1020

It might suggest a class of combinators that captured more items (two, three, etc.). Hence they would be a worse choice than e.g. skip 2 if you didn't want to synthesize the values, so hopefully people wouldn't reach for them unless they really wanted blocks. But that would create an irregularity that ONE wouldn't make a block when the others did (if ONE gave back a block, it means the captured thing was itself a block). Or maybe it's a PICK where the series is implicit?

>> parse [1020 304] [x: two]
>> x
== 304

(That would make it seem like it should be FIRST and SECOND instead of ONE and TWO, but I don't particularly like FIRST for this... I don't think.)

I think I like ONE. It's easy to type, and I think it seems more meaningful than <any>. Especially when there is an ANY combinator that does something more related to the non-PARSE ANY.

We could also have an arity-0 NEXT combinator that could return the next position, if you were trying to convey more that you were just skipping ahead and not intending to take any input.

1 Like