- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] GSoC proposal: Units for GHC
by George Giorgidze 04 Apr '12

04 Apr '12

Implementing this proposal in GHC, as opposed to the library-only approach, would allow for generation of much more useful and user friendly error messages. I believe this aspect is important when it comes to type systems supporting physical units. Cheers, George > This sounds pretty cool and useful. How much of this can be implemented in a library and how much of this would need to be supported on a compiler level? Ideally, most of this would be solved on the library level.

1 0

ANNOUNCE: fast-tags-0.0.1
by Evan Laforge 04 Apr '12

04 Apr '12

A while back I was complaining about the profusion of poorly documented tags generators. Well, there is still a profusion of poorly documented tags generators... I was able to find 5 of them. So, that said, here's my contribution to the problem: fast-tags, haskell tag generator #6. Why not use one of the other 5? Two of them use haskell-src which means they can't parse my code. Two more use haskell-src-exts, which is slow and fragile, breaks on partially edited source, and doesn't understand hsc. Then there's the venerable hasktags, but it's buggy and the source is a mess. I fixed a bug where it doesn't actually strip comments so it makes tags to things inside comments, but then decided it would be easier to just write my own. fast-tags is fast because it has a parser that's just smart enough to pick out the tags. It can tagify my entire 300 module program in about a second. But it's also incremental, so it only needs to do that the first time. I have vim's BufWrite autocommand bound to updating the tags every time a file is written, and it's fast enough that I've never noticed the delay. It understands hsc directly (that's trivial, just ignore the # lines) so there's no need to run hsc2hs before tagifying. The result is tags which are automatically up to date all the time, which is nice. If people care about lhs and emacs tags then it wouldn't be hard to support those too, and at that point I could replace hasktags and we'd be back down to 5 again. But I'm not even sure anyone uses hasktags, since surely someone would have noticed that comment bug. Anyway, it's been working great for me for a couple weeks so I uploaded it to hackage: http://hackage.haskell.org/package/fast-tags

5 9

A Modest Records Proposal
by Gershom B 03 Apr '12

03 Apr '12

