[Haskell-cafe] Using streams to clarify (?) the signature of Data.Text.replace

[Daniel Díaz]

(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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160627/d8ef4e61/attachment.html>