Re: [Caml-list] environment idiom

[Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE>]

On Mon, 13 Dec 2004, skaller wrote:

> I.e. a simplified Assembler.
> 
> Is assmebler code functional?
> 
> No of course not!
> 
> Yes of course it is! Is is nothing more
> than a function from registers to registers where
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the instructions guarrantee you can't access the prior state.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> That's just the state monad .. :)

That's not quite how I would describe the state monad to work.

However solid the mental picture which you have of a brick may be,
you will not be able to hit real people with it as with a real brick. You 
can, of course, have a solid mental picture of solidly hitting real people 
with a solid real brick. This transformation of "mental picture of a solid 
brick" to "real brick in a mental picture of something that involves a 
brick" is just monadic binding.

I know all this may sound a bit hairsplitting, but it is precisely the 
necessity of this hairsplitting that makes it so difficult for beginners 
that have been poisoned by the imperative side of the force(TM) to get the 
idea behind the monadic approach.

Back to the question:

> Is assmebler code functional?

After all, "code" can mean very different things here: a string that can 
be parsed in a given grammar, a sequence of instructions that are to be 
fed into a processor, an actually running programm, etc. Some people work 
hard to get the fine distinctions one has to make here into other people's 
heads. My impression is that your statements just work against these 
distinctions other people try to establish.


> The point really is: what do you mean by purely functional?
> I think the answer depends on context.

I think the answer depends on properly wording the question!

Can one express transformations on sequences of machine instructions in a 
functional language? ("Language" in the much broader sense than just 
"functional programming language, especially haskell"; rather: "using 
proper mathematical reasoning".) Sure, and this is in many aspects 
perhaps the best way to talk about such transformations.

Do sequences of machine instructions of the type

   Ra = foo Rb Rc

respect some "naive" substitution properties like e.g.

   Ra = foo Rb Rc
   Ra = foo Rb Rc
-->
   Ra = foo Rb Rc

The answer is, of course, that no one would expect this.

These questions could not be any more different! What irks me is when such 
very different things are subsumed under a statement of the form "depends 
whether you ask this question in the outer or inner context". As it is a 
very different question you are asking! It does not depend on "context", 
but actually on the meaning you connect with the words which you use.

So, can one do array mutation in haskell? Certainly not. Can one use 
haskell to talk about doing array mutations? For sure. But nothing more. 
Well, systems like hugs will actually behave in funny ways if especially 
plans to do IO appear in certain magical places, but this is an entirely 
different story.



My point is that with statements like

> Yes, that indeed is my intention. Basically, any non-transparent
                                               ^^^^^^^^^^^^^^^^^^^
> non-function code can be made purely functional and transparent
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> with a simple transformation, yet it doesn't by this transformation
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> get any easier to reason about the code.

you are trying to "hit real people with mental bricks".


> I'm sure you can implement this machine using the ST monad...

I'm sure you can even do without. :-)

-- 
regards,               tf@cip.physik.uni-muenchen.de              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)