The records discussion has been really complicated and confusing. But I have a suggestion that should provide a great deal of power to records, while being mostly[1] backwards-compatible with Haskell 2010. Consider this example: data A a = A{a:a, aa::a, aaa :: a -> A (a -> a)} data B a = B{aaa :: a -> A (a -> a), a :: A} Now what is the type of this? aaaa aaaaa a aa = aaaaa{a = a, aaa = aa} Using standard Haskell typeclasses this is a difficult question to answer. The types of aaaa for A and B do not unify in an obvious way. However, while they are intensionally quite distinct, they unify trivially extensionally. The obvious thing to do is then to extend the type system with extensional equality on record functions. Back when Haskell was invented, extensional equality was thought to be hard. But purity was thought to be hard too, and so were Monads. Now, we know that function existentionality is easy. In fact, if we add the Univalence Axiom to GHC[2], then this is enough to get function existensionality. This is a well-known result of Homotopy Type Theory[3], which is a well-explored approach that has existed for at least a few years and produced more than one paper[4]. Homotopy Type Theory is so sound and well understood that it has even been formalized in Coq. Once we extend GHC with homotopies, it turns out that records reduce to mere syntactic sugar, and there is a natural proof of their soundness (Appendix A). Furthermore, there is a canonical projection for any group of fields (Appendix B). Even better, we can make "." into the identity path operator, unifying its uses in composition and projection. In fact, with extended (parenthesis-free) section rules, "." can also be used to terminate expressions, making Haskell friendly not only to programmers coming from Java, but also to those coming from Prolog! After some initial feedback, I'm going to create a page for the Homotopy Extensional Records Proposal (HERP) on trac. There are really only a few remaining questions. 1) Having introduced homotopies, why not go all the way and introduce dependent records? In fact, are HERP and Dependent Extensional Records Proposal (DERP) already isomorphic? My suspicion is that HERP is isomorphic, but DERP is not. However, I can only get away with my proof using Scott-free semantics. 2) Which trac should I post this too? Given how well understood homotopy type theory is, I'm tempted to bypass GHC entirely and propose this for haskell-prime. 3) What syntax should we use to represent homotopies? See extend discussion in Appendix C. HTH HAND, Gershom [1] To be precise, 100% of Haskell 2010 programs should, usually, be able to be rewritten to work with this proposal with a minimal set of changes[1a]. [1a] A minimal set of changes is defined as the smallest set of changes necessary to make to a Haskell 2010 program such that it works with this proposal. We can arrive at these changes by the following procedure: 1) Pick a change[1b]. 2) Is it minimal? If so keep it. 3) are we done? If not, make another change. [1b] To do this constructively, we need an order. I suggest the lo mein, since noodles give rise to a free soda. [2] I haven't looked at the source, but I would suggest putting it in the file Axioms.hs. [3] http://homotopytypetheory.org/ [4] http://arxiv.org/ *Appendix A: A Natural Proof of the Soundness of HERP Take the category of all types in HERP, with functions as morphisms. Call it C. Take the category of all sound expressions in HERP, with functions as morphisms. Call it D. Define a full functor from C to D. Call it F. Define a faithful functor on C and D. Call it G. Draw the following diagram. F(X)----F(Y) | | | | | | G(X)----G(Y) Define the arrows such that everything commutes. *Appendix B: Construction of a Canonical Projection for Any Group of Fields. 1) Take the fields along the homotopy to an n-ball. 2) Pack them loosely with newspaper and gunpowder. 3) Project them from a cannon. In an intuitionistic logic, the following simplification is possible: 1) Use your intuition. *Appendix C: Homotopy Syntax Given that we already are using the full unicode set, what syntax should we use to distinguish paths and homotopies? At first, I thought we could avoid providing any syntax for homotopies at all. Haskell is a language with type inference, so we should just be able to infer paths and homotopies behind the scenes by adding homotopies to the type system. That's a very nice answer in theory. But in the real world, when we're writing code that solves actual problems, theoretical niceties break down. What if a user wants to use a nonstandard homotopy? Why should we stop them just because we're too lazy to come up with a good syntax? I then realized that we keep running out of syntax because we've limited ourselves to unicode. Instead, I propose we add a potentially infinite universe of identifiers: youtube videos. For example, the higher inductive type for a circle can be written as: homotopyType http://www.youtube.com/watch?v=dQw4w9WgXcQ where Base ::: http://www.youtube.com/watch?v=dQw4w9WgXcQ Loop ::: http://www.youtube.com/watch?v=J---aiyznGQ Base Base Note that the urls do not use SSL. For portability reasons, I propose that SSL only be enabled as an optional extension.

8 9

(no subject)
by Mark Snyder 02 Apr '12

02 Apr '12

<a href="http://dreadscottart.com/mynewwebsite/wp-content/plugins/extended-comment-o…"> http://dreadscottart.com/mynewwebsite/wp-content/plugins/extended-comment-o…</a>

1 0

Regarding simple xml string parser code review
by rajendra prasad 02 Apr '12

02 Apr '12

Hi, I am trying to fetch the values under tags in an xml string given the tag string and xml string. Actually, I don't want to use xml parser since I need to parse very small xml strings. Also, I dont want to use anything else other than haskell platform. I wrote some routines and want to know whether there is any better option available. Please review them and the comments will be highly appreciated. please find routines posted at http://hpaste.org/66357 Thanks in advance. Regards, Rajendra

1 0

Towards a single, unified API for incremental data processing
by John Millikin 02 Apr '12

02 Apr '12

There are currently several APIs for processing strict monoidal values as if they were pieces of a larger, lazy value. Some of the most popular are based on Oleg's left-fold enumerators, including the "iteratee", "enumerator", "iterIO". Other choices include "comonads", "conduits", and "pipes". Despite having various internal implementations and semantics, these libraries generally export a similar-looking API. This is a terrible duplication of effort, and it causes dependant packages to be strongly tied to the underlying implementation. I propose that a new package, "tzinorot", be written to provide a single API based on Data.List. It should be pretty easy to use, requiring only a few common extensions to the type system. For example, the enumerator package's 'mapM' function could be generalized for use in tzinorot through a few simple modifications to the type signature: ---------- -- enumerator mapM mapM :: Monad m => (ao -> m ai) -> Enumeratee ao ai m b -- tzinorot mapM mapM :: (Monad m, Tzinorot t, ListLike l1 a1, ListLike l2 a2) => (l1 a1 -> m (l2 a2)) -> t Void s (TzinorotItems (l1 a1)) (TzinorotItems (l2 a2)) m r ---------- To make it easier to install and use the tzinorot package, it will depend on all of its supported implementations (iteratee, enumerator, conduits, pipes, etc), and use Michael Snoyman's "cabala" tool to manage dependency versions. See the cabala announcement for details on use: http://www.yesodweb.com/blog/2012/04/replacing-cabal

