Isaac Dupree wrote:

Maybe some sort of ISOLATE, DON'T_OPTIMIZE (but CAF), or USED_AS_GLOBAL_VARIABLE pragma instead of just the insufficient NOINLINE would be a good first step... if successful it would remove the occasional need for -fno-cse for a whole module in GHC, at least.

I have a hard time trying to understand why anyone would prefer this to the simple and clear <- syntax that's been proposed. As for the ACIO monad itself, this is utterly trivial and requires no language change. It's just a library. Maybe the first pragma you propose might have other uses to control optimisations, so I'm not totally anti this. But generally I dislike pragmas (I always find myself wondering what's wrong with the language design that makes the pragma necessary). So pragmas that influence optimisation are something I can live with. But using pragmas to influence *semantics* really is an evil practice IMO and is something that should be discouraged, not made an unavoidable necessity. But yes, if this problem isn't going to be properly addressed then at the very least the -fno-cse flag or something similar needs standardising (NOINLINE already is I think). Or we port all existing unsafePerfomIO hacked code to use Johm Meachams variant of the hack (uses types to ensure the compiler doesn't see common sub-expressions). Regards -- Adrian Hey

Hello Isaac, Sunday, May 20, 2007, 6:41:54 PM, you wrote:

Maybe some sort of ISOLATE, DON'T_OPTIMIZE (but CAF), or USED_AS_GLOBAL_VARIABLE pragma instead of just the insufficient NOINLINE would be a good first step...

or LOOK_BUT_DON'T_TOUCH :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Isaac Dupree wrote:

var :: IORef Int var = {-# EVALUATE_THIS_TEXT_ONLY_ONCE #-} (unsafePerformIO (newIORef 3))

I think I still prefer.. var :: IORef Int var <- newIORef 3 or, more likely.. var :: IORef Int var <- ACIO.newIORef 3 The <- syntax should make the intended semantics clear and unambiguous, so it becomes the problem of individual implementors (not standards writers) to make sure that whatever optimisations or transformations that may be appropriate for their implementation preserve those semantics. (IOW there's no need to worry about what a pragma really means in operational terms, AFAICS). The ACIO monad also restricts what programmers may use on the rhs of the <-. But if you want a good name for the pragma how about this..

var :: IORef Int var = {-# <- #-} (unsafePerformIO (newIORef 3))

:-) Regards -- Adrian Hey

Taral wrote:

On 5/23/07, Adrian Hey wrote:

...

I think I still prefer..

var :: IORef Int var <- newIORef 3

So do I. For one very good reason: this syntax could be defined as a "constructor" syntax and guaranteed to run before main.

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). But anyway, the constraints of the ACIO monad allow creation to occur at any time before the first attempt to read or write the IORef.

The other syntaxes proposed don't strike me as sufficiently rigorous.

Me neither. It's always been a great source of puzzlement to me why this very simple and IMO conservative proposal should be so controversial. Unless someone can point out some severe semantic difficulty or suggest something better it seems like a no-brainer to me. Regards -- Adrian Hey

Adrian Hey wrote:

Taral wrote:

...

On 5/23/07, Adrian Hey wrote:

...

I think I still prefer..

var :: IORef Int var <- newIORef 3

So do I. For one very good reason: this syntax could be defined as a "constructor" syntax and guaranteed to run before main.

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). But anyway, the constraints of the ACIO monad allow creation to occur at any time before the first attempt to read or write the IORef.

...

The other syntaxes proposed don't strike me as sufficiently rigorous.

Me neither. It's always been a great source of puzzlement to me why this very simple and IMO conservative proposal should be so controversial. Unless someone can point out some severe semantic difficulty or suggest something better it seems like a no-brainer to me.

This is going to be highly subjective, but to me it still doesn't feel like it falls under the bar for implementation cost given its usefulness. The new syntax requires additions all the way through the front end of the compiler: parser, abstract syntax, renamer, type checker, desugarer, for something that is rarely used. It's a first-class language construct (a new top-level binding form, no less), and it has to pay its way. Also you want to add the ACIO monad as a built-in to the language. Not that my gut feeling should in any way be considered the final word on the subject, but I thought I should say something about why we're not running to implement this right now. To me it seems like we should let it simmer some more. Cheers, Simon

David House wrote:

On 24/05/07, Adrian Hey 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.

There seems to be quite a few implicit (and incorrect) assumptions in your argument, which is fallacious IMO. The logic of your argument would imply that *no* top level expression can be evaluated at compile time. This might be the case with ghc, though I doubt it (and even if it was this would just be a ghc problem). BTW, the Haskell standard says nothing about any kind of heap, let alone a C style malloc. Regards -- Adrian Hey

Aaron Denney wrote:

On 2007-05-24, David House wrote:

...

On 24/05/07, Adrian Hey 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