it does apply. I think this is quite reasonable and I have
no intention of changing my programming habits to cope with weird
instances for which:
(x == y) = True does not imply x=y
or
max x y is not safely interchangeble with max y x.
I'm not saying some people are not right to want classes
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
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
Taral wrote:
On 5/23/07, Adrian Hey <[EMAIL PROTECTED]> 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 t
doSomething
.. laziness will ensure that nothing will happen unless the value
resultOfSomething is demanded (by main ultimately).
Of course, this does not imply the above hack is at all safe.
Regards
--
Adrian Hey
___
Haskell-prime mailing list
Haskell
sure if this is a problem with what you're proposing, but
I think it's important that we don't get into a situation where
the mere presence or absence of some definition in a module can
influence program behaviour, even if it isn't
eally
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))
:-)
R
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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
h
ble" then that must be down to inexperience and
general cluelessness on their part just seems wrong to me. It simply
isn't true.
(Anyone who disagrees with this should feel free to submit the patches
needed to fix up the base package :-)
Regards
--
Adrian Hey
___
27;ll try to put something reasonably simple together to test this
again. Last time I tested it was a probably a couple of years ago so
what I said might not be true of current ghc. The effect wasn't huge
in any case (using strict constructors was about 5% slower).
Regards
--
iler
does). But on modern memory architectures, forcing the code to inspect
heap records that it shouldn't have to inspect will be a bad thing.
So semantically I agree with "strict fields have no effect on
deconstructing data types", but they should have an effec
11 matches
Mail list logo
