I think a specification
> any p = or . map p
is much more concise than the implementation
> any p [] = False
> any p (x:xs) = p x || any p xs
another reason to prefer the higher-level variant
is that the compiler can apply fusion laws, as in
any p . map f = or . map p . map f
> Am I the only one who finds the exclusive emphasis on combinator
> languages slightly disappointing (in fact, the article seems to equate
> functional language with domain-specific combinator languages, which is
> more than a bit mistleading)?
What declarative approach(es) (other than comb
Hello!
On Mon, Jan 22, 2001 at 11:19:42AM -0600, Eric Shade wrote:
> I have some questions about the specifications of 'any', 'all', and
> 'findIndices' in the Haskell 98 reports. The specifications of 'any'
> and 'all' are
> any p = or . map p
> all p = and . map p
> While this is cor
I have some questions about the specifications of 'any', 'all', and
'findIndices' in the Haskell 98 reports. The specifications of 'any'
and 'all' are
any p = or . map p
all p = and . map p
While this is correct, it seems to me that it generates a lot of
garbage because map will produce
> With all this talk of preprocessor generated information and whatnot, I
> am reminded of a paper I read not too long ago but can't seem to find
> anymore about a dedicated pre-processor for haskell based on the C
> preprocessor but made to deal with haskell constructs a bit more sanely.
This wa
> > This article is very good, and having read the conference paper earlier
> > in the year I finished it with only one question: What's a 'quant' ...
> > and is it good or bad to be one?
> >
> > "Ten years ago, Jean-Marc Eber, then a quant at Société
> > Générale, ..."
>
> The OED has:
I agree with Koen: \\ is list subtraction and we're all used to subtraction being left
associative.
John.
Jon Fairbairn wrote:
>
> On Wed, 17 Jan 2001, Koen Claessen wrote:
> > I propose that it gets the following fixity:
> >
> > infixl 5 \\
>
> Unless the it's common usage outside of Hask
On Sun, 21 Jan 2001, David Bakin wrote:
> This article is very good, and having read the conference paper earlier
> in the year I finished it with only one question: What's a 'quant' ...
> and is it good or bad to be one?
>
> "Ten years ago, Jean-Marc Eber, then a quant at Société
> Gén
