If you mean a lazy functional program, then the difference is that those are generally demand-driven. You execute a thunk, and it executes thunks that it needs. In most dataflow models, computation is availability driven, in that thunks which can run will do, and when they complete they will enable other thunks which needed those values to now run.
You're right, I meant 'strictly' rather than 'purely' there (hate that bit of jargon, btw). Unfortunately 'continuation-passing style' was probably the wrong choice of words too: I meant 1) the restricted language with only tail calls, no evaluable arguments etc., not 2) the method (thread the continuation through the code, etc.) used to encode arbitrary functional programs into 1). Naturally 2) produces programs which run in 1), but not usually idiomatic programs in 1) (while otoh idiomatic/arbitrary programs in 1) may be side-effect-free, but they're not usually really functional in the sense of equational reasoning/term-rewriting).
AFAIK you can encode either the lazy or eager variants of functional programs into 1), while 1) itself is effectively "super-eager" as it just doesn't permit any arguments that need evaluation except where explicitly delayed inside a lambda, right?
