Re: [Haskell-cafe] Parsec line number off-by-one
Hi Ben,
This is indeed a bug in parsec.
I have written a patch that fixes this. Currently Antoine Latter (current
parsec's maintainer) and I are working on getting these patches into the
next parsec release.
As a workaround until then, you can apply the attached patch manually.
darcs get http://code.haskell.org/parsec3
cd parsec3
darcs apply parsec.dpatch
cabal install
With this patch, the error message is:
Left (unknown) (line 18, column 1):
expecting space or atom name
* Ben Gamari bgamari.f...@gmail.com [2011-09-20 23:32:34-0400]
Recently I've been playing around with Parsec for a simple parsing
project. While I was able to quickly construct my grammar (simplified
version attached), getting it working has been a bit tricky. In
particular, I am now stuck trying to figure out why Parsec is
mis-reporting line numbers. Parsec seems convinced that line 12 of my
input (also attached) has a % character,
$ runghc Test.hs
Left (unknown) (line 12, column 1):
unexpected %
expecting space or atom name
while my file clearly disagrees,
10 %FLAG ATOM_NAME
11 %FORMAT(20a4)
12 C1 H1 C2 H2 C3 H3 C4 H4 C5 C6 C7 C8 N1 C9 H9 C10 H10 C11
H11 C12
13 H12 C13 H13 C14 C15 N2 C16 C17 C29 H18 C19 H19 C20 H20 C21 H21 C22
H221H222H223
...
18 %FLAG CHARGE
19 %FORMAT(5E16.8)
The task here is to identify the block of data lines (lines 12-17),
ending at the beginning of the next block (starting with %). It seems
likely that my problem stems from the fact that I use try to
accomplish this but this is as far as I can reason.
Any ideas what might cause this sort of off-by-one? Does anyone see a
better (i.e. working) way to formulate my grammar? Any and all help
would be greatly appreciated. Thanks.
Cheers,
- Ben
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Roman I. Cheplyaka :: http://ro-che.info/
4 patches for repository http://code.haskell.org/parsec3:
Sun Feb 20 18:24:22 EET 2011 Roman Cheplyaka r...@ro-che.info
* Choose the longest match when merging error messages
Sun Feb 20 18:24:49 EET 2011 Roman Cheplyaka r...@ro-che.info
* try: do not reset the error position
Sun Feb 20 18:29:20 EET 2011 Roman Cheplyaka r...@ro-che.info
* lookAhead: do not consume input on success; update documentation
Sun Feb 20 19:30:26 EET 2011 Roman Cheplyaka r...@ro-che.info
* Improve ?
New patches:
[Choose the longest match when merging error messages
Roman Cheplyaka r...@ro-che.info**20110220162422
Ignore-this: 54e2733159a1574abb229e09ff6935c1
] hunk ./Text/Parsec/Error.hs 137
= ParseError pos (msg : filter (msg /=) msgs)
mergeError :: ParseError - ParseError - ParseError
-mergeError (ParseError pos msgs1) (ParseError _ msgs2)
-= ParseError pos (msgs1 ++ msgs2)
+mergeError (ParseError pos1 msgs1) (ParseError pos2 msgs2)
+= case pos1 `compare` pos2 of
+-- select the longest match
+EQ - ParseError pos1 (msgs1 ++ msgs2)
+GT - ParseError pos1 msgs1
+LT - ParseError pos2 msgs2
instance Show ParseError where
show err
[try: do not reset the error position
Roman Cheplyaka r...@ro-che.info**20110220162449
Ignore-this: 8508bc41fc6dcd9b7c06aac762f12c71
] hunk ./Text/Parsec/Prim.hs 435
try :: ParsecT s u m a - ParsecT s u m a
try p =
-ParsecT $ \s@(State _ pos _) cok _ eok eerr -
-let pcerr parseError = eerr $ setErrorPos pos parseError
-in unParser p s cok pcerr eok eerr
+ParsecT $ \s cok _ eok eerr -
+unParser p s cok eerr eok eerr
-- | The parser @tokenPrim showTok posFromTok testTok@ accepts a token @t@
-- with result @x@ when the function @testTok t@ returns @'Just' x@. The
[lookAhead: do not consume input on success; update documentation
Roman Cheplyaka r...@ro-che.info**20110220162920
Ignore-this: e884771490209b93e9fec044543a18ef
] {
hunk ./Text/Parsec/Combinator.hs 279
|
do{ x - p; xs - scan; return (x:xs) }
--- | @lookAhead p@ parses @p@ without consuming any input.
-
-lookAhead :: (Stream s m t) = ParsecT s u m a - ParsecT s u m a
-lookAhead p = do{ state - getParserState
-; x - p
-; setParserState state
-; return x
-}
-
hunk ./Text/Parsec/Prim.hs 40
, (|)
, label
, labels
+, lookAhead
, Stream(..)
, tokens
, try
hunk ./Text/Parsec/Prim.hs 439
ParsecT $ \s cok _ eok eerr -
unParser p s cok eerr eok eerr
+-- | @lookAhead p@ parses @p@ without consuming any input.
+--
+-- If @p@ fails and consumes some input, so does
Re: [Haskell-cafe] Binding a socket to all interfaces
Hi Michael, Kazu recently fixed this (in the stable branch on GitHub) in Network.listenOn but perhaps the more basic Network.Socket.listen should also be changed. Lets discuss what's the right thing to do in this thread. On Wed, Sep 21, 2011 at 1:38 PM, Michael Snoyman mich...@snoyman.comwrote: Hi, One of the recurring issues that comes up in Warp is binding to IPv4 versus IPv6 hosts. Our current code is available at [1]. It was updated to look like that in this commit [2] in order to support both IPv4 and IPv6 hosts by default. However, now it seems than on Debian and FreeBSD, it *only* responds to IPv6 by default[3][4]. I'm frankly stumped at this point on how to have our cake and eat it too. Does anyone have an idea of the correct incantation to get Warp to do the Right Thing(tm) here? And if not, is there any advice on sensible default behavior? I'm considering allowing a few special host values: * * (default, what we have now): Make this bind to IPv4 * ipv4: Again, bind to IPv4. Guaranteed not to change in the future * ipv6: Bind to IPv6. Michael [1] https://github.com/yesodweb/wai/blob/master/warp/Network/Wai/Handler/Warp.hs#L119 [2] https://github.com/snoyberg/warp/commit/02c1396c86e3fceb48cbe7df58cb631c804e24d4 [3] https://github.com/snoyberg/warp/issues/9 [4] http://stackoverflow.com/questions/7486257/yesod-devel-server-only-listening-on-ipv6 ___ 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
[Haskell-cafe] stack overflow pain
I'm getting a stack overflow exception in code like this: -- applyAction :: A - IO [B] vs - fmap concat $ mapM applyAction sas return vs I don't get it if I change the code to this: -- applyAction :: A - IO [B] mapM_ applyAction sas return [] But of course, I need the results from the actions. I know that the returned list contains approximately 1 million items. Any suggestions on how I should rewrite the first code snippet to not blow the stack? I do find debugging stack overflow errors quite difficult - with little information from the runtime I'm often left guessing which parts of a large codebase might be causing them. Note that there's plenty of heap space available, it's the evaluation stack that is being used up. I could run with -K to increase the size of the stack, but if possible I'd rather solve this in the code. Thanks for any pointers. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] stack overflow pain
Tim Docker wrote: I'm getting a stack overflow exception in code like this: -- applyAction :: A - IO [B] vs - fmap concat $ mapM applyAction sas return vs I don't get it if I change the code to this: -- applyAction :: A - IO [B] mapM_ applyAction sas return [] But of course, I need the results from the actions. I know that the returned list contains approximately 1 million items. Any suggestions on how I should rewrite the first code snippet to not blow the stack? Of course, a list of 1 million items is going to take a lot of memory, unless you generate it lazily. Unfortunately mapM cannot generate its result lazily because it has to execute all IO actions before returning the list of results. I'm not entirely sure whether the stack overflow happens in this part of your code, though. What happens if you change it to map_ applyAction sas return [1..100] ? If this still throws a stack overflow, then problem is in the part of the code that consumes said list. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered not entirely great?
Daniel Fischer daniel.is.fisc...@googlemail.com writes: Btw, -0.0 can be problematic too. How so? As far as I can tell Ord and Eq treat it as equal to 0.0 in every way, Yes. Which can be inconvenient if you are interested in whether you got a -0.0, so if that's the case, you can't simply use (== -0.0). For instance, somebody might have the idea to store floating point values in a HashSet, which might (or might not) produce a different result from the regular Set in this case. Conversely, you might get different values out of the set than the ones you put into it, which could be surprising. IMO, it's definitely a good practice to avoid otherwise distinguishable values comparing as equal. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] stack overflow pain
On 21/09/11 02:39, Heinrich Apfelmus wrote: Tim Docker wrote: I'm getting a stack overflow exception in code like this: -- applyAction :: A - IO [B] vs - fmap concat $ mapM applyAction sas return vs I don't get it if I change the code to this: -- applyAction :: A - IO [B] mapM_ applyAction sas return [] But of course, I need the results from the actions. I know that the returned list contains approximately 1 million items. Any suggestions on how I should rewrite the first code snippet to not blow the stack? Of course, a list of 1 million items is going to take a lot of memory, unless you generate it lazily. Unfortunately mapM cannot generate its result lazily because it has to execute all IO actions before returning the list of results. I'm OK with it taking a lot of memory. I should have enough. It's the stack overflow exception I'm struggling with. I'm not entirely sure whether the stack overflow happens in this part of your code, though. What happens if you change it to map_ applyAction sas return [1..100] ? If this still throws a stack overflow, then problem is in the part of the code that consumes said list. I believe the error is happening in the concat because there are subsequent IO actions that fail to execute. ie the code is equivalent to: vs - fmap concat $ mapM applyAction sas someOtherAction consume vs and someOtherAction seems not to be run. However, to be sure, I'll confirm with code akin to what you suggest above. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Turn GC off
I doubt it. Even if you could turn GC completely off, the vast majority of GHC Haskell programs will run out of memory very quickly. Lazy evaluation has been called evaluation by allocation; unless your program has very simple requirements and can live in the completely-strict fragment of Haskell without consing, almost everything allocates something. Also, your programs probably won't even run faster without GC, as GHC's GC is an important part of getting halfway reasonable L2 cache performance. Best, Leon On Wed, Sep 14, 2011 at 12:42 PM, Andreas Voellmy andreas.voel...@gmail.com wrote: Hi everyone, Is there a way to completely turn garbage collection off in the Haskell runtime system? I'm aware of the -A runtime option, but I'd like to completely turn it off, if possible. I'm OK with running the program until it runs out of memory, and I'm willing to recompile GHC if needed. Regards, Andreas ___ 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] stack overflow pain
On Thursday 22 September 2011, 01:00:37, Tim Docker wrote: I believe the error is happening in the concat because there are subsequent IO actions that fail to execute. ie the code is equivalent to: vs - fmap concat $ mapM applyAction sas someOtherAction consume vs and someOtherAction seems not to be run. However, to be sure, I'll confirm with code akin to what you suggest above. I suspect that `applyAction x' produces a large thunk for several x in sas, and those blow the stack. You could try forcing evaluation earlier, mapM' :: (a - IO [b]) - [a] - IO [b] mapM' act (m:ms) = do xs - act m yss - length xs `seq` mapM' act ms return (xs ++ yss) mapM' _ [] = return [] perhaps even forcing the values of xs (deepseq, if b is an NFData instance). Depending on what your actual problem is, that could help or make it worse. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] stack overflow pain
On Wed, Sep 21, 2011 at 3:39 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: Of course, a list of 1 million items is going to take a lot of memory, unless you generate it lazily. Unfortunately mapM cannot generate its result lazily because it has to execute all IO actions before returning the list of results. That's oversimplifying a bit. The outer list cannot be generated lazily, but the inner values (in this case inner lists) can be generated lazily. On Wed, Sep 21, 2011 at 7:00 PM, Tim Docker t...@dockerz.net wrote: I believe the error is happening in the concat because there are subsequent IO actions that fail to execute. ie the code is equivalent to: vs - fmap concat $ mapM applyAction sas someOtherAction consume vs and someOtherAction seems not to be run. However, to be sure, I'll confirm with code akin to what you suggest above. The error shouldn't be happening in either concat or mapM. Are you sure that someOtherAction isn't being run? Might it be writing to a file and the result isn't getting flushed? GHC has no inherent limit on the stack size, though using extremely large amounts of stack is usually indicative of an error. You can up the stack limit with the -Ksize RTS option, and I think there is a way it can be disabled entirely.You might try upping your stack size and profiling your program to see if that's helpful: the -xt profiling option might be useful, but I haven't played with it much. I suspect the issue is that one of your applyAction is creating a thunk that blows the stack when it's evaluated, and return [] ensures that the thunk is never evaluated.Though it's not clear to me why it'd be getting evaluated in this new scenario with the information you've provided, assuming you really truly aren't running someOtherAction. Best, Leon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange No instance error with cabal install
Sorry, forgot to send to the list, But everything works today, and the commit was pulled from aeson to aeson-native, so that must have been it. Thanks! On Wed, Sep 21, 2011 at 8:20 AM, Rune Harder Bak r...@bak.dk wrote: So you are saying, that this is basically because he has other version of different packages, not providing the same instances, that makes sense. The other problem was no instance for Default (Request R) (Request from Network.Wai) It was provided by http-enumerator, but maybe not in his version of the package. I tried with aeson-native after you post without look, but I see a new one has been released now. Going to try it today. Thanks! On Tue, Sep 20, 2011 at 2:00 PM, Roel van Dijk vandijk.r...@gmail.com wrote: I see the aeson version with the stricter dependency on deepseq 1.2 is now also released on hackage: http://hackage.haskell.org/package/aeson-0.3.2.12 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hackage library info
On Tue, Sep 20, 2011 at 2:16 PM, Joachim Breitner m...@joachim-breitner.dewrote: Hi, Am Dienstag, den 20.09.2011, 22:07 +0100 schrieb Stephen Tetley: There have been plans to add rankings to Hackage and a GSOC looked into adding them. Roel van Dijk built reverse dependencies for Hackage which illustrated the most popular libraries, unfortunately the link seems broken: http://bifunctor.homelinux.net/~roel/hackage/packages/hackage.html If you just need to look up the reverse dependencies (which is important, e.g., for distribution packagers before upgrading a library), there is also http://packdeps.haskellers.com/reverse That's useful. Is there a way to see which packages do the depending? Greetings, Joachim -- Joachim nomeata Breitner m...@joachim-breitner.de | nome...@debian.org | GPG: 0x4743206C xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ ___ 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] stack overflow pain
Tim Docker t...@dockerz.net writes:
mapM_ applyAction sas
Maybe you could try a lazy version of mapM? E.g., I think this would do
it:
import System.IO.Unsafe (unsafeInterleaveIO)
:
mapM' f = sequence' . map f
where sequence' ms = foldr k (return []) ms
k m m' = do { x - m; xs - unsafeInterleaveIO m'; return (x:xs) }
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec line number off-by-one
Hi, 1. your lookAhead is unnecessary, because your items (atomNames) never start with %. 2. your try fails in (line 12, column 1), because the last item (aka atomName) starts consuming \n, before your eol parser is called. So rather than calling spaces before every real atom, I would call it after every real atom and after your formatDecl (so before your linesOf parser). atomNameBlock = do flagDecl ATOM_NAME formatDecl spaces atomNames - many1 atomName return $ AtomNames atomNames where atomName = do name - countBetween 1 4 (alphaNum | oneOf \'+-) ? atom name spaces return name Since spaces also consume \n, linesOf can just be many1! HTH Christian Am 21.09.2011 05:32, schrieb Ben Gamari: Recently I've been playing around with Parsec for a simple parsing project. While I was able to quickly construct my grammar (simplified version attached), getting it working has been a bit tricky. In particular, I am now stuck trying to figure out why Parsec is mis-reporting line numbers. Parsec seems convinced that line 12 of my input (also attached) has a % character, $ runghc Test.hs Left (unknown) (line 12, column 1): unexpected % expecting space or atom name while my file clearly disagrees, 10 %FLAG ATOM_NAME 11 %FORMAT(20a4) 12 C1 H1 C2 H2 C3 H3 C4 H4 C5 C6 C7 C8 N1 C9 H9 C10 H10 C11 H11 C12 13 H12 C13 H13 C14 C15 N2 C16 C17 C29 H18 C19 H19 C20 H20 C21 H21 C22 H221H222H223 ... 18 %FLAG CHARGE 19 %FORMAT(5E16.8) The task here is to identify the block of data lines (lines 12-17), ending at the beginning of the next block (starting with %). It seems likely that my problem stems from the fact that I use try to accomplish this but this is as far as I can reason. Any ideas what might cause this sort of off-by-one? Does anyone see a better (i.e. working) way to formulate my grammar? Any and all help would be greatly appreciated. Thanks. Cheers, - Ben ___ 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] instance Enum Double considered not entirely great?
From: Casey McCann c...@uptoisomorphism.net CAJ5riwLLu=wAFXm8VPnqRG2Daxxgf=upgxzchydmebgngix...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 20, 2011 at 8:20 PM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: However, nowadays I tend to think that making the Eq and Ord instances well-behaved (wrt the class contract) and having separate IEEE comparisons would overall be preferable. There is still the question whether all NaNs should be considered equal or not [and where Ord should place NaNs]. IEEE semantics are incompatible with Ord regardless. The problem can be fixed by changing Ord, removing the instance completely, or changing the instance to ignore the IEEE spec. I think the latter is the least bad option in the big picture. I still don't see why it makes sense to add separate IEEE comparisons instead of just adding a standard partial order class, though. Surely posets are common enough to justify the abstraction, and it surprises me that one isn't already included. No doubt there are at least three or four different partial ordering classes on Hackage already. I agree with this already, and will agree more strongly if ConstraintKinds become widely available. Google suggests Exception for NaN from May. Ah, yes, wherein someone suggested that comparing to NaN should be a runtime error rather than give incorrect results. A strictly more correct approach, but not one I find satisfactory... I would consider this better than the current situation. At least your sets wouldn't be silently corrupted. John L. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Binding a socket to all interfaces
Hello, My fix intended that Haskell code behaves the same in various environments. That is, one socket catches both IPv4 and IPv6. And the fix works even in both IPv4-only env and IPv6-only env. Johan's observation is correct. Network.listenOn is alreay fixed but Network.Socket.listen, which Warp relies on, is not fixed yet. I will try to fix it. When the next version of the network library will be released, the problem will disappear, I hope. --Kazu Hi Michael, Kazu recently fixed this (in the stable branch on GitHub) in Network.listenOn but perhaps the more basic Network.Socket.listen should also be changed. Lets discuss what's the right thing to do in this thread. On Wed, Sep 21, 2011 at 1:38 PM, Michael Snoyman mich...@snoyman.com wrote: Hi, One of the recurring issues that comes up in Warp is binding to IPv4 versus IPv6 hosts. Our current code is available at [1]. It was updated to look like that in this commit [2] in order to support both IPv4 and IPv6 hosts by default. However, now it seems than on Debian and FreeBSD, it *only* responds to IPv6 by default[3][4]. I'm frankly stumped at this point on how to have our cake and eat it too. Does anyone have an idea of the correct incantation to get Warp to do the Right Thing(tm) here? And if not, is there any advice on sensible default behavior? I'm considering allowing a few special host values: * * (default, what we have now): Make this bind to IPv4 * ipv4: Again, bind to IPv4. Guaranteed not to change in the future * ipv6: Bind to IPv6. Michael [1] https://github.com/yesodweb/wai/blob/master/warp/Network/Wai/Handler/ Warp.hs#L119 [2] https://github.com/snoyberg/warp/commit/ 02c1396c86e3fceb48cbe7df58cb631c804e24d4 [3] https://github.com/snoyberg/warp/issues/9 [4] http://stackoverflow.com/questions/7486257/ yesod-devel-server-only-listening-on-ipv6 ___ 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] instance Enum Double considered not entirely great?
On Tue, Sep 20, 2011 at 11:29 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: On 21/09/2011, at 2:59 AM, Chris Smith wrote: On Mon, 2011-09-19 at 22:09 -0700, Evan Laforge wrote: Then I tried switching to a fixed point format, and discovered my mistake. Enum is supposed to enumerate every value between the two points, and the result is memory exhaustion. % ghci Prelude [1.0..2.0]::[Double] [1.0,2.0] (..) for Doubles is using (+1), not nextAfter, and is NOT enumerating every value between 1.0 and 2.0 import Ratio Prelude Ratio [1%2..7%2] :: [Ratio Int] [1 % 2,3 % 2,5 % 2,7 % 2] (..) for (Ratio a) is using (+1), and is NOT enumerating the infinitely many values between 1.5 and 3.5. Why should your fixed point format behave any differently? Evan's claim was that Double and Ratio are doing the incorrect thing; the evidence you gave may support your point, but it supports his as well. My claim now, and I think Evan agrees although I am not sure, is that Double and Ratio shouldn't be instances of Enum at all, since enumerating (a simulation of) the reals and enumerating the rationals in order is nonsensical. I also find that toEnum . fromEnum /= id annoying; anything that relies on it, like EnumSet/EnumMap [1], goes down the toilet. Other things I think are reasonable to expect are also broken; for example, toEnum . succ . fromEnum /= succ (granted, it is reasonable to expect this to be broken considering that toEnum . fromEnum is broken). With fixed point numbers, it makes sense to have an Enum instance. Enumeration is reasonable because most applications for fixed point arithmetic do *not* want to pretend that they are real numbers; you almost always want to be aware of the current precision and whether you might overflow or need more precision. This situation is no different from Word or Int. toEnum and fromEnum are also inverses. No expectations are violated here unless you have already gotten used to the broken Float, Double, and Rational instances. - Jake [1] http://www.haskell.org/haskellwiki/EnumSet_EnumMap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec line number off-by-one
On Wed, 21 Sep 2011 11:27:31 +0200, Christian Maeder christian.mae...@dfki.de wrote: Hi, 1. your lookAhead is unnecessary, because your items (atomNames) never start with %. I see. 2. your try fails in (line 12, column 1), because the last item (aka atomName) starts consuming \n, before your eol parser is called. Ahh, this is a good point. I for some reason seeded the thought in my mind that spaces takes the ' ' character, not '\n'. So rather than calling spaces before every real atom, I would call it after every real atom and after your formatDecl (so before your linesOf parser). Excellent solution. I appreciate your help. That would have taken me quite a bit of head-banging to find. Cheers, - Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec line number off-by-one
On Wed, 21 Sep 2011 09:37:40 +0300, Roman Cheplyaka r...@ro-che.info wrote: Hi Ben, This is indeed a bug in parsec. Ahh good. I'm glad I'm not crazy. Given that it seems the lookahead is actually unnecessary, looks like I can skip the patch too. Thanks for your reply! Cheers, - Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mapM is supralinear?
On 09/09/2011, at 8:19 PM, John Lato wrote: Agreed. Whenever I'd like to use mapM (or any other function for which a *M_ is available), I've found the following rules helpful: 1. If I can guarantee the list is short (~ n=20), go ahead and use mapM 2. Otherwise use mapM_, foldM_, or foldM if a real reduction is possible (i.e. not foldM snocM []). Step 2 sometimes requires changing my design, but it's always been for the better. `mapM_` tends to require more pipeline composition, so it's leveraging the language's strengths. This thread is really interesting - it relates directly to problems I am currently having with mapM over large lists (see the thread stack overflow pain). Can you explain what you mean by mapM_ tends to require more pipeline composition? In what way is it leveraging the language strengths? Thanks, Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] poles/residues - FIR tap weights ?
Anyone know of a Haskell package containing a function for converting a list of pole/residue pairs into FIR filter tap weights? Thanks, -db ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered not entirely great?
On Tue, Sep 20, 2011 at 11:47 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: On 21/09/2011, at 2:18 PM, Casey McCann wrote: I still don't see why it makes sense to add separate IEEE comparisons instead of just adding a standard partial order class, though. In any mathematical partial order, we expect x `le` x to be a law. But in IEEE arithmetic, if x is a NaN, x `le` x is false. I don't see how to reconcile these. Ah, true. There is an obvious way to reconcile this that almost suffices, and is what I'd had in mind--simply declare that, just as positive and negative zero are distinct values but identified with each other by the ordering, let NaN be disidentified with itself. Essentially this treats NaN as representing an unbounded collection of distinct, but indistinguishable and incomparable, values, where you never end up getting the same one twice. This interpretation is self-consistent so long as the expressions being compared are distinct to begin with, but now that you point it out explicitly I realize it not only can't be justified when comparing syntactically identical terms, but that given equivalent expressions it would imply that a pure function gives different results each time, which is not in any way a satisfactory result of something that's trying to *improve* the semantics involved! So that's a bust. Bother. Specialized comparisons providing IEEE semantics seems the best option after all, then. I'd still like to see a standard partial order type class, but apparently it wouldn't help in this case. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New: A French translation of Learn You A Haskell for Great Good!
On Wed, Sep 21, 2011 at 00:00:26 +0200, Valentin ROBERT wrote: http://lyah.haskell.fr Excellent http://haskell.fr Since you're starting from fresh, it would be great if the wiki were running Gitit instead of Mediawiki. Advantages: - Markdown is used in many places - You can have a Git/Darcs repository behind this See http://wiki.darcs.net for an example of this in action. Would be great if Haskell wiki were also running Gitit but that's a potentially a tougher nut to crack -- Eric Kow http://erickow.com pgpbyqUY94Xxb.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hackage library info
Unfortunately the bifunctor.homelinux.net domain stopped working. The reverse dependencies can now be found at: http://revdeps.hackage.haskell.org/ The reverse dependency algorithm needs some love. Some packages have -1 reverse dependencies, which is somewhat strange. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hackage library info
On 20 September 2011 23:07, Stephen Tetley stephen.tet...@gmail.com wrote: Roel van Dijk built reverse dependencies for Hackage which illustrated the most popular libraries, unfortunately the link seems broken: http://bifunctor.homelinux.net/~roel/hackage/packages/hackage.html The new URL is: http://revdeps.hackage.haskell.org We still have to announce it officially. However we would like to fix some minor bugs first. Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New: A French translation of Learn You A Haskell for Great Good!
On Wed, Sep 21, 2011 at 16:01, Eric Y. Kow eric@gmail.com wrote: On Wed, Sep 21, 2011 at 00:00:26 +0200, Valentin ROBERT wrote: http://lyah.haskell.fr Excellent http://haskell.fr On this particular topic, someone asked me why I did not reuse the FR part of Haskell wiki. That's a reasonable question in my opinion. We have this page: http://www.haskell.org/haskellwiki/Fr/Haskell Now, is it feasible, and okay, to create a French sub-wiki inside Haskell Wiki? What would be the advantages, and inconvenients? If we wanted to, I could just have haskell.fr redirect there. I am actually not satisfied with the wiki I created, for instance syntax highlighting with the presence of links is a huge pain, as you might notice if you read the sources... and not automated at all... I'd be happy to test Gitit and switch to it if it makes sense. Concerning the integration or separation with HaskellWiki: * Integration (+) Everything is in the same place (+) We can link english articles from the French ones when there's no translation (+) We benefit from the work that was done on HaskellWiki (the design, the syntax highlighting) (-) When people go to the home page, it's all English again! (-) Lack of visibility (it's actually not trivial to find the page I linked up there...) (-) We inherit the flaws of HaskellWiki (as you mentioned, maybe use another wiki engine) (?) How feasible is it? Should all our pages be into a fr namespace or something in these lines? * Separation (+) We are free to do things differently (-) We're separated from haskell.org, which is the reference place Well, I'd be happy to discuss this further. As you said, it's still fresh enough that I'm okay with moving everything elsewhere or restarting from zero. - Valentin Robert Since you're starting from fresh, it would be great if the wiki were running Gitit instead of Mediawiki. Advantages: - Markdown is used in many places - You can have a Git/Darcs repository behind this See http://wiki.darcs.net for an example of this in action. Would be great if Haskell wiki were also running Gitit but that's a potentially a tougher nut to crack -- Eric Kow http://erickow.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Binding a socket to all interfaces
Hi, On Wed, Sep 21, 2011 at 7:38 PM, Kazu Yamamoto k...@iij.ad.jp wrote: Johan's observation is correct. Network.listenOn is alreay fixed but Network.Socket.listen, which Warp relies on, is not fixed yet. I will try to fix it. When the next version of the network library will be released, the problem will disappear, I hope. We should consider how we fix this. Right now N.S.listen just wraps the underlying system call. Is that the right place to set socket options? Perhaps we should set them when creating the socket instead? -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] stack overflow pain
On Wed, Sep 21, 2011 at 6:04 AM, Ketil Malde ke...@malde.org wrote:
Tim Docker t...@dockerz.net writes:
mapM_ applyAction sas
Maybe you could try a lazy version of mapM? E.g., I think this would do
it:
Another option is to use a version of mapM that accumulates the result
on the heap. Maybe this would do the trick:
mapM' f = go []
where
go acc [] = return (reverse acc)
go acc (a:as) = do {x - a; go (x:acc) as}
HTH,
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Binding a socket to all interfaces
Hi, We should consider how we fix this. Right now N.S.listen just wraps the underlying system call. Is that the right place to set socket options? Perhaps we should set them when creating the socket instead? Yes, of course. If I remember correctly, this option works only between socket() and listen(). I need to check that this option is effective to all sockets or only to listing sockets. Anyway, I will try this in the next week. I used to be an expert of IPv6 but I forget many things recently... I should remember. --Kazu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] stack overflow pain
On 21 September 2011 17:32, Felipe Almeida Lessa felipe.le...@gmail.com wrote:
On Wed, Sep 21, 2011 at 6:04 AM, Ketil Malde ke...@malde.org wrote:
Tim Docker t...@dockerz.net writes:
mapM_ applyAction sas
Maybe you could try a lazy version of mapM? E.g., I think this would do
it:
Another option is to use a version of mapM that accumulates the result
on the heap. Maybe this would do the trick:
mapM' f = go []
where
go acc [] = return (reverse acc)
go acc (a:as) = do {x - a; go (x:acc) as}
HTH,
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
I think that's indeed the problem. It reminds me of bug:
http://hackage.haskell.org/trac/ghc/ticket/5042
There the fix was also to accumulate results on the heap.
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] skein-0.1: Skein, a family of cryptographic hash functions. Includes Skein-MAC as well.
On Wed, Sep 21, 2011 at 2:29 AM, Vincent Hanquez t...@snarc.org wrote:
Hi Felipe,
it's good to see more Skein stuff. it's a great crypto hash and one of the
few remaining candidate for SHA-3.
Have you seen the cryptohash package
http://hackage.haskell.org/package/cryptohash ?
I always wanted to expose more skein operations specially the hmac function,
but never came around to, and maybe it would be good to merge to avoid
duplicating efforts ?
I'm aware of cryptohash. I just went through the lazy route of
binding to the C library instead of implementing those UBI details =).
It would be nice to merge and have everything on cryptohash though.
And I guess that cryptohash may become faster than skein because the C
library has some implementation details that are unneeded (e.g. it has
a buffer, but hash/hash' are kind enough to only give full buffers to
the libraries).
Also, it seems that cryptohash's Skein is currently broken. The skein
package comes with the golden KATs sent by the Skein team to the
NIST, and passes everything. OTOH, cryptohash's Skein256/Skein512 do
not agree with skein's Skein_256_256/Skein_512_512. I've attached a
test suite that quickchecks if both implementations give the same
answer. My hunch is that you are using the wrong constants, because
the first test case (the empty string) already fails:
1) cryptohash and skein have the same implementation of Skein-256-256 FAILED
*** Failed!
skein: bc 27 63 f7 07 e2 62 b8 0e 03 13 79 15 43 a7 ab 0a 4b 6c
d0 83 27 0a fb 2f ce 42 72 e1 bb 0a a9
cryptohash: 0b 04 10 3b 82 8c dd ae bc f5 92 ac 84 5e ca fd 58 87 f6
12 30 a7 55 40 6d 38 d8 53 76 e1 ae 08
(after 1 test):
(none)
2) cryptohash and skein have the same implementation of Skein-512-512 FAILED
*** Failed!
skein: d3 f7 26 3a 09 83 7f 4c e5 c8 ef 70 a5 dd ff ac 7b 92 d6
c2 ac e5 a1 22 65 bd 5b 59 32 60 a3 ff 20 d8 b4 b4 c5 49 4e 94 54 48
b3 7a bb 1f c5 26 f6 b4 60 89 20 8f de 93 8d 7f 23 72 4c 4b df b7
cryptohash: 5a f6 8a 49 12 e0 a6 18 7a 00 49 47 a9 d2 a3 7d 7a 1f 08
73 f0 bd d9 dc 64 83 8e ce 60 da 55 35 c2 a5 5d 03 9b d5 8e 17 89 48
99 6b 7a 83 36 48 6e d9 69 c8 94 be 65 8e 47 d5 95 a5 a9 b8 6a 8b
(after 1 test):
(none)
Cheers, =D
--
Felipe.
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# OPTIONS_GHC -fno-warn-orphans #-}
import Data.Char (intToDigit)
import Data.List (intersperse)
import Test.Hspec.Monadic hiding (Result)
import Test.QuickCheck hiding (Result(..), reason, property)
import Test.QuickCheck.Property (succeeded, failed, Result(..))
import Test.Hspec.QuickCheck
import qualified Data.ByteString as B
import Data.Serialize (encode)
import Crypto.Classes (Hash, hash')
import Crypto.Hash.Skein256 (Skein256)
import Crypto.Hash.Skein512 (Skein512)
import Crypto.Skein (Skein_256_256, Skein_512_512)
main :: IO ()
main = hspecX $ do
describe cryptohash and skein have the same implementation of $ do
it Skein-256-256 $ property $ same (u :: Skein_256_256) (u :: Skein256)
it Skein-512-512 $ property $ same (u :: Skein_512_512) (u :: Skein512)
u :: a
u = undefined
same :: (Hash ctx1 dig1, Hash ctx2 dig2) = dig1 - dig2 - Input - Result
same dig1 dig2 (Input inp) =
let h1 = hash' inp `asTypeOf` dig1
h2 = hash' inp `asTypeOf` dig2
in if encode h1 == encode h2
then succeeded
else failed { reason = \nskein: ++ show (Input $ encode h1) ++
\ncryptohash: ++ show (Input $ encode h2) ++ \n}
newtype Input = Input B.ByteString
instance Show Input where
show (Input bs)
| B.null bs = (none)
| otherwise = concat $ intersperse $ map toHex $ B.unpack bs
where toHex = map intToDigit . (\(a,b) - [a,b]) . (`divMod` 16) . fromIntegral
instance Arbitrary Input where
arbitrary = (Input . B.pack) `fmap` arbitrary
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] doctest: Interpreter exited with an error: ExitFailure 127
On Tue, Sep 20, 2011 at 7:50 PM, informationen informatio...@gmx.de wrote: doctest: Interpreter exited with an error: ExitFailure 127 You are trying the doctest binary from the command line and not the library interface? I tried this with ghc 7.0.3 and doctest 0.4.1 but could not reproduce it with $ doctest Fib.hs. On the other hand you have in the example a space before -- | Compute.. and that produces a parse error for me. This is the content of Fib.hs: module Fib where -- | Compute Fibonacci numbers -- Sakari ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] doctest: Interpreter exited with an error: ExitFailure 127
On Wed, Sep 21, 2011 at 07:30:16PM +0300, Sakari Jokinen wrote: On Tue, Sep 20, 2011 at 7:50 PM, informationen informatio...@gmx.de wrote: doctest: Interpreter exited with an error: ExitFailure 127 You are trying the doctest binary from the command line and not the library interface? I tried this with ghc 7.0.3 and doctest 0.4.1 but could not reproduce it with $ doctest Fib.hs. On the other hand you have in the example a space before -- | Compute.. and that produces a parse error for me. This is the content of Fib.hs: module Fib where -- | Compute Fibonacci numbers -- Sakari Hi Sakari, yes, i am using the binary version of doctest. I don't know where the extra space comes from, but that is not the problem. Do you have any idea, what the error message wants to tell me. What does interpreter exited with .. mean. If i add a main-method i can run the program flawlessly with runghc, but doctest still refuses to work. Kind regards Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] skein-0.1: Skein, a family of cryptographic hash functions. Includes Skein-MAC as well.
The skein package comes with the golden KATs sent by the Skein team to NIST Great! Care to add that to the crypto-api test code? Cheers, Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] doctest: Interpreter exited with an error: ExitFailure 127
On Wed, Sep 21, 2011 at 7:52 PM, informationen informatio...@gmx.de wrote: Do you have any idea, what the error message wants to tell me. What does interpreter exited with .. mean. If i add a Doctests starts ghc in interactive mode for evaluating the examples. interpreter exited with.. means that the spawned ghc process exited with an error code. See src/Interpreter.hs : closeInterpreter for details. One guess based on the 127 exit code would be that runnable ghc is not found in the place defined by GHC.Paths.ghc. By the way it seems that doctest (or haddoc) needs you to specify the type signature for functions for which you write examples. So no examples are run for 'fib' Sakari ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered not entirely great?
On Tue, Sep 20, 2011 at 11:33 PM, rocon...@theorem.ca wrote: For what it's worth, at some point in time I was sketching a proposal to split the Enum class into two classes because I felt that two distinct ideas were being conflated. Unfortunately this was years ago and I have forgotten what the details I was thinking. Perhaps someone can reconstruct a proposal along these lines. Considering the desugaring of list range syntax in general, rather than the Enum class as such, I would argue for *three* ideas, which are all supported with varying degrees of success by the current implementation: 1) Exhaustive enumeration of a finite range, where the desired meaning of [a..z] is almost exactly that of Data.Ix.range (a, z). 2) Iterative generation of a sequence, where the desired meaning of [a, b..z] is iterating a function implicitly defined by the offset between a and b, plus an optional takeWhile using some predicate determined by z. The nature of the offset, predicate, c. would be defined on a per-type basis, possibly including a default offset for when b isn't specified, but personally I'd rather just disallow that in this case. 3) Evenly-spaced divisions of an infinite range, where the desired meaning of [a,b..z] assumes that the distance from a to b evenly divides the distance from a to z, and the result is a list containing (1 + (z-a)/(b-a)) elements such that all differences between successive elements are equal, with a and z present as the first and last elements. For most types other than fractional numbers and floats, the third interpretation isn't well-defined and the first coincides both with an Ix instance (if one exists) and with the second interpretation using the smallest nonzero offset. Note that the first interpretation does not require a total ordering, and in fact the Ord constraint on Ix is somewhat misleading and nonsensical. As such, the first interpretation naturally extends to more general ranges than what the second can describe. For rationals, floats, approximations of the reals, or any other type with a conceptually infinite number of values in a range, the first interpretation isn't well-defined, and the second and third interpretations should coincide when all three parameters are equal, ignoring rounding errors and inexact representations. The current Enum class attempts to be something like an ill-defined mixture of all three, and where the interpretations don't coincide, the disagreement between them is a likely source of bugs. Worse still, the instance for floating point values mixes the naively expected results of both the second and third in a very counterintuitive way: the enum to value at the end behaves neither as an upper bound (the sequence may exceed it in an effort to avoid rounding errors) nor as a final element (it may not be in the sequence at all, even if it has an exact floating point representation). This seems needlessly confusing to me and is arguably broken no matter which way you slice it. My thoughts are that the first interpretation is most naturally suited to list range syntax, that the second would be better served by a slightly different syntax to make the predicate more explicit, and that the third bugs the crap out of me because it's really very useful but I can't think of a concise and unambiguous syntax for it. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered not entirely great?
On Wed, Sep 21, 2011 at 12:09 AM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: Yes. Which can be inconvenient if you are interested in whether you got a -0.0, so if that's the case, you can't simply use (== -0.0). Okay, problematic is a too strong word, but it's another case that may require special treatment. Hmm. I was going to suggest that it's not a major concern so long as the distinction can't be observed without using functions specific to floating point values, since that preserves consistent behavior for polymorphic functions, but... that's not true, because the sign is preserved when dividing by zero! So we currently have the following behavior: 0 == (-0) = True 1/0 == 1/(-0) = False signum (-0) = 0.0 signum (1/0)= 1.0 signum (1/(-0)) = -1.0 All of which is, I believe, completely correct according to IEEE semantics, but seems to cause very awkward problems for any sensible semantics of Haskell's type classes. ...sigh. which is correct and shouldn't break any expected behavior. I don't think it's required that distinguishable values be unequal, But desirable, IMO. I'm ambivalent. I can see it making sense for truly equivalent values, where there's a reasonable expectation that anything using them should give the same answer, or when there's a clearly-defined normal form that values may be reduced to. But as demonstrated above, this isn't the case with signed zeros if Num is available as well as Eq. I still don't see why it makes sense to add separate IEEE comparisons Pure and simple: speed. That is what the machine instructions, and hence the primops, deliver. Oh, I assume the IEEE operations would be available no matter what, possibly as separate operations monomorphic to Float and Double, that they'd be used to define the partial ordering instance, and could be imported directly from some appropriate module. But as it turns out the partial ordering isn't valid anyway, so I retract this whole line of argument. Ah, yes, wherein someone suggested that comparing to NaN should be a runtime error rather than give incorrect results. A strictly more correct approach, but not one I find satisfactory... Umm, 'more correct' only in some sense. Definitely unsatisfactory. More correct in the very narrow sense of producing fewer incorrect answers, according to Haskell semantics. :] That it would produce fewer answers in general and a great deal more bottoms is another matter. Certainly not useful, and in fact actively counterproductive given that the whole purpose of silent NaNs is to allow computations to proceed without handling exceptions at every step along the way. I'm becoming increasingly convinced that the only strictly coherent approach in the overall scheme of things would be to banish floating point values from most of the standard libraries except where they can be given correct implementations according to Haskell semantics, and instead provide a module (not re-exported by the Prelude) that gives operations using precise IEEE semantics and access to all the expected primops and such. As you said above, the importance of floating point values is for speed, and the IEEE semantics are designed to support that. So I'm happy to consider floats as purely a performance optimization that should only be used when number crunching is actually a bottleneck. Let Rational be the default fractional type instead and save everyone a bunch of headaches. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered not entirely great?
On Wed, Sep 21, 2011 at 14:31, Casey McCann c...@uptoisomorphism.net wrote: My thoughts are that the first interpretation is most naturally suited to list range syntax, that the second would be better served by a slightly different syntax to make the predicate more explicit, and that the third bugs the crap out of me because it's really very useful but I can't think of a concise and unambiguous syntax for it. Based on what you said, I'm wondering if the first gets basic fromTo syntax, the third gets fromThenTo syntax, and the second strikes me as a simplified form of list comprehension and might possibly be phrased as a cross between range and comprehension. Although the most correct such cross has an ambiguity with the comma... can we still use | as the delimiter, read as such that? ([a .. z | filter]) -- 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
Re: [Haskell-cafe] [ANNOUNCE] skein-0.1: Skein, a family of cryptographic hash functions. Includes Skein-MAC as well.
On Wed, Sep 21, 2011 at 2:27 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: The skein package comes with the golden KATs sent by the Skein team to NIST Great! Care to add that to the crypto-api test code? I don't really understand how the testing workflow works on the crypto-api package, but I confess that I didn't try hard enough to understand. I don't like the use of the test flag to conditionally expose Test.* modules. Given that we can't have a flag constraint in build-depends, using those modules would basically break the skein package test suite by default. They would break even in my own box, since crypto-api is installed system-wide without the test flag. So, could we split those Test.* modules into a new package like crypto-api-tests? Then I could have in my .cabal: Library Build-depends: ... crypto-api ... Test-suite runtests Build-depends: ... crypto-api, crypto-api-tests ... and everything would beautifully work =). Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Proposal: Subcomputations in arrow notation
Hello fellow Haskellers, this is a proposal to extend the arrow notation (-XArrows). I find myself writing the following very often: system :: Wire IO () String system = proc _ - do botAddPeriod - succ ^ noise - () botAddSpeed - noise1 - () botAddStart - noise1 - () botMsg - event addBot - (botAddPeriod, botAddSpeed, botAddStart) bots - manager - ((), maybe MgrNop id botMsg) let botStr = concatMap (printf %8.2) . M.elems $ bots :: String identity - printf Bot positions: %s botStr where addBot :: Wire IO (Double, Double, Double) (MgrMsg Int IO () Double) addBot = proc (addPeriod, addSpeed, addStart) - do periodically - addPeriod botId - identifier - () identity - MgrAdd botId (constant addSpeed integral addStart) The relevant part is the first paragraph of the first arrow computation: botAddPeriod - succ ^ noise - () botAddSpeed - noise1 - () botAddStart - noise1 - () botMsg - event addBot - (botAddPeriod, botAddSpeed, botAddStart) This line should generate a message for the bot manager at random intervals. The actual event generator is in the second arrow computation 'addBot'. I would like to be able to write this more in line with the rest of the code. The following is possible: system :: Wire IO () String system = proc _ - do botAddPeriod - succ ^ noise - () botAddSpeed - noise1 - () botAddStart - noise1 - () botMsg - event (proc (addPeriod, addSpeed, addStart) - do periodically - addPeriod botId - identifier - () identity - MgrAdd botId (constant addSpeed integral addStart)) - (botAddPeriod, botAddSpeed, botAddStart) bots - manager - ((), maybe MgrNop id botMsg) let botStr = concatMap (printf %8.2) . M.elems $ bots :: String identity - printf Bot positions: %s botStr This is probably not a big improvement. It's more concise, but also harder to understand. My proposal is to add syntax to allow the following notation: system :: Wire IO () String system = proc _ - do botAddPeriod - succ ^ noise - () botAddSpeed - noise1 - () botAddStart - noise1 - () botMsg - event $ do periodically - addPeriod botId - identifier - () identity - MgrAdd botId (constant addSpeed integral addStart) bots - manager - ((), maybe MgrNop id botMsg) let botStr = concatMap (printf %8.2) . M.elems $ bots :: String identity - printf Bot positions: %s botStr Again the relevant part is the event generator in the middle. In this hypothetical syntax, the compiler would figure out from the inner computation, which variables from the outer scope are used and pass them automatically in an appropriate tuple. You wouldn't need any explicit passing anymore. If others like the idea, too, and there is nobody to implement it, then I would be willing to get in touch with the GHC code and implement this as a patch myself. What do you think? Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered not entirely great?
On Wed, Sep 21, 2011 at 2:41 PM, Brandon Allbery allber...@gmail.com wrote: On Wed, Sep 21, 2011 at 14:31, Casey McCann c...@uptoisomorphism.net wrote: My thoughts are that the first interpretation is most naturally suited to list range syntax, that the second would be better served by a slightly different syntax to make the predicate more explicit, and that the third bugs the crap out of me because it's really very useful but I can't think of a concise and unambiguous syntax for it. Based on what you said, I'm wondering if the first gets basic fromTo syntax, the third gets fromThenTo syntax, and the second strikes me as a simplified form of list comprehension and might possibly be phrased as a cross between range and comprehension. Although the most correct such cross has an ambiguity with the comma... can we still use | as the delimiter, read as such that? ([a .. z | filter]) Hmm. I actually wrote (..) better served by some variation on a list comprehension there at first before editing it to be more non-committal. Interesting to see someone else immediately go for the same idea. Anyway, I think this can already be expressed using GHC's generalized list comprehensions, but the result is more verbose than I would like for this particular very common case. My first thought on resolving ambiguity is to rely on having something distinct following a .., e.g. desugaring [a, b.. | z] as takeWhile ( z) [a, b..], where anything ending in .. ] is taken to be an infinite iterated sequence. This is only slightly more verbose than the current form, arguably more readable, and certainly more explicit. Would need to be more clearly specified what forms the predicate expression could have, however. The fromThenTo syntax doesn't seem entirely satisfactory for the third case, because it creates ambiguity if the step size doesn't evenly divide the range size. Having the first and last elements appear exactly as given in the sequence and having the interval sizes be as consistent as possible are pretty much the entire purpose here, so I'm not sure how to reconcile that. Perhaps rounding the specified interval to the nearest divisor? Kind of a hack, but seems to best approximate the intent (as well as being resilient in the face of imprecision, which is also important). - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Enum Double considered not entirely great?
On Wednesday 21 September 2011, 20:39:09, Casey McCann wrote: On Wed, Sep 21, 2011 at 12:09 AM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: Yes. Which can be inconvenient if you are interested in whether you got a -0.0, so if that's the case, you can't simply use (== -0.0). Okay, problematic is a too strong word, but it's another case that may require special treatment. Hmm. I was going to suggest that it's not a major concern so long as the distinction can't be observed without using functions specific to floating point values, since that preserves consistent behavior for polymorphic functions, but... that's not true, because the sign is preserved when dividing by zero! So we currently have the following behavior: 0 == (-0) = True 1/0 == 1/(-0) = False signum (-0) = 0.0 signum (1/0)= 1.0 signum (1/(-0)) = -1.0 All of which is, I believe, completely correct according to IEEE semantics, Yup. but seems to cause very awkward problems for any sensible semantics of Haskell's type classes. Well, that's something you risk whenever you have an Eq instance regarding some non-identical values as equal. Some function may distinguish between them, cf. e.g. showTree in Data.Set/Map for a non-floating-point example. ...sigh. which is correct and shouldn't break any expected behavior. I don't think it's required that distinguishable values be unequal, But desirable, IMO. I'm ambivalent. I can see it making sense for truly equivalent values, where there's a reasonable expectation that anything using them should give the same answer, or when there's a clearly-defined normal form that values may be reduced to. Yes, it's not an absolute, but if your Eq instance declares distinguishable values equal, you better have a very good reason for it. The reason for Data.Set/Map is good enough, I think. -0.0 == 0.0 is borderline. If Double/Float get Eq and Ord instances avoiding the NaN poison, I'd prefer to distinguish -0.0 from 0.0 too, leaving the identification to the IEEE comparisons. But as demonstrated above, this isn't the case with signed zeros if Num is available as well as Eq. I still don't see why it makes sense to add separate IEEE comparisons Pure and simple: speed. That is what the machine instructions, and hence the primops, deliver. Oh, I assume the IEEE operations would be available no matter what, possibly as separate operations monomorphic to Float and Double, that That too, but I want to keep the polymorphic variants available, it's easier to change a few type signatures near the top than hunting through the entire project to replace eqDouble with eqFloat etc. and recompile everything. they'd be used to define the partial ordering instance, and could be imported directly from some appropriate module. But as it turns out the partial ordering isn't valid anyway, so I retract this whole line of argument. Ah, yes, wherein someone suggested that comparing to NaN should be a runtime error rather than give incorrect results. A strictly more correct approach, but not one I find satisfactory... Umm, 'more correct' only in some sense. Definitely unsatisfactory. More correct in the very narrow sense of producing fewer incorrect answers, according to Haskell semantics. :] That it would produce fewer answers in general and a great deal more bottoms is another matter. Certainly not useful, and in fact actively counterproductive given that the whole purpose of silent NaNs is to allow computations to proceed without handling exceptions at every step along the way. Quite. I'm becoming increasingly convinced that the only strictly coherent approach in the overall scheme of things would be to banish floating point values from most of the standard libraries except where they can Hmm. I don't particularly like that idea. Correctly handling floating point numbers isn't trivial - So What? They're extremely useful, they deserve their place. Put a bumper over the sharpest edges, write Enter at your own risk on the garage door, that's enough. be given correct implementations according to Haskell semantics, and instead provide a module (not re-exported by the Prelude) that gives operations using precise IEEE semantics and access to all the expected primops and such. As you said above, the importance of floating point values is for speed, and the IEEE semantics are designed to support that. So I'm happy to consider floats as purely a performance optimization that should only be used when number crunching is actually a bottleneck. Let Rational be the default fractional type instead and save everyone a bunch of headaches. If only things were so easy. You can't satisfactorily define functions like sqrt, exp, log, sin, cos ... for Rational, so for a large class of tasks you need floating point numbers (yes, one could also use arbitrary precision numbers of
Re: [Haskell-cafe] ghc 7.0.3 view patterns and exhaustiveness
On Tue, Sep 20, 2011 at 10:31:58PM -0400, Richard Cobbe wrote:
I'm starting to play around with GHC's support for view patterns, and I'm
running into what appears to be an annoying limitation of the
implementation.
GHC 7.0.3 (32-bit), MacOS 10.6.8.
First module; defines an abstract type provides a (trivial) view for it.
module Term(Term, TermView(..), view) where
data Term = TVar String
| TApp Term Term
| TLam String Term
data TermView = Var String
| App Term Term
| Lam String Term
view :: Term - TermView
view (TVar x) = Var x
view (TApp rator rand) = App rator rand
view (TLam x body) = Lam x body
Second module tries to use the view in a trivial function:
{-# LANGUAGE ViewPatterns #-}
module Client where
import Term
numVarRefs :: Term - Integer
numVarRefs (view - Var _) = 1
numVarRefs (view - App rator rand) = numVarRefs rator + numVarRefs rand
numVarRefs (view - Lam _ body) = numVarRefs body
-- numVarRefs (view - _) = error bogus
f :: TermView - Integer
f (Var _) = 1
f (App rator rand) = f (view rator) + f (view rand)
f (Lam _ body) = f (view body)
GHCI complains when trying to load this second module:
Client.hs:8:1:
Warning: Pattern match(es) are non-exhaustive
In an equation for `numVarRefs': Patterns not
matched: _
This is a known limitation. Your particular example is perhaps not so
hard to figure out, but what if we had
view :: Bool - Bool
view x = search for a counterexample to the Goldbach conjecture; if
one is found, return x, otherwise return False
foo (view - False) = ...
How is the compiler supposed to decide whether foo's pattern matching
is complete? In this case, it boils down to deciding whether the
Goldbach conjecture is true. Yes, this example is contrived, but I
hope you can see that it is a difficult problem, because it requires
analyzing the possible behavior of the view function, which could be
arbitrarily complicated. Since no general solution exists, the
compiler just punts and does not try to analyze the view function at
all.
-Brent
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Subcomputations in arrow notation
I think this proposal makes so much sense that I'm surprised it didn't already work this way. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] skein-0.1: Skein, a family of cryptographic hash functions. Includes Skein-MAC as well.
On 09/21/2011 05:01 PM, Felipe Almeida Lessa wrote: I'm aware of cryptohash. I just went through the lazy route of binding to the C library instead of implementing those UBI details =). hehe, fair enough. :-) It would be nice to merge and have everything on cryptohash though. And I guess that cryptohash may become faster than skein because the C library has some implementation details that are unneeded (e.g. it has a buffer, but hash/hash' are kind enough to only give full buffers to the libraries). speed wise, i would really like to see the parallel tree hashing going :) Also, it seems that cryptohash's Skein is currently broken. The skein package comes with the golden KATs sent by the Skein team to the NIST, and passes everything. OTOH, cryptohash's Skein256/Skein512 do not agree with skein's Skein_256_256/Skein_512_512. I've attached a test suite that quickchecks if both implementations give the same answer. My hunch is that you are using the wrong constants, because the first test case (the empty string) already fails: oops darn, thanks for reporting. i'll have a look at that ASAP; It used to work in the past, and i've copied some expected values from the original implementation in my small unit tests (which still pass :-/ ), so i'm a bit puzzle here. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HackageDB User Account
How does one go about getting an account? I sent an email to the address provided at http://hackage.haskell.org/packages/accounts.html but haven't received any response yet. Since it's been over 3 weeks, I decided to try my luck here. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc 7.0.3 view patterns and exhaustiveness
On 2011-09-21 22:06, Brent Yorgey wrote: On Tue, Sep 20, 2011 at 10:31:58PM -0400, Richard Cobbe wrote: numVarRefs :: Term - Integer numVarRefs (view - Var _) = 1 numVarRefs (view - App rator rand) = numVarRefs rator + numVarRefs rand numVarRefs (view - Lam _ body) = numVarRefs body -- numVarRefs (view - _) = error bogus This is a known limitation. Your particular example is perhaps not so hard to figure out, but what if we had view :: Bool - Bool view x = search for a counterexample to the Goldbach conjecture; if one is found, return x, otherwise return False foo (view - False) = ... But in Richard's example, all possible values of the result of view are handled. For your foo example, the equivalent would be. foo (view - False) = ... foo (view - True) = ... Ghc should be able to detect this case, and not issue a warning. All that needs to be done is check if the function can be rewritten to numVarRefs t = case view t of ... Where ... is exhaustive. Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Subcomputations in arrow notation
Ertugrul Soeylemez writes: I find myself writing the following very often: system :: Wire IO () String system = proc _ - do botAddPeriod - succ ^ noise - () botAddSpeed - noise1 - () botAddStart - noise1 - () botMsg - event addBot - (botAddPeriod, botAddSpeed, botAddStart) bots - manager - ((), maybe MgrNop id botMsg) let botStr = concatMap (printf %8.2) . M.elems $ bots :: String identity - printf Bot positions: %s botStr where addBot :: Wire IO (Double, Double, Double) (MgrMsg Int IO () Double) addBot = proc (addPeriod, addSpeed, addStart) - do periodically - addPeriod botId - identifier - () identity - MgrAdd botId (constant addSpeed integral addStart) If addPeriod is supposed to be the same as botAddPeriod, etc, this should be equivalent: system :: Wire IO () String system = proc _ - do addPeriod - succ ^ noise - () addSpeed - noise1 - () addStart - noise1 - () botMsg - (|event (do periodically - addPeriod botId - identifier - () identity - MgrAdd botId (constant addSpeed integral addStart))|) bots - manager - ((), maybe MgrNop id botMsg) let botStr = concatMap (printf %8.2) . M.elems $ bots :: String identity - printf Bot positions: %s botStr See the GHC Arrow notation documentation for more about the banana brackets, which let you use user-defined control structures like event. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mapM is supralinear?
On Wed, Sep 21, 2011 at 1:57 PM, Tim Docker t...@dockerz.net wrote: On 09/09/2011, at 8:19 PM, John Lato wrote: Agreed. Whenever I'd like to use mapM (or any other function for which a *M_ is available), I've found the following rules helpful: 1. If I can guarantee the list is short (~ n=20), go ahead and use mapM 2. Otherwise use mapM_, foldM_, or foldM if a real reduction is possible (i.e. not foldM snocM []). Step 2 sometimes requires changing my design, but it's always been for the better. `mapM_` tends to require more pipeline composition, so it's leveraging the language's strengths. This thread is really interesting - it relates directly to problems I am currently having with mapM over large lists (see the thread stack overflow pain). Can you explain what you mean by mapM_ tends to require more pipeline composition? In what way is it leveraging the language strengths? Hmm, that is suitably cryptic. One way to think of it is an inversion of control. Instead of operating on whole collections of things in a monad, you specify monadic actions (pipelines) which are applied sequentially to each input. Here's a simple example. Suppose you have a bunch of data serialized to files, and you want to read each file into a data structure, apply some process based upon the last file's data, and write out the output to new files. One way to do that would look like: do dats - mapM readMyData files let pairs = zip (mempty:dats) dats zipWithM_ (\(last, this) fname - writeMyData (update last this) fname) pairs newFiles However, you could also put everything into a single monadic operation, like this do foldM_ (\last (infile, outfile) - do this - readMyData infile writeMyData (update last this) outfile return this ) mempty (zip files newFiles) The first interleaves control (mapM, zipWIthM_) with monadic actions (file IO), whereas the second only has one control function (foldM_) which completely processes one input. I say this is more pipeline composition because you have to create an entire pipeline from input to output, which is then sequentially fed inputs by the control function. I say this leverages Haskell's strengths because it's quite easy to compose functions and monadic actions in Haskell. It also tends to be garbage-collector friendly. I also find it much easier to reason about space usage. You don't need to worry if part of a list is being retained, because the full list of data doesn't appear anywhere. If you need to access prior elements they're specified explicitly so you know exactly how much data you're holding on to. My perspective might be warped by my work on iteratees, but I find this a very natural approach. John L. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] regex-applicative library needs your help! (algorithmic challenge)
On Sep 18, 2011, at 11:28 AM, Brandon Allbery allber...@gmail.com wrote: On Sat, Sep 17, 2011 at 22:11, Anton Tayanovskyy anton.tayanovs...@gmail.com wrote: By the way, can Haskell have a type that admits regular expression and only those? I mostly do ML these days, so trying to write up a regex types in Haskell I was unpleasantly surprised to discover that there are all sorts of exotic terms inhabiting it, which I did not have to worry about in ML. Besides `undefined` you can have for terms that try to define a grammar with nested parentheses. Using regex-applicative syntax: expr = ... | pure (\ _ x _ - x) * sym ( * expr * sym ) The general case for this is solving the Halting Problem, so neither Haskell nor any other language can do it. You can disallow infinite values by encoding the length into the type, but (a) in Haskell this is painful and (b) runtime values now require runtime types, which you can accommodate but at the price of reintroducing the problems you are trying to prevent. (Dependently typed languages work better for this, but I suspect the result is rather more draconian than you intend.) You needn't solve the halting problem. Any reasonable total language can prevent this case and there is no need to keep types as simple as these around at runtime. See the Agda total parser combinator library for an example, but yes, dependent types are overkill. I usually enforce constraints like this with ! patterns in the constructors, which lets me enforce the fact that at least I know that any attempt to define a cycle like this will bottom out, so I can safely think only inductive thoughts from there out. Another way is to just define a template Haskell regex quasi quoter, and enforce the limitation there. That of course costs you runtime generation. -Edward Kmett___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] skein-0.1: Skein, a family of cryptographic hash functions. Includes Skein-MAC as well.
On Wed, Sep 21, 2011 at 5:19 PM, Vincent Hanquez t...@snarc.org wrote: Also, it seems that cryptohash's Skein is currently broken. The skein package comes with the golden KATs sent by the Skein team to the NIST, and passes everything. OTOH, cryptohash's Skein256/Skein512 do not agree with skein's Skein_256_256/Skein_512_512. I've attached a test suite that quickchecks if both implementations give the same answer. My hunch is that you are using the wrong constants, because the first test case (the empty string) already fails: oops darn, thanks for reporting. i'll have a look at that ASAP; It used to work in the past, and i've copied some expected values from the original implementation in my small unit tests (which still pass :-/ ), so i'm a bit puzzle here. Perhaps you have implemented some old version of Skein? I know they have changed the constants some times in the past. Alas, their paper (I have skein1.3.pdf, is there an updated version?) actually has wrong test vectors. For example, they say that for B.pack [0xFF] the result should be B.pack [0x0B, 0x98, 0xDC, ..., 0xD2], while their own KAT says that the result should be B.pack [0xA4, 0x7B, 0xE7, ..., 0x91]. Unfortunately, for the same input cryptohash's Skein256 says that the result should be B.pack [0x42, 0xC8, 0x82, ..., 0xE8] which is different from both =). I assume that the KATs included in the skein package have the correct results since those KATs were given to the NIST. Cheers, =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Monad Laws and Do Notation
I've got this expression expression = do w - hello y - to you return w I wanna know how can I reduce it using monad laws -- View this message in context: http://haskell.1045720.n5.nabble.com/Monad-Laws-and-Do-Notation-tp4828598p4828598.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad Laws and Do Notation
On 22 September 2011 11:46, diazepan spanishbizar...@yahoo.com wrote: I've got this expression expression = do w - hello y - to you return w I wanna know how can I reduce it using monad laws I don't think you can: the best you can do is minimise it with other monadic functions. The general case you can do something like discard from polyparse: http://hackage.haskell.org/packages/archive/polyparse/latest/doc/html/Text-ParserCombinators-Poly-Base.html#v:discard -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 200
Welcome to issue 200 of the HWN, a newsletter covering developments in the Haskell community. This release covers the week of September 11 to 17, 2011. You can find the HTML version of this issue at: http://contemplatecode.blogspot.com/2011/09/haskell-weekly-news-issue-200.html Announcements Chris Smith is exploring the interest of holding a Virtual Hackathon, using Google+ and a Wiki. Come check it out if you would be interested in being part of it! [1] http://goo.gl/lWnea Valentin Robert has completed Apprendre Haskell vous fera le plus grand bien!, a translation of Learn You a Haskell for Great Good! into French, and has also created a wiki page with basic information about Haskell for the French speaking world. Kudos to Valentin for his work on this project! [2] http://goo.gl/ixiXW [3] http://goo.gl/1CG7j New and Updated Projects * netwire (Ertugrul Soeylemez; 1.2.5) Multiple major and minor changes. [4] http://goo.gl/DS4QR * webwire (Ertugrul Soeylemez; 0.1.0) An experimental web framework based on the functional reactive programming library netwire. [5] http://goo.gl/DS4QR * numerals (Roel van Dijk) Contains functions to convert numbers to words in a number of languages. [6] http://goo.gl/4YfhK * splaytree (Jehn Lato; 0.1) Provides splay tree based implementations of Sets, Seqs, and RangeSets. [7] http://goo.gl/aQfX5 * qrcode (Chris Yuen) Intended to be a full featured QR Code library with encoding and decoding and other advanced features. [8] http://goo.gl/pymtr * haskdogs (Sergey Mironov; 0.1) Project-level ctag file generator. [9] http://goo.gl/SA6cx Quotes of the Week * Jafet: Can oleg create a term so complicated that even he could not type-check it? * ion: let es = [vim, emacs, nano] in map (\e - intercalate and (delete e es) ++ suck, learn ++ e) es * cmccann: [on using SomeException] just catch all exceptions, then ignore them. it's the industry-proven way * kmc: une monade est comme une crepe. una monada es como un burrito. eine Monade ist wie ein Strudel. * dylukes: I learned PBMMPPULCDADMABRRRBBBLLTAAMMBBC. It's the operator precedence of C. * benmachine: ozataman: does it have a main, or a thing with type IO thing which looks sort of mainish? Top Reddit Stories * Categorized Weaknesses from the State of Haskell 2011 Survey Domain: nickknowlson.com, Score: 72, Comments: 42 On Reddit: [10] http://goo.gl/0h0K5 Original: [11] http://goo.gl/DZB5V * Haskell B. Curry, born Sept. 12, 1900 Domain: en.wikipedia.org, Score: 69, Comments: 17 On Reddit: [12] http://goo.gl/FYP0F Original: [13] http://goo.gl/S520L * The Records problem in Haskell - help build a consensus about how to fix it, finally Domain: hackage.haskell.org, Score: 59, Comments: 132 On Reddit: [14] http://goo.gl/8cZnI Original: [15] http://goo.gl/VuVoQ * Wrriten in Haskell: The Dynamic Scheduling System for the Green Bank Telescope Domain: self.haskell, Score: 51, Comments: 4 On Reddit: [16] http://goo.gl/vaD3C Original: [17] http://goo.gl/vaD3C * Announcing: Sirkel, a Haskell implementation of the Chord DHT with fault tolerance and replication! Domain: mortenlysgaard.com, Score: 36, Comments: 1 On Reddit: [18] http://goo.gl/VNpSv Original: [19] http://goo.gl/05NIn * Not going to ICFP? Here's an excuse for you Domain: ro-che.info, Score: 30, Comments: 5 On Reddit: [20] http://goo.gl/ABvsq Original: [21] http://goo.gl/uI2Mj * Announce: Yesod 0.9.2 - Everything Just Works Domain: yesodweb.com, Score: 24, Comments: 2 On Reddit: [22] http://goo.gl/izCme Original: [23] http://goo.gl/H0bLr * A play in one act Domain: hpaste.org, Score: 24, Comments: 17 On Reddit: [24] http://goo.gl/OLncN Original: [25] http://goo.gl/lcssv * HaTeX 3 - New version of the Haskell LaTeX library. Domain: deltadiaz.blogspot.com, Score: 20, Comments: 6 On Reddit: [26] http://goo.gl/AgAOp Original: [27] http://goo.gl/4z7nJ * Open Quark: Another haskell like language on JVM. Much more older and mature than Frege. Yet unknown and forgotten. Domain: openquark.org, Score: 19, Comments: 6 On Reddit: [28] http://goo.gl/6Lfx6 Original: [29] http://goo.gl/BI0mC Top StackOverflow Questions * Proving “no corruption” in Haskell votes: 17, answers: 3 Read on SO: [30] http://goo.gl/Xclnk * How to handle feature requests that add new package dependencies votes: 13, answers: 3 Read on SO: [31] http://goo.gl/Gw6HQ * Left and Right Folding over an Infinite list votes: 12, answers: 4 Read on SO: [32] http://goo.gl/YKHlB * Shorter way to write this code votes: 11, answers: 6 Read on SO: [33] http://goo.gl/7ZmBZ * Can't link OpenCL on
Re: [Haskell-cafe] Evaluating type expressions in GHCi
From: Sean Leather leat...@cs.uu.nl
I would like to ask GHCi for the type that a type expression will evaluate to,
once all definitions of type synonyms and (when possible) type families have
been inlined.
It appears that I can do some part of this for type T by using :t undefined
:: T:
...
undefined :: F (Int, Bool) :: (Bool, Int)
I also get what I expect here:
ghci :t undefined :: F (a, Bool)
undefined :: F (a, Bool) :: (F a, Int)
Of course, this doesn't work on types of kinds other than *.
In the absence of interpreter support, you can work around that by making
appropriate type constructors.
{-# LANGUAGE TypeFamilies, KindSignatures, EmptyDataDecls #-}
type family G a :: * - *
type instance G Int = Maybe
type instance G Bool = []
data Wrap1 (t :: * - *)
ghci :t undefined :: Wrap1 (G Int)
undefined :: Wrap1 (G Int) :: Wrap1 Maybe
The development version of ghci seems to support type declarations,
which would make this easier.
https://github.com/ghc/ghc/commit/3db757241ce7fb99c096c30481aefa86bb9855a1
Brandon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New: A French translation of Learn You A Haskell for Great Good!
hello, I second the choice of gitit, if only to follow eat your own dog food principle. but gitit is also a really great piece of software. I have really no strong advice on whether or not the wiki should be part of Haskell.org. but whatever the choice, I will definitely support this initiative as much a I can : I feel sad the French community is not much more vibrant (of course, this particular language space is occupied by ocaml In France), and will try to contribute a things or two I have been working on. Arnaud Le 21 sept. 2011 à 16:20, Valentin ROBERT valentin.robert...@gmail.com a écrit : On Wed, Sep 21, 2011 at 16:01, Eric Y. Kow eric@gmail.com wrote: On Wed, Sep 21, 2011 at 00:00:26 +0200, Valentin ROBERT wrote: http://lyah.haskell.fr Excellent http://haskell.fr On this particular topic, someone asked me why I did not reuse the FR part of Haskell wiki. That's a reasonable question in my opinion. We have this page: http://www.haskell.org/haskellwiki/Fr/Haskell Now, is it feasible, and okay, to create a French sub-wiki inside Haskell Wiki? What would be the advantages, and inconvenients? If we wanted to, I could just have haskell.fr redirect there. I am actually not satisfied with the wiki I created, for instance syntax highlighting with the presence of links is a huge pain, as you might notice if you read the sources... and not automated at all... I'd be happy to test Gitit and switch to it if it makes sense. Concerning the integration or separation with HaskellWiki: * Integration (+) Everything is in the same place (+) We can link english articles from the French ones when there's no translation (+) We benefit from the work that was done on HaskellWiki (the design, the syntax highlighting) (-) When people go to the home page, it's all English again! (-) Lack of visibility (it's actually not trivial to find the page I linked up there...) (-) We inherit the flaws of HaskellWiki (as you mentioned, maybe use another wiki engine) (?) How feasible is it? Should all our pages be into a fr namespace or something in these lines? * Separation (+) We are free to do things differently (-) We're separated from haskell.org, which is the reference place Well, I'd be happy to discuss this further. As you said, it's still fresh enough that I'm okay with moving everything elsewhere or restarting from zero. - Valentin Robert Since you're starting from fresh, it would be great if the wiki were running Gitit instead of Mediawiki. Advantages: - Markdown is used in many places - You can have a Git/Darcs repository behind this See http://wiki.darcs.net for an example of this in action. Would be great if Haskell wiki were also running Gitit but that's a potentially a tougher nut to crack -- Eric Kow http://erickow.com ___ 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
