Hmm, Hugs gives me this:
(.) . (.) . (.) :: (a -> b) -> (c -> d -> e -> a) -> c -> d -> e -> b
which I think is correct, if still not transparent in its meaning.
(ghci gives me a slightly re-named and explicitly quantified
variation).
Basically, the idea is that this sort of expression,
Iavor Diatchki writes in response to Thomas JÃger
Literal patterns need equality:
f 2 = e
is like:
f x | x == 2 = e
These do not force the 'Num' class to be a superclass of 'Ord' or
'Eq'. If 'Num' was not a superclass of 'Eq', whenver you used a
literal pattern there would be an extra constraint t
Thanks!
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On 11 Feb 2005, at 19:09, Dmitri Pissarenko wrote:
readClassifiedImages :: [ClassifiedImage] -> [IO (ClassifiedImage,
Image)]
which is what I want.
However, when in the program I insert the statement
classifiedImagesWithData :: [IO (ClassifiedImage, Image)]
so that it becomes
do ...
classifiedIma
Hello!
I could now find the place, where an error occurs.
In my program, I have following statement:
do ...
classifiedImagesWithData <- (readClassifiedImages trainingSet)
readClassifiedImages is defined as follows:
readClassifiedImages :: [ClassifiedImage] -> [IO (ClassifiedImage, Image)]
readClass
Hi,
On Fri, 11 Feb 2005 12:02:56 +0100, Thomas Jäger <[EMAIL PROTECTED]> wrote:
>
> iii) As a side effects of how n+k patterns work, each instance of the
> Num class must also be an instance of Eq, which of course doesn't make
> sense for all numeric types.
Well this is not entirely true. I don'
Hello!
I have now another problem.
I have a function
readClassifiedImages :: [ClassifiedImage] -> [IO (ClassifiedImage, Image)]
readClassifiedImages classifiedImages = map readClassifiedImagesSelector
classifiedImages
data ClassifiedImage = ClassifiedImage {imageFileName :: String, subjectID ::
Str
Am Donnerstag, 10. Februar 2005 20:50 schrieben Sie:
> > > incrEach' i is = is >>= \i' -> return (i'+i)
> >
> > Ugh, but I think the natural way to write it looks more like
> >
> > incrAll :: Integer -> [Integer] -> [Integer]
> > incrAll n ks = map (+n) ks
> >
> > which is no less readable than m
Hi,
On Thu, 10 Feb 2005 16:18:19 -0800, Iavor Diatchki
<[EMAIL PROTECTED]> wrote:
> > because I don't like the current situation with (n+k)-patterns:
> > Everybody says they're evil, but hardly anybody can explain why he
> > thinks so.
>
> I think 'evil' may be a little too strong. I think the u
David Menendez wrote:
Here's another one:
addTriple (s,p,o) = addArc s p o . addNode s . addNode p . addNode o
I like to think it's pretty straightforward.
I suppose you could argue that these are examples of "semi-point-free"
style, or something. Certainly, I wouldn't want to rewrite tsArcFwd
Thanks for the help!
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Fri, 11 Feb 2005, Remi Turk wrote:
> 1) It's talking about the compiler having difficulty with some
>warnings when using guards.
http://www.haskell.org//pipermail/haskell-cafe/2005-January/008290.html
>f x | odd x = ...
>| even x = ...
>
>GHC does complain. I wou
[EMAIL PROTECTED] wrote:
Note that "currying" applies to operator sections too. The idiom of
"pipelined functions" deserves its own special mention:
countlines = length . lines
But this is really a shorthand for:
countlines cs = length . lines $ cs
an interesting use of $ (in conjunction w
Matthew Roberts <[EMAIL PROTECTED]> writes:
>> [Point-free] compositions of functions with arity greater than 1,
>> [...] compositions of sections of composition or application,
>> arrow notation without the sugar, and so forth---will always be more
>> difficult to read and understand than the dir
14 matches
Mail list logo
