[Haskell-cafe] GHC trac
I just noticed that the GHC trac was moved to http://ghc.haskell.org/trac/ghc/ and I cannot login with my old credentials. Were the old accounts transferred to the new trac? Also, the registration page [1] does not work. [1] http://ghc.haskell.org/trac/ghc/register ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Ajhc Haskell Compiler 0.8.0.7 Release
On Jul 6, 2013, at 03:07 , Kiwamu Okabe kiw...@debian.or.jp wrote: Umm... Is your question Is Ajhc's goal that build the compiler for Android? If so, the answer is No. The Ajhc's goal is that find the compiler to rewrite the NetBSD kernel with Haskell. But you can do support Android. I think porting (A)jhc's RTS to Android NDK is as easy as to Cortex-M4. Similarly, I might look into a PIC32 port (= MIPS 4K). I don't expect any problems. I presume nobody have started on this yet. Tommy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Ajhc Haskell Compiler 0.8.0.7 Release
Any plans on supporting the popular Raspberry Pi platform? I poked at the source code a bit, but I didn't even know where to begin. - jeremy On Fri, Jul 5, 2013 at 11:01 PM, Kiwamu Okabe kiw...@debian.or.jp wrote: We are happy to announce Ajhc 0.8.0.7. You can program interrupt handler with Haskell language on this release. But not yet collect (big) patch sets, the changes will be merged to jhc. You can get Ajhc using cabal install ajhc command. The usage is found at Ajhc's project web site http://ajhc.metasepi.org/. The source code at https://github.com/ajhc/ajhc/tags. Welcome sending any bugs or your ideas to https://github.com/ajhc/ajhc/issues. ## An example of interrupt handler written with Haskell https://github.com/ajhc/demo-cortex-m3/tree/master/stm32f3-discovery The demo for Cortex-M4 has main context and intrrupt context. The main context waits time expire with polling counter. https://github.com/ajhc/demo-cortex-m3/blob/master/stm32f3-discovery/hs_src/Intr.hs#L17 The interrupt context is called from clock exception, and decrement counter. https://github.com/ajhc/demo-cortex-m3/blob/master/stm32f3-discovery/hs_src/Intr.hs#L9 ## Other changes * Guard StablePtr critical section. * Add _JHC_JGC_SAVING_MALLOC_HEAP option for getting smaller malloc heap. * Link forkIO to forkOS. Enjoy! :) - - - Metasepi team ___ 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] same function's type accepted in top level, but rejected in where clause
On Fri, Jul 5, 2013 at 11:03 PM, Ömer Sinan Ağacan omeraga...@gmail.comwrote: There's an implicit quantifier in type of `f`, like this: `f :: forall a. a - ListF a a`. When I add `ScopedTypeVariables` and `forall a. ...` in top level definition, it's like all `a`s in scope of top level definition are same, except when explicitly defined as `forall a. ...`. Is my intuition correct? Yes it is ! :) ScopedTypeVariables is a very nice and non problematic extension, it may even be made part of some future Haskell standard. -- Jedaï ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] same function's type accepted in top level, but rejected in where clause
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/07/13 19:50, Chaddaï Fouché wrote: On Fri, Jul 5, 2013 at 11:03 PM, Ömer Sinan A?acan omeraga...@gmail.comwrote: There's an implicit quantifier in type of `f`, like this: `f :: forall a. a - ListF a a`. When I add `ScopedTypeVariables` and `forall a. ...` in top level definition, it's like all `a`s in scope of top level definition are same, except when explicitly defined as `forall a. ...`. Is my intuition correct? Yes it is ! :) ScopedTypeVariables is a very nice and non problematic extension, it may even be made part of some future Haskell standard. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Is this just speculation and wishful thinking or has there actually been discussion about it already? I think it'd be great if it was the part of the standard but I'm sure there are tens of naysayers ready to repaint my shed. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJR2wu9AAoJEM1mucMq2pqXM64P/RGQR+/qItSQumuUCXkagp5V jMx3UaoJIyjOlcDBAmbHitZH4gTSNKFh3toWH7brb8SPfMpzgl1rGFtCsr4pzvOS 3GzM2giTvw9cs8rGv5f1O7h2hSpaNgU9xVxzpYxRd4g/h3sMEuWji++jJDhDY6mo SkOmtMGozi4AwhtMrybDjeNhsno82mKPU9SQF8fKz1yj/MMJY9BwWGs6k3OlvxWM eNqyRfoyQtgRLB2Th1dJqIV30dakmnMSCX9ALnD0Pg8/lQnqj0iJ1O7b1S2iqn/e UtxTTyOgwNF56K4CnUpt/os//bHyqsQFFQyFBkdZMstcro57Ta7wcXcPqzhuySNQ GOerfMkVAOApVkXO6t78XLgy1vkc+RXaxY5obICXN+nRu4WuZBLow0HdxlkKffHE cwXHigU3KkKIeoyvgpI9pEFSUMPJcBvI7SG9MqWIb5sOxuZhFv2KmDSanptL1bA8 yccRb0yN2vfmL3+hLIBKTfn9TWKCpnEaCpwPBCCM9kFvA31D0Rul5EZT5H8IB2/9 t5DGTOXlACgKbr8GODCFdtLQUCXaKYj7N83yQHt9kBC6PfVe9ECOJjnZrfvnA1na sTPzzxNFWdAmKQBhZBlldwYvLNtIO7UK0H+l01gacKd5KOldS6u1K+5EDT0WuIg5 LPxtoY8kYIJlwUmZgAqZ =ZaDI -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Possible extension to Haskell overloading behavior
So I've been thinking about something, and I'm curious whether anyone (in particular, people involved with GHC) think this is a worthwhile idea. I'd like to implement an extension to GHC to offer a different behavior for literals with polymorphic types. The current behavior is something like: 1. Give the literal a polymorphic type, like (Integral a = a) 2. Type check the whole program, possibly giving the term a more constrained type. 3. If the type is still ambiguous, apply defaulting rules. I'd like to add the option to do this instead. 1. Take the polymorphic type, and immediately apply defaulting rules to get a monomorphic type. 2. Type check the program with the monomorphic type. Mostly, this would reduce the set of valid programs, since the type is chosen before considering whether it meets all the relevant constraints. So what's the purpose? To simplify type errors for programmers who don't understand type classes. What I have in mind is domain-specific dialects of Haskell that replace the Prelude and are aimed at less technical audiences - in my case, children around 10 to 13 years old; but I think the ideas apply elsewhere, too. Type classes are (debatably) the one feature of Haskell that tends to be tricky for non-technical audiences, and yet pops up in very simple programs (and more importantly, their error messages) even when the programmer wasn't aware of it's existence, because of its role in overloaded literals. In some cases, I think it's a good trade to remove overloaded literals, in exchange for simpler error messages. This leaves new programmers learning a very small, simple language, and not staring so much at cryptic error messages. At the same time, it's not really changing the language, except for the need to explicitly use type classes (via conversion functions like fromInteger) rather than get them thrown in implicitly. With GHC's extended defaulting rules that apply for OverloadedStrings, this could also be used to treat all string literals as Text, too, which might make some people happy, too. Of course, the disadvantage is that for numeric types, you would lose the convenience of overloaded operators, since this is only a sensible thing to do if you're replacing the Prelude with one that doesn't use type classes. But in at least my intended use, I prefer to have a single Number type anyway (and a single Text type that's not sometimes called [Char]). In the past, explaining these things has eaten up far too much time that I'd rather have spent on more general skills and creative activities. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible extension to Haskell overloading behavior
Oops, when I wrote this, I'd assumed it was possible to export defaults from a module, like an alternate Prelude. But it looks like they only affect the current module. So this whole thing depends on also being able to either define defaults in an imported module, or in options to GHC. On Mon, Jul 8, 2013 at 12:54 PM, Chris Smith cdsm...@gmail.com wrote: So I've been thinking about something, and I'm curious whether anyone (in particular, people involved with GHC) think this is a worthwhile idea. I'd like to implement an extension to GHC to offer a different behavior for literals with polymorphic types. The current behavior is something like: 1. Give the literal a polymorphic type, like (Integral a = a) 2. Type check the whole program, possibly giving the term a more constrained type. 3. If the type is still ambiguous, apply defaulting rules. I'd like to add the option to do this instead. 1. Take the polymorphic type, and immediately apply defaulting rules to get a monomorphic type. 2. Type check the program with the monomorphic type. Mostly, this would reduce the set of valid programs, since the type is chosen before considering whether it meets all the relevant constraints. So what's the purpose? To simplify type errors for programmers who don't understand type classes. What I have in mind is domain-specific dialects of Haskell that replace the Prelude and are aimed at less technical audiences - in my case, children around 10 to 13 years old; but I think the ideas apply elsewhere, too. Type classes are (debatably) the one feature of Haskell that tends to be tricky for non-technical audiences, and yet pops up in very simple programs (and more importantly, their error messages) even when the programmer wasn't aware of it's existence, because of its role in overloaded literals. In some cases, I think it's a good trade to remove overloaded literals, in exchange for simpler error messages. This leaves new programmers learning a very small, simple language, and not staring so much at cryptic error messages. At the same time, it's not really changing the language, except for the need to explicitly use type classes (via conversion functions like fromInteger) rather than get them thrown in implicitly. With GHC's extended defaulting rules that apply for OverloadedStrings, this could also be used to treat all string literals as Text, too, which might make some people happy, too. Of course, the disadvantage is that for numeric types, you would lose the convenience of overloaded operators, since this is only a sensible thing to do if you're replacing the Prelude with one that doesn't use type classes. But in at least my intended use, I prefer to have a single Number type anyway (and a single Text type that's not sometimes called [Char]). In the past, explaining these things has eaten up far too much time that I'd rather have spent on more general skills and creative activities. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec error message not making any sense
Hi Fredrik, First, do you use the latest parsec version (3.1.3)? If not, can you try the same with 3.1.3? Second, please upload your code to hpaste.org or a similar service and give us the link. It's not much fun to extract code from an html email. Roman * Fredrik Karlsson dargo...@gmail.com [2013-07-08 23:54:17+0200] Dear list, I have a Parsec parser that fails and gives the following error message: *Main parseFromFile textgridfile testFile Left /Users/frkkan96/Documents/src/ume/umecore/testing/testdata/testdata.TextGrid (line 35, column 5): unexpected t expecting intervals [ Now, this is perfectly understandable, but line 35, col 5 in the file being parsed looks like the supplies image - there is no 't' there. Any ideas on what is going on? The parser I am using is: data VariableLine = VariableLine String String deriving Show data TierType = IntervalTier | PointTier deriving Show data Tier = Tier String deriving Show data LabelFile = LabelFile Double Double deriving Show data Label = Label String TierType Double Double String deriving Show haskelldef = makeTokenParser haskellDef textgridfile :: Parser (LabelFile, [[Label]]) textgridfile = do h - header ll - many1 tier return $ (h,ll) header :: Parser LabelFile header = do string headTS1 start - try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) string xmax = end - try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) string tiers? exists \n string size = integer haskelldef string item []: whiteSpace haskelldef return $ LabelFile start end tier :: Parser [Label] tier = do whiteSpace haskelldef string item [ integer haskelldef string ]: whiteSpace haskelldef try (string class = \IntervalTier\) | string class = \TextTier\ whiteSpace haskelldef string name = char '' name - many quotedChar char '' ? quote at end of cell whiteSpace haskelldef string xmin = try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) whiteSpace haskelldef string xmax = try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) string intervals: size = | string points: size = integer haskelldef whiteSpace haskelldef labelList - many1 (interval name) return $ labelList interval :: String - Parser Label interval tierName = do whiteSpace haskelldef string intervals [ integer haskelldef string ]: whiteSpace haskelldef string xmin = start - try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) whiteSpace haskelldef string xmax = end - try (float haskelldef) | (fmap fromInteger $ integer haskelldef ) whiteSpace haskelldef string text = char '' text - many quotedChar char '' ? quote at end of cell return $ Label tierName IntervalTier start end text which fails on the attached input file. I can't see how 't' is found?? What am I doing wrong? /Fredrik -- Life is like a trumpet - if you don't put anything into it, you don't get anything out of it. ___ 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] Announcing postgresql-libpq-0.8.2.3
I just fixed a fairly serious performance problem with postgresql-libpq's binding to PQescapeStringConn; in was exhibiting a non-linear slowdown when more strings are escaped and retained. https://github.com/lpsmith/postgresql-libpq/commit/adf32ff26cdeca0a12fa59653b49c87198acc9ae If you are using postgresql-libpq's escapeStringConn, or a library that uses it (e.g. postgresql-simple, or persistent-postgresql), I do recommend upgrading. You may or may not see a performance improvement, depending on your particular use case, but if you do it can be quite substantial. It's not entirely clear to me what the root cause really is, but it certainly appears as though it's related to the (direct) use of mallocBytes, which was replaced with (indirect) calls to mallocForeignPtrBytes / mallocPlainForeignPtrBytes (through the bytestring package). In this case, it resulted in an asymptotic improvement in time complexity of some algorithms. Best, Leon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [database-devel] Announcing postgresql-libpq-0.8.2.3
On Mon, Jul 8, 2013 at 9:03 PM, Leon Smith leon.p.sm...@gmail.com wrote: I just fixed a fairly serious performance problem with postgresql-libpq's binding to PQescapeStringConn; in was exhibiting a non-linear slowdown when more strings are escaped and retained. I'd like to point out a somewhat related bottleneck in postgresql-simple (but not postgresql-libpq). Every PQescapeStringConn or PQescapeByteaConn call involves a withMVar, which is about 100ns on the threaded RTS on my system. Taking the Connection lock once for the whole buildQuery call might be much faster, especially for multi-row inserts and updates. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Harder Question - Chapter 4 - 4.12 - haskell the craft of functional programming - Second Edition
Hi everybody! I am trying to solve the question for a long time: [*4.12 Harder] Find out the maximum number of pieces we can get by making a given* *number of flat (that is planar) cuts through a solid block. It is not the same* *answer as we calculated for straight-line cuts of a flat piece of paper.* I find out that this function has the following results: f 0 = 1 f 1 = 2 f 2 = 4 f 3 = 8 That is, from 0 to 3, the flat cuts all the pieces in two other pieces, so the number of pieces is doubled. But, starting from f 4, the flat can not cuts all the pieces, in case of f 4, the flat can cut 6 out of the 8 pieces, resulting in 12 pieces plus 2 pieces 2 = 14 pieces. But I can not reach a general case. Can anybody help me to find out the solution? Thank you very much! Manoel Menezes. __ Manoel Messias da Silva Menezes Jr M.Sc.in Computer Science Federal University of Pernambuco System Analyst - Petrobras ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [database-devel] Announcing postgresql-libpq-0.8.2.3
I'll have to benchmark withMVar on my system, but (at least on my old laptop) a safe foreign function call is also on the order of 100ns. As c_PQescapeStringConn and c_PQescapeByteaConn are currently safe calls, that would limit the maximum time saved at ~50%. Perhaps it would make sense to make these unsafe calls as well, but the justification I used at the time was that the amount of time consumed by these functions is bounded by the length of the string being escaped, which is itself unbounded.Certainly postgresql-libpq is currently overly biased towards safe calls; though when I took the bindings over it was overly biased towards unsafe calls. (Though, arguably, it's worse to err on the side of making ffi calls unsafe.) I've also considered integrating calls to c_PQescapeStringConn with blaze-builder and/or bytestring-builder, which could help a fair bit, but would also introduce dependencies on the internals of these libraries when currently there is none. There is certainly a lot of room for optimizing query generation in postgresql-simple, this I've been well aware of since the beginning. And it probably would be worthwhile to move to protocol-level parameters which would avoid the need for escaping value parameters altogether, and open up the possibility of binary formats as well, which would be a huge performance improvement for things like numerical values and timestamps. Although IIRC, one downside is that this prevents multiple DML commands from being issued in a single request, which would subtly change the interface postgresql-simple exports. Best, Leon On Mon, Jul 8, 2013 at 10:00 PM, Joey Adams joeyadams3.14...@gmail.comwrote: On Mon, Jul 8, 2013 at 9:03 PM, Leon Smith leon.p.sm...@gmail.com wrote: I just fixed a fairly serious performance problem with postgresql-libpq's binding to PQescapeStringConn; in was exhibiting a non-linear slowdown when more strings are escaped and retained. I'd like to point out a somewhat related bottleneck in postgresql-simple (but not postgresql-libpq). Every PQescapeStringConn or PQescapeByteaConn call involves a withMVar, which is about 100ns on the threaded RTS on my system. Taking the Connection lock once for the whole buildQuery call might be much faster, especially for multi-row inserts and updates. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linux users needed for OpenGL extensions survey
Brian, I think it would be better to provide your email in the thread. E.g. from http://www.haskell.org/pipermail/haskell-cafe/2013-July/109061.html I can only reply to the maillist. I'm answering now through Google Groups hope it will get to you. Kind regards, Kirill Zaborsky воскресенье, 7 июля 2013 г., 22:54:04 UTC+4 пользователь Brian Lewis написал: Hi, I'm doing a survey to find out how well various OpenGL extensions are supported, to know where to focus efforts on Haskell game software. If you run Linux on your desktop and want to help, here's how: 1.) Save the information like this: $ glxinfo SOMENAME.glxinfo ... where SOMENAME is your name, or nickname, or the computer's name, whatever you like. If you don't have glxinfo, you might need to install mesa-utils on Ubuntu, or mesa-demos on Arch. 2.) Ensure the file contains information about OpenGL extensions supported by your graphics card. 3.) Attach it to me *off list*. If you have questions, please ask me *off list*. If there's interest, I'll make the survey results available. Thanks! ___ Haskell-Cafe mailing list haskel...@haskell.org javascript: http://www.haskell.org/mailman/listinfo/haskell-cafe qrilka.glxinfo Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
