Parsing infinite streams style

[Hal Snyder]

Joe Armstrong <joe@REDACTED> writes:

> <<aside1 I actually returned {done,Result,NewParserFunction} not
>   {ok, R, X1} - but the idea is the same>>
>
> <<aside2: It's not a good idea to try and think about how mutually
> recursive definitions work (it just makes you head hurt) - think
> base case, recursive case. Then prove that the recursive case
> make the problem smaller. 

Right. I think I'm ok with recursion - it's the continuation passing
that needs to be assimilated as a familiar technique - especially when
the funs are nested, flung across processes, handed off for spawn_link
sometime later, etc.


On a separate note, looking at the concatenations in the get_int()
example 

> get_begin("begin " ++ T) -> get_int(T, 0);
> get_begin(S)             -> {more, fun(Data) -> get_begin(S ++ D) end}.

> get_int(" " ++ T, N) -> get_end(T, N);
> get_int([H|T], N)    -> get_int(T, N*10-H-$0);
> get_int([], N)       -> {more, fun(S) -> get_int(S, N)}.

> get_end("end" ++ T, N) -> {done, N, fun(I) -> get_begin(I)};
> get_end(T, N)          -> {more, fun(S) -> get_end(T++S, N) end}.

makes me wonder about speed gains possible by

a. using binaries instead of lists
b. pattern matching with readv-type multi-segment capability

The motivation being processing of real-time media protocols, not just
session setup and teardown.