2 1

ANN: acme-http
by Jeremy Shaw 01 Apr '12

01 Apr '12

Hello, As we all know, the true measure of performance for a web server is the classic PONG test. And, so the Happstack team is pleased to announce the release of the new acme-http server! hackage: http://hackage.haskell.org/package/acme-http source: http://patch-tag.com/r/stepcut/acme-http When testing on my laptop with +RTS -N4 using the classic PONG test: $ httperf --hog -v --server 127.0.0.1 --port 8000 --uri / --num-conns=1000 --num-calls=1000 --burst-length=20 --rate=1000 acme-http delivered 221,693.0 req/s, making it the fastest Haskell web server on the planet. By comparison, warp delivered 51,346.6 req/s on this machine. The secret to acme-http's success is that it large avoids doing anything not required to win the PONG benchmark. It does not support timeouts, it does not check quotas, it assumes the client is HTTP 1.1, it does not catch exceptions, and it responds to every single request with PONG. The goal of acme-http is two fold: 1. determine the upper-bound on Haskell web-server performance 2. push that upper bound even higher In regards to #1, we have now established the current upper limit at 221,693.0 req/s. In regards to #2, I believe acme-http will be useful as a place to investigate performance bottlenecks. It is very small, only 250 lines of code or so. And many of those lines deal with pretty-printing, and other non-performance related tasks. Additionally, it works in the plain IO monad. It does not use conduits, enumerators, pipes, or even lazy IO. As, a result, it should be very easy to understand, profile, and benchmark. In providing such a simple environment and avoiding as much extra work as possible we should be able to more easily answer questions like "Why is so much RAM required?", "What is limiting the number of connections per second", etc. As we address these issues in acme-http, we can hopefully bring solutions back to practical frameworks, or to the underlying GHC implementation itself. If performance tuning is your thing, I invite you to check out acme-http and see if you can raise the limit even higher! - jeremy

2 2

Re: [Haskell-cafe] hint and type synonyms
by Claude Heiland-Allen 01 Apr '12

01 Apr '12

Hi Daniel, cafe, On 31/03/12 17:47, Daniel Gorín wrote: > Could you provide a short example of the code you'd like to write but gives you problems? I'm not able to infer it from your workaround alone... This problem originally came up on #haskell, where Rc43 had a problem making a library with a common module that re-exports several other modules: http://hpaste.org/66281 My personal interest is somewhat secondary, having not yet used hint in a real project, but code I would like to write at some point in the future is much like the 'failure' below, unrolled it looks like: main = (print =<<) . runInterpreter $ do setImports ["Prelude"] interpret "1/5" (as :: Rational) -- fails Having to remember that Rational is defined as type Rational = Ratio Integer and that Ratio is defined in Data.Ratio and then to add that to the setImports list is a little inconvenient: main = (print =<<) . runInterpreter $ do setImports ["Prelude", "Data.Ratio" ] interpret "1/5" (as :: Rational) -- works But for my own purposes this is probably much saner in the long run than my newtype wrapping approach below. However, this is not always possible: supposing Ratio itself was defined as a type synonym of Ratio2, and Ratio2 was not exported. Perhaps this is what Rc43 was experiencing, but I shouldn't speculate, as this is all getting a bit theoretical - I should try out hint in the real world to see if this problem makes things impractical for me - sorry for the noise! Thanks, Claude > Thanks, > Daniel > > > On Mar 31, 2012, at 6:19 PM, Claude Heiland-Allen wrote: > >> Hi all, >> >> What's the recommended way to get hint[0] to play nice with type synonyms[1]? >> >> A problem occurs with in scope type synonyms involving types not in scope. >> >> I came up with this after looking at the source[2], but it makes me feel ill: >> >> --8<-- >> -- hint and type synonyms don't play nice >> module Main where >> >> import Language.Haskell.Interpreter >> >> import Data.Typeable as T >> import Data.Typeable.Internal >> import GHC.Fingerprint.Type >> >> main = failure>> success >> >> test t = (print =<<) . runInterpreter $ do >> setImports [ "Prelude" ] >> interpret "1/5" t >> >> failure = test (as :: Rational) >> -- Left (WontCompile [GhcError {errMsg = "Not in scope: type constructor or class `Ratio'"}]) >> >> success = test (as :: Q) >> -- Right (1 % 5) >> >> newtype Q = Q Rational >> >> instance Show Q where >> show (Q a) = show a >> showsPrec n (Q a) = showsPrec n a >> >> instance Typeable Q where >> typeOf _ = TypeRep (Fingerprint 0 0) (T.mkTyCon "Rational") [] >> --8<-- >> >> Thanks, >> >> >> Claude >> >> [0] http://hackage.haskell.org/package/hint >> [1] http://www.haskell.org/onlinereport/decls.html#type-synonym-decls >> [2] http://hackage.haskell.org/packages/archive/hint/0.3.3.4/doc/html/src/Hint-… >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >

