On Mon, 2004-12-13 at 21:20, Thomas Fischbacher wrote:


> Referential transparency is about the substitution of definitions. 
> Evidently, x <- ... is _not_ a definition. 

But this is a bit circular. It is suspect to use the Haskell
definition of 'definition' and then say Haskell is referentially
transparent, a property depending on the definition of 'definition',
because you cannot apply that definition to any other language.

C also has 'definitions' but they're not at all the same
as Haskell ones.

When I first read the text of Barbara Liskov's Substitution
Principle I fell over laughing. The text makes so many
assumptions about the kind of language it is dealing
with it is useless. You could rewrite it for C++,
using *initialisation* instead of substitution, for example.

So when you're looking at monadic Haskell that contains

	x <- ...

you can claim it isn't a definition.. but it surely
looks like one.. more precisely it looks like an assignment.

It's like me trying to argue -- repeatedly and heatedly --
that no matter what the C++ Standard says, there is no
such type as 'const int'. There really isn't <g> even though
the grammar has a production which makes that a valid type
specifier it doesn't denote a type distinct from int.
Of course people argued I was wrong -- the Standard said so.

> The notion of "substitution" of course only makes sense for this 
> "official" form. 

Right. But consider for a moment a meta-system with
enough well thought out sugar that it had a calculus
of its own. Just because the reduced form is transparent
doesn't mean the sugar calculus is.

I guess that's my point, badly stated. The sugar level *counts*.
Just as Haskell counts, even though GHC generates C which generates
assembler .. semantics and its relation to syntax -- such as
exhibited by the referential transparency property of purely
functional code appears to be a 'multilevel' phenomena.

> This is a bit like 
> FORTRAN programmers asked to adjust themselves to C showing the attitude 
> that "at least, they can forget all that for/while/etc. mumbo-jumbo and 
> do everything with goto, as they are used to".

Good point.

> Coming back to the original question, which was whether one may "just 
> stick in some monadic stuff to get a notion of an `environment'", I'm 
> inclined to say that from the purely functional point of view, this 
> perhaps is not a good idea, as this is not just "a minor change to the 
> code" but changes pretty much anything of its original properties.

However clearly the ST monad is sometimes useful.. 
can you explain when that is?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net