Re: [Haskell-cafe] How helpful is h-99 (and should we complete the missing ones)?
So here's my question: how useful is h-99 (are they overrated as learning tools)? I find myself solve most of them in a from the scratch fashion (e.g., no Monad, no Applicative, no Functor aside from List and a few Maybe). Some of them are paper-worthy, for example the prime problems. I hope some guru-level Haskeller could do away the missing few, and maybe dive deeper into the surface to produce more insights (like the knights travel page or the sieve paper, which are both beautiful). As another new-haskeller I say: Yes No. Yes for necessity of several described algorithms and gained intuition for real programming. No for needed ammount of work to understand pitfalls of Haskell when real programming. And of-course, problems and solutions are not annotated with there typical real world aplications, they are not obvious for average beginners. Why would I make Binary tree balanced, when I don't know, what I'll gain (except balanced binary tree)? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: notcpp-0.0.1
On 04/13/2012 10:49 PM, Ben Millwood wrote: I'm pleased to announce my first genuinely original Hackage package: notcpp-0.0.1! http://hackage.haskell.org/package/notcpp [...] Why is it scopeLookup :: String - Q Exp with n bound to x :: T = @scopeLookup n@ evaluates to an Exp containing @Just x@ , not scopeLookup :: String - Q (Maybe Exp) with n bound to x :: T = @scopeLookup n@ evaluates to Just (an Exp containing @x@) ? Shouldn't n's being in scope be a compile time decision? That would also make the openState: runtime name resolution has its drawbacks :/[1] a compile time error. -- Steffen [1] http://hackage.haskell.org/packages/archive/notcpp/0.0.1/doc/html/NotCPP-ScopeLookup.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How helpful is h-99 (and should we complete the missing ones)?
On Sun, Apr 15, 2012 at 09:58, Daniel Hlynskyi abcz2.upr...@gmail.comwrote: And of-course, problems and solutions are not annotated with there typical real world aplications, they are not obvious for average beginners. Why would I make Binary tree balanced, when I don't know, what I'll gain (except balanced binary tree)? They're not intended to be an algorithms course. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] strange GHCi type inference behavior involving map and partially applied functions
Hi All,
I found a really strange case where GHC and GHCi behave differently in
inferring types. It took me hours to figure this out.
The following program
{-# LANGUAGE NoMonomorphismRestriction #-}
g x i = x ++ show i
[a,b] = map g [X,Y]
will not load without NoMonomorphismRestriction. With that option, it will
load and return the correct types (as expected):
*Main :t [a,b]
[a,b] :: Show a = [a - [Char]]
*Main a 1
X1
However, if I do the same thing GHCi, the type inferencing seems to have been
messed up:
*Main let g x i = x ++ show i
*Main let [a,b] = map g [X,Y]
*Main :t [a,b]
[a,b] :: [() - [Char]]
*Main :t map g [X,Y]
map g [X,Y] :: Show a = [a - [Char]]
Note how in the last two instances the terms on the left and right-hand sides
of the definition return different types. Also, the correct return type should
be a list of unary functions taking an (Show a) as
the parameter. Now the result is unusable:
*Main a 1
interactive:52:3:
No instance for (Num ())
arising from the literal `1'
Possible fix: add an instance declaration for (Num ())
In the first argument of `a', namely `1'
In the expression: a 1
In an equation for `it': it = a 1
I am using GHCi 7.4.1 under windows. I also tried this under GHC 7.0x
Is this a GHCi bug or could anyone please explain why this can of strange
behavior happens?
If this is a bug, could anyone with an account help file a bug for this?
Thanks in advance,
Ting
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] strange GHCi type inference behavior involving map and partially applied functions
GHCi is defaulting the 'a' in 'Show a' to unit because of the extended
defaulting feature [1] in GHCi. If you turn on
NoMonomorphismRestriction in GHCi, you get the same behavior as in
GHC. If you turn on ExtendedDefaulting in GHC, you get the same
behavior as in GHCi.
Erik
[1]
http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules
On Sun, Apr 15, 2012 at 22:31, Ting Lei tin...@hotmail.com wrote:
Hi All,
I found a really strange case where GHC and GHCi behave differently in
inferring types. It took me hours to figure this out.
The following program
{-# LANGUAGE NoMonomorphismRestriction #-}
g x i = x ++ show i
[a,b] = map g [X,Y]
will not load without NoMonomorphismRestriction. With that option, it
will load and return the correct types (as expected):
*Main :t [a,b]
[a,b] :: Show a = [a - [Char]]
*Main a 1
X1
However, if I do the same thing GHCi, the type inferencing seems to have
been messed up:
*Main let g x i = x ++ show i
*Main let [a,b] = map g [X,Y]
*Main :t [a,b]
[a,b] :: [() - [Char]]
*Main :t map g [X,Y]
map g [X,Y] :: Show a = [a - [Char]]
Note how in the last two instances the terms on the left and right-hand
sides of the definition return different types. Also, the correct return
type should be a list of unary functions taking an (Show a) as
the parameter. Now the result is unusable:
*Main a 1
interactive:52:3:
No instance for (Num ())
arising from the literal `1'
Possible fix: add an instance declaration for (Num ())
In the first argument of `a', namely `1'
In the expression: a 1
In an equation for `it': it = a 1
I am using GHCi 7.4.1 under windows. I also tried this under GHC 7.0x
Is this a GHCi bug or could anyone please explain why this can of strange
behavior happens?
If this is a bug, could anyone with an account help file a bug for this?
Thanks in advance,
Ting
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit Best Practices for leftover data
Thanks for responding to this. Some responses are inline. On Sat, Apr 14, 2012 at 8:30 PM, Michael Snoyman mich...@snoyman.com wrote: On Thu, Apr 12, 2012 at 9:25 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Hello, I am interested in the argument to Done, namely, leftover data. More specifically, when implementing a conduit/sink, what should the conduit specify for the (Maybe i) argument to Done in the following scenarios (Please note that these scenarios only make sense if the type of 'i' is something in Monoid): 1) The conduit outputted the last thing that it felt like outputting, and exited willfully. There seem to be two options here - a) the conduit/sink should greedily gather up all the remaining input in the stream and mconcat them, or b) Return the part of the last thing that never got represented in any part of anything outputted. Option b seems to make the most sense here. Yes, option (b) is definitely what's intended. 2) Something upstream produced Done, so the second argument to NeedInput gets run. This is guaranteed to be run at the boundary of an item, so should it always return Nothing? Instead, should it remember all the input it has consumed for the current (yet-to-be-outputted) element, so it can let Data.Conduit know that, even though the conduit appeared to consume the past few items, it actually didn't (because it needs more input items to make an output)? Remembering this sequence could potentially have disastrous memory usage. On the other hand, It could also greedily gather everything remaining in the stream. No, nothing so complicated is intended. Most likely you'll never return any leftovers from the second field of NeedInput. One other minor point: it's also possible that the second field will be used if the *downstream* pipe returns Done. Just to help me understand, what is a case when you want to specify something in this field? I can't think of a case when a Conduit would specify anything in this case. 3) The conduit/sink encountered an error mid-item. In general, is there a commonly-accepted way to deal with this? If a conduit fails in the middle of an item, it might not be clear where it should pick up processing, so the conduit probably shouldn't even attempt to continue. It would probably be good to return some notion of where it was in the input when it failed. It could return (Done (???) (Left errcode)) but this requires that everything downstream in the pipeline be aware of Errcode, which is not ideal.I could use MonadError along with PipeM, but this approach completely abandons the part of the stream that has been processed successfully. I'd like to avoid using Exceptions if at all possible. Why avoid Exceptions? It's the right fit for the job. You can still keep your conduit pure by setting up an `ExceptionT Identity` stack, which is exactly how you can use the Data.Conduit.Text functions from pure code. Really, what you need to be asking is is there any logical way to recover from an exception here? I suppose this is a little off-topic, but do you prefer ExceptionT or ErrorT? Any exception/error that I'd be throwing is just a container around a String, so both of them will work fine for my purposes. It doesn't seem that a user application even has any way to access leftover data anyway, so perhaps this discussion will only be relevant in a future version of Conduit. At any rate, any feedback you could give me on this issue would be greatly appreciated. Leftover data is definitely used: 1. If you compose together two `Sink` with monadic bind, the leftovers from the first will be passed to the second. You can do that That's so cool!I never realized that Pipes are members of Monad. 2. If you use connect-and-resume ($$+), the leftovers are returned as part of the `Source`, and provided downstream. This too is really neat :] I didn't realize how this worked. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: notcpp-0.0.1
On Sun, Apr 15, 2012 at 7:14 PM, Steffen Schuldenzucker sschuldenzuc...@uni-bonn.de wrote: On 04/13/2012 10:49 PM, Ben Millwood wrote: I'm pleased to announce my first genuinely original Hackage package: notcpp-0.0.1! http://hackage.haskell.org/package/notcpp [...] Why is it scopeLookup :: String - Q Exp with n bound to x :: T = @scopeLookup n@ evaluates to an Exp containing @Just x@ , not scopeLookup :: String - Q (Maybe Exp) with n bound to x :: T = @scopeLookup n@ evaluates to Just (an Exp containing @x@) ? Shouldn't n's being in scope be a compile time decision? That would also make the openState: runtime name resolution has its drawbacks :/[1] a compile time error. -- Steffen [1] http://hackage.haskell.org/packages/archive/notcpp/0.0.1/doc/html/NotCPP-ScopeLookup.html This way minimises the amount the user has to know about Template Haskell, because the user can just splice the expression immediately and then operate on it as an ordinary value. The design you suggest would require messing about in the Q monad to construct the expression you wanted based on whether you got a Nothing or a Just, which in my view is more awkward. I can see how your version would be useful too, though – in particular I can move the error call to a report call, which throws a compile-time error as you say. I'd be happy to expose both next version ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] strange GHCi type inference behavior involving map and partially applied functions
Eric: Thanks a lot for explaining the issue. That's very helpful.
Kind of a newbie question, how can I automatically turn on
NoMonomorphismRestriction using emacs mode for haskell?
I know there is the :set command, but I don't want to do it every time I start
up emacs.
In my humble opinion, I think the GHC should turn on ExtendedDefaulting if GHCi
has it on by default. Otherwise it is confusing for newbies.
Also, the defaulting is a kind of wierd and arbitrary behavior as I see it. In
the case I showed, it gives unintuivive (or even errorneous)
behavior. A function that can be applied now suddenly causes type mismatches.
Isn't it a good thing in Haskell that if you get the type
right, you get a big portition your program right? If turning on
ExtendedDefaulting causes too much trouble, maybe then GHC should
turn it off by default in both GHI and GHCi. In either case, I think the two
should be consistent.
Thanks again for help,
Ting
From: hessel...@gmail.com
Date: Sun, 15 Apr 2012 22:45:47 +0200
Subject: Re: [Haskell-cafe] strange GHCi type inference behavior involving
map and partially applied functions
To: tin...@hotmail.com
CC: haskell-cafe@haskell.org
GHCi is defaulting the 'a' in 'Show a' to unit because of the extended
defaulting feature [1] in GHCi. If you turn on
NoMonomorphismRestriction in GHCi, you get the same behavior as in
GHC. If you turn on ExtendedDefaulting in GHC, you get the same
behavior as in GHCi.
Erik
[1]
http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive-evaluation.html#extended-default-rules
On Sun, Apr 15, 2012 at 22:31, Ting Lei tin...@hotmail.com wrote:
Hi All,
I found a really strange case where GHC and GHCi behave differently in
inferring types. It took me hours to figure this out.
The following program
{-# LANGUAGE NoMonomorphismRestriction #-}
g x i = x ++ show i
[a,b] = map g [X,Y]
will not load without NoMonomorphismRestriction. With that option, it
will load and return the correct types (as expected):
*Main :t [a,b]
[a,b] :: Show a = [a - [Char]]
*Main a 1
X1
However, if I do the same thing GHCi, the type inferencing seems to have
been messed up:
*Main let g x i = x ++ show i
*Main let [a,b] = map g [X,Y]
*Main :t [a,b]
[a,b] :: [() - [Char]]
*Main :t map g [X,Y]
map g [X,Y] :: Show a = [a - [Char]]
Note how in the last two instances the terms on the left and right-hand
sides of the definition return different types. Also, the correct return
type should be a list of unary functions taking an (Show a) as
the parameter. Now the result is unusable:
*Main a 1
interactive:52:3:
No instance for (Num ())
arising from the literal `1'
Possible fix: add an instance declaration for (Num ())
In the first argument of `a', namely `1'
In the expression: a 1
In an equation for `it': it = a 1
I am using GHCi 7.4.1 under windows. I also tried this under GHC 7.0x
Is this a GHCi bug or could anyone please explain why this can of strange
behavior happens?
If this is a bug, could anyone with an account help file a bug for this?
Thanks in advance,
Ting
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] process-conduit appears to hang on windows
Hi, I am trying to use process-conduit on windows, but it appears to hang when using the conduitCmd. Is there a reason why this doesn't work? Thanks for any help, Grant I have made an attempt to create a version of process conduits that appears to work on Windows and Linux. Unfortunately it looks a bit ugly. Does anyone have any input on if this is the right approach and if so, how it can be improved? Thanks for any help. Grant https://gist.github.com/2395361 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit Best Practices for leftover data
2. If you use connect-and-resume ($$+), the leftovers are returned as part of the `Source`, and provided downstream. I'm trying to figure out how to use this, but I'm getting a little bit confused. In particular, here is a conduit that produces an output for every 'i' inputs. I'm returning partial data when the input stream hits an EOF (And I verified that the partial data is correct with Debug.Trace), yet the output of 'partial' is ([[1,2,3,4,5]],[]) instead of ([[1,2,3,4,5]],[6,7,8]). Can you help me understand what's going on? Thanks, Myles import qualified Data.Conduit as C import qualified Data.Conduit.List as CL -- functionally the same as concatenating all the inputs, then repeatedly running splitAt on the concatenation. takeConduit :: (Num a, Monad m) = a - C.Pipe [a1] [a1] m () takeConduit i = takeConduitHelper i [] [] where takeConduitHelper x lout lin | x == 0 = C.HaveOutput (takeConduitHelper i [] lin) (return ()) $ reverse lout | null lin = C.NeedInput (takeConduitHelper x lout) (C.Done (Just $ reverse lout) ()) | otherwise = takeConduitHelper (x - 1) (head lin : lout) $ tail lin partial :: (Num t, Monad m, Enum t) = m ([[t]], [[t]]) partial = do (source, output) - CL.sourceList [[1..8]] C.$$+ (takeConduit 5 C.=$ CL.consume) output' - source C.$$ CL.consume return (output, output') On Sun, Apr 15, 2012 at 2:12 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Thanks for responding to this. Some responses are inline. On Sat, Apr 14, 2012 at 8:30 PM, Michael Snoyman mich...@snoyman.com wrote: On Thu, Apr 12, 2012 at 9:25 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Hello, I am interested in the argument to Done, namely, leftover data. More specifically, when implementing a conduit/sink, what should the conduit specify for the (Maybe i) argument to Done in the following scenarios (Please note that these scenarios only make sense if the type of 'i' is something in Monoid): 1) The conduit outputted the last thing that it felt like outputting, and exited willfully. There seem to be two options here - a) the conduit/sink should greedily gather up all the remaining input in the stream and mconcat them, or b) Return the part of the last thing that never got represented in any part of anything outputted. Option b seems to make the most sense here. Yes, option (b) is definitely what's intended. 2) Something upstream produced Done, so the second argument to NeedInput gets run. This is guaranteed to be run at the boundary of an item, so should it always return Nothing? Instead, should it remember all the input it has consumed for the current (yet-to-be-outputted) element, so it can let Data.Conduit know that, even though the conduit appeared to consume the past few items, it actually didn't (because it needs more input items to make an output)? Remembering this sequence could potentially have disastrous memory usage. On the other hand, It could also greedily gather everything remaining in the stream. No, nothing so complicated is intended. Most likely you'll never return any leftovers from the second field of NeedInput. One other minor point: it's also possible that the second field will be used if the *downstream* pipe returns Done. Just to help me understand, what is a case when you want to specify something in this field? I can't think of a case when a Conduit would specify anything in this case. 3) The conduit/sink encountered an error mid-item. In general, is there a commonly-accepted way to deal with this? If a conduit fails in the middle of an item, it might not be clear where it should pick up processing, so the conduit probably shouldn't even attempt to continue. It would probably be good to return some notion of where it was in the input when it failed. It could return (Done (???) (Left errcode)) but this requires that everything downstream in the pipeline be aware of Errcode, which is not ideal.I could use MonadError along with PipeM, but this approach completely abandons the part of the stream that has been processed successfully. I'd like to avoid using Exceptions if at all possible. Why avoid Exceptions? It's the right fit for the job. You can still keep your conduit pure by setting up an `ExceptionT Identity` stack, which is exactly how you can use the Data.Conduit.Text functions from pure code. Really, what you need to be asking is is there any logical way to recover from an exception here? I suppose this is a little off-topic, but do you prefer ExceptionT or ErrorT? Any exception/error that I'd be throwing is just a container around a String, so both of them will work fine for my purposes. It doesn't seem that a user application even has any way to access leftover data anyway, so perhaps this discussion will only be relevant in a future version of Conduit. At any rate, any feedback you could give me on this issue would be greatly appreciated. Leftover data is
Re: [Haskell-cafe] Conduit Best Practices for leftover data
Sorry for the spam. A similar matter is this following program, where something downstream reaches EOF right after a conduit outputs a HaveOutput. Because the type of the early-closed function is just 'r' or 'm r', there is no way for the conduit to return any partial output. This means that any extra values in the chunk the conduit read are lost. Is there some way around this? -- takeConduit as in previous email -- partial2 outputs ([[1,2,3,4,5]],[]) instead of ([[1,2,3,4,5]],[6,7,8]) monadSink :: Monad m = CI.Sink [a1] m ([[a1]], [[a1]]) monadSink = do output - takeConduit 5 C.=$ CL.take 1 output' - CL.consume return (output, output') partial2 :: (Num t, Monad m, Enum t) = m ([[t]], [[t]]) partial2 = CL.sourceList [[1..8]] C.$$ monadSink Thanks, Myles On Sun, Apr 15, 2012 at 4:53 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: 2. If you use connect-and-resume ($$+), the leftovers are returned as part of the `Source`, and provided downstream. I'm trying to figure out how to use this, but I'm getting a little bit confused. In particular, here is a conduit that produces an output for every 'i' inputs. I'm returning partial data when the input stream hits an EOF (And I verified that the partial data is correct with Debug.Trace), yet the output of 'partial' is ([[1,2,3,4,5]],[]) instead of ([[1,2,3,4,5]],[6,7,8]). Can you help me understand what's going on? Thanks, Myles import qualified Data.Conduit as C import qualified Data.Conduit.List as CL -- functionally the same as concatenating all the inputs, then repeatedly running splitAt on the concatenation. takeConduit :: (Num a, Monad m) = a - C.Pipe [a1] [a1] m () takeConduit i = takeConduitHelper i [] [] where takeConduitHelper x lout lin | x == 0 = C.HaveOutput (takeConduitHelper i [] lin) (return ()) $ reverse lout | null lin = C.NeedInput (takeConduitHelper x lout) (C.Done (Just $ reverse lout) ()) | otherwise = takeConduitHelper (x - 1) (head lin : lout) $ tail lin partial :: (Num t, Monad m, Enum t) = m ([[t]], [[t]]) partial = do (source, output) - CL.sourceList [[1..8]] C.$$+ (takeConduit 5 C.=$ CL.consume) output' - source C.$$ CL.consume return (output, output') On Sun, Apr 15, 2012 at 2:12 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Thanks for responding to this. Some responses are inline. On Sat, Apr 14, 2012 at 8:30 PM, Michael Snoyman mich...@snoyman.com wrote: On Thu, Apr 12, 2012 at 9:25 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Hello, I am interested in the argument to Done, namely, leftover data. More specifically, when implementing a conduit/sink, what should the conduit specify for the (Maybe i) argument to Done in the following scenarios (Please note that these scenarios only make sense if the type of 'i' is something in Monoid): 1) The conduit outputted the last thing that it felt like outputting, and exited willfully. There seem to be two options here - a) the conduit/sink should greedily gather up all the remaining input in the stream and mconcat them, or b) Return the part of the last thing that never got represented in any part of anything outputted. Option b seems to make the most sense here. Yes, option (b) is definitely what's intended. 2) Something upstream produced Done, so the second argument to NeedInput gets run. This is guaranteed to be run at the boundary of an item, so should it always return Nothing? Instead, should it remember all the input it has consumed for the current (yet-to-be-outputted) element, so it can let Data.Conduit know that, even though the conduit appeared to consume the past few items, it actually didn't (because it needs more input items to make an output)? Remembering this sequence could potentially have disastrous memory usage. On the other hand, It could also greedily gather everything remaining in the stream. No, nothing so complicated is intended. Most likely you'll never return any leftovers from the second field of NeedInput. One other minor point: it's also possible that the second field will be used if the *downstream* pipe returns Done. Just to help me understand, what is a case when you want to specify something in this field? I can't think of a case when a Conduit would specify anything in this case. 3) The conduit/sink encountered an error mid-item. In general, is there a commonly-accepted way to deal with this? If a conduit fails in the middle of an item, it might not be clear where it should pick up processing, so the conduit probably shouldn't even attempt to continue. It would probably be good to return some notion of where it was in the input when it failed. It could return (Done (???) (Left errcode)) but this requires that everything downstream in the pipeline be aware of Errcode, which is not ideal.I could use MonadError along with PipeM, but this approach completely abandons the part of the stream that has been processed
Re: [Haskell-cafe] strange GHCi type inference behavior involving map and partially applied functions
On 16 April 2012 01:44, Ting Lei tin...@hotmail.com wrote: Kind of a newbie question, how can I automatically turn on NoMonomorphismRestriction using emacs mode for haskell? I know there is the :set command, but I don't want to do it every time I start up emacs. You can just add it to your ~/.ghci or the .ghci file of your project directory. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] strange GHCi type inference behavior involving map and partially applied functions
On Sun, Apr 15, 2012 at 19:44, Ting Lei tin...@hotmail.com wrote: In my humble opinion, I think the GHC should turn on ExtendedDefaulting if GHCi has it on by default. Otherwise it is confusing for newbies. I think we're kinda tending in the opposite direction: we'd like NoMonomorphismRestriction to be the default unless operating in strict Haskell98 or Haskell2010 mode. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Building cabal-install for new ghc build
Hi Café. I'm building GHC from package ghc-7.4.1-src.tar.bz2 as the binary download was throwing segfaults for me (and apparently a few others). This has worked well and my issues with GHC and GHCi are now resolved. However I have needed to build cabal-install. This can't be done using cabal-install because it isn't installed :) I've found that I had to make several modifications to the bootstrap.sh and cabal-install.cabal files in order to get this to work. I am wondering how the maintainers of the Haskell-platform, etc are dealing with these issues. There seems to be a cabal-install-7.4.1 package on Hackage to address these issues, but I couldn't get it to work for me. Is this actually being used by the community? I realize that I am making trouble for myself by not just using the Haskell-Platform, but there are some packages I want to use that depend on recent versions of base. Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit Best Practices for leftover data
On Mon, Apr 16, 2012 at 12:12 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Thanks for responding to this. Some responses are inline. On Sat, Apr 14, 2012 at 8:30 PM, Michael Snoyman mich...@snoyman.com wrote: [snip] No, nothing so complicated is intended. Most likely you'll never return any leftovers from the second field of NeedInput. One other minor point: it's also possible that the second field will be used if the *downstream* pipe returns Done. Just to help me understand, what is a case when you want to specify something in this field? I can't think of a case when a Conduit would specify anything in this case. There are a number of examples in the built-in libraries. For example, Data.Conduit.Binary.takeWhile http://hackage.haskell.org/packages/archive/conduit/0.4.1.1/doc/html/src/Data-Conduit-Binary.html#takeWhile [snip] Why avoid Exceptions? It's the right fit for the job. You can still keep your conduit pure by setting up an `ExceptionT Identity` stack, which is exactly how you can use the Data.Conduit.Text functions from pure code. Really, what you need to be asking is is there any logical way to recover from an exception here? I suppose this is a little off-topic, but do you prefer ExceptionT or ErrorT? Any exception/error that I'd be throwing is just a container around a String, so both of them will work fine for my purposes. ExceptionT is a means to allow non-IO stacks to throw exceptions. ErrorT is only an instance of MonadThrow if the underlying monad is an instance of MonadThrow. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit Best Practices for leftover data
I'm not really certain of your previous example, but what you're describing here is data loss. AFAIK, this is inherent to any kind of streaming approach. Have a look at the chapter in the Yesod book on conduit, the description of data loss is still accurate. On Mon, Apr 16, 2012 at 3:46 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Sorry for the spam. A similar matter is this following program, where something downstream reaches EOF right after a conduit outputs a HaveOutput. Because the type of the early-closed function is just 'r' or 'm r', there is no way for the conduit to return any partial output. This means that any extra values in the chunk the conduit read are lost. Is there some way around this? -- takeConduit as in previous email -- partial2 outputs ([[1,2,3,4,5]],[]) instead of ([[1,2,3,4,5]],[6,7,8]) monadSink :: Monad m = CI.Sink [a1] m ([[a1]], [[a1]]) monadSink = do output - takeConduit 5 C.=$ CL.take 1 output' - CL.consume return (output, output') partial2 :: (Num t, Monad m, Enum t) = m ([[t]], [[t]]) partial2 = CL.sourceList [[1..8]] C.$$ monadSink Thanks, Myles On Sun, Apr 15, 2012 at 4:53 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: 2. If you use connect-and-resume ($$+), the leftovers are returned as part of the `Source`, and provided downstream. I'm trying to figure out how to use this, but I'm getting a little bit confused. In particular, here is a conduit that produces an output for every 'i' inputs. I'm returning partial data when the input stream hits an EOF (And I verified that the partial data is correct with Debug.Trace), yet the output of 'partial' is ([[1,2,3,4,5]],[]) instead of ([[1,2,3,4,5]],[6,7,8]). Can you help me understand what's going on? Thanks, Myles import qualified Data.Conduit as C import qualified Data.Conduit.List as CL -- functionally the same as concatenating all the inputs, then repeatedly running splitAt on the concatenation. takeConduit :: (Num a, Monad m) = a - C.Pipe [a1] [a1] m () takeConduit i = takeConduitHelper i [] [] where takeConduitHelper x lout lin | x == 0 = C.HaveOutput (takeConduitHelper i [] lin) (return ()) $ reverse lout | null lin = C.NeedInput (takeConduitHelper x lout) (C.Done (Just $ reverse lout) ()) | otherwise = takeConduitHelper (x - 1) (head lin : lout) $ tail lin partial :: (Num t, Monad m, Enum t) = m ([[t]], [[t]]) partial = do (source, output) - CL.sourceList [[1..8]] C.$$+ (takeConduit 5 C.=$ CL.consume) output' - source C.$$ CL.consume return (output, output') On Sun, Apr 15, 2012 at 2:12 PM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Thanks for responding to this. Some responses are inline. On Sat, Apr 14, 2012 at 8:30 PM, Michael Snoyman mich...@snoyman.com wrote: On Thu, Apr 12, 2012 at 9:25 AM, Myles C. Maxfield myles.maxfi...@gmail.com wrote: Hello, I am interested in the argument to Done, namely, leftover data. More specifically, when implementing a conduit/sink, what should the conduit specify for the (Maybe i) argument to Done in the following scenarios (Please note that these scenarios only make sense if the type of 'i' is something in Monoid): 1) The conduit outputted the last thing that it felt like outputting, and exited willfully. There seem to be two options here - a) the conduit/sink should greedily gather up all the remaining input in the stream and mconcat them, or b) Return the part of the last thing that never got represented in any part of anything outputted. Option b seems to make the most sense here. Yes, option (b) is definitely what's intended. 2) Something upstream produced Done, so the second argument to NeedInput gets run. This is guaranteed to be run at the boundary of an item, so should it always return Nothing? Instead, should it remember all the input it has consumed for the current (yet-to-be-outputted) element, so it can let Data.Conduit know that, even though the conduit appeared to consume the past few items, it actually didn't (because it needs more input items to make an output)? Remembering this sequence could potentially have disastrous memory usage. On the other hand, It could also greedily gather everything remaining in the stream. No, nothing so complicated is intended. Most likely you'll never return any leftovers from the second field of NeedInput. One other minor point: it's also possible that the second field will be used if the *downstream* pipe returns Done. Just to help me understand, what is a case when you want to specify something in this field? I can't think of a case when a Conduit would specify anything in this case. 3) The conduit/sink encountered an error mid-item. In general, is there a commonly-accepted way to deal with this? If a conduit fails in the middle of an item, it might not be clear where it should pick up processing, so the conduit probably shouldn't even attempt to continue. It would
Re: [Haskell-cafe] process-conduit appears to hang on windows
On Mon, Apr 16, 2012 at 2:50 AM, grant the...@hotmail.com wrote: Hi, I am trying to use process-conduit on windows, but it appears to hang when using the conduitCmd. Is there a reason why this doesn't work? Thanks for any help, Grant I have made an attempt to create a version of process conduits that appears to work on Windows and Linux. Unfortunately it looks a bit ugly. Does anyone have any input on if this is the right approach and if so, how it can be improved? Thanks for any help. Grant https://gist.github.com/2395361 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I'm not sure what the original problems were that caused it to hang on Windows, so I can't really speak to that part of the code. The conduit-specific stuff looks good though. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
