I think Henning is right, I've been misunderstood. My understanding is that FRP is a way to structure programs that take time-varying signals as input. What I'm interested in is how to represent the signal itself. For example, say I want a signal that goes 0 to 1 like f(x) = x^2, and goes back to 0 like f(x) = -x. In the function-oriented representation, I could write: expon t = t^2 linear t = -t + 1 f t | t < 1 = expon t | t >= 1 = linear (t - 1) sampled = map f [0, 0.25 .. 2] I have to shift 'linear' in time by t+1, presumably I'd be annotating these functions with start and end times, and write a (<>) that merges them. Meanwhile, here's the same thing, but with a piecewise-linear representation: srate = 4 expon start end = [(start + t, t^2) | t <- [0, 1/srate .. end-start]] linear start end = [(start, 1), (end, 0)] f = expon 0 1 <> linear 1 2 at f t = case dropWhile ((<t) . fst) f of ((t1, y1) : (t2, y2) : _) -> (y2 - y1) / (t2 - t1) * (t - t1) + y1 sampled = map (at f) [0, 0.25 .. 2] Notice that 'expon' can only be approximated with a sampling rate, but linear works out exactly because it corresponds to the interpolation I'm doing at the end to create 'sampled'. In the example, I think 'at' is broken because it doesn't understand coincident samples, but you get the idea. A piecewise-flat (stepwise?) version would look the same, except 'linear' would need to use 'srate' and 'at' would just emit 'y1', without linear interpolation. With the toy example, #1 is obviously simpler and more accurate, but as I said it might have memory leaks. Also, for #1 I*have*to sample the result even when the value is constant, and I don't know where the breakpoints are. That won't do, because imagine the signal represents pitch. If it gets misaligned with note attack time, even by a single audio-rate sample, the result is very different. #2 doesn't have this problem. Or, imagine the consumer of #2 is a GUI, it can draw a line with a single call, and it comes out high DPI and with antialiasing, so it likes #2. If the GUI or whatever is in another process, I have to sample #1 anyway to serialize it, and all I can do is end up with a worse #2.