xah lee | 1 Nov 08:12 2005

haskell logo for webmasters

i created two haskell logos for websites to spread Haskell.

  http://xahlee.org/haskell/haskell-logo.html

it's in public domain.

suggestions welcome. Thanks.

  Xah
  xah <at> xahlee.org
∑ http://xahlee.org/
John Goerzen | 1 Nov 16:30 2005

Haskell Weekly News: November 1, 2005

                     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.

   1. http://www.haskell.org/mailman/listinfo/haskell
   2. http://sequence.complete.org/

New Releases

     * Time Library 0.2. Ashley Yakeley [3]announced a draft of a new time
       library and solicited comments.

   3. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/3882

Calls for participation

   HCAR entries due TODAY. Andres Loeh posted a [4]reminder that entries for
   the Haskell Communities and Activities Report are due today.

   4. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8876

Discussion

   Undecidable instances. In a [5]thread about the need for undecidable
   instances, Johannes Waldmann [6]suggested the use of termination
   analyzers.

(Continue reading)

Scherrer, Chad | 1 Nov 21:19 2005

specification of sum

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 much more
natural to me. Is there a case where the build-in definition is
preferable?

Chad Scherrer
Computational Mathematics Group
Pacific Northwest National Laboratory

"Time flies like an arrow; fruit flies like a banana." -- Groucho Marx
Ralf Hinze | 1 Nov 21:48 2005
Picon

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

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  Frown generates four different types of parsers. As a common
   characteristic, the parsers are genuinely functional (ie `table-free');
   the states of the underlying LR automaton are encoded as mutually
   recursive functions. Three output formats use a typed stack
   representation, one format due to Ross Paterson (code=stackless)
   works even without a stack.

o  Encoding states as functions means that each state can be treated
   individually as opposed to a table driven-approach, which
   necessitates a uniform treatment of states. For instance,
   look-ahead is only used when necessary to resolve conflicts.

o  Frown comes with debugging and tracing facilities; the standard
   output format due to Doaitse Swierstra (code=standard) may be
   useful for teaching LR parsing.

o  Common grammatical patterns such as repetition of symbols can be
   captured using rule schemata. There are several predefined rule
   schemata.

o  Terminal symbols are arbitrary variable-free Haskell patterns or
(Continue reading)

Sebastian Sylvan | 1 Nov 23:41 2005
Picon

Re: specification of sum

On 11/1/05, Scherrer, Chad <Chad.Scherrer <at> pnl.gov> 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 (+) 0
>
> But as far as I know, (+) is always strict, so foldl' seems much more
> natural to me. Is there a case where the build-in definition is
> preferable?

The library definition in ghc actually uses foldl.
It's conceivable that you may not want (+) to be non-strict for
certain data types.
The question then becomes, is there a case where you want _sum_ to be
non-strict?

/S
--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
Cale Gibbard | 2 Nov 00:38 2005
Picon

Re: specification of sum

On 01/11/05, Sebastian Sylvan <sebastian.sylvan <at> gmail.com> wrote:
> On 11/1/05, Scherrer, Chad <Chad.Scherrer <at> pnl.gov> 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 (+) 0
> >
> > But as far as I know, (+) is always strict, so foldl' seems much more
> > natural to me. Is there a case where the build-in definition is
> > preferable?
>
> The library definition in ghc actually uses foldl.
> It's conceivable that you may not want (+) to be non-strict for
> certain data types.
> The question then becomes, is there a case where you want _sum_ to be
> non-strict?
>

I'd argue that the likely answer is no, given that (+) is an operation
in an Abelian group and not a monoid. Regardless of whether (+) is
strict, when you compute a sum you will always have to consume the
entire list. This is because until you have observed the last element
of the list, nothing can be said about the final result. To see this,
it's enough to see that even if the sum of all the other elements of
the list is g, the final element could be -g + h, which would give a
final result of h, regardless of what g is.
(Continue reading)

Cale Gibbard | 2 Nov 00:44 2005
Picon

Re: specification of sum

On 01/11/05, Scherrer, Chad <Chad.Scherrer <at> pnl.gov> 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 (+) 0
>
> But as far as I know, (+) is always strict, so foldl' seems much more
> natural to me. Is there a case where the build-in definition is
> preferable?
>
> Chad Scherrer
> Computational Mathematics Group
> Pacific Northwest National Laboratory
>

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, somewhat like zipWith (+) over the lists of coefficients.

 - Cale
Lennart Augustsson | 2 Nov 01:19 2005
Picon

Re: specification of sum

Cale Gibbard wrote:
> On 01/11/05, Sebastian Sylvan <sebastian.sylvan <at> gmail.com> wrote:
> 
>>On 11/1/05, Scherrer, Chad <Chad.Scherrer <at> pnl.gov> 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 (+) 0
>>>
>>>But as far as I know, (+) is always strict, so foldl' seems much more
>>>natural to me. Is there a case where the build-in definition is
>>>preferable?
>>
>>The library definition in ghc actually uses foldl.
>>It's conceivable that you may not want (+) to be non-strict for
>>certain data types.
>>The question then becomes, is there a case where you want _sum_ to be
>>non-strict?
>>
> 
> 
> I'd argue that the likely answer is no, given that (+) is an operation
> in an Abelian group and not a monoid. Regardless of whether (+) is
> strict, when you compute a sum you will always have to consume the
> entire list.
(Continue reading)

Scherrer, Chad | 2 Nov 01:39 2005

RE: specification of sum

> 
> 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, somewhat like zipWith 
> (+) over the lists of coefficients.
> 
>  - Cale

Hmm, this is a good point, but for most people, It seems like the most
common usage would be to add up a list of actual concrete numbers, and
the resulting memory leak in the code using sum is at least a minor
annoyance. It's hard to say how much time a given newbie will take to
catch this nuance. Since 

sum' = foldl' (+) 0

(like foldl', the ' means "strict" ) is so often preferable, I'll go so
far as to suggest it be included it in upcoming versions of Data.List.
That way it would be hard to miss, and would remove what could otherwise
be a very common stumbling block for anyone doing numerical work with
Haskell.

I haven't used product so extensively, but I suspect there may be
similar issues with it?

-Chad
Cale Gibbard | 2 Nov 02:35 2005
Picon

Re: specification of sum

On 01/11/05, Lennart Augustsson <lennart <at> augustsson.net> wrote:
> Cale Gibbard wrote:
> > On 01/11/05, Sebastian Sylvan <sebastian.sylvan <at> gmail.com> wrote:
> >
> >>On 11/1/05, Scherrer, Chad <Chad.Scherrer <at> pnl.gov> 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 (+) 0
> >>>
> >>>But as far as I know, (+) is always strict, so foldl' seems much more
> >>>natural to me. Is there a case where the build-in definition is
> >>>preferable?
> >>
> >>The library definition in ghc actually uses foldl.
> >>It's conceivable that you may not want (+) to be non-strict for
> >>certain data types.
> >>The question then becomes, is there a case where you want _sum_ to be
> >>non-strict?
> >>
> >
> >
> > I'd argue that the likely answer is no, given that (+) is an operation
> > in an Abelian group and not a monoid. Regardless of whether (+) is
> > strict, when you compute a sum you will always have to consume the
(Continue reading)


Gmane