[Haskell-cafe] Overriding a Prelude function?

[Claus Reinke]

> 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(*:-) 

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.

>From the implementation perspective, representations of programs
are translated downwards into executable code, the code is executed, 
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