2 1

Re: [Haskell-cafe] Google Summer of Code - Lock-free data
by John Lato 01 Apr '12

01 Apr '12

Slightly related: I think it would be interesting to compare a Disruptor-based concurrency communications mechanism and compare it to e.g. TChans 1. Disruptor - http://code.google.com/p/disruptor/ > From: Ryan Newton <rrnewton(a)gmail.com> > >> I think so. Atomically reading and writing a single memory location >>> (which CAS does) is just a very simple transaction. But using a CAS >>> instruction should be more efficient, since STM has to maintain a >>> transaction log and commit transactions, which creates some overhead. >>> >> >> Ah, I see. In that case, it may be worthwhile to implement the CAS >> instruction in terms of STM as well and measure the performance difference >> this makes for the final data structure. After all, STM is a lot more >> compositional than CAS, so I'd like to know whether the loss of >> expressiveness is worth the gain in performance. > > > There's one annoying hitch with doing apples-to-apples comparisons here. > > The problem is that CAS falls short of being a hardware-accelerated version > of a simple transaction (read TVar, (==) against expected value, > conditionally update TVar), because CAS is based on pointer equality rather > than true equality. (eq? rather than equal? for any Schemers out there.) > > For this reason our "Fake" version of CAS -- for older GHCs and for > performance comparison -- has to use reallyUnsafePointerEquality#: > > > http://hackage.haskell.org/packages/archive/IORefCAS/0.2/doc/html/Data-CAS-… > > But we do provide a "CASable" type class in that package which is precisely > for comparing the performance of: > > - Hardware CAS > - Fake CAS -- atomicModifyIORef + ptrEquality > - Foreign CAS -- gcc intrinsic + function call

3 2

get a string representation (show) of a function argument
by TP 01 Apr '12

01 Apr '12

Hi, I don't known the advanced features and extensions of GHC at all. Look at the following program: ---------------- f :: Integer -> Integer -> IO Integer f a b = do print $ "first argument=" ++ (show a) print $ "second argument=" ++ (show b) print $ a+b return (a+b) main = do k <- f 3 5 f 2 k ---------------- It yields: ---------------- "first argument=3" "second argument=5" 8 "first argument=2" "second argument=8" 10 10 ---------------- I am wondering if there is any means to get "f 3 5" instead of "8" in the output of this program. My idea would be to write some generic test function: I give it an expression (probably a function call) and the expected result (as a string), and then: * it should check that the obtained result is identical to the expected one. * it should also print the expression that yielded the first argument of the test function (i.e. the function call), under an understandable form (show). This is the feature that is missing to my mind in some test suites: for example in HUnit, it is not automatic: in the first argument of assertEqual, we may give a string corresponding to the executed command, see the documentation of Test.HUnit: test1 = TestCase (assertEqual "for (foo 3)," (1,2) (foo 3)) > runTestTT tests # Failure in: 0:test1 for (foo 3), expected: (1,2) but got: (1,3) Cases: 2 Tried: 2 Errors: 0 Failures: 1 So, we have duplication of code: "foo 3". On the other hand, I guess that the needed features to do that are not possible in Haskell (related to some kind of metaprogramming), but I prefer to ask people about that. Thanks in advance, TP

2 1