GET-GROUP!s in PARSE mean "execute and splice as rule"

[hostilefork]

Okay, this thread is five years old, so there's a lot to clean up and process here...

@hostilefork

I was confused by it, because I thought that IF was arity 2 and was running the rule after it. But it doesn't run any rule at all, it just directs continue-or-not.

The confusingness has been resolved by renaming this to WHEN.

@hostilefork

One thing I notice about the evaluative parity of literal blocks and regular blocks is that it can act as a comment, of sorts:

 either condition [  ; code fragment producing parse rule
      blah blah blah
      '[some "a"]
 ][
     blah blah blah
     '[thru <terminal>]
 ]

You can't do this anymore if you expect binding to work on those blocks. Keyword recognition (like SOME and THRU) is done literally, so you can do some things without binding...but if you have any variables you want to refer to that won't work. You need to use e.g. $[some "a"] or just [some "a"], which are synonyms in this context.

@hostilefork

If the expression inside the GET-GROUP! evaluates to a null, it splices nothing into the rule stream.

@hostilefork

I proposed another I-think-awesome feature in chat, which is that LOGIC! #[true] be a no-op in parse (same as BLANK!) while #[false] not match anything.

There is no more #[true] and #[false], only ~okay~ and ~null~ antiforms for logic.

NULL counts as no match. OKAY continues and vaporizes (synthesizes NIHIL). VOID continues and synthesizes void.

GET-GROUP!s in PARSE mean “execute and splice as rule”

Leading colon will no longer mean "GET" of anything.

There's no technical reason we couldn't continue to have this done by "GET-GROUP"--which is really a CHAIN! with a BLANK! at the head and a GROUP! in the second slot. I just don't like it anymore. (To be honest, I never really liked it very much in the first place.)

So we need another answer.

THE-GROUP! can't be the answer, because THE means match the thing literally:

>> block: [some rule]

>> parse [[some rule] [some rule]] [some @block]
== [some rule]

So in its group form, @(...) means synthesize a value from an expression and then match that exact value.

I don't think anything fits particularly well here symbolically in the current model. There's no reason it couldn't just be done with a keyword... I've likened this to PARSE's version of REEVALUATE (REEVAL), so maybe it could be called REPARSE...better suggestions welcome:

>> parse [a b b a] ['a reparse (if 1 = 1 '[some 'b]) 'a]
== a

Leading slash would be an option, were we to consider it to be parallel to asking to run things in the evaluator, and that would make some sense:

>> parse [a b b a] ['a /(if 1 = 1 '[some 'b]) 'a]
== a

Currently I use slashes for "action combinators", to indicate you want to run a regular function and have it gather its args through parse.

Action combinators are very useful--and in general perhaps more useful than retriggering groups as rules.

We'll also have FENCE!...and I don't know what FENCE! is going to do. But I don't think it should be doing this.

Maybe It's Time To ((Go Back To Doubled Groups))

When the feature was first conceived, it used doubled-up groups.

>> parse [a b b a] ['a ((if 1 = 1 '[some 'b])) 'a]
== a

It wasn't bad, just weird. And looking back on it, it wasn't terrible...definitely has some advantages.

Maybe we'll go with that. This might call for the idea that the GROUP! combinator subdispatches if it notices asymmetric patterns, so you can put in the combinator map things like (| |) and it will assume you want any group that adheres to that pattern to go through that dispatch if it exists. So (()) would be searched for if it fit that pattern...