As far as referential transparency is concerned, you'd need to keep your reference levels straight, which can seem confusing if you can only communicate via representations(*:-)
From the implementation perspective, representations of programs are translated downwards into executable code, the code is executed,
That came out more confusing than it needs to be, so let me try that again, from scratch: Reduction systems take programs that are representations of problems and produce programs that are representations of solutions. One level of representation, so users can pretend there is no representation: for them, reduction systems reduce programs to simpler programs. the system states resulting at the end (or when the reduction count runs out) are translated upwards into representations of programs again. Slightly more intricate, but users still see only programs reducing to other programs. It doesn't matter whether the end programs are values, functions, or partially reduced applications - they are always represented in the same high-level form users started out with, without user programs having to deal explicitly in representations. Referential transparency is never in question. In current Haskell implementations, representations of programs are translated downwards into executable code, the code is executed. There is something missing here: the resulting system states are never translated back into language-level representations, so users have to deal with the gap between high-level and low-level representations. To do that, we use 'show' and 'IO' in our programs - we write programs that talk about representations of a subset of programs, namely 'Show'able values, and about printing those representations. So we end up with representations of programs-that-print-out- representations-of-values; the programs are translated downwards into executable code, the code is executed, doing so prints out representations of values. What GHCi and Hugs do is to wrap a 'putStrLn . show' around our input programs, so there is some chance of getting a representation of result values back. GHCi also allows us to make and inspect (show values or types of) bindings at the prompt, but it doesn't give us a representation of the program context we are constructing. When using a reduction system, I was able to focus on programs. When using a Haskell implementation, I have to think about representations of results, and how I get them out of a running program. If the intended result is something for which programs cannot produce or print a representation (functions, partially reduced applications) I am stuck. I might ask for a debugger, if only to get some kinds of insight into what my program is doing when it isn't printing representations of values for me, but I won't get a language-level view of program execution via representations of intermediate programs. Hope that is a less confusing view of the differences, Claus