[Haskell-cafe] [Conduit] weird action of leftover.
Say I have code like below. If I comment the leftover in main, I got (Just "L1\n", Just "L2\n", Just "L3\n", Just "L4\n"). But if I did not comment the leftover, then I got (Just "L1\n", Just "L1\n", Just "", Just "L2\n"). Why is not it (Just "L1\n", Just "L1\n", Just "L2\n", Just "L3\n")? takeLine :: (Monad m) => Consumer ByteString m (Maybe ByteString) takeLine = do mBS <- await case mBS of Nothing -> return Nothing Just bs -> case DBS.elemIndex _lf bs of Nothing -> return $ Just bs Just i -> do let (l, ls) = DBS.splitAt (i + 1) bs leftover ls return $ Just l main = do m <- runResourceT $ sourceFile "test.simple" $$ (do a <- takeLine leftover $ fromJust a b <- takeLine c <- takeLine d <- takeLine return (a, b, c, d)) print m -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] llvm-3.0.1.0 installation on Mac
Thanks Brandon. I've patched: /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libHSrts-ghc7.4.2.dylib and /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/ibHSrts_thr-ghc7.4.2.dylib both pointing to: /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib Unfortunately, it looks like /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib is pointing to the dodgy library too, e.g.: > otool -L > /Library/Frameworks/GHC.framework/Versions/7.4.2-x86_64/usr/lib/ghc-7.4.2/libffi.dylib /Users/ian/zz64/ghc-7.4.2/libffi/build/inst/lib/libffi.5.dylib (compatibility version 6.0.0, current version 6.10.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) Not sure what to patch the first reference in that one to. On 2013-04-07, at 9:42 PM, Brandon Allbery wrote: > On Mon, Apr 8, 2013 at 12:10 AM, Luke Evans wrote: > Unfortunately, it looks like my cabal build failure occurs in a temporary and > very short-lived directory. So presumably the dodgy FFI gets copied into > there from elsewhere. I wonder if I can find the source... > > It's running an executable it seems to have built to generate something else > for the build, so I suspect you are in fact seeing the ghc bug and you should > fix the ghc reference. If you installed the official HP package, you need to > find libHSrts-ghc7.4.2.dylib somewhere under /Library/Haskell and use > install_name_tool on that. > > -- > brandon s allbery kf8nh sine nomine associates > allber...@gmail.com ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Vector Fabrics is hiring!
[Apologies for multiple postings.] Vector Fabrics is hiring: we are looking for a top-notch programmer to extend our program-analysis and parallelization products. You design and implement algorithms to assist the programmer to create a parallel design from a sequential C or C++ program. You work with our international team of world-class computer scientists and experts in the Haskell / OCaml functional programming languages. Your work is at the forefront of technology, giving you the opportunity to publish your work in major conferences and directly cooperate with processor design companies and domain-specific application vendors. As we are a startup company, you will quickly have a major impact on our products and get to know all aspects of product creation. You will be part of a strongly committed development team and contribute to our agile development process and automated test suites. Interested? Send your CV, GitHub account or other proof of what you can do to j...@vectorfabrics.com. RESPONSIBILITIES * Design and implement software optimization (e.g. parallelization) algorithms for CPUs and GPUs; * Thoroughly test your code, create automated test suites; * Contribute to our agile development planning and process; * Analyze complex customer applications for optimization opportunities and translate this to new analysis algorithms. PROFILE * Your friends and colleagues describe you as a "rockstar" programmer; your programming ability is way above average; * Demonstrable experience in design and implementation of complex software applications; prior experience in functional programming languages is preferred; * You continuously surprise us with your creative yet pragmatic solutions for complex software problems; * You are strongly committed to deliver working software as early as possible; * You work against very high quality standards. Refactoring is your bread and butter, pair-programming is how you prefer to review your code; * Whatever technologies, languages, or development environments you've been using, we expect you have mastered them in depth, and we expect that you will be able to master any technology, language, or development environment that we need in the future; * You are not afraid to get your hands dirty on low-level code, hijack a malloc() call in the standard C library, port the latest gdb debugger to Android on a jail-broken tablet? You get it done. * Excellent command of written and spoken English. EDUCATION MSc, MEng or PhD in Computer Science or significant relevant experience. ABOUT VECTOR FABRICS Vector Fabrics is a high-tech software company, developing tools for embedded multicore programming. Its technology and expertise is getting widespread recognition in the industry as being innovative and unique in their ability to address heterogeneous multicore application-specific silicon platforms. Due to the advanced nature of its tools, Vector Fabrics operates at the forefront of the next generation of embedded platforms for diverse markets ranging from supercomputers to automotive to cell phones. Vector Fabrics puts absolute priority on hiring top class individuals in key positions. Vector Fabrics’ team profile is exceptional and its ambition is to hire only individuals that match or surpass that profile. The company pays top salary and offers a challenging, engaging and stimulating work environment with a high degree of responsibility. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] llvm-3.0.1.0 installation on Mac
On Mon, Apr 8, 2013 at 12:10 AM, Luke Evans wrote: > Unfortunately, it looks like my cabal build failure occurs in a temporary > and very short-lived directory. So presumably the dodgy FFI gets copied > into there from elsewhere. I wonder if I can find the source... It's running an executable it seems to have built to generate something else for the build, so I suspect you are in fact seeing the ghc bug and you should fix the ghc reference. If you installed the official HP package, you need to find libHSrts-ghc7.4.2.dylib somewhere under /Library/Haskell and use install_name_tool on that. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] llvm-3.0.1.0 installation on Mac
Ah, I see GHC bug #5982, which smells awfully similar. The bug suggests a fix along the lines of: install_name_tool /usr/local/lib/ghc-7.4.1/libHSrts-ghc7.4.1.dylib -change /Users/ian/zz64/ghc-7.4.1/libffi/build/inst/lib/libffi.5.dylib /usr/local/lib/ghc-7.4.1/libffi.dylib Presumably this is still an issue in the 7.4.2 build I have installed from Haskell Platform. Unfortunately, it looks like my cabal build failure occurs in a temporary and very short-lived directory. So presumably the dodgy FFI gets copied into there from elsewhere. I wonder if I can find the source... On 2013-04-07, at 8:39 PM, Luke Evans wrote: > > My cabal-fu is extremely weak, so I'll plug on and see if I can figure out > how cabal's analysis/build might be going wrong here. > I'd be very grateful for any clues though! > > -- Luke > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] llvm-3.0.1.0 installation on Mac
I'm trying to get LLVM 3.0 installed and then have the llvm-3.0.1.0 package install and bind against it with cabal. I'm on a recent 64 bit Mac which shows up in various messages like: "Target platform inferred as: x86_64-apple-darwin" I was advised on the Haskell IRC channel to install a 3.0 LLVM from a location like MacPorts first, then point cabal at the location where LLVM was installed with the appropriate config option. So, I did a "sudo ./port install llvm-3.0", and everything seemed to proceed fine. Then I did: cabal install llvm --configure-option=--with-llvm-prefix=/opt/local/libexec/llvm-3.0 This looks promising (compared to missing the config option), but eventually this happens: Building llvm-base-3.0.1.0... Preprocessing library llvm-base-3.0.1.0... dyld: Library not loaded: /Users/ian/zz64/ghc-7.4.2/libffi/build/inst/lib/libffi.5.dylib Referenced from: /private/var/folders/tz/vlbc03q5333897z201hkmcb4gn/T/llvm-base-3.0.1.0-3941/llvm-base-3.0.1.0/dist/build/LLVM/FFI/Analysis_hsc_make Reason: image not found running dist/build/LLVM/FFI/Analysis_hsc_make failed (exit code 5) command was: dist/build/LLVM/FFI/Analysis_hsc_make >dist/build/LLVM/FFI/Analysis.hs Failed to install llvm-base-3.0.1.0 I have no idea where "/Users/ian/..." is coming from! My cabal-fu is extremely weak, so I'll plug on and see if I can figure out how cabal's analysis/build might be going wrong here. I'd be very grateful for any clues though! -- Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers book in Haskell
A swapped order probably appeals to most haskellers (by contrast I first learned ML). The real difference is that the Haskell books will focus on lazy languages. If your tastes are in implementing fast lazy languages using graph reduction then you may also be interested in [1]: although I haven't read all of it. I would say that the material in Appel's books and SPJ's books is fairly disjoint, and if you're interested in Haskell you should definitely focus on those. (However, Appel's book is also worth browsing if you're at a library, it can be read fairly quickly, the main "cool concepts" are in chapter two!) Kris [1] http://wiki.clean.cs.ru.nl/Functional_Programming_and_Parallel_Graph_Rewriting On Sun, Apr 7, 2013 at 9:00 PM, Tommy Thorn wrote: > You beat me to it although I'd reverse the order of your list. > > Also I wouldn't ignore the classic, > http://www.amazon.com/Compilers-Principles-Techniques-Tools-Edition/dp/0321486811 > but know that it has next to nothing useful specific to FP languages, > and certainly not lazy languages. > > Tommy > > On Apr 7, 2013, at 07:40 , Kristopher Micinski wrote: > >> I disagree about the recommendation for Modern Compiler Design: I >> found it to be a pretty good introduction to compiler technology, but >> not functional programming with compilers, it's coverage was *very* >> shallow. >> >> By contrast, I can recommend both Compiling with Continuations (the >> "standard" text on implementing compilers in functional languages, >> using ML as an example), and The Implementation of Functional >> Programming Languages [2]. >> >> This topic is covered pretty well in course material scattered >> throughout the web, (lots of course with online pdf sets about >> implementing functional compilers), but not in a comprehensive fashion >> that talks about more complex aspects of compiling functional >> languages. Implementing Functional Langauges: a tutorial, is also >> excellent and worth a look. >> >> kris >> >> [1] >> http://www.amazon.com/Compiling-Continuations-Andrew-W-Appel/dp/052103311X >> [2] >> http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/index.htm >> [3] >> http://research.microsoft.com/en-us/um/people/simonpj/Papers/pj-lester-book/ >> >> On Sun, Apr 7, 2013 at 4:36 AM, Sergey Bushnyak >> wrote: >>> Books about compilers is rare artifact, in comparison to some technology >>> books. It is uncommon to see topics on compilers for functional languages. >>> >>> I was surprised, when saw it in "Modern Compiler Design", which I've >>> mentioned earlier. "Compiler design" series from Springer maybe reveal >>> topics on FL in future as it become more popular. In new books about 1/5 of >>> it is about FL, but very basic stuff. >>> >>> Кnowledge mostly lies in research papers, occasional articles like "The >>> Glasgow Haskell Compiler"[1] in AOSA from creators, and source code :) >>> >>> >>> [1] http://www.aosabook.org/en/ghc.html >>> >>> -- >>> Best regards, >>> Sergey Bushnyak >>> >>> >>> ___ >>> 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] Compilers book in Haskell
You beat me to it although I'd reverse the order of your list. Also I wouldn't ignore the classic, http://www.amazon.com/Compilers-Principles-Techniques-Tools-Edition/dp/0321486811 but know that it has next to nothing useful specific to FP languages, and certainly not lazy languages. Tommy On Apr 7, 2013, at 07:40 , Kristopher Micinski wrote: > I disagree about the recommendation for Modern Compiler Design: I > found it to be a pretty good introduction to compiler technology, but > not functional programming with compilers, it's coverage was *very* > shallow. > > By contrast, I can recommend both Compiling with Continuations (the > "standard" text on implementing compilers in functional languages, > using ML as an example), and The Implementation of Functional > Programming Languages [2]. > > This topic is covered pretty well in course material scattered > throughout the web, (lots of course with online pdf sets about > implementing functional compilers), but not in a comprehensive fashion > that talks about more complex aspects of compiling functional > languages. Implementing Functional Langauges: a tutorial, is also > excellent and worth a look. > > kris > > [1] http://www.amazon.com/Compiling-Continuations-Andrew-W-Appel/dp/052103311X > [2] > http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/index.htm > [3] > http://research.microsoft.com/en-us/um/people/simonpj/Papers/pj-lester-book/ > > On Sun, Apr 7, 2013 at 4:36 AM, Sergey Bushnyak > wrote: >> Books about compilers is rare artifact, in comparison to some technology >> books. It is uncommon to see topics on compilers for functional languages. >> >> I was surprised, when saw it in "Modern Compiler Design", which I've >> mentioned earlier. "Compiler design" series from Springer maybe reveal >> topics on FL in future as it become more popular. In new books about 1/5 of >> it is about FL, but very basic stuff. >> >> Кnowledge mostly lies in research papers, occasional articles like "The >> Glasgow Haskell Compiler"[1] in AOSA from creators, and source code :) >> >> >> [1] http://www.aosabook.org/en/ghc.html >> >> -- >> Best regards, >> Sergey Bushnyak >> >> >> ___ >> 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] GSoC Project Proposal: Markdown support for Haddock
On 8 April 2013 07:12, Roman Cheplyaka wrote:
> Looks like a bug in cpphs to me (CC'ing Malcolm). It should respect
> comments. E.g. GNU cpp strips C comments.
Not quite: http://hackage.haskell.org/trac/ghc/ticket/4836
>
> Roman
>
> * John MacFarlane [2013-04-05 16:04:32-0700]
>> I like markdown and use it all the time. While I acknowledge the
>> problems that have been pointed out, markdown has the advantage of being
>> easily readable "as it is" in the source document, and not looking like
>> markup.
>>
>> But I do want to point out one problem with markdown as a format for
>> documentation in Haskell files. Consider:
>>
>>
>> module MyModule
>> {-
>> # Introduction
>>
>> This is my module
>> -}
>> where
>> import System.Environment
>>
>> main = getArgs >>= print
>>
>>
>> Now try to compile with -cpp, and you'll get an error because of the '#'
>> in column 1. '#' in column 1 is common in markdown (and even
>> indispensible for level 3+ headers).
>>
>> One could work around this by disallowing level 3+ headers, by allowing
>> the headers to be indented, or by introducing new setext-like syntax for
>> level 3+ headers, but it is a problem for the idea of using a markdown
>> SUPERset.
>>
>> John
>>
>> +++ dag.odenh...@gmail.com [Apr 05 13 21:59 ]:
>> >I forgot the mention the craziness with the *significant trailing
>> >whitespace*.
>> >
>> >On Fri, Apr 5, 2013 at 9:49 PM, [1]dag.odenh...@gmail.com
>> ><[2]dag.odenh...@gmail.com> wrote:
>> >
>> >Personally I think Markdown sucks, although perhaps less than Haddock
>> >markup.
>> >Still:
>> >* No document meta data
>> >* No code block meta data like language for syntax highlighting
>> >* No tables
>> >* No footnotes
>> >* HTML fallback is insecure
>> >* Confusing syntax (is it []() or ()[] for links?)
>> >* Syntax that gets in the way (maybe I don't want *stars* emphasized)
>> >* Above point leads to non-standard dialects like "GitHub Markdown"
>> >(no, GitHub doesn't use markdown)
>> >* Not extensible, leading to even more non-standard hacks and
>> >work-arounds (GitHub Markdown, Pandoc Markdown, other Markdown
>> >libraries have their own incompatible extensions)
>> >* Not well suited for web input (e.g. four-space indentation for code
>> >blocks), although not that important for Haddock
>> >An important thing to note here is that no, Markdown has *not* won
>> >because no one is actually using *Markdown*. They're using their own,
>> >custom and incompatible dialects.
>> >Only two of the above points apply to reStructuredText (web input and
>> >syntax getting in the way), and those particular points don't apply to
>> >Creole. Therefore I tend to advocate Creole for web applications and
>> >reStructuredText for documents.
>> >On Thu, Apr 4, 2013 at 6:49 PM, Johan Tibell
>> ><[3]johan.tib...@gmail.com> wrote:
>> >
>> > Hi all,
>> > Haddock's current markup language leaves something to be desired
>> > once
>> > you want to write more serious documentation (e.g. several
>> > paragraphs
>> > of introductory text at the top of the module doc). Several features
>> > are lacking (bold text, links that render as text instead of URLs,
>> > inline HTML).
>> > I suggest that we implement an alternative haddock syntax that's a
>> > superset of Markdown. It's a superset in the sense that we still
>> > want
>> > to support linkifying Haskell identifiers, etc. Modules that want to
>> > use the new syntax (which will probably be incompatible with the
>> > current syntax) can set:
>> > {-# HADDOCK Markdown #-}
>> > on top of the source file.
>> > Ticket: [4]http://trac.haskell.org/haddock/ticket/244
>> > -- Johan
>> > ___
>> > Haskell-Cafe mailing list
>> > [5]Haskell-Cafe@haskell.org
>> > [6]http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>> > References
>> >
>> >1. mailto:dag.odenh...@gmail.com
>> >2. mailto:dag.odenh...@gmail.com
>> >3. mailto:johan.tib...@gmail.com
>> >4. http://trac.haskell.org/haddock/ticket/244
>> >5. mailto:Haskell-Cafe@haskell.org
>> >6. 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
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail
Re: [Haskell-cafe] abs on Float/Doubles
On 8/04/2013, at 11:21 AM, Levent Erkok wrote: > It appears that the consensus is that this is a historical definition dating > back to the times when IEEE754 itself wasn't quite clear on the topic itself, > and "so nobody thought that hard about negative zeroes." (The quote is from a > comment from Lennart.) I would expect abs(f) to be identical to copysign(f, 1.0). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] abs on Float/Doubles
Hello all, I definitely do not want to create a yet another thread on handling of floating-point values in Haskell. My intention is only to see what can be done to make it more "compilant" with IEEE754. (Also, my interest is not a theoretical one, but rather entirely practical: I'm interested in using SMT solvers for reasoning about Haskell programs, in particular using the new SMT logics that cover IEEE-754 semantics. So, any discrepancy between Haskell and IEEE-754 is a cause for concern as we strive to build powerful tools around the Haskell eco-system.) In IEEE-754, there are two zero values: +0, and -0; inhabiting all floating point types. IEEE-754 requires these two compare equal, but be distinguished when used as arguments to functions as they can produce different results. (Unfortunately the standard is not freely available, but there's a nice discussion in wikipedia: http://en.wikipedia.org/wiki/Negative_zero.) As far as I know, Haskell's floating-point handling does *not* explicitly claim to be IEEE-754 compliant, but I think it's safe to assume that any serious implementation will take advantage of the underlying CPU's floating-point facilities; and thus will use IEEE-754 semantics. In particular, Haskell supports both +0 and -0; and you can distinguish them using the isNegativeZero function of the RealFloat class. Furthermore, the show instance for Float/Double will turn these two values to strings differently, preserving the minus sign if it receives a negative-zero. Comparisons follow the IEEE rules; so all these behaviors seem to be in accordance with IEEE754. Unfortunately, the same isn't true for the abs function. In Haskell, the call: "isNegativeZero (abs (-0::Double))" evaluates to "True". IEEE754 requires abs to always return "+0" in this case. The same also holds for the semantics of the newly proposed SMT-Lib logic for IEEE754: See section 3.3.1 (page 8) of: http://www.philipp.ruemmer.org/publications/smt-fpa.pdf The fix is easy. A one line change in the Double/Float instances of the Num class in the Prelude would guarantee the IEEE754 semantics. The reason I'm not simply posting this as a "library" issue is that it appears the topic came up in stack-overflow a while ago; without any clear resolution: http://stackoverflow.com/questions/10395761/absolute-value-of-negative-zero-bug-or-a-part-of-the-floating-point-standard It appears that the consensus is that this is a historical definition dating back to the times when IEEE754 itself wasn't quite clear on the topic itself, and "so nobody thought that hard about negative zeroes." (The quote is from a comment from Lennart.) I think it's a safe bet to assume IEEE754 semantics (for better or worse) is here to stay, and it would be nice to reduce any discrepancy we have in the Haskell libraries with respect to it. So, if there's consensus, I'd like to propose a library change to implement the proper IEEE754 semantics for the abs function for Double and Float types. Note that the argument is not really about semantics here, but rather with compliance to the accepted industrial standard. So, it would be best if we kept the discussion purely to the IEEE-compliance here, as opposed to relative merits of the semantics as defined. -Levent. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
Looks like a bug in cpphs to me (CC'ing Malcolm). It should respect
comments. E.g. GNU cpp strips C comments.
Roman
* John MacFarlane [2013-04-05 16:04:32-0700]
> I like markdown and use it all the time. While I acknowledge the
> problems that have been pointed out, markdown has the advantage of being
> easily readable "as it is" in the source document, and not looking like
> markup.
>
> But I do want to point out one problem with markdown as a format for
> documentation in Haskell files. Consider:
>
>
> module MyModule
> {-
> # Introduction
>
> This is my module
> -}
> where
> import System.Environment
>
> main = getArgs >>= print
>
>
> Now try to compile with -cpp, and you'll get an error because of the '#'
> in column 1. '#' in column 1 is common in markdown (and even
> indispensible for level 3+ headers).
>
> One could work around this by disallowing level 3+ headers, by allowing
> the headers to be indented, or by introducing new setext-like syntax for
> level 3+ headers, but it is a problem for the idea of using a markdown
> SUPERset.
>
> John
>
> +++ dag.odenh...@gmail.com [Apr 05 13 21:59 ]:
> >I forgot the mention the craziness with the *significant trailing
> >whitespace*.
> >
> >On Fri, Apr 5, 2013 at 9:49 PM, [1]dag.odenh...@gmail.com
> ><[2]dag.odenh...@gmail.com> wrote:
> >
> >Personally I think Markdown sucks, although perhaps less than Haddock
> >markup.
> >Still:
> >* No document meta data
> >* No code block meta data like language for syntax highlighting
> >* No tables
> >* No footnotes
> >* HTML fallback is insecure
> >* Confusing syntax (is it []() or ()[] for links?)
> >* Syntax that gets in the way (maybe I don't want *stars* emphasized)
> >* Above point leads to non-standard dialects like "GitHub Markdown"
> >(no, GitHub doesn't use markdown)
> >* Not extensible, leading to even more non-standard hacks and
> >work-arounds (GitHub Markdown, Pandoc Markdown, other Markdown
> >libraries have their own incompatible extensions)
> >* Not well suited for web input (e.g. four-space indentation for code
> >blocks), although not that important for Haddock
> >An important thing to note here is that no, Markdown has *not* won
> >because no one is actually using *Markdown*. They're using their own,
> >custom and incompatible dialects.
> >Only two of the above points apply to reStructuredText (web input and
> >syntax getting in the way), and those particular points don't apply to
> >Creole. Therefore I tend to advocate Creole for web applications and
> >reStructuredText for documents.
> >On Thu, Apr 4, 2013 at 6:49 PM, Johan Tibell
> ><[3]johan.tib...@gmail.com> wrote:
> >
> > Hi all,
> > Haddock's current markup language leaves something to be desired
> > once
> > you want to write more serious documentation (e.g. several
> > paragraphs
> > of introductory text at the top of the module doc). Several features
> > are lacking (bold text, links that render as text instead of URLs,
> > inline HTML).
> > I suggest that we implement an alternative haddock syntax that's a
> > superset of Markdown. It's a superset in the sense that we still
> > want
> > to support linkifying Haskell identifiers, etc. Modules that want to
> > use the new syntax (which will probably be incompatible with the
> > current syntax) can set:
> > {-# HADDOCK Markdown #-}
> > on top of the source file.
> > Ticket: [4]http://trac.haskell.org/haddock/ticket/244
> > -- Johan
> > ___
> > Haskell-Cafe mailing list
> > [5]Haskell-Cafe@haskell.org
> > [6]http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> > References
> >
> >1. mailto:dag.odenh...@gmail.com
> >2. mailto:dag.odenh...@gmail.com
> >3. mailto:johan.tib...@gmail.com
> >4. http://trac.haskell.org/haddock/ticket/244
> >5. mailto:Haskell-Cafe@haskell.org
> >6. 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] ANNOUNCE: binary-conduit-1.0
I'm happy to announce new binary-conduit [1] library, that's a serialization/deserialization library for using binary [2] package. [1] http://hackage.haskell.org/package/binary-conduit [2] http://hackage.haskell.org/package/binary -- Alexander ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: antiquoter-0.1.0.0
Hi, A late reply, I was a bit busy. My comments are inline On Thu, Apr 4, 2013 at 7:30 PM, Tillmann Rendel < ren...@informatik.uni-marburg.de> wrote: > Hi, > > L Corbijn wrote: > >> I'm happy to announce the release of my first package antiquoter, a >> >> combinator library for writing quasiquoters and antiquoters. The main >> aim is to simplify their definitions and reduce copy-and-paste >> programming. >> > > Very interesting. I'm using something similar to your EP class, but yours > looks more refined. See class PatOrExp in > https://github.com/Toxaris/pts/blob/master/src-lib/PTS/QuasiQuote.hs > That looks interesting. Maybe I should include your version of Lift, to extend the version of template-haskell to also work on patterns. > > I'm a bit overwhelmed by the rest of your library, though. Is the overall > design explained somewhere? > > It isn't really explained somewhere, so I should update the documentation with it. The basic idea is that you build an AntiQuoter out of separate AntiQuoterPass-es using (<<>) or (<>>). The resulting AntiQuoter can then be used by dataToExpQ/dataToPatQ to form the total QuasiQuote, or using the helper function mkQuasiQuoter. The pattern-expression similarity is build is build on top of this abstraction, where the result of the AntiQuoter(Pass) is fixed to any instance of the EP class. Which are then used to define quite a few combinators. Anyway, I'll try to update the documentation soon to make the design a bit clearer. > And: Your package description says that it is "especially aimed at making > user extensible antiquoters". That sounds very cool. Can you provide an > example for how the antiquoter package supports extensions, and what kinds > of extensions are supported? > > That aim should have been removed as it still is not done. But let me put it into context. The package started of as some reusable parts which I got from refactoring haskell-src-exts-qq. Its quasiquoter has three patterns to get something antiquoted each with their own special use cases. The problem was that I wanted something antiquoted which could not be done in one of those three patterns. Adding a fourth pattern has its problems, so I started antiquoter with one of the aims being to make antiquoters extensible by the user. I think I have got some ideas of how to do this, but I didn't find the time to add them. Lars >Tillmann > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers book in Haskell
I disagree about the recommendation for Modern Compiler Design: I found it to be a pretty good introduction to compiler technology, but not functional programming with compilers, it's coverage was *very* shallow. By contrast, I can recommend both Compiling with Continuations (the "standard" text on implementing compilers in functional languages, using ML as an example), and The Implementation of Functional Programming Languages [2]. This topic is covered pretty well in course material scattered throughout the web, (lots of course with online pdf sets about implementing functional compilers), but not in a comprehensive fashion that talks about more complex aspects of compiling functional languages. Implementing Functional Langauges: a tutorial, is also excellent and worth a look. kris [1] http://www.amazon.com/Compiling-Continuations-Andrew-W-Appel/dp/052103311X [2] http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/index.htm [3] http://research.microsoft.com/en-us/um/people/simonpj/Papers/pj-lester-book/ On Sun, Apr 7, 2013 at 4:36 AM, Sergey Bushnyak wrote: > Books about compilers is rare artifact, in comparison to some technology > books. It is uncommon to see topics on compilers for functional languages. > > I was surprised, when saw it in "Modern Compiler Design", which I've > mentioned earlier. "Compiler design" series from Springer maybe reveal > topics on FL in future as it become more popular. In new books about 1/5 of > it is about FL, but very basic stuff. > > Кnowledge mostly lies in research papers, occasional articles like "The > Glasgow Haskell Compiler"[1] in AOSA from creators, and source code :) > > > [1] http://www.aosabook.org/en/ghc.html > > -- > Best regards, > Sergey Bushnyak > > > ___ > 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] Compilers book in Haskell
On Sat, Apr 6, 2013 at 10:34 PM, Andrés Sicard-Ramírez < andres.sicard.rami...@gmail.com> wrote: > Juan, te puede interesar > > On Sat, Apr 6, 2013 at 5:56 PM, Sergey Bushnyak < > sergey.bushn...@sigrlami.eu> wrote: > >> I will recommend you book "Modern Compiler Design" by Dick Grune and >> others. >> Besides discussing different topics, authors use Haskell as example for >> describing ideas behind compilers for functional language. >> > > Sorry for the spam. The above email should not be sent to haskell-cafe. -- Andrés ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Error when building executable with profiling enabled
Krzysztof Skrzętnicki gmail.com> writes: > see this documentation on profiling with TH: http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/template-haskell.html#id624714 "GHC cannot load the profiled object code and use it when executing the splices." That means I do not get profiling information for the code that gets spliced in? Or for the code that is producing the splice? What's the work-around for the first case? (short of -ddump-splices, which seems somewhat problematic, according to http://hackage.haskell.org/trac/ghc/ticket/5016 ) - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] code-as-config, run-time checks and error locations
This one[1] sounds so awesome! I just read the paper. In particular I like how one could access the current call stack structure live. However, the most recent changes to the code are from early 2009. Anyone knows what happened to this? [1] http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack/CorePassImplementation ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is there an escape from MonadState+MonadIO+MonadError monad stack?
On Sun, Apr 7, 2013 at 5:03 AM, Ömer Sinan Ağacan wrote: > That's interesting, thanks! Do you have any recommendations about > which file to start reading? AFAIK, GHC is _huge_. Without a discussion of your interests, it's hard to say. Certainly, I'd set up the reading environment, namely an editor that can traverse from usage to point of definition and back. An interesting idea that occurred to me is to start with the file with the largest comments to code ratio. -- Kim-Ee ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers book in Haskell
Books about compilers is rare artifact, in comparison to some technology books. It is uncommon to see topics on compilers for functional languages. I was surprised, when saw it in "Modern Compiler Design", which I've mentioned earlier. "Compiler design" series from Springer maybe reveal topics on FL in future as it become more popular. In new books about 1/5 of it is about FL, but very basic stuff. Кnowledge mostly lies in research papers, occasional articles like "The Glasgow Haskell Compiler"[1] in AOSA from creators, and source code :) [1] http://www.aosabook.org/en/ghc.html -- Best regards, Sergey Bushnyak ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
