On 9/15/05, Simon Marlow <[EMAIL PROTECTED]> wrote:
On 15 September 2005 01:04, Karl Grapone wrote:> I'm considering using haskell for a system that could, potentially,> need 5GB-10GB of live data.> My intention is to use GHC on Opteron boxes which will give me a max
> of 16GB-32GB of real ram. I
> I have another proposal, though. Introduce a new keyword, which I'll
> call "borrow" (the opposite of "return"), that behaves like a
> function of type (Monad m) => m a -> a inside of do statements. More
> precisely, a do expression of the form
>
> do { ... ; ... borrow E ... ; ... }
>
> i
On 15.09 23:40, Bulat Ziganshin wrote:
> of course
>
> class Ref c a where
> new :: a -> IO (c a)
> get :: c a -> IO a
> set :: c a -> a -> IO ()
Maybe even:
class Ref m t where
new :: a -> m (t a)
get :: t a -> m a
set :: t a -> a -> m ()
Or if you want to support things like FastM
I raise you:
class (Monad m) => Ref m c | c -> m
where new :: a -> m (c a)
get :: c a -> m a
peek :: c a -> m a
set :: c a -> a -> m ()
modify :: c a -> (a -> a) -> m a
modify_ :: c a -> (a -> a) -> m ()
modifyM :: c a -> (a -> m a) -> m a
Hello Lyle,
Thursday, September 15, 2005, 10:50:30 PM, you wrote:
>> z := *x + *y -- translated to { x' <- readIORef x; y' <- readIORef y;
>> writeIORef z (x'+y') }
>>
LK> Right, I realize my suggestion is the same as Ben's. I just prefer a
LK> more succinct notation, like special brackets
Bulat Ziganshin wrote:
Hello Ben,
Wednesday, September 14, 2005, 6:32:27 PM, you wrote:
BRG> do { ... ; ... borrow E ... ; ... }
BRG> is transformed into
BRG> do { ... ; x <- E ; ... x ... ; ... }
i strongly support this suggestion. actually, i suggest the same for
dealing with re
Hello Ben,
Wednesday, September 14, 2005, 6:32:27 PM, you wrote:
BRG> do { ... ; ... borrow E ... ; ... }
BRG> is transformed into
BRG> do { ... ; x <- E ; ... x ... ; ... }
i strongly support this suggestion. actually, i suggest the same for
dealing with references (IORef/MVar/...),
Hello Simon,
Thursday, September 15, 2005, 2:42:44 PM, you wrote:
>> of 16GB-32GB of real ram. I gather that GHC is close to being ported
SM> It'll be a good stress test for the GC, at least. There are no reasons
SM> in principle why you can't have a heap this big, but major collections
SM> ar
On 15 September 2005 14:48, S. Alexander Jacobson wrote:
> Should one interpret this as GHC now targets 64-bit systems or does
> one need to employ some sort of clevernesss to use this much memory?
> (I posted this question a while ago and was told that GHC did not at
> that time support 64-bit so
Should one interpret this as GHC now targets 64-bit systems or does
one need to employ some sort of clevernesss to use this much memory?
(I posted this question a while ago and was told that GHC did not at
that time support 64-bit so could not use that much memory)
On a related note, does GHC n
Am Donnerstag, 15. September 2005 08:33 schrieb Ben Horsfall:
> On 15/09/05, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> > Page 0? What is that?
>
> OK, I admit there is no page zero (although the JFP contents page
> gives pages 0--255, which is where the information in my bibtex file
> must hav
On 15 September 2005 01:04, Karl Grapone wrote:
> I'm considering using haskell for a system that could, potentially,
> need 5GB-10GB of live data.
> My intention is to use GHC on Opteron boxes which will give me a max
> of 16GB-32GB of real ram. I gather that GHC is close to being ported
> to am
12 matches
Mail list logo
