RFC, ensureHeaped

[spir]

On Tue, 16 Nov 2010 23:28:37 -0800
Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> It has already been argued that I/O should be exempt (at least for debugging 
> purposes), and I think that that would could be acceptable for weakly pure 
> functions. But it's certainly true that as it stands, dealing with I/O and 
> purity doesn't work very well. And since you have to try and mark as much as 
> possible pure (to make it weakly pure at least) if you want much hope of being 
> able to have much of anything be strongly pure, it doesn't take long before you 
> can't actually have I/O much of anywhere - even for debugging. It's definitely a 
> problem.

(See also my previous post on this thread).
What we are missing is a clear notion of program state, distinct from physical machine. A non-referentially transparent function is one that reads from this state; between 2 runs of the function, this state may have been changed by the program itself, so that execution is influenced. Conversely, an effect-ive function is one that changes state; such a change may influence parts of the program that read it, including possibly itself.

This true program state is not the physical machine's one. Ideally, there would be in the core language's organisation a clear definition of what state is -- it could be called "state", or "world". An approximation in super simple imperative languages is the set of global variables. (Output does not write onto globals -- considering writing onto video port or memory state change is close to nonsense ;-) In pure OO, this is more or less the set of objects / object fields. (A func that does not affect any object field is effect-free.)
State is something the program can read (back); all the rest, such as writing to unreachable parts of memory like for output, cannot have any consequence on future process (*). I'm still far to be clear on this topic; as of now, I think only assignments to state, as so defined, should be considered effects.
This would lead to a far more practicle notion of "purity", I guess, esp for imperative and/or OO programming.


Denis

(*) Except possibly when using low level direct access to (pseudo) memory addresses. Even then, one cannot read plain output ports, or write to plain input ports, for instance.
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com