Aaron Denney wrote:
On 2007-05-24, David House wrote:
On 24/05/07, Adrian Hey <[EMAIL PROTECTED]> wrote:
Or even at compile time (which is why I think it's reasonable to
regard operations like newIORef etc.. as not really being "IO"
operations at all).
You can allocate heap space at compile time? (Well, I guess you could,
but that wouldn't still be usable at run time...) I imagine newIORef
as mallocing() some room, then returning a pointer to that memory.
That doesn't seem like something that could be done at compile time.

You can allocate bss or data space at compile time for the executable
you are compiling.  (Well, if you read compile as compile and link.
It's a bit fuzzy.)

Well we don't need to get too bogged down with the details of how
any particular compiler/linker/rts might work. The point being that
with any..

myIORef <- newIORef initialExpression

whether or not it's at the top level, the only information needed
to create the IORef is the initialExpression, and if it's at the
top level then this is available at compile time (it doesn't even
have to be evaluated at compile time in order to create the IORef).

But it doesn't require any information from, nor should it have
any effect on, the outside world that an executing program is
interacting with. It is conceivable that for some newIORef
implementations this would not be true, but in that case it's
difficult to see how such implementations could safely put
their newIORef in the ACIO monad anyway.

Regards
--
Adrian Hey





_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Reply via email to