Calling Combinators (Decoders?) as Normal Functions

[hostilefork]

@hostilefork

A few times I've talked about the potential of making it possible to call a COMBINATOR function from outside of PARSE.

This is to say that if some PARSE-specific parameter was missing (e.g. the "parse state") there'd be a mode in the guts of the COMBINATOR mechanic which cooked up something like a temporary parse session just for the input you passed in.

So I think I've ruled out the concept of trying to do this with anything that "combinates". It's too fuzzy what it would mean in terms of the arity of invocation. Just call PARSE.

However...

@hostilefork

Seeing how SOME isn't a good example for this, maybe the right way of saying what I'm trying to say here this is that there's some category of functions we might call "decoders"...and PARSE would be willing to call these.

They'd fit a standard format regarding things like taking an input series and giving back an amount of progress or an error.

This idea has merit.

@hostilefork

>> debin [le + 3] #{FEFFFF00}  ; asking for 3 bytes of decode, passed 4
** Error: DEBIN did not consume all input, request remainder if intentional

Asking for a remainder could prevent the error:

>> [value rest]: debin [le + 3] #{FEFFFF00}
== 16777214

>> rest
== #{00}

For reasons of composability, multi-return no longer lets the right hand side "see" what the left hand side requested. (You can read the long winding history to understand why.)

So it's kind of like all of these would need to offer something like TRANSCODE's :next refinement. And I think the convention for those functions returning the series as the primary result is sound.

>> [rest value]: debin:next [le + 3] #{FEFFFF00}
== #{00}

>> value
== 16777214

PARSE would have to ask for the :NEXT to do its job.

DEBIN Seems Like A Good First Target. But ENBIN?

An encoder could be used in UPARSE as well, though its only real meaning would be to splice in data at the current position and then move the tail to after the splice.

You could do that with [insert (/your-encoding call-here)] as a parse rule, so it's not necessary to have access to the parsed series...unless you thought it would be more optimal to have the evil :INTO to say where to put the data...

Maybe encoders have an :INTO and that's what distinguishes them from ordinary run-of-the-mill functions, I don't know.

Anyway, just throwing a couple more thoughts in here...