[Haskell] Re: Writing large n-dim un-boxed array of Int32 quickly?

2005-11-01 Thread Chung-chieh Shan
Rene de Visser <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in gmane.comp.lang.haskell.general: > To do this I need to cast my 5 dimensional array to a 1 dimensional > array? Does this work? i.e. how do I know that GHC uses a flat array > representation for multidemsional arrays (rath

[Haskell] Haskell Weekly News: November 1, 2005

2005-11-01 Thread John Goerzen
Haskell Weekly News: November 1, 2005 Greetings, and thanks for reading the 13th issue of HWN, a weekly newsletter for the Haskell community. Each Tuesday, new editions will be posted (as text) to [1]the Haskell mailing list and (as HTML) to [2]The Haskell Sequence

[Haskell] Re: Monads vs. continuations

2005-11-01 Thread Chung-chieh Shan
Gregory Woodhouse <[EMAIL PROTECTED]> wrote in article <[EMAIL PROTECTED]> in gmane.comp.lang.haskell.general: > Okay, this seems sensible enough. Loosely speaking, I see this code > as getting a line, checking to see if it's empty. If it is, it just > quits (returning the "empty" value). Othe

[Haskell] specification of sum

2005-11-01 Thread Scherrer, Chad
I was wondering... In my experience, it's worked much better to use sum' = foldl' (+) 0 than the built-in "sum" function, which leaks memory like crazy for large input lists. I'm guessing the built-in definition is sum = foldr (+) 0 But as far as I know, (+) is always strict, so foldl' seems mu

[Haskell] ANNOUNCE: Frown - an LALR(k) Parser Generator for Haskell (version 0.6, beta)

2005-11-01 Thread Ralf Hinze
I'm pleased to announce the first release of Frown (version 0.6, andromeda release), an LALR(k) Parser Generator for Haskell 98. This is a beta quality release. Frown's salient features are: o The generated parsers are time and space efficient. On the downside, the parsers are quite large. o

Re: [Haskell] specification of sum

2005-11-01 Thread Sebastian Sylvan
On 11/1/05, Scherrer, Chad <[EMAIL PROTECTED]> wrote: > I was wondering... In my experience, it's worked much better to use > > sum' = foldl' (+) 0 > > than the built-in "sum" function, which leaks memory like crazy for > large input lists. I'm guessing the built-in definition is > > sum = foldr (+

Re: [Haskell] specification of sum

2005-11-01 Thread Cale Gibbard
On 01/11/05, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: > On 11/1/05, Scherrer, Chad <[EMAIL PROTECTED]> wrote: > > I was wondering... In my experience, it's worked much better to use > > > > sum' = foldl' (+) 0 > > > > than the built-in "sum" function, which leaks memory like crazy for > > large

Re: [Haskell] specification of sum

2005-11-01 Thread Cale Gibbard
On 01/11/05, Scherrer, Chad <[EMAIL PROTECTED]> wrote: > I was wondering... In my experience, it's worked much better to use > > sum' = foldl' (+) 0 > > than the built-in "sum" function, which leaks memory like crazy for > large input lists. I'm guessing the built-in definition is > > sum = foldr (

Re: [Haskell] specification of sum

2005-11-01 Thread Lennart Augustsson
Cale Gibbard wrote: On 01/11/05, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: On 11/1/05, Scherrer, Chad <[EMAIL PROTECTED]> wrote: I was wondering... In my experience, it's worked much better to use sum' = foldl' (+) 0 than the built-in "sum" function, which leaks memory like crazy for larg

RE: [Haskell] specification of sum

2005-11-01 Thread Scherrer, Chad
> > You don't always want (+) to be strict. Consider working with > the ring of formal power series over, say, the integers. You > don't want (+) to force the evaluation of an infinite formal > summation which is passed to it, since that's an infinite > loop, so it will have to be non-strict,

Re: [Haskell] specification of sum

2005-11-01 Thread Cale Gibbard
On 01/11/05, Lennart Augustsson <[EMAIL PROTECTED]> wrote: > Cale Gibbard wrote: > > On 01/11/05, Sebastian Sylvan <[EMAIL PROTECTED]> wrote: > > > >>On 11/1/05, Scherrer, Chad <[EMAIL PROTECTED]> wrote: > >> > >>>I was wondering... In my experience, it's worked much better to use > >>> > >>>sum' =

Re: [Haskell] specification of sum

2005-11-01 Thread John Meacham
The solution would be to bring 'sum' and 'product' into the Num class so the most efficient version for each type can be used and the default is no worse than the current non-class versions. (this is even pretty much completly backwards compatable so could be considered for haskell 06) I'd also li

Re: [Haskell] specification of sum

2005-11-01 Thread Cale Gibbard
On 01/11/05, John Meacham <[EMAIL PROTECTED]> wrote: > The solution would be to bring 'sum' and 'product' into the Num class so > the most efficient version for each type can be used and the default is > no worse than the current non-class versions. (this is even pretty much > completly backwards c

[Haskell] RE: specification of sum

2005-11-01 Thread Scherrer, Chad
> The solution would be to bring 'sum' and 'product' into the Num class so > the most efficient version for each type can be used and the default is > no worse than the current non-class versions. (this is even pretty much > completly backwards compatable so could be considered for haskell 06) > >