Re: [Haskell-cafe] Inecxact map?
On Tue, Mar 13, 2012 at 6:14 AM, Holger Siegel holgersiege...@yahoo.de wrote: Am 13.03.2012 um 09:15 schrieb Morten Olsen Lysgaard: I'd like to be able to do inexact lookups on the map. Firstly, ignore the difference between upper lower case, that's easy. But secondly, have a function: search :: (Num b) = Data.Map.Map String a - String - b - [a] This function is like the normal lookup, but it takes an extra argument b. B is the allowed character error rate. That is the Levenstein distance divided on the length. It should return all the strings that has an error rate lower that b and in a ordered manner, best first. You could take a trie and extend the lookup functions so that it also returns inexact matches up to a given error rate. That should be quite easy, because the definition of Levenshtein distance is recursive as well as the trie's lookup function. There are also Burkhard-Keller trees, which are a pretty cool data structure: http://hackage.haskell.org/package/bktrees-0.3.1 --S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exception for NaN
You can set and clear float exception flags directly with ieee-utils: http://hackage.haskell.org/packages/archive/ieee-utils/0.4.0/doc/html/Numeric-IEEE-FloatExceptions.html It looks like it needs a few tweaks to build with GHC 7, but even then that particularly module should still build fine. So before a complicated numeric calculation, clear the flags. Then, after forcing the result, check to see if any flags have been triggered and take appropriate action. This is more efficient than checking the flags after every operation anyway. Cheers, Sterl. On May 12, 2011, at 1:14 PM, Grigory Sarnitskiy wrote: How do I make my program stop whenever it gets somewhere NaN as a result during a calculation? If there is no appropriate flag for ghc maybe there exist flags for C to use in optc. I don't want NaN to propagate, it is merely stupid, it should be terminated. ___ 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] Summer of Code Mentors for Language.C
On Tue, Mar 29, 2011 at 3:05 PM, Aaron Tomb at...@galois.com wrote: However, I should mention that the Haskell community has put together a fairly long list of potential projects, many of which are more widely useful than Language.C work. This may mean that it would have a relatively low chance of being accepted. A high-quality proposal would help the odds, however. :) A high-quality proposal from a student that demonstrates some prior experience, capacity, and knowledge is huge in the decision making process. Motivated students can also turn in more than one proposal, which I would encourage. It can be the case that two talented candidates both applied for the same proposal, or that of a candidate's proposals, one fits much better than the other with what folks are looking to sponsor. Cheers, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to daemonize a threaded Haskell program?
On Mar 5, 2011, at 5:59 PM, Bas van Dijk wrote: On 5 March 2011 21:51, Vincent Hanquez t...@snarc.org wrote: On Sat, Mar 05, 2011 at 08:51:59PM +0100, Bas van Dijk wrote: Hello, I like to turn my Haskell program into a unix daemon. One of the steps in daemonizing a process is to fork it then exit the parent and continue with the child. All this is nicely abstracted in hdaemonize[1] which internally calls forkProcess[2]. Have you looked at direct-daemonize[1]? I'm not sure if it will do the job, but it's certainly worth mentioning. Cheers, Sterl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fun with the ST monad
On Feb 24, 2011, at 3:45 PM, Andrew Coppin wrote: OK, so I had a function that looks like transform :: [Word8] - [Word16] It works nicely, but I'd like to use mutable state inside. No problem! Use the ST monad. Something like transform :: [Word8] - [Word16] transform xs = runST (work xs) where work :: [Word8] - ST s [Word16] Ah, yes, well there is one *small* problem... If you do that, the function becomes too strict. unsafeInterleaveST? http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad-ST.html#v:unsafeInterleaveST --Sterl___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: unordered-containers - a new, faster hashing-based containers library
A quick grep of some of my own source reveals that I've used M.size and S.size only to test for sizes equal to 1. So, for my purposes at least, an O(1) isSingleton operation would be just as useful as an O(1) size. Cheers, Sterl On Feb 23, 2011, at 4:32 PM, Johan Tibell wrote: On Wed, Feb 23, 2011 at 1:27 PM, Gwern Branwen gwe...@gmail.com wrote: You could look at them yourself; I attached the files. I see 6 uses out of ~100 which involve an == 0 Looks like the mailing list gateway didn't let your attachements through. No need to attach them though, I can just grep Hackage for uses. Johan ___ 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] ANN: unordered-containers - a new, faster hashing-based containers library
On Sat, Feb 19, 2011 at 3:04 PM, Johan Tibell johan.tib...@gmail.com wrote: On Sat, Feb 19, 2011 at 11:58 AM, Louis Wasserman wasserman.lo...@gmail.com wrote: A couple thoughts: size takes O(n). That's just depressing. Really. This applies to all the container types. We could support O(1) size at the cost of slowing down e.g lookup, insert, and delete a little bit. I haven't measure how much yet. Would it be worth it? Getting a bit picky, but for the record, Data.Map and Data.Sequence provide O(1) size, and Data.HashTable I believe stores the information but doesn't expose it from its tiny API. That's not an argument either way for what a HashMap should do, however :-) Cheers, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Summers of Code retrospective (updated for 2010)
On Feb 9, 2011, at 6:18 PM, Gwern Branwen wrote: 2 years ago in February 2009, I wrote up a history of Summers of Code through 2008 (http://www.haskell.org/pipermail/haskell-cafe/2009-February/055489.html). But the Wheel turns, and years come and pass, leaving memories that fade into 404s; a wind rose in Mountain View, whispering of the coming Summer... I have considerably expanded and updated the coverage: http://www.gwern.net/Haskell%20Summer%20of%20Code.html There was some discussion of this on reddit. [1] Below is a slightly cleaned-up version of my comments there. I really appreciate this roundup. But I think the bar is set somewhat too high for success. A success in this framework seems to be a significant and exciting improvement for the entire Haskell community. And there have certainly been a number of those. But there are also projects that are well done, produce results that live on, but which aren't immediately recognizable as awesome new things. Furthermore, GSoc explicitly lists a goal as inspiring young developers towards ongoing community involvement/open source development, and these notes don't really take that into account. For example, I don't know of any direct uptake of the code from the HaskellNet project, but the author did go on to write a small textbook on Haskell in Japanese. As another example, Roman (of Hpysics) has, as I understand it, been involved in a Russian language functional programming magazine. So I think there needs to be a slightly more granular scale that can capture some of these nuances. Perhaps something like the following: [ ] Student completed (i.e. got final payment) [ ] Project found use (i.e. as a lib has at least one consumer, or got merged into a broader codebase) [ ] Project had significant impact (i.e. wide use/noticable impact) [ ] Student continued to participate/make contributions to Haskell community A few more detailed comments about projects that weren't necessarily slam dunks, but were at the least, in my estimation, modest successes: GHC-plugins -- Not only was the work completed and does it stand a chance of being merged, but it explored the design space in a useful way for future GHC development, and was part of Max becoming more familiar with GHC internals. Since then he's contributed a few very nice and useful patches to GHC, including, as I recall, the magnificant TupleSections extension. GHC refactoring -- It seems unfair to classify work that was taken into the mainline as unsuccessful. The improvement weren't large, but my understanding is that they were things that we wanted to happen for GHC, and that were quite time consuming because they were cross-cutting. So this wasn't exciting work, but it was yeoman's work helpful in taking the GHC API forward. It's still messy, I'm given to understand, and it still breaks between releases, but it has an increasing number of clients lately, as witnessed by discussions on -cafe. Darcs performance -- by the account of Eric Kow other core darcs guys, the hashed-storage stuff led to large improvements (and not only in performance)[2] -- the fact that there's plenty more to be done shouldn't be counted as a mark against it. [1] http://www.reddit.com/r/haskell/comments/fid5w/haskell_summers_of_code_retrospective_updated_for/ [2] http://blog.darcs.net/2010/11/coming-in-darcs-28-read-only-support.html Cheers, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrency best practices?
On Feb 5, 2011, at 2:37 PM, Evan Laforge wrote: I recall reading that clojure has a concept of associative combination. If you can declare that certain operations are associative then the runtime doesn't have to care if they get out of order. I think that you're thinking about the commute operation: http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/commute There's more discussion elsewhere on the web, including here: http://squirrel.pl/blog/2010/07/13/clojure-alter-vs-commute/ Cheers, Sterl___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Polymorphic function over pairs of maybes.
Basically, I have a signal processing loop, where values are passed updated with a Maybe, representing whether there is or is not a change to the value. I could use a single Maybe around the whole thing, but that would require then re-updating a potentially large structure entirely. I want to be able to build a combinator that can combine two signal-fetching actions into a larger one: IO (Maybe a) - IO (...) - IO (Maybe a, (...)) and then an action that could, given the previous value: (a, (...)) update any places in this chain of pairs where the Maybe is not Nothing. Sounds like you want a generic diff: http://hackage.haskell.org/package/gdiff-1.0 Cheers, Sterl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] syb-with-class problem.
Sorry. I've had the patch sitting around but have been too busy/otherwise occupied to push it. This gave me the necessary kick in the posterior. HStringTemplate 0.6.6 is now on Hackage, and should work properly with ghc 7, I think. Cheers, Sterl. On Dec 16, 2010, at 6:21 PM, Magicloud Magiclouds wrote: On Thu, Dec 16, 2010 at 9:15 PM, Antoine Latter aslat...@gmail.com wrote: Hi there, The only version of template haskell which will work is the version that the compiler was built against. So if you're working with ghc-7, it is 2.5 or nothing. Why doesn't HStringTemplate work with 2.5.0.0? What error were you getting? Antoine On Thu, Dec 16, 2010 at 6:23 AM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, I am trying to make happstack work in my box, which is using ghc 7. While compiling HStringTemplate, which I did a little modification to make it work, I found that it does not work with template-haskell-2.5.0.0. I changed it to use template-haskell-2.4.0.1. This step worked fine. Then I got another error: $ cabal install Resolving dependencies... Configuring syb-with-class-0.6.1.1... Preprocessing library syb-with-class-0.6.1.1... Building syb-with-class-0.6.1.1... [1 of 4] Compiling Data.Generics.SYB.WithClass.Context ( Data/Generics/SYB/WithClass/Context.hs, dist/build/Data/Generics/SYB/WithClass/Context.o ) [2 of 4] Compiling Data.Generics.SYB.WithClass.Basics ( Data/Generics/SYB/WithClass/Basics.hs, dist/build/Data/Generics/SYB/WithClass/Basics.o ) [3 of 4] Compiling Data.Generics.SYB.WithClass.Derive ( Data/Generics/SYB/WithClass/Derive.hs, dist/build/Data/Generics/SYB/WithClass/Derive.o ) Data/Generics/SYB/WithClass/Derive.hs:23:1: Bad interface file: /home/magicloud/.cabal/lib/template-haskell-2.4.0.1/ghc-7.0.1/Language/Haskell/TH.hi Something is amiss; requested module template-haskell-2.4.0.1:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH cabal: Error: some packages failed to install: HStringTemplate-0.6.3 depends on syb-with-class-0.6.1.1 which failed to install. syb-with-class-0.6.1.1 failed during the building phase. The exception was: ExitFailure 1 How to resolve this? -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I see. The building problem with 2.5.0.0 is Language.Haskell.TH.Quote.QuasiQuoter. It changed from 2 params constructor to 4 params. And I have no idea how to give the 2 new params. -- 竹密岂妨流水过 山高哪阻野云飞 ___ 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] handling multiple versions of a data structure
On Dec 16, 2010, at 5:48 PM, Daniel Peebles wrote: Have you considered moving these packages that are unrelated to web development into a separate namespace? I know that I never considered looking under the happstack namespace simply because I never do webapps. On Thu, Dec 16, 2010 at 5:09 PM, Jeremy Shaw jer...@n-heptane.com wrote: Hello, You should use happstack-data for this (you do not need the other happstack components to use happstack-data)*. It was created to solve this exact problem. +1 -- This package looks like it solves this (common) problem in a pretty good way. I've off and on considered writing a package that was very similar, and despite using happstack frequently, have never touched any of the data layers, and assumed they were all tied to the persistence layer, which I've avoided. This could definitely use some juice and traction on its own. Cheers, Sterl.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 7.0.1 developer challenges
On Tue, Nov 30, 2010 at 9:24 AM, Ryan Ingram ryani.s...@gmail.com wrote: On Mon, Nov 29, 2010 at 12:36 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Do you have an alternative to suggest? After all, the previous situation wasn't good either. I suggest that we should be able to specify RTS options at compile/link time, or as pragmas in the Main module. -- ryan What's feasible to write now, and almost better (but lacking toolchain/library support) is writing two executables. The first takes command line options, decides what to do based on them, and then passes control to the second, with flags set only as appropriate. Doing this cleanly is OS dependent, and tied to System.Process, daemonizing-type techniques, and all that. Such a library, possibly implemented as a nontrivial extension (or borrowing code from) the excellent-looking hdaemonize package, would be very welcome! Cheers, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Downloading web page in Haskell
On Nov 20, 2010, at 5:10 PM, Yitzchak Gale wrote: José Romildo Malaquias wrote: Web browsers like Firefox and Opera does not seem to have the same problem with this web page. I would like to be able to download this page from Haskell. Hi Romildo, This web page serves the head, including a lot of JavaScript, and the first few hundred bytes of the body, then pauses. That causes web browsers to begin loading and executing the JavaScript. Apparently, the site only continues serving the rest of the page if the JavaScript is actually loaded and executed. If not, it aborts. Actually, I think it's just a misconfigured proxy. The curl executable fails, at the same point, but a curl --compressed call succeeds. The curl bindings don't allow you to automatically get and decompress gzip data, so you could either set the accept: gzip header yourself, then pipe the output through the appropriate decompression routine, or, more simply, just get the page via using System.Process to drive the curl binary directly. Cheers, Sterl___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Musings on type systems
On Nov 19, 2010, at 6:22 PM, Aaron Gray wrote: IIRC It Does not deal Hindley-Milner type system at all. i.e. it does not cover ML's type system. Its successor ATTAPL :- http://www.cis.upenn.edu/~bcpierce/attapl/index.html Handles an ML like type systems using constraints. TAPL certainly covers the basic ML system -- which is pretty much the typed lambda calculus with first order polymorphism. What it doesn't do is cover type inference (or reconstruction) in any depth, although it does actually sketch at least one algorithm for HM type inference (including constraints) -- see chapter 22. You're right that ATTAPL covers much more in the realm of type inference, as well as plenty else. Cheers, Sterl.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Quasi quotation question
On Nov 19, 2010, at 6:00 PM, jean-christophe mincke wrote: Hello, Is it possible for a quasi quoter to have access to information about haskell identifiers declared before the quasi-quotation? Nope. There are staging restrictions in place, since you can't sanely use things that haven't been fully defined and typechecked yet. Quasiquotation in fact runs at the renaming stage, before there's been any typechecking of the module yet, so the situation is even more dire. I tried the 'reify' function but without success. Just as in the following exemple: a = 6 x = [$expr|a|] However, in your example, you just want to generate `x = a`. You can do that just fine! Just generate a syntax tree that includes a variable named a. If there's no variable named a, or it has the wrong type, the syntax tree is still generated just fine -- the error just comes at the typechecking phase. It would be generating x = 6 that is impossible. Cheers, Sterl___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is simplest extension language to implement?
On Tue, Nov 2, 2010 at 11:08 AM, Donn Cave d...@avvanta.com wrote: The quotes around scripts are well chosen, since it sounds like you might be using the word in a different sense of `small program', vs. the extension language notion of a programmable UI. Haskell's suitability for something like this has come up before. The worries about its complexity and giant learning curve seem misplaced to me - as a scripting extension it would have less to do, so there would be less to learn, I think - but it's all hand-waving without more concrete ideas about the typical application. And it's a moot point if there's no way to do it. If (and this is a big if) the type of extensions you want the user to provide are well captured in a simple combinator-style DSL you can write an AST and interpreter for, then as a first pass Read/Show over the AST is sufficient. If the syntax and parser messages are too confusing, then a parsec-based parser can get you the rest of the way. Once you grok the principles, writing your own functional mini-language in Haskell (including as an external DSL) is in many ways more straightforward than binding to any sort of external runtime. That said, some sort of slow but low-footprint mini-hask for extension languages would be pretty awesome. I'm seeing a function like -- evalMiniHask :: Environment - String - Either ParseOrTypeError Dynamic. where type Environment = ([DataRep], [FunctionRep]) and type DataType = (String,TyCon,Dynamic) -- the latter being the concrete type constructor, wrapped in a dynamic type FunctionType = (String, TypeRep, Dynamic) -- the latter being the concrete function, wrapped in a dynamic I can see a number of use cases in my own code already Cheers, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How can we make Haskell-Cafe scale? (was: Re: Edit Hackage)
There's been some grumbling about users migrating from -cafe to Reddit and Stack Overflow in particular. First, as Don has pointed out, the fact is that people are moving away, and that's just the trend. But why are people moving? One reason is that Stack Overflow, Reddit, and -cafe all provide *different things*, with features tailored to specific purposes. I'll try to explain what those things are, why they don't threaten, but augment -cafe, and why we need at least one new mailinglist as well. 1. When Stack Overflow is Better Than -cafe Stack Overflow is *better* for a QA format. I can scan for questions I'm competent to answer or interested in answers to (and the rss feed helps with that), and be confident that for the most part there won't be thread derails, and that the title will maintain consistency with the discussion inside. If the title isn't informative, I can be confident that someone with sufficient rights (which are granted by accumulation of karma) will edit it to be informative. Likewise the question itself, if it evolves over time, can be edited to reflect what it should have been to begin with. And most importantly, if an answer to a question is provided on -cafe, it quickly gets drowned in surrounding traffic. And if an answer becomes out of date, there's no good way to annotate the archives to indicate that. I don't *need* to read all s.o. questions, on the off chance than an answer might become relevant to me later. I know that s.o. provides the right tools so I can find the answer when I need it. And I know that s.o. lets users update pages with new posts, or edits, so that answers don't become stale over time. A technical QA site serves different purposes than a mailinglist, and it needs different technology to do so. There are other, smaller, advantages to stackoverflow which I haven't even touched on. 2. When Reddit is Better Than -cafe As for reddit, while some people obviously treat -cafe as an anything goes place to crack jokes or pursue arguments of rather narrow interest, I'm acutely aware that every message sent to this list lands in the mailbox of thousands some multiple thousands of programmers, many very talented, and almost all with better things to do than wade through the massive traffic of -cafe for the few things of interest to them. So, generally, I tend to shy away from posting to -cafe. Reddit, on the other hand has (although maybe a bit too much) a bit more of the freewheeling atmosphere of, e.g., the #haskell irc channel. People are going to reddit during a long compile, or on a coffee break. There's an understanding that the conversation will tend to be casual, that there will be occasional trolls and occasional gems, and that the primary content will be in high-quality links to papers, blogposts, articles, etc., while the discussion threads will be a way to shoot the breeze about them. This distinction between content and chatter is in many ways a useful thing. Again, the medium of reddit facilitates this type of content. Because messages are shown in their threaded context with relatively high information density, they don't have to quote or indicate their surrounding context. The incremental cost of each message, both to reader and writer, is tiny, and this facilitates a more free-flowing conversational style than over email. Again, upvotes and downvotes (the dreaded ratings and karma) make it easy to see immediately which points others found useful or bogus, and to register simple agreement or disagreement without adding more semantic noise to the mix. 3. How -cafe Can Be Better than -cafe If Stack Overflow is better for QA and Reddit is better for link aggregation and casual chat, that doesn't mean that -cafe should lose subscribers, or pack up and go home. It means that -cafe can shed those aspects, and get on with what *is* better here. For example, the recent set of DSL conversations have been very rich and productive. And I can't think of an online fora besides -cafe where they could have taken place. In one sense, because -cafe has too many posts, it in fact has too few subscribers. Plenty of people who do great work in Haskell, either as academics or commercially, don't have the time and energy to devote to -cafe, even though there are conversations that would be perfect for them. -cafe has averaged about 50 posts/day for this last month. Of those, I'd say about 2/3 are on topic for what I'd like -cafe to be. Some followed from release announcements which led into discussions of some aspect of the project. Some were related to issues with standard libraries, widely-used packages or otherwise relevant to the whole of the Haskell community. Some were well served by taking the temperature of the Haskell community (e.g. the lambda-case discussion). And some were questions suited to generating a broad discussion rather than one or two correct single answers. The other third, by my
Re: [Haskell-cafe] Need programming advice for Network ProtocolParsing
On Oct 27, 2010, at 6:23 PM, Claus Reinke wrote: I'm occasionally working on making a friendly yet performant library that simultaneously builds parsers and generators, but it's non-trivial. If you I'm probably missing something in the friendly yet performant requirements, but I never quite understood the difficulty: A typical translation of grammar to parser combinators has very little code specific to parsing - it is mostly encoding the grammar in a coordination framework that calls on literal parsers at the bottom. Since the coordination framework uses some form of state transformers, exchanging the literal parsers with literal unparsers should turn the grammar parser into a grammar unparser (in essence, the non-terminal code is reusable, the terminal code is specific to the direction of data flow). On this topic, folks might be interested in the awesome Invertible Syntax Descriptions paper presented by Tillmann Rendel and Klaus Ostermann at this year's Haskell Symposium: http://www.informatik.uni-marburg.de/~rendel/unparse/ Cheers, Sterl___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: MonadCatchIO, finally and the error monad
On Oct 18, 2010, at 6:31 AM, Michael Snoyman wrote: Thank you for the offer, but I don't think I'm in a position to take over maintainership of another library. However, I think that my original suggestion of moving all of the exception-handling functions into the type class itself would solve the current issue; is there a reason not to do so? I'm still not sure what to do about ContT. As I posted some time ago, the scheme community has long know that genuine unwind-protect (i.e. bracket) is impossible in the presence of call/CC. I suggest that the instance simply be removed from the catchIO libraries to avoid confusion, and that the reason for its omission be documented. Cheers, Sterl.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: MonadCatchIO, finally and the error monad
On Mon, Oct 18, 2010 at 8:50 AM, Michael Snoyman mich...@snoyman.com wrote: The point here is that we want to treat these things very differently. Just take a look at the runHandler code in the Yesod.Handler module: runtime exceptions need to be wrapped up in an internal server error, whereas Left values from the ErrorT get cased on. I understand that all of this could be done with extensible exceptions, but that's really just taking something which is currently explicit and type-checkable and making it implicit. It really does seem to me to be a typical dynamic-versus-static issue. I fail to see how this is a dynamic-static issue. You're already forced to catch exceptions and wrap them in a MLeft, and then later you force the MLeft and MRight values in to a uniform representation which you then case on. Catching a special exception type for exit and forcing it into the same ultimate union representation doesn't seem conceptually any more difficult, and in fact removes the need to reason about two types of exceptions throughout the rest of the code base. I've got a large project that is based on a transformer stack over IO, and one of my ongoing regrets has been that I went with Either as well as extensible exceptions -- there's never been a genuine payoff, and there have been more than a few headaches. Cheers, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Lambda-case / lambda-if
On Oct 6, 2010, at 5:39 AM, Simon Marlow wrote:
A slightly different suggestion from Simon PJ and myself (we agreed on
something syntax-related :-) is the following:
\case 1 - f
2 - g
where the two-token sequence '\ case' introduces a new optional layout
context, the body of which is exactly the same as in a case expression. So
you could also write
\case { 1 - f; 2 - g }
if you want. Guards are allowed of course.
* a bit more noisy than just \: I'm not sure what the
ramifications of having \ introduce a layout context
on its own would be, but I suspect there would be difficulties.
Certainly some existing code would fail to parse, e.g.
(case e of [] - \x - x+1; (x:xs) - \x - x+2)
\ introducing a layout context is a no-go because, as in the example given, it
breaks too much code. However, \case as described is somewhat less powerful. In
particular, \ with a layout context lets us have multi-argument pattern
matching, while both \case and case of give only single argument pattern
matching. I don't know if the extra functionality is that important, but I
don't see why we can't provide for it anyway, as in:
\case (x:xs) n - go xs; _ n - n;
Cheers,
Sterl.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pointers for EDSL design
Stephen's list is great! Two more points of reference from the recent ICFP -- Geoff Mainland's Nikola [1], and a nice talk on Kansas Lava [2]. [1] http://www.eecs.harvard.edu/~mainland/publications/ [2] http://www.scribd.com/doc/38559736/kansaslava-hiw10 -- hopefully the video from the implementor's workshop to appear soon. I suspect however, that it will prove hard to impossible to reuse Data.List and Control.Monad functions directly. You don't want to invoke functions at compile time, but represent invocations. Cheers, Sterl.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Relaxing atomicity of STM transactions
Clojure has a commute operator whose semantics seem appropriate to your concerns: http://clojure.org/refs http://richhickey.github.com/clojure/clojure.core-api.html#clojure.core/commute Commute in haskell would be roughly :: TVar a - (a - a) - STM a. The TVar touched by commute does not get marked such that the transaction could retry. Nor is the TVar itself even updated at the time. Rather, it is read, and the result of applying some transform to it is returned. Then, when the transaction commits, the tvar is atomically modified by the function and actually updated. This works if the operation commutes with all other operations performed on the TVar anywhere else that may be running concurrently, and if no essential use (i.e. requiring atomicity) is made of the value returned from commute. Both properties can only be enforced by the discipline of the programmer. I don't know how much discussion there's been in the Clojure community about the utility of commute, as a quick google mainly reveals people trying to either figure it out or explain it. Cheers, Sterl. On Sep 28, 2010, at 7:36 PM, Tom Hawkins wrote: Thanks for the responses, but I think I should explain a bit more. I'm not interested in being able to read the live value of a TVar at any arbitrary time (via. unsafeIOToSTM). But rather I would like looslyReadTVar to have exactly the same semantics as readTVar, except that the STM runtime would not reject the transaction if the TVar is modified by another transaction before the atomic commit takes place. Also, as I would be implementing something similar in Atom, I'm not necessarily interested in a Haskell implementation, but rather if the programming experience is elevated by these alternative semantics. For example: incr :: TVar - STM () incr a = looslyReadTVar a = writeTVar a . (+ 1) decr a :: TVar - STM () decr a = readTVar a = writeTVar a . (- 1) If incr and decr where atomically started at the same time with the same TVar, decr would be rejected if incr completed first, but not the other way around. The initial reaction may be that this seriously breaks the atomicity of STM, but there may be cases where this could be useful. For instance, it allow a computationally expensive transactions to complete, even if their inputs are constantly being modified. In the embedded domain, this could be a fault monitor that reads a bunch of constantly changing sensors. -Tom ___ 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] MonadCatchIO and bracket.
There’s a history of rich debate and discussion on these issues coming from the scheme world, where it takes the guise of implementing unwind-protect in the presence of call/cc. Kent Pitman’s take is presented here: http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuations-overview.html There’s some context given in the following ltu discussion: http://lambda-the-ultimate.org/node/2966 Will Clinger’s notes on his revised implementation are particularly useful: http://www.ccs.neu.edu/home/will/UWESC/uwesc.sch Note that none of the implementations translate directly, I think, as they rely on top-level mutable state. In any case, my take is the following -- first, remove the ContT instance from the CatchIO package as it is obviously wrong. Next, don’t use ContT in the presence of exceptions. There are few cases where one really needs to do so, given that exceptions provide a powerful means of flow control themselves. Finally, it is much easier to provide a bracket function with one-shot continuations (i.e., MonadExit), and doing so could well simplify most of the current uses of ContT. Cheers, Sterl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Seeking the correct quote
I first encountered this quip on ltu: http://lambda-the-ultimate.org/node/1926#comment-23411 However, that comment doesn't give a source either. Cheers, Sterl. On Tue, Apr 27, 2010 at 4:23 PM, Jacques Carette care...@mcmaster.ca wrote: I have heard generic programming described tongue-in-cheek as the kind of polymorphism that a language does not (yet) have. I find this description rather apt, and it matches fairly what I see called 'generic' in various communities. But who said this, where and when? Jacques ___ 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] ANN: HStringTemplate 0.6.2
I haven't sent out a release announcement for HStringTemplate in some time. In that time, there's been a host of new users, and consequently a host of feature requests and bug reports. Among the relatively recent changes: * Simple quasiquotation. * Proper unicode support (files are read in UTF-8, Data.Text templates are supported). * Creation of groups from hierarchies of directories. * Separators are applied within iterated template application. * Chained iterated template application now occurs depthwise rather than breadthwise. * Encoding functions generalized from String - String to (Stringable a) = a - a * Trailing newlines stripped from templates. * Initial newlines stripped after conditionals. * Functions to check templates for proper parsing, and existence of all necessary parameters and invoked templates. Current version is, as always, on Hackage: http://hackage.haskell.org/package/HStringTemplate User-maintained documentation on the wiki: http://www.haskell.org/haskellwiki/HStringTemplate Patches, bug reports, requests, and especially additional work on the documentation always welcome. Cheers, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Efficient functional idiom for histogram
On Aug 1, 2009, at 2:06 PM, Paul Moore wrote: Is the issue with random numbers just the implementation, or is it something inherent in the non-pure nature of a random number generator that makes it hard for Haskell to implement efficiently? If the latter, that probably makes Haskell a somewhat poor choice for simulation-type programs. Well, I'm not sure of the details, but in your original implementation, you're performing IO to pull the seed out of a ref at every iteration. Pekka Karjalainen's doesn't do that, which probably helps with the speedup. Along with that, Haskell has a fairly slow random implementation. As I recall however, this is partially because it hasn't received a great deal of optimization, but mainly because the algorithm itself fulfills some rather strong properties -- in particular it must be fairly statistically robust, and it must provide a split function which produces generators that are independently robust [1]. This limits algorithm choice quite a bit. For other random numbers, with different properties (faster, but with tradeoffs in robustness, or ability to split, or both), you can check hackage for at least mersenne-random and gsl-random. There may be others that I don't recall. Cheers, Sterl. [1] http://www.haskell.org/onlinereport/random.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec for C or C++
A parser for JavaScript (admittedly a much simpler beast) is part of Brown's WebBits: http://hackage.haskell.org/packages/archive/WebBits/0.15/doc/html/ BrownPLT-JavaScript-Parser.html Cheers, Sterl. On Jul 16, 2009, at 1:40 PM, Roy Lowrance wrote: Turns out that Language.C uses alex and happy. I'm looking to use Parsec. So back to the original question: Does anyone know of a C or java parser written using Parsec? - Roy On Thu, Jul 16, 2009 at 12:43 PM, Roy Lowranceroy.lowra...@gmail.com wrote: Thanks Rick. A perfect tip! - Roy On Thu, Jul 16, 2009 at 12:29 PM, Rick Rrick.richard...@gmail.com wrote: There is language.c http://www.sivity.net/projects/language.c/ http://hackage.haskell.org/package/language-c From a parsing standpoint, C++ is a massive departure from C. Good luck though. On Thu, Jul 16, 2009 at 12:25 PM, Roy Lowrance roy.lowra...@gmail.com wrote: I am working on a research language that is a variant of C. I'd like to use Parsec as the parser. Is there an existing Parsec parser for C or C++ (or Java) that could serve as a starting point? Thanks, Roy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- The greatest obstacle to discovering the shape of the earth, the continents, and the oceans was not ignorance but the illusion of knowledge. - Daniel J. Boorstin -- Roy Lowrance home: 212 674 9777 mobile: 347 255 2544 -- Roy Lowrance home: 212 674 9777 mobile: 347 255 2544 ___ 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: AW: [Haskell-cafe] Example for formatted show in HStringTemplate
What I suspect that you've encountered is an infelicity when importing
GenericStandard. The ToSElem instance defaults to that provided by (Data a)
context. However, there is no special handler for Data.Time types in the
`extQ` chain. I could add one, but that would require relying on the
Data.Time library being the latest (since Typeable isn't provided until
then) or on conditional compilation and standalone deriving, which is a
pain. As the new time package comes into widespread use, I'll fix up the
gToSElem function with the appropriate handlers, but until then I'm afraid
that standard generics won't play well with Data.Time. GenericWithClass, on
the other hand, might yield better results.
There is, by the way, (thanks to the efforts of Luke Plant) now an
HStringTemplate page on the haskellwiki:
http://www.haskell.org/haskellwiki/HStringTemplate. Edits, improvements,
etc. of course welcome by all.
You may want to post this question and answer there.
By the way, I plan to have a new version with a real announcement and a fair
share of bugfixes in the next week or so.
Cheers,
Sterl.
Kemps-Benedix Torsten wrote:
John,
thanks for your answer, but HStringtemplate has instance definitions for
Date.Time.Day. The question is more on the script side: How do I have to
write the ST calls with ;format= embedded in HTML?
regards,
Torsten
-Ursprüngliche Nachricht-
Von: John MacFarlane [mailto:fiddlosop...@gmail.com]
Gesendet: Dienstag, 14. Juli 2009 08:20
An: Kemps-Benedix Torsten
Cc: ha...@googlegroups.com; haskell-cafe@haskell.org
Betreff: Re: Example for formatted show in HStringTemplate
+++ Kemps-Benedix Torsten [Jul 13 09 23:56 ]:
Hello,
is there a working example of how to use the format clause with
HStringTemplate, e.g. for Data.Time.Day? I think, if there is a parameter
$day$, a reasonable template might contain e.g.:
$day;format=%d.%b.%Y$
But I only get toModifiedJulianDay: [54960] as the result which
corresponds to the unformatted show.
You probably need to define a StringTemplateShows instance for
Data.Time.Day, and then use stShowsToSE to define a ToSElem instance.
Something like
instance StringTemplateShows Day
where stringTemplateFormattedShow formatString = formatTime
defaultTimeLocale formatString
{- or whatever -- I'm not sure what the correct time-formatting
function is -}
instance ToSElem Day
where toSElem = stShowsToSE
John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
View this message in context:
http://www.nabble.com/Example-for-formatted-show-in-HStringTemplate-tp24470429p24480823.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] Alternative IO
On Jul 10, 2009, at 4:35 AM, Wolfgang Jeltsch wrote: I fear that this instance doesn’t satisfy required laws. As far as I know, the following equalities should hold: (*) = () f * empty = empty empty | g = g This implies the following: (f empty) | g = g But this wouldn’t hold with your instance. (f empty) | g would cause the side effects of f and of g, while g would (obviously) only cause the side effects of g. I think the third equality you provide is too strong (which isn't to say that it might not be the law that people have documented and expect). Lots of useful alternative instances fail it, not least any parser combinator library (such as Parsec) without automatic backtracking. A more realistic law would perhaps be: (f * empty) | g = f * g Additionally, the second equality you provide is just wrong. f * empty = empty is no more true than f * g = g, which is no more true than f g = g, which is obviously not true at all, as putStrLn Hey There return () obviously /= return () Cheers, Sterl___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A generics question
On Jun 8, 2009, at 7:10 PM, Henry Laxen wrote: convert :: (Data a, Data b) =Int -a -b convert i x = let c = dataTypeConstrs (dataTypeOf x) !! (i-1) in fromConstr c I would like to be able to say: x = convert 1 c and have it assign Red to x then I would like to say: y = convert 1 s and have it assign Small to y, however, when I try that I get: Ambiguous type variable `b' in the constraint: `Data b' arising from a use of `convert' at interactive:1:8-18 Probable fix: add a type signature that fixes these type variable(s) Of course if I say x :: Color = convert 1 c, it works, but I would like to avoid that if possible, as all of the information is already contained in the parameter c. Is there any way to do this? Thanks in advance for your wise counsel. Best wishes, Henry Laxen The type signature for 'convert' is throwing away the information you want. Try it with the following type signature and it should work fine: convert :: (Data a) = Int - a - a Of course, as has been noted, SYB is a rather big sledgehammer for the insect in question. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: StrictBench 0.1 - Benchmarking code through strict evaluation
On Jun 8, 2009, at 6:58 AM, Magnus Therning wrote: Is there no way to force repeated evaluation of a pure value? (It'd be nice to be able to perform time measurements on pure code so that it's possible to compare Haskell implementations of algorithms to implementations in other languages, without running into confounding factors.) This perhaps introduces too much inefficiency, but one trick is to pack the computation into an existential. i.e. calculate :: Floating b = (forall c. Floating c = c) - b calculate = id This method is used to evaluate the same numeric formula with different rounding modes in ieee-utils. http://hackage.haskell.org/packages/archive/ieee-utils/0.4.0/doc/html/ src/Numeric-IEEE-Monad.html#perturb Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Concurrent Haskell Actions with Timeout
The proper way is just to wrap System.Timeout, which does some rather clever things with regards to exception semantics. The code for it is a joy to read, by the way. --S. On May 30, 2009, at 5:36 PM, Sebastian Sylvan wrote: On Sat, May 30, 2009 at 10:32 PM, Cetin Sert cetin.s...@gmail.com wrote: Thank you for your reply, I'd come up with the following: timed :: Int → IO a → b → IO (Either b a) timed max act def = do r ← new t ← forkIO $ do a ← act r ≔ Right a s ← forkIO $ do wait max e ← em r case e of True → do kill t r ≔ Left def False → return () takeMVar r - *Network.Port.Scan timed 500 (wait 5 return 0) 'x' Left 'x' *Network.Port.Scan timed 50 (wait 5 return 0) 'x' Right 0 - before reading your reply: timed timeout act fallback = do res - newEmptyMVar tid - forkIO $ act = writeMVar res threadDelay timeout stillRunning - isEmptyMVar res if stillRunning then killThread tid return fallback else takeMVar res - *Network.Port.Scan timed2 500 (wait 5 return 0) 'x' interactive:1:33: No instance for (Num Char) arising from the literal `0' at interactive:1:33 Possible fix: add an instance declaration for (Num Char) In the first argument of `return', namely `0' In the second argument of `()', namely `return 0' In the second argument of `timed2', namely `(wait 5 return 0)' Right, I forgot about the Either bit so you'd have to make sure the action's result and the default has the same type (or modify it to return an Either). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ 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] Program using 500MB RAM to process 5MB file
I also suspect that manyTill is a really bad choice, since it doesn't give you anything until the end token. It would be much better if you could rewrite your parser in terms of many and many1. --Sterl On Apr 2, 2009, at 10:08 PM, Luke Palmer wrote: 2009/4/2 lu...@die.net.au I'm relatively new to haskell so as one does, I am rewriting an existing program in haskell to help learn the language. However, it eats up all my RAM whenever I run the program. http://hpaste.org/fastcgi/hpaste.fcgi/view?id=3175#a3175 Obviously I'm doing something wrong, but without my magical FP pants I don't know what that might be. (1) You are using plain Strings. Those things are like 8 bytes per character (or something, someone more knowledgeable can give a more accurate figure). Use bytestrings (with bytestring-utf8 if you need it) instead. (2) You are parsing strictly, meaning you have to read the whole input file before anything can be output. This may be necessary for your application, but Haskell is very strong with streaming applications. Change to a lazy parser and you will run in constant memory. (I don't know offhand of any lazy parsing libraries, but I've heard them discussed before, so they're somewhere) Luke ___ 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] TMVar's are great but fail under ghc 6.10.1 windows
Is it possible to rewrite this without unsafeIOToSTM? unsafeIOToSTM is insanely unsafe, and can cause otherwise working STM code to do unpredictable and terrible things to the runtime. Cheers, Sterl. On Mar 30, 2009, at 4:27 PM, Alberto G. Corona wrote: Control.Concurrent.STM.TMVar's combine the best of MVars and TVars: -Unlike TVars, they permit blocking/early retry when the TMVar is being used by other process, so that complete processes are not retried at the end when happens that the TVars have been modified in the meantime. - Unlike MVars, they have no deadlocks, specially when a process is trying to adquire exclusive access to more than one TMVar. however, It happens that fails in my windows box with ghc 6.10.1 , single core here is the code and the results: ---begin code: module Main where import Control.Concurrent.STM import Control.Concurrent import System.IO.Unsafe import GHC.Conc mtxs= unsafePerformIO $ mapM newTMVarIO $ take 5 $ repeat 0 proc i= atomically $ do unsafeIOToSTM $ putStr $ init of process ++ show i++\n xs- mapM takeTMVar mtxs mapM (\(mtx,x) -putTMVar mtx (x+1)) $ zip mtxs xs xs' - mapM readTMVar mtxs unsafeIOToSTM $ putStr $ End of processs ++show i ++ result= + + show xs'++\n main=do mapM (forkIO . proc) [1..5] threadDelay 1 -end code the rigth result must be (occasionally with some init of process x repeated) init of process 1 init of process 2 End of processs 1 result= [1,1,1,1,1] init of process 2 -- retried End of processs 2 result= [2,2,2,2,2] init of process 3 End of processs 3 result= [3,3,3,3,3] init of process 4 End of processs 4 result= [4,4,4,4,4] init of process 5 End of processs 5 result= [5,5,5,5,5] under windows the program produces strange results for example init of process 1 init of process 2 init of process 3 init of process 4 init of process 5 End of processs 1 result= [1,1,1,1,1] End of processs 2 result= [1,1,1,1,1] (deadlock) or this other: init of process 1 init of process 2 init of process 3 init of process 4 init of process 5 End of processs 1 result= [1,1,1,1,1] End of processs 2 result= [1,1,1,1,1] init of process 3 init of process 4 init of process 5 init of process 2 End of processs 4 result= [2,2,2,2,2] End of processs 3 result= [2,2,2,2,2] End of processs 5 result= [2,2,2,2,2] End of processs 2 result= [2,2,2,2,2] init of process 3 init of process 5 init of process 2 End of processs 3 result= [3,3,3,3,3] End of processs 5 result= [3,3,3,3,3] ___ 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] Unique monad?
On the other hand, I find its use in Control.Timeout to be perfectly sane (or at least as sane as anything else in that particular library). Cheers, Sterl. On Mar 30, 2009, at 4:42 PM, Jeremy Shaw wrote: At Mon, 30 Mar 2009 20:57:02 +0100, Lennart Augustsson wrote: I think Data.Unique is horrible and should be banned. It encourages a global variable style of programming that will just bite you in the end. Agreed. I'm ashamed I even mentioned it. - jeremy ___ 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] Re: toSelem takes no format parameter
If you have a type that requires a format string, the proper place to pass that string in is not the toSElem method. Rather, one should construct a ToSElem instance that wraps the item in an (STSH . STShow) constructor. The item itself then should be made an instance of StringTemplateShows, with an appropriate stringTemplateFormattedShow method. It's a bit of plumbing, I'll grant, but allows for setting the format where it should be -- in the template itself. If, on the other hand, you simply want to apply the locale to the attribute as you pass it in to the template, then you can just pack them together in a tuple or a record, and write a ToSElem instance for that. Cheers, S. On Mar 27, 2009, at 8:41 AM, Kemps-Benedix Torsten wrote: Sterling, the toSElem function of ToSElem does not take a parameter that allows specification of e.g. the locale that shall be used for rendering a specific attribute. If one wants to change this, one also has to change setAttribute and the like. Do you have any plans to extend HStringTemplate in this way? Schöne Grüße Torsten Kemps-Benedix (Geschäftsführer) SKS Unternehmensberatung GmbH Co KG Geheimrat-Hummel-Platz 4 D-65239 Hochheim am Main Germany M +49.163.36017.01 T +49.700.36017.000 F +49.700.36017.011 torsten.kemps-bene...@sks-ub.de http://www.sks-ub.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HSTringTemplate and syb-with-class
You don't need to derive ToSElem -- you get the instance for free if you derive Data. Import GenericWithClass to get the instance for Data from syb-with-class, and import GenericStandard for use with Data from the vanilla syb that comes with GHC. Cheers, Sterl. 2009/3/23 Kemps-Benedix Torsten torsten.kemps-bene...@sks-ub.de: Hello all, I’m trying to use the generic capabilities of HSTringTemplate. The documentation claims that the package is able to automatically generate instances of ToSElem if syb-with-class is installed but gives no further details. I installed syb-with-class and then installed HSTringTemplate with additional configure parameter syb-with-class=True. But when I import Text.StringTemplate.GenericWithClass and then try deriving ToSElem or $(derive ToSElem), I just get an error like “Can't make a derived instance of `ToSElem …”. Any suggestions or pointer to further docs? Kind regards Torsten ___ 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] symbolic evaluator for Haskell?
On Mar 18, 2009, at 1:40 AM, wren ng thornton wrote: Lambdabot (on #haskell) has something similar using a type, Expr, to overload certain names, e.g. koninkjefoldr f z [1..5] lambdabot f 1 (f 2 (f 3 (f 4 (f 5 z It's a complete hack and isn't as sophisticated as what you're after, but it could serve as a basis for implementation ideas. This is, I believe, essentially the simple-reflect package on Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/simple- reflect At least two of lennart's libraries provide related functionality: Traced: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ traced and Data.Number.Symbolic in numbers: http://hackage.haskell.org/cgi- bin/hackage-scripts/package/numbers Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parallel programming (threads, cores, processors)
On Mar 10, 2009, at 10:38 PM, Mark Spezzano wrote: Hi, I’m an experienced software developer, but a bit of a newbie when it comes to parallel processing in any language. Question 1: Is there any programmatic change in dealing with multiple threads as opposed to multiple cores in most languages (specifically Haskell)? That is, to write multiple threads you normally “spin-off” a new thread which runs in parallel along with other threads. Is Haskell smart enough to do this by magic by itself, or would I need to tell it explicitly : Run thread A whilst running thread B Also, what about multicore architectures? Do I have to tell the language to spin off two separate programs to run on each core and then somehow use some kind of communications to exchange data? GHC's parallel runtime, which is what we're really talking about when we're talking about Haskell concurrency, operates roughly like this: Threads at the language level are green -- i.e. they are conceptually threads, and the runtime schedules them as it sees fit, but they aren't tied to any given core for execution. You can create (using the forkIO primitive) as many new threads as you like. If you then execute your program with runtime options (i.e. +RTS -N 2 for two cores) that specify how many actually operating system threads you want, the runtime will then map your set of green threads onto OS threads (and presumably cores) in what it thinks is an efficient manner. Communication between threads is via MVars, which are like one-item mailboxes, and are one concurrency primitive, or TVars, which are for Software Transactional Memory. I also assume that, in theory it would be possible to have multiple threads running on each core. Say, 3 threads spawned from program 1 running on core 1 and 5 threads on program 2 running on core 2 Generally, the runtime system moves threads between cores as it sees fit. However, you can tie threads to particular cores using other concurrency primitives (i.e. runInBoundThread). See the documentation for Control.Concurrent (http://www.haskell.org/ ghc/docs/latest/html/libraries/base/Control-Concurrent.html) and Control.Concurrent.STM (http://www.haskell.org/ghc/docs/latest/html/ libraries/stm/Control-Concurrent-STM.html) for more details. Likewise I would suppose that it would be possible to have multiprocessors, each potentially multicore, each core running multiple threads. Yep, see above, although I don't know of any way to distinguish between cores and processors as you're really just mapping to OS threads (i.e. capabilities) and relying on the OS to distribute these among cores and processors reasonably. Question 2: In light of the above statement, is the programmatic change DIFFERENT for dealing with each of a) Multithreading in Haskell versus b) Multicores in Haskell verus c) Multiprocessors in Haskell Generally, you'll want to write concurrent Haskell code as an abstraction to think about things that are naturally concurrent -- i.e. which are best thought of as happening at the same time. At runtime, you specify how many OS capabilities you want to map onto. For algorithms where you want computations to happen in parallel, there's an entirely different set of operations, based around `par` (see Control.Parallel [http://www.haskell.org/ghc/docs/latest/html/ libraries/parallel/Control-Parallel.html] and Control.Parallel.Strategies). In neither case should you need, generally, to concern yourself with the details of threads vs. cores vs. processors. Cheers, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] derive Drift - some help please
You shouldn't need any extra tools for this. A combination of the StandaloneDeriving and DeriveDataTypeable extensions in GHC should suffice. Cheers, S. On Sun, Mar 8, 2009 at 10:30 AM, Gü?nther Schmidt gue.schm...@web.dewrote: Hi, I need to derive Data, Typeable for Data.Time.LocalTime. I had hoped to use either derive or DrIFT to generate the instance declarations for it. I tried to understand the respective user manuals but it's still all Greek to me. Someone please help! Günther ___ 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] Supplying a default implementation for a typeclass based on another class
On Feb 28, 2009, at 5:59 AM, Svein Ove Aas wrote: I'm in the process of writing a distributed filesystem (in haskell, yay), which of course means I'm using Binary for de/serialization. Now, that's fine enough, but for simplicity (and for wireshark), I'd like to be able to have Binary fall back on an instance based on Show/Read for any type that lacks any other Binary instance. Rather than something funny with extensions, why not write two methods, of type defBinaryPut :: Show a = a - Put defBinaryGet :: Read a = Get a Then, if somebody tries to use something lacking a Binary instance, they can just define a simple instance with those two methods. And when they want to improve performance, they just write better methods. :-) In fact, these seem useful enough to go into, if not Data.Binary itself, a separate package. After all, proper serialization shouldn't be a barrier to rapid prototyping. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org GSoC
On Feb 18, 2009, at 4:43 AM, Max Bolingbroke wrote: 2009/2/18 Sterling Clover s.clo...@gmail.com: The punchline: With GHC plugins, it should be possible, and reasonable, to add a proper unit system for Haskell. Alas, GHC plugins cannot change the type system - only meddle with the compilation strategy or analyse the code and suchlike. I'm working with Simon Peyton Jones to get plugins integrated fully into GHC (parts of it have been commited already) but we're both busy and so progress is slow. I don't think any GSoC projects should take a dependency on it being both integrated into GHC and stable in time for the summer. Thanks for the update on plugins! I look forward to trying them out from the GHC mainline at some point. I don't think that units as I envision them would need to mess with the type system directly, but could be implemented simply as a static analysis step, such as you describe. Units really do something quite different from standard types, and unit-correctness seems orthogonal to type correctness. A simple plugin would, e.g., allow unit annotations as distinct from type annotations (although, with an appropriate preprocessor step, they could, with cleverness, be written jointly), and simply track unit usage throughout the code to ensure correctness. It would, I assume, only need to operate on things which belonged to the Num typeclass to begin with, and assume that all unannotated numbers were scalars. Even lacking any sophisticated features, I would find this very useful, and certainly easier to envision than a more general extension to the type system that made unit tracking feasible, but yet, somehow, didn't veer fully into either simulated or actual dependent typing. So I guess I'll just keep this idea in mind and pitch it for next year's GSoC. :-) Cheers, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Overloading functions based on arguments?
On Feb 19, 2009, at 9:09 AM, John A. De Goes wrote: Let's try a little test: 1. If the parameter is a tree, what do you think flatten would do? I would imagine that it would be join on trees -- i.e. take a tree of trees and turn it into a tree. But perhaps it would be arbitrarily deep. Or perhaps it would turn a tree into a list, but I would of course prefer toList for that. 2. If the parameter is a list, what do you think flatten would do? Since a list is already flat, it couldn't possibly turn it into a list -- but again, it could perhaps be join or it could be deepJoin or maybe if it was a list of numbers that represented a signal, it would smooth out peaks beyond standard deviation, but maybe it would do that treating the numbers as a time series or perhaps it would do that treating the numbers as coefficient to a series of trigonometric functions. 3. If the parameter is a Style (possible a composite Style consisting of other styles), what do you think flatten would do? If the style included colors, perhaps it would mute them? Or, maybe, it would mean, as you intended, join. And if a style may consist of other styles, then isn't it, properly speaking, a variant of a tree to begin with? 4. If the parameter is a Bezier curve, what do you think flatten would do? One would imagine, produce a straight line. But would this line be between the original endpoints, or would it be a projection onto the horizontal axis? My guess is that we would come to the same conclusions for (1) - (4). The name flatten is a perfectly good name for all of these operations, because the domains are distinct, and because using that name suggests the correct meaning to you. (Note use of the word suggests -- like an analogy or parable, you're likely not going to know exactly what the function does just by reading its name, but you'll be in the ballpark and have an intuition about it, which is extremely valuable.) In three cases, depending on what you intended flatten to mean (I've been a bit provocative, but honestly I do have no idea), then the domains may not be distinct, because join is an operation that they do properly have in common. And no, the name doesn't suggest one clear meaning -- what does, generally, suggest a single clear meaning to me, is a good type signature, but since I could no longer query :t flatten in GHCI and get a single response, I would be, I'm afraid, somewhat at sea -- even more so if in some cases flatten was a typeclass operation, and in others not. Or, worse yet, if flatten was declared as a typeclass operation in one place, defined on lists in another, and in a third, lists were given an orphaned Flattenable instance. Cheers, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell.org GSoC
Something that hit me tonight: Last GSoC gave us GHC compiler plugins. We have examples, but no documented significant uses, suitable for production code. Plugins, in essence, as I understand them, let us extend the type system in useful ways. Haskell has libraries for units[1], but no lightweight (i.e. without simulated dependent types or a dsl) way to embed units in Haskell calculations. Units in a functional language are possible, and implemented in, e.g., F# [2] The punchline: With GHC plugins, it should be possible, and reasonable, to add a proper unit system for Haskell. Given a suitable SoC candidate, I'd love to see this, and if it worked reasonably enough, I'm sure that I would use it. Cheers, Sterl. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ dimensional, http://liftm.wordpress.com/2007/06/03/ scientificdimension-type-arithmetic-and-physical-units-in-haskell/, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/caldims [2] http://blogs.msdn.com/andrewkennedy/archive/2008/09/04/units-of- measure-in-f-part-three-generic-units.aspx ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
+1 for some graphical tools for darcs, especially even a graphical merge tool (and a console/curses based version as well, to be sure). And +1 for darcs and xmonad applying as mentoring organizations in their own right. For that matter, it might be worthwhile for GHC to apply as well! That would ensure some dedicated compiler slots, and more could be contributed from the main haskell.org pool as appropriate. As well, I know that there's quite a nice new hackage2 almost rolled out, but I'm sure that there's at least an SoC project or two worth of feature additions to that as well. Off the top of my head, and bearing in mind that some might be further along than I think: a generalized way to search the package database, slicing and dicing by upload time, authors/maintainers, popularity, limiting views to packages that build on certain platforms, etc; some thought into security measures; a ratings system and associated reviews (thread/ wikibased); ways to mark packages as depreciated/for historic purposes. And there's bound to be more. As for numerics, I recall that Greg Wright, who knows whereof he speaks, had some particular issues that he thought no existing library addressed. I can't recall the details or do them justice, but perhaps he might care to enlighten us? Cheers, Sterl. On Feb 12, 2009, at 3:16 AM, Matthew Elder wrote: would love to see this. basic features first i suppose. here are some of my ideas: 1. browseable change history with preview pane (preview pane shows diff and patch message) 2. darcs send which goes through the usual interactive console but then prompts with a file save pane where you will save the .dpatch (easy contribution). 3. graphical dependency chart for patches (also shows conflict patches as merges). On Wed, Feb 11, 2009 at 11:52 PM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Mittwoch, 11. Februar 2009 20:45 schrieb Gwern Branwen: Here are the projects I favor (in no particular order): […] * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); this could possibly be based on TortoiseDarcs http:// tortoisedarcs.sourceforge.net/. Perhaps the specific project could be making TortoiseDarcs not Windows specific? I plan to start writing a GUI interface to darcs together with some of our students. (However, we don't want to base it on TortoiseDarcs.) So if you have ideas of what features such an interface should have, please write me quickly. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Need somewhere to put your code? http://patch-tag.com Want to build a webapp? http://happstack.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] Is using Data.Dynamic considered a no-go?
SYB makes very heavy use of Typeable as well, although not, as I
recall dynamics as such.
Cheers,
Sterl.
On Feb 12, 2009, at 3:40 PM, Don Stewart wrote:
Notably, extensible exceptions use dynamics, in conjunction with type
classes and existentials.
A number of solutions to the 'expression problem' involve dynamics.
bugfact:
It would be interesting to see when you HAVE to use dynamics, e.g.
when no
other solution is possible in Haskell...
Right now if I use it, it feels that I'm doing so because I'm too
new to
Haskell.
On Thu, Feb 12, 2009 at 7:53 PM, Lennart Augustsson
lenn...@augustsson.net
wrote:
You're quite right. You should only be allowed to derive
Typeable.
(Which could be arranged by hiding the methods of typeable.)
On Thu, Feb 12, 2009 at 6:24 PM, Jonathan Cast
jonathancc...@fastmail.fm wrote:
On Thu, 2009-02-12 at 19:04 +0100, Lennart Augustsson wrote:
They are not unsafe in the way unsafePerformIO is,
I beg permission to demur:
newtype Unsafe alpha = Unsafe { unUnsafe :: alpha }
instance Typeable (Unsafe alpha) where
typeOf _ = typeOf ()
pseudoSafeCoerce :: alpha - Maybe beta
pseudoSafeCoerce = fmap unUnsafe . cast . Unsafe
Note that
pseudoSafeCoerce = Just . unsafeCoerce
but I regard them
as a last resort in certain situations.
Still, in those situations they are very useful.
But I would agree with both of these. As long as you *derive*
Typeable.
jcc
___
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 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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Network.UrlDisp
I'm not working on hvac at the moment, but the UrlDisp code was split out of it by Artyom Shalkhakov. So some of the old example code from hvac should still be of interest. The following, for example, was an implementation of a threaded message board: http://code.haskell.org/~sclv/hvac/Examples/hvac-board.hs Note that this code uses the infix combinators. After a chorus of it's worse than perl! went up, standard message dispatch combinators were added as well. I explained briefly how they worked here: http://fmapfixreturn.wordpress.com/2008/05/21/some-concepts-behind- hvac/#comment-94 The validation stuff used both in the code example and the blog post is not part of UrlDisp, by the way. Cheers, S. On Feb 1, 2009, at 2:46 PM, Pieter Laeremans wrote: Hello, Has anyone some exampe usages of : Network.UrlDisp ? thanks in advance, Pieter -- Pieter Laeremans pie...@laeremans.org ___ 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] space leak with 'concat' ?
Note that only monomorphic declarations are CAFed. If you have an explicit polymorphic signature, it will be treated as a function and garbage-collected as usual. So if you have, e.g., a list of Doubles, declaring it as foo :: Num a = [a] would do the trick. Cheers, S. On Tue, Jan 27, 2009 at 6:22 PM, Jake McArthur j...@pikewerks.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henning Thielemann wrote: | in that module I defined the text to be printed as top-level | variable which might have been the problem. But this can't be the | problem of the compiled version of the program, where I encountered the | leak. So I have to keep on searching that leak. You have created a constant applicative form (commonly abbreviated CAF). GHC assumes that all top level declarations are constants, and simply does not garbage collect them. In the case of infinite structures, this can be a bad thing. This *does* affect even compiled code. The best way to avoid the problem, of course, is to avoid having infinite constants at the top level. Assuming that is impossible, your solution seems acceptable to me. Somebody more knowledgeable or creative than I may be able to come up with something nicer, though. - - Jake -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl/lz0ACgkQye5hVyvIUKl0JgCgx5ddBc0Y44+ghFakr7Mex1RP zfUAnjh9BDI5+A9tEnaox20DbXbipX33 =2MCw -END PGP SIGNATURE- ___ 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: Improved documentation for Bool (Was: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt)
This is a great effort, but the root of the problem isn't just poor
documentation, but an insistence on some obscure name. How about
renaming Bool to YesOrNoDataVariable? I think this would help novice
programmers a great deal.
It would also make the documentation flow much more naturally:
The Bool type is the coproduct of the terminal object with itself.
--huh?
The YesOrNoDataVariable is the coproduct of the terminal object with
itself.
--Oh! Of course!
--S
On Jan 18, 2009, at 12:17 PM, Benja Fallenstein wrote:
On Sun, Jan 18, 2009 at 5:48 PM, rocon...@theorem.ca wrote:
I noticed the Bool datatype isn't well documented. Since Bool is
not a
common English word, I figured it could use some haddock to help
clarify it
for newcomers.
-- |The Bool datatype is named after George Boole (1815-1864).
-- The Bool type is the coproduct of the terminal object with itself.
Russell, this does seem like it might be very helpful, but it might be
useful to include a note about what category you are working in.
People may sometimes naively assume that one is working in the
category of Haskell/Hugs/GHC data types and Haskell functions, in
which there are no terminal -- or initial -- objects ('undefined' and
'const undefined' are distinct maps between any two objects X and Y),
or else in the similar category without lifted bottoms, in which the
empty type is terminal and the unit type isn't ('undefined' and 'const
()' are both maps from any object X to the unit type). These niceties
will not confuse the advanced reader, but it may help the beginner if
you are more explicit.
- Benja
P.S. :-)
___
Libraries mailing list
librar...@haskell.org
http://www.haskell.org/mailman/listinfo/libraries
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]
On Thu, Jan 08, 2009 at 11:14:18AM -0700, John A. De Goes wrote: But really, what's the point? FFI code is fragile, often uncompilable and unsupported, and doesn't observe the idioms of Haskell nor take advantage of its powerful language features. Rather than coding through Just for clarity's sake, we should specify that the Erlang ffi interface that's been worked on (not my project, I've just browsed the code) is *not* low-level via C, but rather a set of parsers/ unparsers between haskell data types and the Erlang wire format and a set of behaviors for message queuing that between them let a haskell program act as a node to Erlang programs, or let Haskell programs communicate between themselves as nodes, which just coincidentally happen to use the same wire format as Erlang. Which is not to say that Erlang does not have specific excellent libraries that allow *certain types* of network programming do be done very easily. The Haskell library-space has lots of room to grow, and lots of inspiration to take from the OTP (although less for hot-swapping which is somewhat overrated, and more from supervision-tree type stuff). However, even now an adequate subset of whatever functionality is needed can be whipped up pretty quickly for any project requiring only that subset. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What are side effects in Haskell?
Granting the everything is a function idea the best intent, maybe what it's trying to express is the related but different notion that everything *can be* a function -- i.e. that any value can be replaced by a function which yields a value of the appropriate type. Alternately, it could be a confusion between the untyped lambda calculus, in which everything really is a function, and the typed lambda calculus, in which things are more complicated? --S. On Jan 2, 2009, at 2:53 PM, Conal Elliott wrote: Hi Cristiano, Similarly, any value can be thought of as a list (perhaps singleton), a Maybe (Just), a pair ((,) undefined or (,) mempty), an IO (return), ... (any Applicative). And yet I've heard everything is a function on several occasions, but not these others. Hence my (continuing) puzzlement about the source of that idea. I have some speculations: * In pure OO programming, everything is an object, so in pure functional programming, one might assume everything is a function. I find the term value-oriented programming a more accurate label than functional programming. * C has definitions for functions but assignments for other types. Since pure functional languages eliminate assignment, one might assume that only functions remain. (I also hear people refer to top-level definitions in a Haskell module as functions, whether they're of function type or not.) Are there other thoughts insights about the source of the idea that everything is a function? Thanks, - Conal On Fri, Jan 2, 2009 at 2:52 AM, Cristiano Paris fr...@theshire.org wrote: On Tue, Dec 30, 2008 at 8:35 AM, Conal Elliott co...@conal.net wrote: Everything in Haskell is a function [...] Where did this idea come from? I'd say every expression in Haskell denotes a pure value, only some of which are functions (have type a-b for some types a b). Maybe more formally correct, but my statement still holds true as any values can be tought as constant functions, even those representing functions themselves. Cristiano ___ 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] Re: Threads with high CPU usage
Thanks John! I've been running into this quite a bit with the ODBC backend as well. Having an entire server app freeze because MS SQL Server decides to deadlock is rather unpleasant. Cheers, Sterl. On Mon, Dec 22, 2008 at 3:59 PM, John Goerzen jgoer...@complete.org wrote: On Mon, Dec 22, 2008 at 04:28:03PM -, Bayley, Alistair wrote: From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Günther Schmidt I understand that Takusen does not use unsafe calls and would like to try it with that one then, but haven't find enough docs yet on how to use Takusen. Not a lot of detailed examples exist for Takusen. I'm hoping the documentation for Database.Enumerator is a reasonable place to start. http://darcs.haskell.org/takusen/doc/html/Database-Enumerator.html I just reviewed the Takusen code and, for no apparent reason, the ODBC module specifies unsafe for all of its FFI imports, but the other modules do not (so they get the default, which I assume is safe). I also was not aware of unsafe calls blocking other threads. I'll change the ODBC imports to be safe (or rather, unspecified). Makes sense. I will make the similar change in all HDBC backends. -- John ___ 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] ANN: bytestring-trie 0.1.0
Thanks for working on this! A nice efficient bytestring-trie is the sort of data structure we should have had in Haskell for some time now, and I'm sure I'll be giving it a great deal of use. Regards, Sterl. On Dec 20, 2008, at 1:06 AM, wren ng thornton wrote: -- Announcing: bytestring-trie 0.1.0 (beta) An efficient finite map from (byte)strings to values. The implementation is based on big-endian patricia trees, like Data.IntMap. We first trie on the Word8 elements of a Data.ByteString, sharing string prefixes where possible, and then trie on the big-endian bit representation of those elements. Patricia trees have efficient algorithms for union and other merging operations, but they're also quick for lookups and insertions. -- Future Extensions * I've done spot checking to make sure it works, but haven't constructed an extensive test suite. Does anyone know of a good data set already out there for testing corner cases? I'm sure other dictionary writers have come up with one. * A Word8 is much smaller than the architecture's natural Word size. Therefore it'd be more efficient for the trie on bits to read off a whole Word at a time. This work is in progress, but I need help from people with 64-bit and big-endian machines in order to verify the code works on those architectures. * Using ByteStrings allows for trieing on any packed byte representation of a value, but they're not Strings. Integration with Data.ByteString.Char8, utf8-string, and utf8-light should happen. * The current implementation also only accepts strict ByteStrings. When chopping up strings to share prefixes we share the smaller string. For very long strings when many deletions are expected, this can still hold onto more memory than necessary. Accepting lazy ByteStrings or adding heuristics for when to copy prefixes instead of sharing will fix this. -- Links Homepage: http://code.haskell.org/~wren/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ bytestring-trie Darcs: http://code.haskell.org/~wren/bytestring-trie/ Haddock (Darcs version): http://code.haskell.org/~wren/bytestring-trie/dist/doc/html/ bytestring-trie/ -- Live well, ~wren ___ 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] Time for a new logo?
Alvaro's infinity lambda is awesome! The fancy treatments -- shadows, reflections, and the funny haskell font can all go, but the infinity lambda is distinctive, conceptually clear, and conveys the notion that we're not just the lambda calculus, but the lambda calculus to the power of our type system. Speaking of which, maybe the lambda cube could be the basis for a logo? --S ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell, successing crossplatform API standart
Haxr provides a basic implementation of the XML-RPC protocol, and while it looks like it doesn' t build on 6.10 at the moment, getting it to build shouldn't be a problem, and although it doesn't appear to be under active development, it does seem to be getting maintenance uploads. [1] These days, however, web services seem to be moving towards a RESTful model with a JSON layer and there are plenty of JSON libraries on hackage, which you could just throw over the fastCGI bindings. Alternately you could try JSON over one of the really lightweight haskell web servers, such as shed [2] or lucu [3]. If you go the latter route, I'd love to hear how it went. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haxr [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/httpd- shed [3] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Lucu Regards, Sterl ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why 'round' does not just round numbers ?
On Oct 30, 2008, at 5:21 PM, Bertram Felgenhauer wrote: George Pollard wrote: There's also the ieee-utils package, which provides an IEEE monad with `setRound`: http://hackage.haskell.org/packages/archive/ieee-utils/0.4.0/doc/ html/Numeric-IEEE-RoundMode.html When run with +RTS -N2 -RTS, the output randomly alternates between Downward and ToNearest - for me at least. The problem is that the setRound call will only affect one worker thread, while the RTS will sometimes migrate RTS threads from one worker to another. runIEEE really has to be executed in a bound thread (see forkOS documentation). Using `par` will also cause trouble - in fact even more. That's a really nice catch! Dons has pointed out to me both the very handy forkOnIO which ensures the forked thread remains bound to a single CPU, and also the -qm flag to the RTS, which prevents thread migration between capabilities. Running the example program with +RTS -N2 -qm restores the behavior to what's intended. I'll try to get around to changing the documentation to reflect this. Also, it's worth noting that the IEEE round mode has no effect on rounding done with the `round` function, as that's explicitly coded to provide the behavior seen in the report. Regards, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monadic Floating Point [was: Linking and unsafePerformIO]
I'd like to direct folks' attention to the IEEE-utils package on hackage [1], which Matt Morrow started and I have made a few additions to. There are bindings to set and check the rounding mode, as well as check and clear the exception register. On top of that I've built a very experimental monadic wrapper (so experimental that I just noticed a typo in the documentation). The monad is essentially a newtype over IO, which enforces a single IEEE state using an MVar propagated through the program as an implicit parameter (as opposed to created with top-level unsafePerfomIO). Strictness could probably be enforced in a more thoroughgoing fashion, but now is explicitly introduced with calculate which is a lifted evaluate. The perturb function is pretty neat -- it uses polymorphism to prevent memoization, such that the same pure calculation can be performed over different rounding modes, to test for numeric stability. I couldn't think of a sane way to deal with fancier traps to the IEEE registers, but obviously a slower but sane implementation of exception traps could be built on top of the existing machinery. With a bit of duct-tape, perturb could no doubt be combined with quickcheck to prove some relatively interesting properties. Matt and I did this mainly out of curiosity and to fill a gap, as neither of us has a real need for this sort of control over IEEE state at the moment. As such, I don't have a good idea of what is good or bad in the API or could be more convenient. However, I'd urge folks with an itch to scratch to give this all a try and maybe provide some feedback, use-cases, implementations of algorithms that need this sort of thing, of course patches, etc. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ieee-utils-0.4.0 Cheers, Sterl. On Fri, Oct 17, 2008 at 11:19 AM, Ariel J. Birnbaum [EMAIL PROTECTED] wrote: It is an interesting question: can IEEE floating point be done purely while preserving the essential features. I've not looked very far so I don't know how far people have looked into this before. Not sure. My doubts are mainly on interference between threads. If a thread can keep its FP state changes 'local' then maybe it could be done. I still think FP operations should be combined in a monad though --- after all, they depend on the evaluation order. Haskell currently only supports a subset of the IEEE FP api. One can assume that that's mainly because the native api for the extended features is imperative. But need it be so? Rounding modes sound to me like an implicit parameter. Traps and exception bits sound like the implementation mechanism of a couple standard exception handling strategies. The interesting thing here is that the exception handling strategy is actually an input parameter. Reader? =) So part of the issue is a functional model of the FP api but the other part is what compiler support would be needed to make a functional api efficient. For example if the rounding mode is an implicit parameter to each operation like + - * etc then we need some mechanism to make sure that we don't have to actually set the FP rounding mode before each FP instruction, but only at points where we know it can change, like passing a new value for the implicit parameter, or calling into a thunk that uses FP instructions. This one seems like a tough one to figure. Again, I'd vouch for a solution like STM --- composition of FP operations is allowed at a certain level (maybe enforcing some settings to remain constant here), while it takes a stronger level to connect them to their surroundings. There's also the issue that if the Float/Double operations take an implicit parameter, can they actually be instances of Num? Is that allowed? I don't know. Technically I guess they could, just like (Num a) = (b-a) can be made an instance. It would look more like State though, IMO. Or Cont. Doesn't even look like Oleg-fu is needed. Should they? That's a horse of a different colour. There are certain properties most programmers come to expect of such instances (regardless of whether the Report demands them or not), such as associativity of (+) and (==) being an equivalence that break miserably for floating point. Floating point is a hairy area for programing in general, but I think it's also one where Haskell can shine with an elegant, typesafe model. -- Ariel J. Birnbaum ___ 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] Spine-lazy multiqueue
On 10/21/08, Luke Palmer [EMAIL PROTECTED] wrote: Well, first, my question was highly malformed. I actually just want a spine lazy map of lists; queues were not what I wanted. [...] The best I've come up with so far is a binary search tree where the most recently inserted thing is at the root. It's not balanced, because balancing would make it strict (as far as I can tell). So it's only logarithmic time sometimes. Surely a trie would do the job? With each node a map? One could probably even produce a Patricia trie at some constant cost to keep things on the order of number of elements (ish)rather than on the order of length of elements. Either way its not exactly going to be log (n) but depending on what you're storing it might be as efficient if not more so, and indeed would let you be lazy in the amount of each key consumed (assuming keys are, e.g., lists and not ints) as well as in the spine. --Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting new user perspective
On Oct 10, 2008, at 5:46 PM, Jonathan Cast wrote: identifier = lexeme $ match [[:lower:]_][[:alphanum:]_]* (pretending match :: String - Parser String is a regex engine). vs. identified = lexeme $ do c - satisfy isLower | satisfy (=='_') s - many $ satisfy isAlphaNum | satisfy (=='_') return (c:s) lexeme $ (:) $ (lowerChar | char '_') * (many $ alphaNum | char '_') ? or (since we're not really talking about full fledged parsers that need lexemes here or such, but usually interpreting a single string, otherwise regexes will quickly become atrocious) foo (x:xs) | isLower x || x == '_', (xs', rest) - break alphaOrUnder xs = Just (x : xs', rest) | otherwise = Nothing where alphaOrUnder = liftM2 (||) isAlphaNum (=='_') foo [] = Nothing A bit more verbose, sure, but operating on text functionally makes it really easy to reason about what your parser is actually doing, unlike the mysteries of a regex. --Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pure Haskell database
So the issue is one writer, many readers across processes? Creating an actual mini-db-server might be the proper way to do this. Expose a simple socket by which other processes can query the DB state. If you need persistence between runs of your main server you can always snapshot on shutdown, or for error-tolerance you can also write to a transactional log (probably with a single writer thread that takes input over a chan). Assuming its still in good shape, haxr [http:// www.haskell.org/haxr/] would simplify writing the socket portion. Depending on how you wrote the surrounding server, you might be able to avoid mvars altogether (i.e. if your server was built in an agent style with only a single request handler thread, then state could just be passed between recursive calls [or even stashed in a State monad] and the request serialization would handle concurrency issues for you). Regards, S. On Oct 1, 2008, at 3:09 PM, Manlio Perillo wrote: Graham Fawcett ha scritto: [...] Never though about sparse array, what is the advantage? For the complexity, the same of a good hash map. Almost certainly worse complexity than a hash map; but the overhead could be much smaller. If (for example) you only needed a small number of key/value pairs (say, hundreds of thousands), you could implement your database trivially, e.g. a NULL-terminated array of key/value structs in shared memory. (Though having separate arrays for keys and values might help cache locality and boost performance). Lookup might be O(n) but with a small-ish N and with such a low overhead, it could perform very, very well. This seems an interesting idea, thanks. Manlio Perillo ___ 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: Re[2]: [Haskell-cafe] Climbing up the shootout...
At the risk of getting sucked into a silly discussion, I'd like to point out that the c code uses the following really simple and naive function: http://sourceware.org/cgi-bin/cvsweb.cgi/libc/stdlib/strtol.c?rev=1.42.2.2content-type=text/x-cvsweb-markupcvsroot=glibc http://sourceware.org/cgi-bin/cvsweb.cgi/libc/stdlib/strtol_l.c?rev=1.4.2.3content-type=text/x-cvsweb-markupcvsroot=glibc Oh, and it simply and naively loops with the following: while (fgets_unlocked (line, MAXLINELEN, stdin)) If Bulat's point is that the shootout has inspired work on Haskell performance, and in the stdlibs no less, then lovely, and that's all to the good. Below every high level interface is lots of low level pain. If his point is anything else, this is getting absurd. --S On Mon, Sep 22, 2008 at 8:16 PM, Bulat Ziganshin [EMAIL PROTECTED]wrote: Hello Don, Tuesday, September 23, 2008, 3:12:37 AM, you wrote: for the same reason i don't feed 5000 men with 7 breads - it's not my business ;) Ok. So I'll just say: high level, efficient code is an overriding theme of many individuals working on Haskell. Things are better and better each year. We do not stand still. yes. when we say that things are greatly improving each year, this means that they was bad previously ;) For example, Bulat cites a paper talking about naive list code from 2002, however, by 2008 we know how to do fusion on lists, so it runs in the same time as low level loops, the technique is implemented and you can download it from hackage, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion someone can ask why this great code isn't used in ghc by default. probably it is just work in progress which isn't yet ready to replace old slow code. then we can see tha fusion isn't magic wand which improves speed of every haskell code that's slower than C one. it just makes C-speed code sometimes Simon Marlow is busy adding more efficient GC and parallelism to GHC, and there's a summer project to rewrite the native code generator. well, i'm sais about *current* real situation. if you consider this as attack against Haskell developers, it's your mistake. the problem is that i many years wrote about slowness of ghc code, every time you cosider this as attack and write that in future Haskell will become much faster. we still wait for this future, however GHC gained pointer tagging in the last release cycle, dramatically reducing the cost of algebraic data types. 10-20% speed improvement, on average. it's the only real improvement (for my own program) i know. i think that ByteString-related libs gived more improvements but their use isn't automatic and they doesn't help in any situation. they just provide fast library code for solving some concrete (although very frequent) situations, such as counting lines At the same time, we're writing books about how to program naively in Haskell, such that your code doesn't suck. That is: training. Teaching people how to write Haskell. it is what i say - if naive code was effective and automagically optimized by ghc, we don't need all those tutorials. anyone looked into your tutorial on writing efficient Haskell code, will never say that it's easier than in C. so we can conclude that optimized haskell programs are several times slower than C ones and need several times more to write We can see it paying off, where naive code performs very very well, http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcollang=all yes! it's my beloved example of elegant haskell code entirely based on the readInt function added to ghc libs specifically to win in this test. it's implementation is really simple and naive: -- - -- Reading from ByteStrings -- | readInt reads an Int from the beginning of the ByteString. If there is no -- integer at the beginning of the string, it returns Nothing, otherwise -- it just returns the int read, and the rest of the string. readInt :: ByteString - Maybe (Int, ByteString) readInt as | null as = Nothing | otherwise = case unsafeHead as of '-' - loop True 0 0 (unsafeTail as) '+' - loop False 0 0 (unsafeTail as) _ - loop False 0 0 as where loop :: Bool - Int - Int - ByteString - Maybe (Int, ByteString) STRICT4(loop) loop neg i n ps | null ps = end neg i n ps | otherwise = case B.unsafeHead ps of w | w = 0x30 w = 0x39 - loop neg (i+1) (n * 10 + (fromIntegral w - 0x30)) (unsafeTail ps) | otherwise - end neg i n ps end _0 _ _ = Nothing end True _ n ps = Just (negate n, ps) end __ n ps = Just (n, ps) when gcc
Re: [Haskell-cafe] Parsing arguments and reading configuration
Alternately, just go with a map initially with default values. Then parse the command line args into a second map (especially if they're all of a format like -argname argvalue). Then lookup your args file with the command line map, and failing that the default map. Then read the args file and finally merge all three maps in the proper order. No need for monoid instances, special data types or any of that, so at a little cost in elegance a much more succinct way to get what you want. As a final step, you can always project the map values into a record type, to get some safety for the rest of your program. The entire process, aside from creating the record, should probably be no more than four or so lines. --Sterl. On Sep 19, 2008, at 8:39 PM, Antoine Latter wrote: On Fri, Sep 19, 2008 at 7:35 PM, Antoine Latter [EMAIL PROTECTED] wrote: I'm not sure how well it would hold up under maintenance, but you coud have a config sum-type which is itself a monoid, and then create two of them: And by sum-type I mean product type. Sheesh. Although having your config options in a sum-type packed into a Set, which is itself a Monoid is another option. Then you get 'mempty' and 'mappend' for free. I think I saw a blog-post or something detailing this, but I don't have a book-mark. -Antoine ___ 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] Language.Haskell and strings
A quick glance at the code reveals that there's an instance of Pretty like such: instance Pretty HsLiteral where pretty (HsInt i)= integer i pretty (HsChar c) = text (show c) pretty (HsString s) = text (show s) pretty (HsFrac r) = double (fromRational r) That HsString instance is wrong for what you want, but there doesn't seem any way to simply override it. It should, however, be easy enough to add a further postprocessing layer to your already pretty- printed text, looking line by line for those lines that are a) too long and b) contain a very large quoted string. This layer could fairly easily do something reasonable to break the string up. Alternately, you could write a preprocessing layer that walked the source tree directly and chunked all HsStrings over a certain length into ++ ++ , etc. At which point, the pretty printer could then decide how to distribute them properly across lines. Neither would be as perfect a solution as integrating with the pretty printer directly, but both would be helpful, and the latter could probably even be a one or two liner with an appropriate use of SYB. --Sterl On Sep 21, 2008, at 5:37 PM, Sukit Tretriluxana wrote: Data.List prettyStr :: Int - String - IO () prettyStr maxlen str = do putStr (\ ++ head brokenStr) mapM_ (\str - putStr (\\\n\\ ++ str)) (tail brokenStr) putStr \\n where brokenStr = map (snd.unzip) $ groupBy (\_ (i,_) - i `mod` maxlen /= 0) $ zip [0..] str Ed On Sat, Sep 20, 2008 at 4:14 PM, Maurí cio [EMAIL PROTECTED] wrote: Hi, I'm using Language.Haskell.* and would like to know if it's possible to pretty-print big strings like this: into something like this: \ \\ \\ \\ \\ \\ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: HStringTemplate to generate html tables
Hmm... an untested suggestion...
table
$cells:{ row | tr$row:{ cell | td$cell$/td}$/tr}$
/table
(i.e. nested iteration)
or to encompass the table call inside,
$cells:{ row | tr$row:{ cell |
td$cell$/td}$/tr}:{table$it$/table}$
Regards,
Sterl.
On Thu, Sep 18, 2008 at 8:16 AM, Thomas Hartman
[EMAIL PROTECTED] wrote:
I am trying to use HStringTemplate for generating html tables, for use
in http://happstutorial.com:5001
The best I could do is below. Seems awfully kludgy.
Can someone suggest a better way, which keeps me inside the
StringTemplate way of doing things? (Eg, no suggestions to use HTML.*
libraries, which are nice for some things but are a higher barrier to
entry than just jumping in and writing html.)
Some kind of map structure... for each... ?
Thanks for any help!
thomas.
{-# LANGUAGE NoMonomorphismRestriction #-}
import Text.StringTemplate
import Control.Applicative
import qualified Text.PrettyPrint as PP
main = putStrLn . PP.render . toPPDoc $ tableFromCells cells
cells = [[mee,mah,moh],[fee,fah,foh]]
-- This does generate an html table, but seems horribly obfuscated.
-- is there machinery for doing things like html table generation
-- in some better way than this hack where /endstart
-- tags are used as a separator?
-- I would imagine something like
-- newSTMP $cells:{td$it$/td}:{tr$it/tr}:{table$it/table}
-- which works a bit like a list comprehension
tableFromCells cells = setAttribute cells cells . optInsertTmpl
[(separator,/tdtd)]
$ newSTMP $cells:\
\{trtd$it$/td/tr}:\
\{table$it$/table}$
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] STM and FFI
I've been playing with this, and on top of STM as it exists, managed to neatly interleave it with sqite3 and postgres. To do so with postgres, however, required setting the locking mode to be a bit more restrictive than it is out-of-the-box. Clever use of encapsulation and monad transformers gets you 90% of the way there quite easily. Note, however, that unsafeIOToSTM is *much* more unsafe at the moment than you would expect -- in fact there is no safe way to use it at all, due to the interaction of exceptions and rollbacks at the moment. The thread about this on glasgow-haskell-users[1], along with my initial note, has a very useful reply by Simon Marlow where he both explains some things about the STM implementation and logic behind it that I didn't understand, and also describes how the GHC team intends to fix this at some point in the future. Regards, Sterl. [1] http://www.nabble.com/Where-STM-is-unstable-at-the-moment%2C-and- how-we-can-fix-it-tc19236082.html#a19236082 On Sep 9, 2008, at 6:08 AM, Arnar Birgisson wrote: On Tue, Sep 9, 2008 at 11:58, Jules Bean [EMAIL PROTECTED] wrote: Maybe this is an idea for an extension to the STM system, adding something like unsafeIOToSTM, except that in addition to the main IO action, it also takes two more IO actions that are invoked on rollback and commit, respectively. This might allow for integration with transactional systems (e.g. a remote transaction on an rdbms), although to support two-phased commit we'd need a third action for the prepare step. That would be an absolutely killer feature. A common problem in large systems is that the underlying RDBMS supports transactionality, but then the software layer has to handle its own rollbacks. I've seen some nasty bugs when the DB rolled back and the software didn't. If we could have a transactional RDBMS linked into STM with matching semantics, that would be a very nice thing. I think this is entirely doable. For comparison we already have done this with another STM framework, the DSTM2 library for Java. I.e. we hooked into prepare, commit and rollback and integrated with both MySQL transactions and a transactional file system library from Apache Commons. I'm not yet involved enough with the GHC library code, but I guess this would require the addition of a prepare phase to the STM code. There's also the question of what to do when the remote TX system indicates failure, should the transaction be retried or aborted? In the DSTM2 case we make it abort and throws an exception encapsulating the remote error to the code that initiated the TX (in Haskell's case, the caller of atomically). On a related note, we do have a paper on utilizing the STM system for authorization and policy enforcement in general. The paper is to be presented at CCS'08, and has an implementation on top of DSTM2, but we have a technical report in the works that implements this on top of the Haskell STM and gives operational semantics for the whole thing. You can find the conference paper on my website: http://www.hvergi.net/arnar/publications cheers, Arnar ___ 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] Control.Concurrent.forkIO versus Control.Parallel.par
I think a better way to look at it is that Haskell has two separate mechanisms for different *notions* of concurrency -- forkIO for actual concurrent computation which needs explicit threads and communication (and within that, either semaphore-based communication with MVars or transactional control with TVars and STM), and par for parallelism which is to express computations that are innately parallel. See, e.g. the GHC users manual which defines them as such: * Parallelism means running a Haskell program on multiple processors, with the goal of improving performance. Ideally, this should be done invisibly, and with no semantic changes. * Concurrency means implementing a program by using multiple I/O- performing threads. While a concurrent Haskell program can run on a parallel machine, the primary goal of using concurrency is not to gain performance, but rather because that is the simplest and most direct way to write the program. Since the threads perform I/O, the semantics of the program is necessarily non-deterministic. (http://www.haskell.org/ghc/docs/latest/html/users_guide/lang- parallel.html) In any case, I suspect that your second parallelize function doesn't work right because \x - x = return is an effective no-op, modulo strictness characteristics of =. And in any case, it can't be evaluated until it is called in a particular monadic environment which is provided, sequencing and all, via liftM2. One can't parallelize in an arbitrary monad in any case, at least without making a number of decisions. E.g., what's the resultant state after two parallel computations are run in a state monad? So if you're using concurrency with a monad transformer, you probably might want to start by stripping back the layers of the concurrent part of your algorithm to the minimum possible, and then explicitly managing passing state into the various forked computations, which can then be wrapped in as many runReaderT or such calls as necessary. On another, general, note, unless you're very careful, mixing IO into your algorithm will probably result in very underperformant parallel code, since it will be IO rather than processor bound. Again the point from the GHC manual that the primary goal of using concurrency is not to gain performance, but rather because that is the simplest and most direct way to write the program seems appropriate. Additionally, many have found it easier at this stage to get good performance out of writing parallel code with concurrent mechanisms rather than `par`, because careless use of `par` will tend to add as much overhead in spark creation as is saved with multiprocessing, while an explicit work queue can be easier to reason about. Regards, S. On Jul 27, 2008, at 10:49 PM, Mario Blažević wrote: Hello. I have a question about parallel computation in Haskell. After browsing the GHC library documentation, I was left with impression that there are two separate mechanisms for expressing concurrency: Control.Parallel.par for pure computations and Control.Concurrent.forkIO for computations in IO monad. This dichotomy becomes a problem when one tries to use concurrency from a monad transformer, though I'm sure that's not the only such situation. One cannot assume that the base monad is IO so forkIO cannot be used, while Control.Parallel.par won't run monads. My first solution was to replace the base monad class for the monad transformer by the following ParallelizableMonad class: -- -- class Monad m = ParallelizableMonad m where parallelize :: m a - m b - m (a, b) parallelize ma mb = do a - ma b - mb return (a, b) instance ParallelizableMonad Identity where parallelize (Identity a) (Identity b) = Identity (a `par` (b `pseq` (a, b))) instance ParallelizableMonad IO where parallelize ma mb = do va - newEmptyMVar vb - newEmptyMVar forkIO (ma = putMVar va) forkIO (mb = putMVar vb) a - takeMVar va b - takeMVar vb return (a, b) -- -- I tested this solution, and it worked for IO computations in the sense that they used both CPUs. The test also ran slower on two CPUs that on one, but that's beside the point. Then I realized that par can, in fact, be used on any monad, it just needs a little nudge: -- -- parallelize :: m a - m b - m (a, b) parallelize ma mb = let a = ma = return b = mb = return in a `par` (b `pseq` liftM2 (,) a b) --
Re: [Haskell-cafe] Mutually recursive modules and google protocol-buffers
What about generating the verbose accessor/single module code, and
then creating a hierarchical module space as well, all importing your
Base module, and reexporting the data types you want as well as less
verbosely named accessor functions? Of course, this will break record
update syntax, but maybe you could move to functional references
instead -- given that you're generating all the code to begin with,
autogenerating fref/lens style getter-setter pairs shouldn't be any
more work.
--Sterl
On Jul 15, 2008, at 10:43 AM, Chris Kuklewicz wrote:
Ah, a teachable moment. One of us is not entirely correct about
what GHC can do with this example. Hopefully I am wrong, but my
experiments...
Max Bolingbroke wrote:
And there is no way ghc can compile these in separate modules.
I may be being redundant here, but you may not know that GHC actually
can compile mutually recursive modules. See
http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-
compilation.html#mutual-recursion
. Of course, this is not a great solution either, as creating hs-boot
files is a bit tedious, but at least the option is there.
Cheers,
Max
Consider these 3 files:
A.hs:
module A(A) where
import B(B)
data A = A B
B.hs
module B(B) where
import A(A)
data B = B A
Main.hs
module Main where
import A
import B
main = return ()
There is no way to create a A.hs-boot file that has all of
(1) Allows A.hs-boot to be compiled without compiling B.hs first
(2) Allows B.hs (with a {-# SOURCE #-} pragma) to be compiled
after A.hs-boot
(3) Allows A.hs to compiled after A.hs-boot with a consistent
interface
But this Main2.hs file works fine:
module Main where
data A = A B
data B = B A
main = return ()
But in Main2.hs I cannot define two record field accessors such as
data A = A { getName :: B}
data B = B { getName :: A}
because there cannot be two different getName created in the same
namespace.
There is no way GHC can put the two field accessors in different
module namespaces because their data types include mutual recursion.
So I can choose one of
(*) Ignore mutual recursion and make all such .proto
specifications break
(*) Autogenerate very verbose data type names and put them all in
the same module to allow mutual recursion. And then either
(**) Autogenerate even more verbose field accessor names
(**) Define no field accessors and create some poor
replacement, such as
class Field'Name a b | a -b where
getName :: a - b
setName :: a - b - a
Cheers,
Chris
___
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] Analysing music
Hofstadter (he of Godel Escher Bach) naturally has a lovely essay on Chopin reproduced in Metamagical Themas, which might be helpful as well. Regards, Sterl. On Jun 5, 2008, at 2:46 PM, Kenn Knowles wrote: David Cope's early research seems relevant. Some LISP code to train a Markov chain on Bach is available from the web page for his current class. http://arts.ucsc.edu/faculty/cope/music206b.html He eschews higher-order functions; using them, you should be able to port it to very concise and readable Haskell. For the musical side of things, the powerpoint presentations hint at additional data you can put into your states and transitions to get better results for e.g. cadences, characteristic embellishments, and melodic arcs. Hope this is helpful, - Kenn On Thu, Jun 5, 2008 at 11:27 AM, Achim Schneider [EMAIL PROTECTED] wrote: The recent discussion about Markoff chains inspired me to try to train one with all the Bach midi's I have on my disk, collecting statistics on what intervals tend to get played simultaneously, which follow others and in which way the pitch offsets from its mean, so that melodies fall and raise naturally. The rationale is that if it's Bach, it's harmonious but not respecting any kind of usual chord progression. So far, I got (a bit confused around the edges): getMid mf = do mid - MidiLoad.fromFile mf return $ MidiRead.retrieveTracks mid toMelody :: MidiMusic.T - StdMelody.T toMelody = Music.mapNote f where f note = let body = MidiMusic.body note in Melody.Note StdMelody.na (MidiMusic.pitch body) main = do args - Env.getArgs let mf:[] = args m - getMid mf putStr $ Format.prettyMelody $ Optimise.all $ Music.chord $ map (\m - Music.line $ map toMelody m) m which results in chord [e 3 bn na, chord [b 2 wn na, line [hnr, d 3 wn na, hnr, cs 3 hn na, a 2 hn na, chord [cs 3 hn na, line [b 2 hn na, c 3 hn na] , for a set of random clicks in rosegarden's matrix editor. Right now, I'm desperately searching for functions that can help me analyse this beast, which afaict right now works best by having a multitude of transformations (e.g. one big top-level chord with maximum polyphony and a hell a lot of rests) that provide easy access to whatever information is needed. Does anyone of you know about previous work in this area? I don't want to break cultural imperatives by not being as lazy as possible. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the maturity of Haskell Web Frameworks
hvac sounds interesting but at that time at least it was not clear whether it was stable or would continue to be maintained. xhtml and HStringTemplate were overkill for what I wanted, so I wound up just using the FastCGI and CGI toolkits themselves. They are surprisingly nice, and with a little bit of wrappers around them for things like validating forms, have worked exceptionally well. I'm in a position now where I can make a reasonable promise that hvac will not only be maintained but undergoing continued development. I just, for example, hooked in some basic postgresql support yesterday (although the changes are not tested/pushed to the repo yet). (Speaking of which, I noticed that the HDBC postgresql bindings don't set seState on an error -- is this intentional, or something that should be fixed up?) As such though, I also can't promise that hvac as it stands is officially stable, although most work I imagine that will be done on it will consist of extensions rather than API-breaking changes. I've also been working on a lightweight testing API for programs using the CGI monad, integrated with quickcheck. Although this project isn't final yet either, there's a working repo at http:// code.haskell.org/~sclv/cgicheck/ if anyone wants to play with it/use it. I plan to use this quite a bit to test hvac, and any applications produced using it. Additionally, the hvac code now has a nice, though also incomplete orm/dsl-type library for database access (also built on top of HDBC). When I feel more confident/polished in the code there, I plan to split it out and hackage it as well. Of course, folks with a little time/inclination who play with these things a bit and put them through the paces are a big help in working out the kinks such that I feel they're closer to release- quality (even if that release *is* only 0.1). :-) Relatedly, I'd be very interested in developing a single common library for encoding/escaping/decoding/unescaping of common web formats (urls, javascript, basic xss escaping, rss-valid character escapes to html-valid ones, etc.) that uses a lightweight invertible combinator approach as described in Pierce's work on lenses (various papers at http://www.seas.upenn.edu/~harmony/) such that the encode/ decode methods are correct-by-construction bijections. There are various encoding bits scattered among the Haskell web libraries at the moment, each with varying degrees of correctness and conformance. It would be nice to direct energy here to a single centralized project, which would have some upfront architecture, and then, unfortunately, probably no small degree of spec-translation. If anyone else is interested in working on such a thing, I'd be delighted for ideas/collaboration (or better yet, if someone just picked up the idea and ran with it themselves!) (hmm... maybe galois has some internal libraries it wouldn't mind sharing as a partial basis?) Regards, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] More on performance
On Jun 4, 2008, at 5:51 AM, Henning Thielemann wrote: How about assisting the compiler with a helper function named 'parallel' ? parallel :: ([a] - b, [a] - c) - [a] - (b,c) parallel (f,g) xs = (f xs, g xs) mean xs = uncurry (/) $ parallel (sum,length) xs ? We could state RULES in terms of 'parallel'. By calling 'parallel', the user tells, that he wants fusion here. Say parallel/foldl/foldl forall f, g, x0, y0. parallel (foldl f x0, foldl g y0) = foldl (\(x,y) z - (f x z, g y z)) (x0,y0) Well, we already have . Would a sufficiently specialized rule over that be a useful addition to Control.Arrow? Regards, Sterl. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Rewrite class with fundeps in pure h98?
This was how it was originally done in HStringTemplate, as I recall. The mptcs were introduced in order to maintain lookup-maps of the correct type, and particularly to allow embedding of templates within one another. There may have been some other corner-cases involved as well. However, unless you run into them, the H98 way is certainly cleaner. --Sterl On Jun 3, 2008, at 1:17 PM, apfelmus wrote: Darrin Thompson wrote: I thought that I should be able to write something like the toHtml function below with pure H98, but when I went to write it I ended up needing fundeps. Is there a way to express this without using any extensions? The idea was to take a remotely Dom-like tree and flatten it into a string, but not require any particular string type. data (IsString s, Monoid s) = Dom s = Element s [Attr s] [Dom s] | Text s data (IsString s, Monoid s) = Attr s = Attr s s class (Monoid s, IsString s) = HTML d s | d - s where toHtml :: d - s instance (Monoid s, IsString s) = HTML (Dom s) s where instance (Monoid s, IsString s) = HTML (Attr s) s where The H98 way is to make a class for type constructors: class HTML d where toHTML :: (Monoid s, IsString s) = d s - s instance HTML Dom where ... instance HTML Attr where ... Btw, naming the class HTML is feels wrong, something like Serialize is probably a better fit. Regards, apfelmus ___ 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] ANN (2 Libs) -- hvac 0.1b, a lightweight web framework and HStringTemplate 0.3
Probably best not to keep this discussion in -cafe after this, as this is more of a debugging-type issue, but in my experience, I bet the lighttpd server is trying to serve the hvac-board fcgi file directly as a binary, rather than launching it as a fastcgi instance at all. The configurations files I've built have worked fine for me, but your milage may vary -- getting fastcgi up and running can be a bit of a bear at times. At a minimum, you should make sure that the lh.conf file points correctly to your binary in the fastcgi.server variable, and that you have all the proper fastcgi libraries installed on your system. Regards, Sterl On Jun 3, 2008, at 1:08 PM, Thomas Hartman wrote: I just tried out hvac. I was trying to run the hvac examples after following the readme in the samples directory. sudo lighttpd -D -f lh.conf [sudo] password for thartman: 2008-06-03 09:30:02: (log.c.75) server started so that's okay, but http://localhost:3000/hvac-board/board/1 in firefox attempted to open a binary file 1. Same result for http://localhost:3000/hvac-board I don't know if this is an hvac issue or a fastcgi issue (seems more likely) but any advice? Thomas. 2008/3/22 Sterling Clover [EMAIL PROTECTED]: 1) hvac 0.1b: transactional, declarative framework for lightweight web applications. 2) HStringTemplate 0.3 1) hvac 0.1b hvac (short for http view and controller) has been my project for the last little while, and is finally in a fairly usable state, so I'm opening up the repo (darcs get http://community.haskell.org/~sclv/hvac/) for folks to play with and to get some feedback. While not quite yet ready for hackage, the package as provided should be fully cabal installable. Documentation is available at http://community.haskell.org/~sclv/hvac/html_docs/hvac/ The aim of hvac is to provide an environment that makes the creation of lightweight fastcgi based web applications as simple as possible, with an emphasis on concise, declarative style code, correct concurrent transactional logic, and transparency in adding caching combinators. There are two included example programs, naturally neither of which is feature complete. They share a common login module of about 50 lines of code, excluding imports, templates, and database schema. The first program is a classic, greenspun-style message board with basic login functionality. It totals roughly 40 lines and tends to use just under 4mb of resident memory on my system. The second is a wiki based on Pandoc and the PandocWiki code. The code totals roughly 30 lines (rendering borrowed from PandocWiki aside) and uses about 5mb of memory. hvac processes all requests in the STM monad, with some bells attached to properly interleave STM with session, database and filesystem operations such that they all conceptually occur together in a single transaction per request. Currently it is only fully tested with sqlite, but it should operate, modulo a few tweaks, with any database accessible via HDBC. hvac is particularly designed to use the HStringTemplate library as an output layer, in a simple declarative fashion. As the StringTemplate grammar is explicitly sub-turing, this ensures a clean separation of program logic from presentation, while providing a nonetheless fairly powerful language to express typical display tasks. The included cache combinators, still experimental, should allow a simple and fine-grained control over the level of caching of various disk- bound operations. Phantom types are used to ensure that no functions that modify state may be cached. To give a flavor of hvac code, the following is the complete (twenty lines!) source of the wiki controller (due to sql statements, some lines are rather long): wikiController tmpl = h |/ login * login_plug tmpl | (h |/ wiki |\\ \pageName -h |// POST * withValidation [ (contents, return) ] (\ [contents] - do pageId - selectVal id from pages where name=? [toSql pageName] maybe (addErrors [(Login,must be logged in.)] continue) (\user - case fromSql pageId of Just (_::Int) - execStat insert into page_hist(pageId,contents,author) values(?,?,?) [pageId, toSql contents, toSql . userName $ user] Nothing - do execStat insert into pages(name,locked) values(?,?) [toSql pageName, toSql (0::Int)] pid - selectVal max(id) from pages [] execStat insert into page_hist(pageId,contents,author) values(?,?,?) [pid, toSql contents, toSql . userName $ user]) = getSes continue) | do pageId - selectVal id from pages where name=? [toSql pageName] (join $ renderf (tmpl showPage) (pageName, pageName) $ pageContents |= selectRow * from page_hist where pageId=? order
Re: [Haskell-cafe] Damnit, we need a CPAN.
And who bootstraps the searchpath? --S On Thu, May 29, 2008 at 4:50 PM, Darrin Thompson [EMAIL PROTECTED] wrote: On Thu, May 29, 2008 at 4:31 PM, Thomas Hartman [EMAIL PROTECTED] wrote: I've been playing a lot with searchpath lately, for doing happs quickstart installation as described on happs.org. Searchpath works great when it works, which usually means -- when the module map file is up to date and pointing everywhere to the right place. When the module map file is out of date though, the error messages for missing dependencies that you would get from searchpath are not as good as the error messages you'd get from a cabal configure. Makes me wonder if searchpath and a good module map file wouldn't be a good way to bootstrap cabal-install. -- Darrin ___ 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] saner shootout programs
Well, it would be meaningful for your own experience in learning Haskell. Some time ago somebody took a shot at nbodies using pure immutable structures, and as I recall, got within about 4x the performance of mutable structures. In 6.6, an STArray based approach was maybe 2x slower, but by now it may well be comparable, as Dons pointed out. In fact, lots of the shootout entries could use an overhaul now that 6.8 is running on their machines, as plenty of older, uglier, optimizations are probably preformed as efficiently if not more so by the newer GHC, whose strictness analysis, for example, is consistently and pleasantly surprising. If you take a stab at some of these benchmarks, with some helpful guidance from #haskell, you'll no doubt get a much better sense of how memory and performance works in haskell, and which tweaks are just there for the last 2%. So even if you can't beat the current winners (and given the compiler changes, you may well be able to) you'll still come out ahead in the process. As for the clean entry though, it no doubt relies heavily on uniqueness typing and so is secretly mutating like crazy under the hood. Cheers, S. On Tue, May 13, 2008 at 12:26 AM, J C [EMAIL PROTECTED] wrote: On Mon, May 12, 2008 at 4:38 AM, Richard Kelsall [EMAIL PROTECTED] wrote: Hello JC, I think you've set yourself a challenge there :) Welcome to Haskell programming. Taking a Shootout entry and playing with it is a great way to learn Haskell. The Shootout provides an example in your favourite previous language for comparison and a small well defined program with exact test results you can pit your wits against. Fame awaits you for a fast and beautiful entry. I'm still learning useful things from the Fasta benchmark. It's surprising how many interesting things you can discover in a small piece of code. It may be fun, but I don't think it would be meaningful. My code will be, most likely, slow, leaving some doubt as to whether it's slow because of the limitations of the compiler or my inexperience. On the other hand, if the experts can't help using malloc, unsafe*, global mutables and IO, I'll be able to conclude that this is probably what it takes to make Haskell run fast :-( ___ 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] Help me speed up my program... or back to the issue of memoization
I actually suspect that your supremum and infimum functions are the problem here -- they look like they might be accumulating thunks and blowing your stack. But beyond this, they're also o(n) for what could be effectively an o(log n) operation at the least, if you used ordered sets. I'd start improving performance here with some profiling, and then some strictness annotations, and then go from there. See http://www.haskell.org/haskellwiki/Performance for a whole bunch of good tips. --Sterl On Mon, May 5, 2008 at 11:57 AM, Kirill Kuvaldin [EMAIL PROTECTED] wrote: Hello, I wrote a program in haskell that works with lattice finite automata (the generalization of notion of finite state automata). Let me post the source code as it is not that long... The problem is that my algorithm that computes the run (see function fun) of an automaton on the given word is not very optimal and takes a lng time as the input word gets larger... (e.g. try this one run m3 11101101110001010101 ) Due to the nature of every haskell function being a referentially transparent, I think I could have speeded up its performance using memoization. I've read the page on haskell wiki (http://www.haskell.org/haskellwiki/Memoization) but it didn't help me because it looks I have to modify the actual function source code to make use of memoized values. What I'm looking for is a kind of a general solution (say, silver bullet :) ) so that I will be able to use my function like new_run = memoize run and the results of the new_run get automatically memoized. Probably it makes sense to memoize deltaext func as well. Is that possible to do that in Haskell?? Thanks a lot! Kirill === SOURCE CODE = -- data type for lattice data Lattice l = Lattice [l] -- set of lattice elements (l - l - l)-- supremum operation (l - l - l)-- infimum operation -- returns the lowest lattice element lattice0 (Lattice l s i) = l !! 0 -- returns the greatest lattice element lattice1 (Lattice l s i) = l !! ((length l)-1) -- supremum of 2 lattice elements sup (Lattice l s i) x y = s x y -- infimum of 2 lattice elements inf (Lattice l s i) x y = i x y supremum (Lattice l sup inf) [] = lattice0 (Lattice l sup inf) supremum (Lattice l sup inf) (x:xs) = sup x (supremum (Lattice l sup inf) xs) infimum (Lattice l sup inf) [] = lattice1 (Lattice l sup inf) infimum (Lattice l sup inf) (x:xs) = inf x (infimum (Lattice l sup inf) xs) inf3 (Lattice l s i) x y z = infimum (Lattice l s i) [x,y,z] --- data type for Lattice Automata (LA) data LA l state sym = LA (Lattice l)-- lattice [state]-- set of states [sym] -- alphabet (state - sym - state - l) -- fuzzy transition function (state - l) -- fuzzy initial state (state - l) -- fuzzy final state --- extended transition function deltaext :: (Eq state) = (LA l state sym) - state - [sym] - state - l deltaext (LA l states chars delta sigma0 sigma1) x [] y = if x == y then (lattice1 l) else (lattice0 l) deltaext la@(LA l states chars delta sigma0 sigma1) x (a:w) y = supremum l [ inf l (delta x a z) (deltaext la z w y) | z - states] -- runs the Lattice Automaton on the given word run la@(LA l states chars delta sigma0 sigma1) w = supremum l [ inf3 l (sigma0 x) (deltaext la x w y) (sigma1 y) | x - states, y - states] --- --- examples --- l3 = Lattice [0.0, 0.5, 1.0] max min where max x y = if x y then x else y min x y = if x y then x else y m3 = LA l3 ['a', 'b'] ['0', '1'] delta sigma0 sigma1 where delta 'a' '0' 'a' = 1 delta 'a' '0' 'b' = 0.5 delta 'b' '0' 'a' = 0.5 delta 'b' '0' 'b' = 1 delta 'a' '1' 'a' = 0 delta 'a' '1' 'b' = 1 delta 'b' '1' 'a' = 1 delta 'b' '1' 'b' = 1 sigma0 'a' = 1 sigma0 'b' = 0.5 sigma1 'a' = 0.5 sigma1 'b' = 1 ___ 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] Generic functional references for free, now!
Recent discussions inspired me to cook up the attached, which through
controlled abuse of various extensions gives functional references
for all records deriving Data and Typeable for free, with no template
haskell necessary. Composition is fully supported, as is
overloading of standard record accessors. For the sake of
preserving at least mild sanity, the (.) operator is not overloaded,
and composition is instead provided via an overloaded `o`.
For anyone that doesn't mind the absurdity of how this is
implemented, it should be suitable for drop in use.
For those that do mind the absurdity, it nonetheless serves as a
proof-of-concept for how far Haskell's reflective capacities can be
pushed.
Cheers, and happy hacking,
Sterl.
Example usage:
data Test = Test {t1 :: Int, t2 :: Int, t3 :: String, t4 ::
InnerTest} deriving (Data, Typeable, Show)
data InnerTest = InnerTest {t'1 :: Int, t'2 :: Int, t'3 :: String}
deriving (Data, Typeable, Show)
testData = Test {t1 = 1, t2 = 2, t3 = foo, t4 = InnerTest {t'1 = 2,
t'2 = 3, t'3 = bar}}
*GenericFRef set t1 23 testData
Test {t1 = 23, t2 = 2, t3 = foo, t4 = InnerTest {t'1 = 2, t'2 = 3,
t'3 = bar}}
*GenericFRef set (t'1 `o` t4) 23 testData
Test {t1 = 1, t2 = 2, t3 = foo, t4 = InnerTest {t'1 = 23, t'2 = 3,
t'3 = bar}}
*GenericFRef update (t2) (\x-x*x) testData
Test {t1 = 1, t2 = 4, t3 = foo, t4 = InnerTest {t'1 = 2, t'2 = 3,
t'3 = bar}}
*GenericFRef update (t'2 `o` t4) (\x-x*x) testData
Test {t1 = 1, t2 = 2, t3 = foo, t4 = InnerTest {t'1 = 2, t'2 = 9,
t'3 = bar}}
p.s. I have a nagging sensation that somebody may have done this
before, although I can't trace the source.
GenericFRef.hs
Description: Binary data
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stronger STM primitives needed? Or am I just doing it wrong?
-- non-primitive retryUntil: retryUntil v p = do x - readVar v unless (p x) retry broken2 = atomically $ do (v1, v2) - expensive_computation :: STM (TVar Int, TVar Int) retryUntil v1 ( 50) x - expensive_computation2 :: STM Int retryUntil v2 ( x) If v1 succeeds and v2 fails, then v1 changes to some other value 50, I am sure that the STM runtime as it stands now will re-run expensive_computation2. But expensive_computation2 is in STM. This means that it *should* be rerun, no? Between the first run and the retry, the result of expensive_computation2 may well have changed. If it doesn't get rerun, then we may have violated another transactional integrity constraint unknowingly. STM transactions should either happen once, or not at all. But if expensive_computation2 is not rerun, there's the possibility of spooky action at a distance effects, as I understand it? A more specific solution would be to build a memo- table (either with a CAF or via either TVars or MVars) structure into expensive_computation2 such that if it is rerun with the same TVar input, its work doesn't need to be recomputed. --S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] ANNOUNCE: Galois web libraries for Haskell released
* feed Interfacing with RSS (v 0.9x, 2.x, 1.0) and Atom feeds http://hackage.haskell.org/cgi-bin/hackage-scripts/package/feed Curious how well this handles malformed feeds -- i.e. is it strict in its parsing, or casual and tagsoup-like? Thanks, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [web-devel] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
In a sense, the CGIT interface provided by Network.CGI already is a sort of halfway implementation of what we're discussing, no? I'd be interested in approaching this from the other way -- specifying exactly what CGIT doesn't provide and therefore what folks want to see. As far as I can tell, the main issue with CGIT is that it doesn't handle streaming/resource issues very well. The main innovation I see provided here is the enumerator interface, which is a very nice and flexible approach to I/O and provides a way to handle comet cleanly to boot. Since the application type as proposed is Env - IO (Code, Headers, ResponseEnumerator), what we're really getting is almost an equiv. (modulo enumerators) of unwrapping CGIT IO CGIResponse with a run function. So what we lose is the ability for all our nicely named record accessors and functions to be shared across frameworks -- i.e. the flexibility a monad transformer *does* provide. So my question is if we can somehow preserve that with an appropriate typeclass. I'd ideally like to see this engineered in two parts -- a cgit-like typeclass interface that allows access to the environment but is agnostic as to response type, so that comet-style and other apps that take special advantage of enumerators can be built on top of it as well as apps that simply perform lazy writes; and the lower-level enumerator interface. This ideally would let the higher-level interface be built over any stack at all (i.e. STM-based as well, or even a pure stack), while the lower level interface that calls it is some glue of the given constant type in the IO monad. This would be of great help to hvac. There's also the fact that this could be designed ground-up with greater bytestring use, but that doesn't seem immense to me. Outside of this, I'm not quite sure what else CGIT lacks. I'm with Chris Smith's arguments as to the headers question, and it seems to me that dicts are best done using MVar-style primitives. I'm a bit at sea as to why the queryString is here just represented as a bytestring -- is it seriously an issue that some apps may want to use it other than in the standard parsed way? Is the idea here that lib functions would fill in and be shared among frameworks? On the other hand, seperating GET and POST vars is a good idea, and its a shame that CGIT doesn't allow this. The openness here seems in part based on the desire to keep different forms of file upload handling available. However, the work that oleg did with regards to CGI also seems promising -- i.e., rather than using an enumerator, simply taking advantage of laziness to unpack the input stream into a lazy dictionary. Regards, S. On Apr 13, 2008, at 7:59 AM, Johan Tibell wrote: Good day hackers, The Python community have been successful in standardizing an interface between web server and applications or frameworks resulting in users having more control over their web stack by being able to pick frameworks independently from web servers, and vice versa. I propose we try to do the same for Haskell. I've written half a draft for a Haskell version of Python's PEP 333 [1]. If you're interested in taking part in this effort please read through the Python spec first (as it is way more complete and you can understand this proposal better by reading it, I've skipped some important issues in my first draft) and then go read the Haskell spec [2]. I'm particularly interesting in feedback regarding: * Doing in this way won't work as it violates HTTP/CGI spec part X, Y and Z (the Python spec takes lots of things from the CGI spec including naming and semantics). * My server/framework could never provide/be run under this interface. * This interface has bad performance by design. * Using a different set of data types would work better. The spec needs to be extended to cover all the corners of HTTP. Some parts need to be motivated better. It is easier for me to motivate things if people would tell me what parts are badly motivated. Note: I'm open to a complete rewrite if needed. I'm not wedded to the current design and/or wording. In fact parts of the wording is borrowed from the Python spec. The parts with bad grammar are all mine. 1. http://www.python.org/dev/peps/pep-0333/ 2. http://www.haskell.org/haskellwiki/WebApplicationInterface -- Johan ___ web-devel mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/web-devel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Web server libraries
Yipe. It's just been pointed out to me that the hvac repo was missing a key file. I just committed it and tried a fresh pull and build, and it seems to work properly now. Apologies to all who couldn't get it working. Regards, Sterl. On Fri, 28 Mar 2008, Sterling Clover wrote: While hvac, which I announced here recently, is not yet ready for primetime, so to speak, you may want to take a look at it -- with a few tweaks it should match your specs. (darcs get http:// community.haskell.org/~sclv/hvac/http://community.haskell.org/%7Esclv/hvac/ ) [...] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Web server libraries
While hvac, which I announced here recently, is not yet ready for primetime, so to speak, you may want to take a look at it -- with a few tweaks it should match your specs. (darcs get http:// community.haskell.org/~sclv/hvac/) It does include some templating, though you don't have to use it significantly, but then again, I find it hard to automate data validation without it (how else do you control showing results?), and it does allow for session support, although it isn't necessary. It is, however FastCGI based and has built-in connection pooling. It should theoretically be able to speak to any database that HDBC speaks to, although it does need a little work (here's the modification issue) to ensure the strong atomicity constraints work properly with anything but sqlite. Additionally, the validation functionality should be very powerful and intuitive, and the control flow combinators equally so, which are also written to parse RESTful parameters as part of url strings as well. Not sure what you mean by marshalling to-from Haskell types -- the validation provides one side of it, and on the other, as you well know, HDBC gives a very convenient way to deal with the SQL end :-) The less tested/more dicey parts of hvac are all those that deal with atomicity and caching, and if you're not relying on those, then that shouldn't be an issue either. And the only questions there, in my mind at least, are to what degree running everything out of STM (i.e. optimistically) could lead to problems in high-contention environments -- so again, possibly not an issue for your needs in any case. As for event model -- hvac tries to be nonjudgemental, though it is request rather than continuations-based and is mainly designed to be REST. One could implement a conversations layer over sessions without too much work -- alternately, control flow can be parameter based, much as one would do in plenty of other web frameworks. Finally, although the atomic stuff is what makes hvac fun, one could rip out either the controller or validation sections without too much work and act directly over FastCGI. On its own even, the FastCGI lib isn't perfect, but as Paul Brown noted, its not too hard to build a few nice structures on top of it to handle whatever you throw at it. Regards, Sterl. On Mar 27, 2008, at 3:26 PM, John Goerzen wrote: Hi again, I'm currently working on a project that has a Web interface to data stored in a SQL database. I wrote this thing in WASH a few years back. Overall, this has been acceptable, but the non-Haskell-adepts around here run away screaming from the code. Not only that, but we don't get control over the names of the form elements, which can make interacting with other software that sometimes plonks users down halfway through the process -- well, interesting. Also, WASH supports nothing better than CGI, which is a big minus when talking to SQL databases. What I really want is some sort of simple tool that supports FastCGI or some such, has basic support for form data input validation and marshalling to/from Haskell types, and basic control flow. I don't need, or really particularly want, something that uses hs-plugins to compile pages on demand (I'm using Haskell for it's static safety, after all). Nor do I need fancy templating systems or session support (we use HTTP auth and are fine with it for now.) So I've looked around a bit at the landscape. Any recommendations? I've found these: HSP: big on dynamic pages. I don't want to make my webserver able to compile Haskell code. Develop code, compile, test, make sure it's right, then push to production every 6 months around here. WASH: Pretty much the right niche, but the event model is hard to use. HAppS: Frankly it is a big collection of confusing packages to me. What documentation exists doesn't seem to be relevant anymore, and it seems to be designed to not use a SQL database. FastCGI: Relies upon CGI for a good part of processing. Does not seem to have any form data validation support built in. Thanks again, -- John ___ 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] ANN (2 Libs) -- hvac 0.1b, a lightweight web framework and HStringTemplate 0.3
1) hvac 0.1b: transactional, declarative framework for lightweight web applications. 2) HStringTemplate 0.3 1) hvac 0.1b hvac (short for http view and controller) has been my project for the last little while, and is finally in a fairly usable state, so I'm opening up the repo (darcs get http://community.haskell.org/~sclv/ hvac/) for folks to play with and to get some feedback. While not quite yet ready for hackage, the package as provided should be fully cabal installable. Documentation is available at http:// community.haskell.org/~sclv/hvac/html_docs/hvac/ The aim of hvac is to provide an environment that makes the creation of lightweight fastcgi based web applications as simple as possible, with an emphasis on concise, declarative style code, correct concurrent transactional logic, and transparency in adding caching combinators. There are two included example programs, naturally neither of which is feature complete. They share a common login module of about 50 lines of code, excluding imports, templates, and database schema. The first program is a classic, greenspun-style message board with basic login functionality. It totals roughly 40 lines and tends to use just under 4mb of resident memory on my system. The second is a wiki based on Pandoc and the PandocWiki code. The code totals roughly 30 lines (rendering borrowed from PandocWiki aside) and uses about 5mb of memory. hvac processes all requests in the STM monad, with some bells attached to properly interleave STM with session, database and filesystem operations such that they all conceptually occur together in a single transaction per request. Currently it is only fully tested with sqlite, but it should operate, modulo a few tweaks, with any database accessible via HDBC. hvac is particularly designed to use the HStringTemplate library as an output layer, in a simple declarative fashion. As the StringTemplate grammar is explicitly sub-turing, this ensures a clean separation of program logic from presentation, while providing a nonetheless fairly powerful language to express typical display tasks. The included cache combinators, still experimental, should allow a simple and fine-grained control over the level of caching of various disk-bound operations. Phantom types are used to ensure that no functions that modify state may be cached. To give a flavor of hvac code, the following is the complete (twenty lines!) source of the wiki controller (due to sql statements, some lines are rather long): wikiController tmpl = h |/ login * login_plug tmpl | (h |/ wiki |\\ \pageName - h |// POST * withValidation [ (contents, return) ] (\ [contents] - do pageId - selectVal id from pages where name=? [toSql pageName] maybe (addErrors [(Login,must be logged in.)] continue) (\user - case fromSql pageId of Just (_::Int) - execStat insert into page_hist (pageId,contents,author) values(?,?,?) [pageId, toSql contents, toSql . userName $ user] Nothing - do execStat insert into pages (name,locked) values(?,?) [toSql pageName, toSql (0::Int)] pid - selectVal max(id) from pages [] execStat insert into page_hist (pageId,contents,author) values(?,?,?) [pid, toSql contents, toSql . userName $ user]) = getSes continue) | do pageId - selectVal id from pages where name=? [toSql pageName] (join $ renderf (tmpl showPage) (pageName, pageName) $ pageContents |= selectRow * from page_hist where pageId=? order by time desc limit 1 [pageId] )) | (redirect . ( ++ /wiki/Index) = scriptName) Future directions for work on hvac include: Stress testing for correctness of transactional logic and benchmarks. Exploration of various efficiency tweaks. Unit tests. Further development of the cache combinator API. Improvement of the example apps and addition of a few others (a blog maybe). Expansion of the library of validator functions. Exploration of transferring hvac to the standard FastCGI bindings (currently it uses a custom modified version to work properly with STM). Improvement of the database layer, particularly with regards to common paging functions. Creation of a set of simple combinators for generating CRUD (create read update delete) pages. Creation of a minimal set of standard templates (maybe). 2) HStringTemplate 0.3.1 This release of HStringTemplate (up now at Hackage) fixes a number of bugs pointed out to me by its small but growing user base (thanks, cinema, elliottt!) ranging from the minor (a particular two-level iteration pattern wasn't working properly) to the truly irritating (poor handling of file groups). It's still unfortunately skimpy on the
Re: [Haskell-cafe] Problem making a program in ghc
This answer may be way off base, but if differences appear between ghci and compiled versions, I've often found its as simple as remembering to compile with the -threaded flag. The ghci runtime is threaded by default, as I understand it, while compiled binaries are not, and IO operations will block in very different fashions (i.e. in their own thread, or stalling the entire app) depending on the runtime. Regards, sterl. On Mar 13, 2008, at 3:47 PM, Adam Langley wrote: web application), I have a log that confirms that the response arrives correctly. I hate to see any requests for help go unanswered here, but this one might be tough. I think you need to give some more information, otherwise the suggestions are going to be very general. Can you put the Haskell source code on a website somewhere and link to it. Since it's a network service, an example request and reply might be good to include. In general, you should check that you are correctly flushing your connection. If you are using Handles to interface to the network, they can buffer the response. hFlush[1] may need to be called when you have finished generating it. [1] http://haskell.org/ghc/docs/latest/html/libraries/base/System- IO.html#v%3AhFlush AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exception handling when using STUArray
On the other hand, there are lots of issues that can be worked on here, foax! While tools like the one is ndm is working on seem to offer a way forward, at the moment, there's no standard way that I know of besides inspection to determine if code might throw an exception, and this is particularly the case with the dreaded lazy IO of prelude functions. And as per a recent discussion on libraries, it's still a royal pain to catch IO exceptions in monads with an IO base. And then, of course, there's the issue of exceptions in ST or STM which have similar issues. All this could be solved if we standardized on some version of gcatch over MonadBase or a variant. The machinery just hasn't been fully written yet, although Control.Monad.Error is, sort of, a start. And of course, using head or any other partial functions in production code without a great deal of care is a really *bad idea*, but the prelude sort of locks us into having them at least. Tutorials and examples might be better served emphasizing why these things are dangerous, and common idioms for avoiding them... Regards, sclv On Mar 9, 2008, at 3:09 AM, Brandon S. Allbery KF8NH wrote: On Mar 9, 2008, at 1:54 , Don Stewart wrote: donn: This seems to me one of the disappointments of Haskell - not just a detail that was handled in an awkward way, but a fundamental flaw. I'm not talking about ArrayException, whatever that is, but the notion that errors encountered in functional code mustn't be handled as exceptions. I don't understand this complaint -- you can handle all these with Control.Exception. xmonad catches all these things for example, in user code, to prevent poorly written modules throwing a pattern match exception, or calling 'error' and making the window manager unstable. Handling exceptions generated from pure code is just another part of making systems more robust -- and of course you can do it in Haskell. I'm unsure what the complaint here is as well. That exceptions must be handled in IO: an exception is, by definition, an unexpected condition. These simply can not exist in the deterministic paradigm of pure code, therefore you must be in IO (home of all things nondeterministic) to catch them. That it is preferred to handle known cases without using exceptions: staying completely pure is cleaner, and gives you more control over what goes on. And enables swapping in different mechanisms to react to failure; note how using the Monad instances of Maybe, Either, or [] allows you to decide how to handle failure (and [] allows you to support multiple possible results as well, while Maybe and Either will stop processing at the first. Basically, the Haskell way is to make as much as possible pure and minimize the intrusion of IO. Exceptions necessarily complicate this, so are when possible avoided in favor of pure alternatives, which are considered better style --- but they are available in IO if needed. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon university KF8NH ___ 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] Haskell Perl architecture question
Not quite sure what you're looking for? Do you mean that you're looking at the possibility of setting such a system up, or that you're looking at a system that is already set up and trying to grok how it works? If the latter, you might want to get a sense of how ghc manages its packages and dependencies at http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html, which also includes links to the information on the cabal infrastructure. If that's not your question, then that material might either be too basic for you or too offbase. The GHC manual is generally very well documented in terms of describing package infrastructure, the linking process and the runtime environment, etc. If, rather, you're looking at issues more directly related to Haskell/web stuff, you might want to specify what exactly you're looking to do, as there are a number of solutions in use rather than a single, e.g., mod_haskell. If it's an established system, then either it will be using a haskell webserver (WASH, HAppS, etc) or it will be written using the CGI/FastCGI libraries. If you're looking to set up a system, then of course it depends what you want to do with it... for lightweight solutions, a combination of FastCGI and HDBC seems to be pretty popular at the moment. In all these cases, note that generally you'll be working with Haskell binaries, rather than scripts, and that such binaries should either be built on the system in question directly, or on one with the same architecture. Hope that helps, Sterl. On Tue, Mar 4, 2008 at 2:06 PM, Marty Landman [EMAIL PROTECTED] wrote: I'm looking at a production system running Perl Haskell in an Apache environment and trying to get a handle on the system architecture. Are there online resources anyone could recommend I start with? Thanks in advance, Marty -- Marty Landman, Face 2 Interface Inc. 845-679-9387 Drupal Development Blog: http://drupal.face2interface.com/ Free Database Search App: http://face2interface.com/Products/FormATable.shtml ___ 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] Issues with hsql-sqllite build; errors from the hackage download
Just noticed, by the way, that haskelldb doesn't build correctly because it still hasn't updated the cabal for the base split. On the other hand, the development repo (which is 0.11 -- 0.10 is on hackage) builds fine. Are the maintainers planning to get an updated version on hackage? --S On Feb 2, 2008, at 10:16 AM, Duncan Coutts wrote: On Fri, 2008-02-01 at 17:05 -0500, bbrown wrote: There seems to be an issue with the hsql-sqlite3. Anyone have a fix. Should I use what is from darcs? HSQL is currently unmaintained. Frederik Eaton was considering taking it over: http://www.nabble.com/HSQL-defunct--td14978532.html Gentoo has a fix: http://haskell.org/~gentoo/gentoo-haskell/dev-haskell/hsql-sqlite/ hsql-sqlite-1.7.ebuild The code in src_unpack() is replacing the Setup.hs with a default copy and then adding 'extra-libraries: sqlite3' to the .cabal file. Pretty straightforward. This does assume that you have sqlite3 installed in the default global location. You may also like to consider alternatives like HDBC-sqlite3. Duncan ___ 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] ANN: HStringTemplate 0.2
HStringTemplate is a general purpose templating system, geared especially towards HTML and based on Terrence Parr’s Java library. On Hackage at: http://hackage.haskell.org/cgi-bin/hackage-scripts/ package/HStringTemplate-0.2 Development version at: darcs get http://code.haskell.org/ HStringTemplate/ Haddocks at: http://code.haskell.org/HStringTemplate/dist/doc/html/ HStringTemplate/Text-StringTemplate.html Additional documentation on the grammar at: http://www.antlr.org/wiki/ display/ST/StringTemplate+3.1+Documentation as well as in some posts at http://fmapfixreturn.wordpress.com Lots of cleanup, lots of additions, hopefully this is an extremely usable release. Still no group or interface files, but I suspect that those are mainly useful for code-generation, which seems like something Haskell programmers would want to use something other than a templating system for in any case. On to the good stuff: * Now on hackage! * Generics. Not one but two types. One set of simple bindings for the standard Data class, and one for syb-with-class. (Alex Drummond’s RJson library, which is really cool, was very helpful in figuring out how to do this). * A withContext method that turns any set of name-value bindings into the context for a StringTemplate. Along with the syb-with-class bindings, this should make for relatively seamless interoperability with HAppS. * Lots of other additional bindings for working with standard time formats, numeric types, etc. * Encoders. A standard mechanism for HTML-escaping strings (or javascript-escaping, or urlencoding them, or etc.) that A) ensures it happens uniformly and B) ensures it happens no more than once. * Improved pretty printing support, eliminating corner-cases where wrapping did not occur. * Creation of directory groups is now done properly in the IO monad, with caching functionality moved to the scarily-named unsafeVolatileDirectoryGroup. * 80% Top-Level testing coverage in the base. (And more to come, but I only have so much time). And of course, patches and feedback always welcome. --Sterl___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why functional programming matters
On Jan 24, 2008, at 6:04 PM, Evan Laforge wrote: Java's just wordy like that. In python you'd say max(foos, key=lambda x: x.update_time). Python / perl / ruby / smalltalk have had first class functions forever, so those are basically already in the mainstream. They may impress a java or C programmer who's never seen a dynamic language. It might reassure a python programmer that static typing doesn't preclude using closures and doesn't mean c++ or java style huge long declarations. So you probably need some other examples to convince python programmers that their language didn't just cherry pick all the great ideas and that there are none left. Actually, citing the degree to which python, perl, ruby etc. have adopted some of the basics of functional programming seems like a clear win. The popularity of a book such as Higher Order Perl almost begs the question -- how much better would it be if folks were doing this in a language designed to make such things efficient from the get-go? While I'm not knowledgeable enough to give the inside scoop about Goldman, they're a good example in that they're doing some very functional stuff, especially frp-related for lots of their main worldwide pricing systems, but mainly doing this in languages that aren't purely functional. Here's one blog post that at least demonstrates that this is happening: http://www.kimbly.com/blog/ 000505.html As I understand it, since they're working on a massively distributed architecture (literally worldwide), functional techniques are not only a huge win, but unavoidable. Along the lines of citing Higher Order Perl the popularity of C+ + template metaprogramming might be a neat way to make the pitch as well. Drawing out how template metaprogramming is a form of functional programming might be a bit much for the talk. But, still, briefly mentioning that is widely recognized as helping to make things clean and efficient, although in a massively verbose and sometimes confusing way, and that more purely functional languages can do the same thing in a nicer way might again be a way to make the point. The neatest piece of simple Haskell code that I can think of, by the way, is the oft-cited Hamming sequence. There's so much going on in it, the manner it exploits laziness and infinite streams, and so forth. --S ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need help with Parsec
Here's a handy simple function I've found very useful. You'll obviously also need to import Debug.Trace: pTrace s = pt | return () where pt = try $ do x - try $ many1 anyChar trace (s++: ++x) $ try $ char 'z' fail x It could perhaps be cleaner, but it does the job for me fine. Just insert a line like pTrace label anywhere in your parsing functions and whenever parsec hits that line you get a nice line of output: label: rest of string to be parsed This tends to help track down just where your code goes wrong. Try works like it should in my experience, but that doesn't necessarily mean it works how you expect. Regards, s On Jan 20, 2008, at 12:12 PM, Nicu Ionita wrote: Hi, I'm playing since a few hours with Parsec and trying to write a small html (fragment) parser, but I'm stuck in a point which I really can't understand. The problem seem to be either in parseProperCont or in closing (see code below). It looks like closing does not work (but it is a very simple function!) or (also hard to believe) function try from Parsec has some problems. Anyway I get this answer: Prelude ParseSHtml pf parseHtmlFrg ptest.txt Left ptest.txt (line 5, column 2): unexpected / expecting element name when I'm parsing this file: div id=normtext one line with breakbr / another line br /br / Mail: a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a /div with this code (sorry for the longer mail): import Text.ParserCombinators.Parsec hiding (label) import Text.XHtml.Strict -- Helper function: parse a string up to one of the given chars upTo :: [Char] - Parser [Char] upTo ds = many1 (noneOf ds) parseHtmlFrg :: Parser Html parseHtmlFrg = do many space choice [parseElem, parseText] ? html fragment parseElem :: Parser Html parseElem = do en - parseElTag many1 space (ats, cnt) - restElem en return $ compElem en cnt ! ats ? html element -- Compose a html element from tag name and content compElem en cnt = if isNoHtml cnt then itag en else tag en cnt parseElTag :: Parser String parseElTag = do char '' en - elemName return en ? element tag elemName :: Parser String elemName = many1 lower ? element name restElem :: String - Parser ([HtmlAttr], Html) restElem nm = do ats - parseAttList ht - (restElNoCont | restElCont nm) return (ats, ht) ? ( or / to close the tag ++ nm) -- Rest element with no content restElNoCont = do char '/' char '' return noHtml ? / -- Rest element with content restElCont nm = do char '' many space els - parseProperCont nm return $ concatHtml els ? element with content -- Parse closing tag or proper content(s) parseProperCont :: String - Parser [Html] parseProperCont nm = try (do closing nm return [] ) | (do h - parseHtmlFrg hs - parseProperCont nm return (h:hs) ) -- | return [] ? proper element content closing nm = do char '' char '/' nm1 - elemName char '' if nm1 == nm then return () else fail $ nm ++ , encountered ++ nm1 ? (closing of ++ nm) -- Parse a html attribute parseAttr :: Parser HtmlAttr parseAttr = do at - many1 lower char '=' va - parseQuote many space return $ strAttr at va ? Attribut parseAttList = many1 parseAttr | return [] ? attribute list -- Parse a quoted string parseQuote :: Parser String parseQuote = do char '' cs - upTo [''] char '' return cs -- Parse a text element parseText :: Parser Html parseText = do s - upTo return (stringToHtml s) ? some text -- For tests: pf p file = parseFromFile p file Nicu ___ 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] Re: STM in F#
B-but, (and here's the ironic part), launchMissile is only idempotent it the missile is atomic. --S 2008/1/18 Brent Yorgey [EMAIL PROTECTED]: On Jan 18, 2008 4:59 AM, Ketil Malde [EMAIL PROTECTED] wrote: apfelmus [EMAIL PROTECTED] writes: I imagine this can only ease the process of learning Haskell, and broaden the base of possible Haskellers, as more people on using .NET stuff become familiar with modern typed FP. There's a reason the STM monad hatched in Haskell: how does the above STM in F# handle side-effects like launchMissile ? If you read the comments at the bottom, it seems it does not. Expect an arbitrary number of missiles (although the final effect of destroying the target city will perhaps be the same). That's only because launchMissile is idempotent. -Brent ___ 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] ANNOUNCE: HStringTemplate -- An Elegant, Functional, Nifty Templating Engine for Haskell
Graham, I'm sort of playing fast and loose with referential transparency here, as I actually am with stringTemplateFileGroup as well. They both use unsafeIO to do what they want, and in corner cases could give silly, though not dangerous results (i.e., in the sense of being hazardous to your program, these calls are substantially less worrisome than head). stringTemplateFileGroup could conceivably be in IO, if it was strict in reading all the files in the directory it was passed, but cacheSTGroup would force every access to a group to take place in IO, which would make the library somewhat of a pain to work with. My semi-justification for this is that its referentially- transparent-enough for most use cases, in that just about the only thing one would be doing with a StringTemplate result would be outputting it again in some form anyway. In my experience, being able to hot-edit templates for a live app is a key benefit of a templating system, and forcing everything into IO to get that seems like an undue burden on end-users. On the other hand, I'm also open to implementing an IO API that's safe and renaming the current functions to something somewhat scarier, or moving both them and their IO equivs to distinct modules so that end users could choose which to import. A number of options seem reasonable here. --Sterl. (btw, I fixed the typo you emailed me about in the repo, and also made a few other changes I documented at http:// fmapfixreturn.wordpress.com/) On Jan 16, 2008, at 8:19 PM, Graham Fawcett wrote: On Jan 14, 2008 2:47 AM, Sterling Clover [EMAIL PROTECTED] wrote: HStringTemplate is a port of Terrence Parr's lovely StringTemplate (http://www.stringtemplate.org) engine to Haskell. This is very cool. Your docs describe a function, cacheSTGroup: cacheSTGroup :: Int - STGen a - STGen a Given an integral amount of seconds and a group, returns a group cached for that span of time. Does not cache misses. How does this work without breaking referential transparency? Shouldn't it be in the IO monad if it is time-dependent? Graham ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: HStringTemplate -- An Elegant, Functional, Nifty Templating Engine for Haskell
I'm absolutely planning to get it up there, but it needs a bit more work first. Just today, gwern sent a bunch of very nice patches that cleaned up some -Wall messages, and fixed a build issue with 6.8. And then, thanks to an email from Martin Lütke, I realized that I had foolishly not exported a function to query groups, because I was too worried about functions to compose them! So yeah, letting your baby out into the world is a bit scary, but everyone's been quite helpful and supportive so far, and hopefully I'll feel ready to get it on hackage in the next week or two. (Of course, after that, I'm now puzzling over the best typesafe ways to represent html entity encoding and url escaping, planning to pull together some more documentation on all the loveliness of the stringtemplate grammar, there are more quickcheck properties to be written, you know.. the usual. :-) ) --S On Jan 14, 2008, at 3:09 AM, Don Stewart wrote: s.clover: HStringTemplate is a port of Terrence Parr’s lovely StringTemplate (http://www.stringtemplate.org) engine to Haskell. It is available, cabalized, at: darcs get http://code.haskell.org/HStringTemplate/ Looks very useful! Will this be on hackage.haskell.org soon? I can't wait to: cabal install HStringTemplate :) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: HStringTemplate -- An Elegant, Functional, Nifty Templating Engine for Haskell
HStringTemplate is a port of Terrence Parr’s lovely StringTemplate (http://www.stringtemplate.org) engine to Haskell. It is available, cabalized, at: darcs get http://code.haskell.org/HStringTemplate/ As interest has grown in using Haskell for web applications, there has been an increasing buzz about the need for a good templating engine in Haskell. Why might we need this? After all, Haskell has lovely combinator libraries for generating HTML programmatically, enforcing good form through its type system. But sometimes, we don’t want well-formed HTML. We want the ugly stuff that floats around to deal with eight varieties of browser incompatibilities and the latest silly ajax trick. Or sometimes we’re working with a team of graphic designers, and they want to work in almost-HTML. Or sometimes we just want to be able to change the design of a web application on the fly, completely independent of our program logic, and of, heavens forbid, recompiling and possibly messing with a live application. So template engines are popular, and indeed, considered a key part of most web frameworks out there. One problem — they’re mainly awful, imperatively-conceived behemoths that capriciously mix program logic with display and, consequently, entail a great deal of overhead. Enter StringTemplate, a nifty and fairly-well developed template format that’s both pure and functional, and therefore pretty much the only one of its kind. Indeed, it also seems to be getting heavy use in code generation because its paradigm maps neatly to traversing parse-trees. HStringTemplate is not feature-complete, and indeed is only at version 0.1. But it should implement pretty much everything in the standard StringTemplate 3.0 grammar, only nicer, because it’s in Haskell. There are scads of different recursive constructs and ways to handle inclusion and inheritance. Furthermore, HStringTemplate handles conditionals, and sports also a very Haskellish implementation of custom rendering. Templates can be constructed that return strings, ShowSs, bytestrings, or even pretty printer Docs that handle wrapping, indentation, and fill elegantly. Even better, these templates are parsed and compiled only once, after which point there isn't a syntax tree anymore, just a function that operates on the environment of attributes that have been passed to it. Where I take it from here depends in part on what sort of response I get, so patches, gripes, API comments and feature requests are all more than welcome. Please note that I'm still working in 6.6.1. Everything should be in place to compile properly with the base split, but if it isn't, again, patches more than welcome. Full announcement at: http://fmapfixreturn.wordpress.com/ --SC___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: PROPOSAL: Some more 'Applicative' combinators
The more general question, which stems from a certain degree of ignorance on my part, is what uses folks have found for Alternative at all outside of parsing. --S On Jan 8, 2008, at 4:43 AM, apfelmus wrote: Iavor Diatchki wrote: Bryan O'Sullivan wrote: Why not make the task specificity clearer, with a separate Control.Applicative.Parsing module? +1 Now _this_ would definitely suggest that they are only good for parsing which would be misleading. Would it? I mean, I currently don't know a second use case for them. Preferably, the names like skipMany , endBy , sepBy etc. should still make sense in the new context. Regards, apfelmus ___ Libraries mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/libraries ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Missing join and split
So a simple thing occured to me today. Rather than worry about the correct behavior for a join/split pair, we should just add unintercalate to the library. A bit verbose as a name, but at least there's no ambiguity. --s On Dec 29, 2007, at 2:18 PM, David Roundy wrote: On Fri, Dec 28, 2007 at 04:24:38PM +0100, Benja Fallenstein wrote: On Dec 28, 2007 3:55 PM, David Roundy [EMAIL PROTECTED] wrote: On Dec 28, 2007 9:51 AM, Benja Fallenstein [EMAIL PROTECTED] wrote: If you use intercalate to join, I would presume that you would want to use an inverse of it to split. I'd write it like this: Of course, there is no inverse to intercalate Right; I misspoke. What I meant was that you would want a split such that intercalate a (split a xs) = a for finite, total (a,xs) (and, since it's achievable, even for infinite xs). Of course, (split a xs = [xs]) satisfies that, but if we add the requirement that split is also supposed to do its job :-) then I think split is fully specified except for whether (split a [] = []) or (split a [] = [[]]). The latter seems better to me; e.g., it satisfies split a (x ++ a ++ y) = split a x ++ split a y Yes, the latter is what darcs' linesPS does. so if you want to use a logical approach, perhaps you'd want to define split first, and then define your join as the inverse of split. If your join comes out as being intercalate, I suppose it's six of one, half a dozen of the other :-) Well, your intercalate \n is not the same as unlines and the inverse of intercalate \n is not the same as lines, nor is its inverse (with ) the same as words. It is true that intercalate is the same as unwords, however. So it does seem like the prelude doesn't really give us any hints as to what would be a useful generic join/split pair. -- David Roundy Department of Physics Oregon State University ___ 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] FW: Treating command-line arguments as a Haskell expression
As the previous answers show, hooking dynamic evaluation, or a subset thereof, into Haskell is not a particularly easy task. If this is just a program to get up-and-running with understanding Haskell, probably best not to delve into this sorts of stuff? A simpler solution, albeit one which requires some boilerplate, would be to ensure that either all the functions you dispatch to call getArgs themselves (i.e. are of type IO ()) or simply take a list of remaining parameters (i.e. are of type [String] -IO ()) and then pull them out of either a list or a map. Something resembling this approach is, for example, here: http://haskell.org/haskellwiki/ Simple_unix_tools --S P.S. using Template Haskell to solve this would be a fairly interesting exercise as well, I suspect. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Importing Data.Char speeds up ghc around 70%
Here's the Prelude imports I see at the moment. Didn't chase down the dependencies in all the code initially and now I see that GHC.Show does import GHC.List. Still, I suspect this has something to do with fusion nonetheless. #ifdef __GLASGOW_HASKELL__ import GHC.Base import GHC.IOBase import GHC.Exception import GHC.Read import GHC.Enum import GHC.Num import GHC.Real import GHC.Float import GHC.Show import GHC.Err ( error, undefined ) #endif (from http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/Prelude.html) --s On Dec 22, 2007 4:44 PM, Stefan O'Rear [EMAIL PROTECTED] wrote: On Sat, Dec 22, 2007 at 04:40:00PM -0500, Sterling Clover wrote: I'm curious if you get the same performance difference importing GHC.Listinstead of Data.Char? I chased some dependencies, and Data.Char imports GHC.Arr, which in turn imports GHC.List, which provides a bunch of fusion rules pragmas that would probably optimize your (++) usage. If this is the case, not sure if its a bug or not, but all this will have to be thought through as more stream fusion is rolled out anyway, I suspect? --S The Prelude imports GHC.List, iirc. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHbYVTFBz7OZ2P+dIRAi02AJ41CyIVwCRLH2MU51Sc8Rjrtgxy+ACeL1m8 F2a0Id2PErsKgjOyggkT8Ig= =T0A3 -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Importing Data.Char speeds up ghc around 70%
I'm curious if you get the same performance difference importing GHC.Listinstead of Data.Char? I chased some dependencies, and Data.Char imports GHC.Arr, which in turn imports GHC.List, which provides a bunch of fusion rules pragmas that would probably optimize your (++) usage. If this is the case, not sure if its a bug or not, but all this will have to be thought through as more stream fusion is rolled out anyway, I suspect? --S ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
