At Mon, 11 Jul 2011 21:18:30 +0300,
Yitzchak Gale wrote:
Please respond to this thread if you own a package
that will be affected by this change.
iterIO uses mkTyCon for the simple reason that ((Typeable t, Typeable
m) = Iter t m) is Typeable1 and there is no automatic way of deriving
At Mon, 4 Jul 2011 20:36:33 +1000,
John Ky wrote:
Hi Haskell Cafe,
enum |$ inumLines .| inumReverse .| inumUnlines .| iter
...
iterLines :: (Monad m) = Iter L.ByteString m [L.ByteString]
iterLines = do
line - lineI
return [line]
iterUnlines
At Sat, 2 Jul 2011 17:23:50 -0400,
Brent Yorgey wrote:
On Sat, Jul 02, 2011 at 09:02:13PM +0200, Daniel Fischer wrote:
- disabling the monomorphism restriction
:set -XNoMonomorphismRestriction
let g = f
This is the recommended solution. The confusion caused by the MR far
outweighs
At Fri, 1 Jul 2011 09:39:32 +0400,
Eugene Kirpichov wrote:
Hi,
I'm rewriting timeplot to avoid holding the whole input in memory, and
naturally a problem arises:
How to represent large but finite streams and functions that process
them, returning other streams or some kinds of aggregate
At Thu, 30 Jun 2011 23:53:02 +1000,
John Ky wrote:
But all I've done is:
enum |$ inumReverseLines .| iter
inumReverseLines = mkInum $ do
line - lineI
return (L.reverse (L.concat [line, C.pack \n]))
mkInum repeatedly invokes its iter argument so as to keep
At Wed, 29 Jun 2011 21:13:47 +1000,
John Ky wrote:
Hi Haskell Cafe,
I've written an echo server using just sockets:
...
When I send text to it, it will echo it back immediately after my newline.
I then modified it to user IterIO:
import Control.Concurrent
import
At Wed, 29 Jun 2011 10:11:26 +1000,
John Ky wrote:
[1 multipart/alternative (7bit)]
[1.1 text/plain; ISO-8859-1 (7bit)]
Hi all,
From the IterIO tutorial:
enumFile' is like enumFile above, but type restricted to data in the lazy
ByteString format, which is more efficient
At Sun, 26 Jun 2011 01:41:01 +0100,
Paterson, Ross wrote:
I thought no type signature meant no type signature inside b1.
No, it means no type signature for the variable.
Otherwise, you are saying nothing could depend on a binding with a
type signature. By that logic, there can be no
At Sun, 26 Jun 2011 09:31:05 +0100,
Paterson, Ross wrote:
Indeed, the Report has two problems:
Sections 4.4.3.2 and 4.5.5 have different definitions of simple pattern.
This has been there since section 4.5.5 (Monomorphism Restriction) was
added in Haskell 1.1. But then the only technical
At Sun, 26 Jun 2011 21:15:06 +0100,
Paterson, Ross wrote:
True. That ambiguity could be avoided by adding the word declaration
after type signature.
On second thoughts, this is unnecessary. The Report consistently uses
expression type signature for the expression and type signature
Section 4.4.3.2 of the 2010 Haskell report says:
A simple pattern binding has form p = e. The pattern p is
matched “lazily” as an irrefutable pattern, as if there were
an implicit ~ in front of it.
This makes it sound as though p is a pattern, which I assume means
what
At Sat, 25 Jun 2011 14:20:52 -0400,
Scott Turner wrote:
g1 x y z = if xy then show x ++ show z else g2 y x
g2 :: (Show a, Ord a) = a - a - String
g2 | False = \p q - g1 q p ()
| otherwise = \p q - g1 q p 'a'
where x = True
It appears to me that
At Sun, 26 Jun 2011 00:17:12 +0100,
Paterson, Ross wrote:
g1 x y z = if xy then show x ++ show z else g2 y x
g2 :: (Show a, Ord a) = a - a - String
g2 | False = \p q - g1 q p ()
| otherwise = \p q - g1 q p 'a'
where x = True
It
At Thu, 02 Jun 2011 13:52:52 +0200,
Ketil Malde wrote:
I have a bunch of old code, parsers etc, which are based on the
'readFile' paradigm:
type Str = Data.ByteString.Lazy.Char8.ByteString -- usually
decodeFoo :: Str - Foo
encodeFoo :: Foo - Str
readFoo = decodeFoo . readFile
I'm using GHC 7.0.2 and running into a compiler error that I cannot
understand. Can anyone shed light on the issue for me? The code does
not make use of GADTs and compiles just fine without them. But when I
add a {-# LANGUAGE GADTs #-} pragma, it fails to compile.
Here is the code:
{-#
At Tue, 31 May 2011 21:30:01 -0500,
austin seipp wrote:
The short story is thus: when you turn on GADTs, it also now turns on
another extension implicitly (MonoLocalBinds) which restricts let
generalization...
You can find a little more info about the change here:
At Wed, 18 May 2011 09:56:22 +0100,
Simon Marlow wrote:
Ok. I'm not sure how feasible RCU is with IORefs, or even whether it's
necessary. After all, the usual pattern of having readers use readIORef
while writers use atomicModifyIORef gives the RCU cost model (zero
overhead for readers,
At Mon, 16 May 2011 10:56:02 +0100,
Simon Marlow wrote:
Yes, it's not actually documented as far as I know, and we should fix
that. But if you think about it, sequential consistency is really the
only sensible policy: suppose one processor creates a heap object and
writes a reference to
At Tue, 17 May 2011 02:18:55 +1000,
Bernie Pope wrote:
http://augustss.blogspot.com/2011/04/
ugly-memoization-heres-problem-that-i.html
He says that There's no guarantee about readIORef and writeIORef when doing
multi-threading.. But I was wondering if that was true, and if it were, what
At Mon, 16 May 2011 22:31:14 +0100,
Simon Marlow wrote:
Good example - so it looks like we don't get full sequential consistency
on x86 (actually I'd been thinking only about write ordering and
forgetting that reads could be reordered around writes).
But that's bad because it means
At Fri, 13 May 2011 02:57:38 -0700 (PDT),
o...@okmij.org wrote:
The code described in this message does exactly that.
Hey, Oleg. This is really cool! In particular, your Bindable class
has the potential to unify a whole bunch of request types and both
simplify and generalize code. Also, Sum
At Thu, 12 May 2011 16:45:02 +0100,
Simon Marlow wrote:
There are no locks here, thanks to the message-passing implementation we
use for throwTo between processors.
Okay, that sounds good. So then there is no guarantee about ordering
of throwTo exceptions? That seems like a good
At Mon, 9 May 2011 17:55:17 +0100,
John Lato wrote:
Felipe Almeida Lessa wrote:
So, in the enumerator vs. iterIO challenge, the only big differences I
see are:
a) iterIO has a different exception handling mechanism.
b) iterIO can have pure iteratees that
At Wed, 11 May 2011 13:02:21 +0100,
Simon Marlow wrote:
There's no guarantee of the form that you mention - asynchronous
exceptions can occur anywhere. However, there might be a way to do what
you want (disclaimer: I haven't looked at the implementation of iterIO).
Control.Exception
At Wed, 11 May 2011 13:02:21 +0100,
Simon Marlow wrote:
There's no guarantee of the form that you mention - asynchronous
exceptions can occur anywhere. However, there might be a way to do what
you want (disclaimer: I haven't looked at the implementation of iterIO).
Control.Exception
At Wed, 11 May 2011 13:02:21 +0100,
Simon Marlow wrote:
However, if there's some simpler way to guarantee that= is the
point where exceptions are thrown (and might be the case for GHC in
practice), then I basically only need to update the docs. If someone
with more GHC understanding
At Sat, 7 May 2011 22:14:27 -0700,
Nicholas Tung wrote:
Dear all,
I'd like to write a function maybeShow :: a - Maybe String, which runs
show if its argument is of class Show.
You can't do this, because in general there is no way to know whether
an arbitrary object a is of class Show.
At Sat, 07 May 2011 21:50:13 +0100,
Maciej Marcin Piechotka wrote:
Sorry for third post but I wonder why the many instances are restricted
by Monad.
It would be great if Functor were a superclass of Monad. However,
since it isn't, and since I can't think of anything particularly
useful to do
At Fri, 6 May 2011 10:15:50 +0200,
Gregory Collins wrote:
Hi David,
Re: this comment from catchI:
It is not possible to catch asynchronous exceptions, such as
lazily evaluated divide-by-zero errors, the throw function, or
exceptions raised by other threads using throwTo if those
At Fri, 6 May 2011 10:10:26 -0300,
Felipe Almeida Lessa wrote:
He also says that the enumerator package's Enumerators aren't
iteratees, only iterIO's enumerators are. Well, that's not what I'm
reading:
-- from enumerator package
newtype Iteratee a m b = Iteratee {runIteratee :: m
At Fri, 6 May 2011 10:54:16 -0300,
Felipe Almeida Lessa wrote:
On Fri, May 6, 2011 at 10:44 AM, Henk-Jan van Tuyl hjgt...@chello.nl wrote:
iterIO cannot be compiled on Windows, because it depends on the package
unix.
That's a big showstopper. I wonder if the package split I recommend
At Sat, 7 May 2011 01:15:25 +1000,
Alex Mason wrote:
Hi All,
I really love the look of this package, but if this is going be
*the* iteratee package, I would absolutely love to see it fix some
of the biggest mistakes in the other iteratee packages, soecifically
naming. A change in naming
At Sat, 07 May 2011 00:09:46 +0200,
Henk-Jan van Tuyl wrote:
On Fri, May 6, 2011 at 10:44 AM, Henk-Jan van Tuyl hjgt...@chello.nl
wrote:
iterIO cannot be compiled on Windows, because it depends on the
package
unix.
[...]
I'd obviously love to make my stuff work on Windows, but
At Fri, 06 May 2011 21:27:21 -0400,
Mario Blažević wrote:
I'd been thinking about using the terms Source and Sink, but Source is
very overloaded, and SinkSource doesn't exactly roll off the tongue
or evoke a particularly helpful intuition.
The SCC package happens to use Source and
34 matches
Mail list logo
