[Haskell-cafe] is Haskell missing a non-instantiating polymorphic case?
The title might be a bit more provocative than necessary. I'm starting to suspect that there are very useful aspects of the parametricity of System F(C) which can't be taken advantage of by Haskell in its current state. To put it briefly, case-matching on a value of type (forall n . T n) forces one to instantiate the "n", even though the branch taken within the case cannot depend on "n" (parametricity). I came up with the simplest example I could and posted it to StackOverflow, but there haven't been any successes (despite some excellent attempts!): http://stackoverflow.com/questions/7720108/ This might sound like an obscure problem, but it actually starts to get in the way of the very useful Washburn+Weirich "Boxes Go Bananas" and related PHOAS representation. I've written up a short example of the problems that happen here: The link above also includes a very rough sketch of a proposal for a "pcase" construct that doesn't instantiate its argument. Is it possible to do what I'm attempting without adding "pcase" to the language? Would "pcase" break the soundness of the type system (I don't think so) or complicate type inference (probably)? I'd be interested in any comments/thoughts/help people can offer. Thanks! - a PS, I suspect that this is somehow related to the issue that Guillemette and Monnier mention in section 5.1 of their paper on type-preserving closure conversion, although I wasn't able to find the code online in order to be sure. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hackage and cabal test support: why does it claim I have no type field when I do?
Actually, it seems to be more related to http://hackage.haskell.org/trac/hackage/ticket/811 since if I remove the conditional elements within the test stanzas it looks like hackage is happy again. Doug From: Doug Burke To: JP Moresmau Cc: "Haskell-Cafe@haskell.org" Sent: Saturday, October 22, 2011 1:19 PM Subject: Re: [Haskell-cafe] hackage and cabal test support: why does it claim I have no type field when I do? Aha, I'd missed that; thanks - I'll try the fix after going pumpkin hunting with the kids! Doug From: JP Moresmau To: Doug Burke Cc: "Haskell-Cafe@haskell.org" Sent: Saturday, October 22, 2011 1:15 PM Subject: Re: [Haskell-cafe] hackage and cabal test support: why does it claim I have no type field when I do? Maybe the issue is that the test modules are missing from the distribution file, which is a known bug. (http://hackage.haskell.org/trac/hackage/ticket/792) JP On Sat, Oct 22, 2011 at 7:04 PM, Doug Burke wrote: > > I've just been updating my code to take advantage of the test support in > Cabal. I have it so that > cabal configure --enable-tests > cabal build > cabal test > works. However, when I try to upload to hackage, I get > cabal upload -c dist/swish-0.6.2.0.tar.gz > Checking dist/swish-0.6.2.0.tar.gz... > Error: dist/swish-0.6.2.0.tar.gz: 400 Error in upload > 400 Error in upload > line 271: The 'type' field is required for test suites. The available test > types are: exitcode-stdio-1.0 > and here are the relevant lines from the cabal file: > 267 if flag(developer) > 268 ghc-options: -Werror > 269 ghc-prof-options: -auto-all > 270 > 271 Test-Suite test-builtinmap > 272 type: exitcode-stdio-1.0 > 273 Hs-Source-Dirs: tests/ src/ > 274 Main-Is: BuiltInMapTest.hs > 275 Other-Modules: TestHelpers > 276 > As you can see, there's a type field for the Test-Suite and I don't see any > obvious discrepancy with the information from the user's guide > (http://www.haskell.org/cabal/users-guide/#test-suites). I also have > Cabal-Version: >= 1.9.2 > > in the file; the full version can be found at > https://bitbucket.org/doug_burke/swish/src/4545220d88e2/swish.cabal#cl-271 > > What am I doing wrong? > Thanks in advance, > Doug > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- JP Moresmau http://jpmoresmau.blogspot.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
Re: [Haskell-cafe] runStateT execution times measurement baffling
On Saturday 22 October 2011, 23:07:44, thomas burt wrote: > Sorry, thought I had replied to this with my result! > > I added `seq` and $! inside `stuffToDo` to ensure that there weren't any > thunks left around after it was called. > > The measured times were only a few hundredths of a second apart after > that. > > So, apparently even with a strict StateT, partially evaluated references > can easily be left around all the way until the call to runStateT > returns. Yes. The 'Strict' isn't very deep, it just means that on 'bind' (>>=), the state/value pair is evaluated to whnf. The components can easily contain unevaluated thunks. The strictness analyser (supposing you compile with optimisations) then can often see further and find that it's good to keep more things evaluated. It's easier for the strictness analyser than for the lazy variant (where the state/value pair is bound by a lazy pattern), but it still doesn't detect all opportunities for strict evaluation, so you're often enough left with accumulating unevaluated thunks. (The compiler may only add strictness where it can prove that doesn't change the semantics of the programme, so the strictness analyser has a pretty hard job.) > In this case my state is a record, if that makes any > difference. Well, it does, in comparison to simpler types. If the state is a plain Int, it's *relatively* easy to find out whether demanding the end result requires the evaluation of intermediate states. The more components and/or layers your state has, the harder it is to determine which ones of them are necessary to evaluate for the end result, the more opportunities for strictness will go unnoticed. Strict fields in the record can greatly help then. > It's not what I expected... I can see why my example is too > small to show why it behaved this way though. > > I thought pattern matching (in Haskell98) was itself strict, so I don't Yes, but that only means that the value is evaluated to the outermost constructor (or, in the case of nested patterns, as far as required). The constructor fields by default remain unevaluated (but they are now directly accessible thunks and no longer thunks hidden inside another thunk). > see what the difference between a lazy and strict stateT is, except > perhaps in cases that the value of runStateT is bound via a different > mechanism than pattern matching. The difference is that (>>=) in the strict StateT takes apart the state/value pair, creating two blobs and a constructor combing those to a pair, while (>>=) in the lazy StateT doesn't take apart the state/value blob. The latter makes it easier for thunks to accumulate (but on the other hand, it allows some feats that can't be done with the former, much less with even stricter variants). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] runStateT execution times measurement baffling
Sorry, thought I had replied to this with my result! I added `seq` and $! inside `stuffToDo` to ensure that there weren't any thunks left around after it was called. The measured times were only a few hundredths of a second apart after that. So, apparently even with a strict StateT, partially evaluated references can easily be left around all the way until the call to runStateT returns. In this case my state is a record, if that makes any difference. It's not what I expected... I can see why my example is too small to show why it behaved this way though. I thought pattern matching (in Haskell98) was itself strict, so I don't see what the difference between a lazy and strict stateT is, except perhaps in cases that the value of runStateT is bound via a different mechanism than pattern matching. On Sat, Oct 22, 2011 at 6:13 AM, Daniel Fischer < daniel.is.fisc...@googlemail.com> wrote: > On Saturday 22 October 2011, 13:55:36, Bas van Dijk wrote: > > On 20 October 2011 22:16, thomas burt wrote: > > > Perhaps I will try and force `stuffToDo` not to leave any partially > > > evaluated thunks behind and compare the cost then. > > > > What happens when you switch to a strict StateT? > > He already uses the strict StateT: > > > By the way I'm using ghc-6.10.4 and Control.Monad.Trans.State.Strict. > > We need to see more of the code to find out what's going on. > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Message
Yeah, I was going to mention Smalltalk too, as one of the languages NOT using plain text to store programs — which led to a very strong boundary between ST and other world, not doing any favors to the first. The idea of using some non-plaintext-based format to store programs appeared lots of times, without any significant achivements. And I think one of the main reasons for that is that it makes interacting with other tools extremely difficult. Not just with pre-existing tools. Even if grep didn't exist, it would be very easy to hack something like it if you need to search your codebase for a specific word; you don't need any complex APIs to read plain text files, there are just two functions — one to read a line of code, and another one to check for eof. Similarly, it's easy to generate your Java files with a Perl script — with Perl itself not knowing anything about Java. Text has the advantage of being SIMPLE — and the vague idea of "embedding a spreadsheet in your code" (what the hell for?) doesn't come close to beating it. And you know what? You don't really need to give up text-based storage to have graphic capabilities. Windows resources files (.rc) are text-based, and there are plenty of visual editors for them, including one in Visual Studio; and, thankfully, it still produces the same old text-based file — and sometimes it's very desirable to look into one, for example, if you want to know which control is tagged with this ID. Отправлено с iPad 22.10.2011, в 21:06, "Claus Reinke" написал(а): >> The world needs programmers to accept and take seriously Greg Wilson's >> extensible programming, and stop laughing it off as "lolwut wysiwyg msword >> for programming", and start implementing it. >> http://third-bit.com/blog/archives/4302.html > > Who is "the world"? For starters, I don't think it is Greg Wilson's > idea, and if you look for alternate sources, often under other titles, you'll > find parts of it implemented, with varying degrees of success > and often little acceptance. The idea is much older than one might think - > conferences on extensible languages were held around 1970. > Early implementation approximations didn't have the disposable computing > power of today's PCs, nor did early implementers find > an audience ready for their ideas (to feed their students or themselves, some > of those who were such ahead of the curve had to switch to working on more > conventional, funded, topics). > > Useful search keys: > > - extensible languages (as in AI, the meaning of "extensible" tends > to be redefined whenever a problem gets solved, so many features > that used to mark an extensible language in the past have now > become standard) > > - structure editors (in that they were forerunners of projectional > IDEs, and exhibited some of their advantages and disadvantages; > there have been many efforts to generate structure editors fromlanguage > descriptions) > > - projectional language workbenches (instead of parsing source > to AST, the IDE/workbench operates on an AST-like abstract > model, and source code views are just projections of that;makes it > easier to embed sublanguages); > > Smalltalkers will probably claim their image-based IDEs have > been doing that all along. > > - hyper-programming (where persistent runtime data can beembedded in code > via linking, similar to hypertext, with > generic editors instead of generic Read/Show) > > - Banana Algebra: Syntactic Language Extension via an Algebraof Languages > and Transformations (one example of research > on language composition) > > IDE generators, IDE tooling for domain-specific languages, language-oriented > programming, language workbenches, ... they all contribute to the now broader > interest in the topic. > > In the context of Haskell, there once was Keith Hanna's > document-centered programming: > > http://www.cs.kent.ac.uk/projects/vital/ > http://www.cs.kent.ac.uk/projects/pivotal/ > > Perhaps Keith's projects can serve as an inspiration to just start hacking?-) > The subject is an instance of these quotes: > > "The future is already here - it's just not very evenly distributed." > William Gibson > > "The best way to predict the future is to invent it." > Alan Kay > > Claus > http://clausreinke.github.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
Re: [Haskell-cafe] hackage and cabal test support: why does it claim I have no type field when I do?
Aha, I'd missed that; thanks - I'll try the fix after going pumpkin hunting with the kids! Doug From: JP Moresmau To: Doug Burke Cc: "Haskell-Cafe@haskell.org" Sent: Saturday, October 22, 2011 1:15 PM Subject: Re: [Haskell-cafe] hackage and cabal test support: why does it claim I have no type field when I do? Maybe the issue is that the test modules are missing from the distribution file, which is a known bug. (http://hackage.haskell.org/trac/hackage/ticket/792) JP On Sat, Oct 22, 2011 at 7:04 PM, Doug Burke wrote: > > I've just been updating my code to take advantage of the test support in > Cabal. I have it so that > cabal configure --enable-tests > cabal build > cabal test > works. However, when I try to upload to hackage, I get > cabal upload -c dist/swish-0.6.2.0.tar.gz > Checking dist/swish-0.6.2.0.tar.gz... > Error: dist/swish-0.6.2.0.tar.gz: 400 Error in upload > 400 Error in upload > line 271: The 'type' field is required for test suites. The available test > types are: exitcode-stdio-1.0 > and here are the relevant lines from the cabal file: > 267 if flag(developer) > 268 ghc-options: -Werror > 269 ghc-prof-options: -auto-all > 270 > 271 Test-Suite test-builtinmap > 272 type: exitcode-stdio-1.0 > 273 Hs-Source-Dirs: tests/ src/ > 274 Main-Is: BuiltInMapTest.hs > 275 Other-Modules: TestHelpers > 276 > As you can see, there's a type field for the Test-Suite and I don't see any > obvious discrepancy with the information from the user's guide > (http://www.haskell.org/cabal/users-guide/#test-suites). I also have > Cabal-Version: >= 1.9.2 > > in the file; the full version can be found at > https://bitbucket.org/doug_burke/swish/src/4545220d88e2/swish.cabal#cl-271 > > What am I doing wrong? > Thanks in advance, > Doug > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- JP Moresmau http://jpmoresmau.blogspot.com/___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hackage and cabal test support: why does it claim I have no type field when I do?
Maybe the issue is that the test modules are missing from the distribution file, which is a known bug. (http://hackage.haskell.org/trac/hackage/ticket/792) JP On Sat, Oct 22, 2011 at 7:04 PM, Doug Burke wrote: > > I've just been updating my code to take advantage of the test support in > Cabal. I have it so that > cabal configure --enable-tests > cabal build > cabal test > works. However, when I try to upload to hackage, I get > cabal upload -c dist/swish-0.6.2.0.tar.gz > Checking dist/swish-0.6.2.0.tar.gz... > Error: dist/swish-0.6.2.0.tar.gz: 400 Error in upload > 400 Error in upload > line 271: The 'type' field is required for test suites. The available test > types are: exitcode-stdio-1.0 > and here are the relevant lines from the cabal file: > 267 if flag(developer) > 268 ghc-options: -Werror > 269 ghc-prof-options: -auto-all > 270 > 271 Test-Suite test-builtinmap > 272 type: exitcode-stdio-1.0 > 273 Hs-Source-Dirs: tests/ src/ > 274 Main-Is: BuiltInMapTest.hs > 275 Other-Modules: TestHelpers > 276 > As you can see, there's a type field for the Test-Suite and I don't see any > obvious discrepancy with the information from the user's guide > (http://www.haskell.org/cabal/users-guide/#test-suites). I also have > Cabal-Version: >= 1.9.2 > > in the file; the full version can be found at > https://bitbucket.org/doug_burke/swish/src/4545220d88e2/swish.cabal#cl-271 > > What am I doing wrong? > Thanks in advance, > Doug > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Message
The world needs programmers to accept and take seriously Greg Wilson's extensible programming, and stop laughing it off as "lolwut wysiwyg msword for programming", and start implementing it. http://third-bit.com/blog/archives/4302.html Who is "the world"? For starters, I don't think it is Greg Wilson's idea, and if you look for alternate sources, often under other titles, you'll find parts of it implemented, with varying degrees of success and often little acceptance. The idea is much older than one might think - conferences on extensible languages were held around 1970. Early implementation approximations didn't have the disposable computing power of today's PCs, nor did early implementers find an audience ready for their ideas (to feed their students or themselves, some of those who were such ahead of the curve had to switch to working on more conventional, funded, topics). Useful search keys: - extensible languages (as in AI, the meaning of "extensible" tends to be redefined whenever a problem gets solved, so many features that used to mark an extensible language in the past have now become standard) - structure editors (in that they were forerunners of projectional IDEs, and exhibited some of their advantages and disadvantages; there have been many efforts to generate structure editors from language descriptions) - projectional language workbenches (instead of parsing source to AST, the IDE/workbench operates on an AST-like abstract model, and source code views are just projections of that; makes it easier to embed sublanguages); Smalltalkers will probably claim their image-based IDEs have been doing that all along. - hyper-programming (where persistent runtime data can be embedded in code via linking, similar to hypertext, with generic editors instead of generic Read/Show) - Banana Algebra: Syntactic Language Extension via an Algebra of Languages and Transformations (one example of research on language composition) IDE generators, IDE tooling for domain-specific languages, language-oriented programming, language workbenches, ... they all contribute to the now broader interest in the topic. In the context of Haskell, there once was Keith Hanna's document-centered programming: http://www.cs.kent.ac.uk/projects/vital/ http://www.cs.kent.ac.uk/projects/pivotal/ Perhaps Keith's projects can serve as an inspiration to just start hacking?-) The subject is an instance of these quotes: "The future is already here - it's just not very evenly distributed." William Gibson "The best way to predict the future is to invent it." Alan Kay Claus http://clausreinke.github.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hackage and cabal test support: why does it claim I have no type field when I do?
I've just been updating my code to take advantage of the test support in Cabal. I have it so that cabal configure --enable-tests cabal build cabal test works. However, when I try to upload to hackage, I get cabal upload -c dist/swish-0.6.2.0.tar.gz Checking dist/swish-0.6.2.0.tar.gz... Error: dist/swish-0.6.2.0.tar.gz: 400 Error in upload 400 Error in upload line 271: The 'type' field is required for test suites. The available test types are: exitcode-stdio-1.0 and here are the relevant lines from the cabal file: 267 if flag(developer) 268 ghc-options: -Werror 269 ghc-prof-options: -auto-all 270 271 Test-Suite test-builtinmap 272 type: exitcode-stdio-1.0 273 Hs-Source-Dirs: tests/ src/ 274 Main-Is: BuiltInMapTest.hs 275 Other-Modules: TestHelpers 276 As you can see, there's a type field for the Test-Suite and I don't see any obvious discrepancy with the information from the user's guide (http://www.haskell.org/cabal/users-guide/#test-suites). I also have Cabal-Version: >= 1.9.2 in the file; the full version can be found at https://bitbucket.org/doug_burke/swish/src/4545220d88e2/swish.cabal#cl-271 What am I doing wrong? Thanks in advance, Doug ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lazy A-star search
Sorry for my English. I mean "can be used in practice, no only for toy examples" 2011/10/22 Richard Senington > ** > How do you mean effective? > > While I am not sure they mention A* search, you might like to look at the > paper > "Modular Lazy Search for Constraint Satisfaction Problems" by Nordin & > Tolmach. > http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.4704 > > RS > > > On 22/10/11 13:28, Anton Kholomiov wrote: > > Recently I was looking for an A-star search algorithm. I've found a > package > but I couldn't understand the code. Then I saw some blogposts but they > were difficult to understand too. I thought about some easier solution > that > relies on laziness. And I've come to this: > > Heuristic search is like depth-first search but solutions in sub-trees > are concatenated with mergeBy function, that concatenates two > list by specific order: > > module Search where > > import Control.Applicative > import Data.Function(on) > import Control.Arrow(second) > import Data.Tree > > -- | Heuristic search. Nodes are visited from smaller to greater. > searchBy :: (a -> a -> Ordering) -> Tree a -> [a] > searchBy heur (Node v ts) = > v : foldr (mergeBy heur) [] (searchBy heur <$> ts) > > -- | Merge two lists. Elements concatenated in specified order. > mergeBy :: (a -> a -> Ordering) -> [a] -> [a] -> [a] > mergeBy _ a [] = a > mergeBy _ []b = b > mergeBy p (a:as)(b:bs) > | a `p` b == LT= a : mergeBy p as (b:bs) > | otherwise = b : mergeBy p bs (a:as) > > > Now we can define specific heuristic search in terms of searchBy: > > -- | Heuristic is distance to goal. > bestFirst :: Ord h => (a -> h) -> (a -> [a]) -> a -> [a] > bestFirst dist alts = > searchBy (compare `on` dist) . unfoldTree (\a -> (a, alts a)) > > -- | A-star search. > -- Heuristic is estimated length of whole path. > astar :: (Ord h, Num h) => (a -> h) -> (a -> [(a, h)]) -> a -> [a] > astar dist alts s0 = fmap fst $ > searchBy (compare `on` astarDist) $ unfoldTree gen (s0, 0) > where astarDist (a, d) = dist a + d > gen (a, d) = d `seq` ((a, d), second (+d) <$> alts a) > > I'm wondering is it effective enough? > > > Anton > > > ___ > Haskell-Cafe mailing > listHaskell-Cafe@haskell.orghttp://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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lazy A-star search
How do you mean effective? While I am not sure they mention A* search, you might like to look at the paper "Modular Lazy Search for Constraint Satisfaction Problems" by Nordin & Tolmach. http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.34.4704 RS On 22/10/11 13:28, Anton Kholomiov wrote: Recently I was looking for an A-star search algorithm. I've found a package but I couldn't understand the code. Then I saw some blogposts but they were difficult to understand too. I thought about some easier solution that relies on laziness. And I've come to this: Heuristic search is like depth-first search but solutions in sub-trees are concatenated with mergeBy function, that concatenates two list by specific order: module Search where import Control.Applicative import Data.Function(on) import Control.Arrow(second) import Data.Tree -- | Heuristic search. Nodes are visited from smaller to greater. searchBy :: (a -> a -> Ordering) -> Tree a -> [a] searchBy heur (Node v ts) = v : foldr (mergeBy heur) [] (searchBy heur <$> ts) -- | Merge two lists. Elements concatenated in specified order. mergeBy :: (a -> a -> Ordering) -> [a] -> [a] -> [a] mergeBy _ a [] = a mergeBy _ []b = b mergeBy p (a:as)(b:bs) | a `p` b == LT= a : mergeBy p as (b:bs) | otherwise = b : mergeBy p bs (a:as) Now we can define specific heuristic search in terms of searchBy: -- | Heuristic is distance to goal. bestFirst :: Ord h => (a -> h) -> (a -> [a]) -> a -> [a] bestFirst dist alts = searchBy (compare `on` dist) . unfoldTree (\a -> (a, alts a)) -- | A-star search. -- Heuristic is estimated length of whole path. astar :: (Ord h, Num h) => (a -> h) -> (a -> [(a, h)]) -> a -> [a] astar dist alts s0 = fmap fst $ searchBy (compare `on` astarDist) $ unfoldTree gen (s0, 0) where astarDist (a, d) = dist a + d gen (a, d) = d `seq` ((a, d), second (+d) <$> alts a) I'm wondering is it effective enough? Anton ___ 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] New rss maintainer
I released a new rss: http://hackage.haskell.org//package/rss-3000.2.0 It no longer requires old-time and is tested with the latest versions of its dependencies. On 21 October 2011 17:34, Vincent Hanquez wrote: > Perhaps, unless someone step up, it would be nice to move packages that have > no maintainer anymore into a github organisation (haskell-janitors ?), Nice idea! However I think we should always strive for having a single or a limited number of maintainers. Finally when nobody wants to take over a package we can hand it over to haskell-janitors. Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New rss maintainer
That's a great idea! On Oct 21, 2011, at 5:34 PM, Vincent Hanquez wrote: > On 10/20/2011 08:27 PM, Bas van Dijk wrote: >> Hello, >> >> I've a small patch[1] that updates the rss package to the latest >> versions of its dependencies. (I'm trying to get the new >> hackage-server to build on ghc-7.2.1) >> >> However Bjorn Bringert told me he's no longer maintaining the package. >> He asked me to ask you if there's already a new maintainer. If not, >> does any one want to take over the package? Jeremy, maybe you? >> >> Otherwise I could take it over. I probably won't make lots of changes >> since I'm a bit swamped at the moment. Just updating it to the latest >> versions. > Perhaps, unless someone step up, it would be nice to move packages that have > no maintainer anymore into a github organisation (haskell-janitors ?), > where each package could have many owners and it's easy and simple to > add/remove push rights there. > > That could also be an obvious place to look, for newcomers, to get involved. > > -- > Vincent > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Sjoerd Visscher http://w3future.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] lazy A-star search
Recently I was looking for an A-star search algorithm. I've found a package but I couldn't understand the code. Then I saw some blogposts but they were difficult to understand too. I thought about some easier solution that relies on laziness. And I've come to this: Heuristic search is like depth-first search but solutions in sub-trees are concatenated with mergeBy function, that concatenates two list by specific order: module Search where import Control.Applicative import Data.Function(on) import Control.Arrow(second) import Data.Tree -- | Heuristic search. Nodes are visited from smaller to greater. searchBy :: (a -> a -> Ordering) -> Tree a -> [a] searchBy heur (Node v ts) = v : foldr (mergeBy heur) [] (searchBy heur <$> ts) -- | Merge two lists. Elements concatenated in specified order. mergeBy :: (a -> a -> Ordering) -> [a] -> [a] -> [a] mergeBy _ a [] = a mergeBy _ []b = b mergeBy p (a:as)(b:bs) | a `p` b == LT= a : mergeBy p as (b:bs) | otherwise = b : mergeBy p bs (a:as) Now we can define specific heuristic search in terms of searchBy: -- | Heuristic is distance to goal. bestFirst :: Ord h => (a -> h) -> (a -> [a]) -> a -> [a] bestFirst dist alts = searchBy (compare `on` dist) . unfoldTree (\a -> (a, alts a)) -- | A-star search. -- Heuristic is estimated length of whole path. astar :: (Ord h, Num h) => (a -> h) -> (a -> [(a, h)]) -> a -> [a] astar dist alts s0 = fmap fst $ searchBy (compare `on` astarDist) $ unfoldTree gen (s0, 0) where astarDist (a, d) = dist a + d gen (a, d) = d `seq` ((a, d), second (+d) <$> alts a) I'm wondering is it effective enough? Anton Search.hs Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] runStateT execution times measurement baffling
On Saturday 22 October 2011, 13:55:36, Bas van Dijk wrote: > On 20 October 2011 22:16, thomas burt wrote: > > Perhaps I will try and force `stuffToDo` not to leave any partially > > evaluated thunks behind and compare the cost then. > > What happens when you switch to a strict StateT? He already uses the strict StateT: > By the way I'm using ghc-6.10.4 and Control.Monad.Trans.State.Strict. We need to see more of the code to find out what's going on. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] runStateT execution times measurement baffling
On 20 October 2011 22:16, thomas burt wrote: > Perhaps I will try and force `stuffToDo` not to leave any partially > evaluated thunks behind and compare the cost then. What happens when you switch to a strict StateT? Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock fails on ConfigFile, but why?
On Sat, Oct 22, 2011 at 12:50:48AM +0200, Daniel Fischer wrote: > On Friday 21 October 2011, 23:49:45, Magnus Therning wrote: > > Would love to get some help on making Haddock accept ConfigFile[1]. The > > error message is about as far from helpful as you can get ;) > > > > dist/build/tmp-15743/src/Data/ConfigFile/Monadic.hs:34:1: > > parse error on input `import' > > > > The author is informed but is as confused as me, it seems[2]. > > Okay, a bit of experimentation showed that the imports must come > before the haddock comment section $overview. > > Whether it's a haddock bug, or a feature request for haddock to > handle such situations, I don't know. Thanks for taking your time to find this out. I've passed on the information to the author. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay pgpRnal78fpLS.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
