(I mistakenly posted this thread in Haskell-cafe instead of the Haskell Pipes list. Oh well.)

On Monday, June 27, 2016 at 2:57:15 AM UTC+2, Richard A. O'Keefe wrote:


>      replace :: Text-> Text -> Text-> Text
>
>
> Which argument is the text to replace, which is the replacement and
> which is the text that should be scanned?

Considering partial application, the order that makes the most sense is
    - what to look for
    - what to replace it with
    - the big string to search and replace in


Interesting, I forgot that the order of parameters can tell you things about how they are used. Did you arrive at your conclusion by assuming the "most variable" arguments come last?

> Imagine a generalized version of replace that 1) works on streams, and

> 2) allows replacing a sequence of texts (like, say, chapter headers)
> instead of replacing the same text repeatedly. It could have the
> following signature:
>
>      replace' :: Stream (Stream (Of Text) m) m ()
>                  -> Stream (Stream (Of Text) m) m Void
>                  -> Stream (Of Text) m r
>                  -> Stream (Of Text) m r
>
>
> Do you find easy to intuit, just by looking at that signature, which
> is the function of each argument?

Absolutely not.  In fact, this crossed my personal complexity horizon
and is still accelerating towards some kind of singularity.


Yeah, I was mostly experimenting about how to encode the the purpose of each argument in the types, without giving much thought to how complicated the signature ended up being.

About the first two function arguments, my reasoning was: the first stream (that returns ()) can be finite or infinite while the second (that returns Void) is necessarily infinite. Therefore it makes sense that the first is the stream of things to search for, and the second the stream of substitutions, that will be consumed as long as matches are found.
 

The more I try to imagine a problem that this might be a solution to,
the less I can understand why it would be approached this way.



A possible use case: you want to "splice" the contents of a sequence of files into another file at certain words, without having to keep whole files in memory, and without using lazy I/O.