LOAD /else on-error option

[rebolbot]

Submitted by: BrianH

I would like a LOAD/else 'on-error option that would allow you to specify fallback behavior to handle REBOL syntax errors. The on-error parameter should be a lit-word! in the spec since it would accept keywords, though arguments of any word type should work.

The on-error actual argument would either be a keyword for a standard, built-in fallback behavior, or a block! that would be treated as the code block of a funct with two parameters:

bc.. - input: The input binary! at the position the next value was supposed to start.

• error: A block! with two elements, the error! and the input at the next position, same as what TRANSCODE would return at this point.

p.

We pass a code block for FUNCT rather than a function! so the function parameters can be ensured to be correct without needing to screen them, and we can still have locals if we need them. We do the same thing with R3 GUI actions for the same reason.

The code block should return a block containing two values:

bc.. - A REBOL value (or #[unset!])

• The input binary! at the position that is supposed to be after that value.

p. This is the same as a regular LOAD/next return.

The block returned could be the same block passed as the error argument, perhaps modified, or a new block with the above contents. If the value returned in the first position is an error!, that error will be thrown - it could be the same error or something different. If something other than a block as described above is returned, an error will be thrown. We might consider allowing a return of #[none], and what that would mean. Any errors thrown by the code will be thrown by LOAD, not caught. RETURN and EXIT should be treated as code block returns, not passed through.

This allows the user to specify fallback behavior that is possibly less strict than LOAD would normally be (i.e. #124), or to localize their input, or to return better errors, or any number of other things. It may be possible to add new standard fallback behaviors at runtime, with new keywords.

LOAD/else on-error would be a wrapper of TRANSCODE/all/else on-error (#536 and #534). LOAD/next/else on-error would be a wrapper of TRANSCODE/next/else on-error (#535 and #534).

This proposal is derived from many requests over the years, and a well-populated debate in AltME 2 months ago.

bc.. ; Some examples

load/else ", a b c" skip == [a b c] load/else "1,000.00" local == 1000.0 load/else ", a b c" [either parse/all input ["," after:] [reduce [copy/part input after after]] [error]] == ["," a b c] ; Note the local variable 'after.

p.

^{CC - Data [ Version: alpha 35 Type: Wish Platform: All Category: n/a Reproduce: Always Fixed-in:none ]}

[rebolbot]

Submitted by: BrianH

Waiting for #534, #535 and #536 to be implemented.

[rebolbot]

Submitted by: Carl

The keywords are possible, the function callback part is not easy because for performance reasons TRANSCODE is not reentrant (although it is, in theory, REBOL thread safe.)

Also, the above description is complex so it's not entirely clear to me the benefit of this mechanism compared to iterative calls to TRANSCODE. The overhead of the callback and related state management would probably be about the same order as the top level calls into TRANSCODE, so there would not be a big win in speed.

[rebolbot]

Submitted by: BrianH

This can be implemented as a separate function that calls TRANSCODE iteratively, now that alpha 39 adds the /error refinement.