Re: [Haskell-cafe] [Conduit] weird action of leftover.
Yes, that's a fair explanation. On Tue, Apr 9, 2013 at 7:48 AM, Magicloud Magiclouds < magicloud.magiclo...@gmail.com> wrote: > Thank you for the reply. I've learnt the code of "lines". So it is because > how ByteString works, that the conduit is not a stream of bytes, but > chunks, right? > > > On Tue, Apr 9, 2013 at 12:12 PM, Michael Snoyman wrote: > >> It's a bug in your implementation of takeLine I believe. It doesn't take >> into account that lines can span multiple chunks. When you call takeLine >> the first time, you get "L1\n". leftover puts a chunk with exactly those >> contents back. When you call takeLine the second time, it gets the chunk >> "L1\n", and your splitAt gives you back "L1\n" and "". The "" is then >> leftover, and the next call to takeLine gets it. >> >> Your takeLine needs to include logic saying "there's no newline in this >> chunk at all, let's get the next chunk and try that." You can look at the >> source to lines[1] for an example of the concept. >> >> Michael >> >> [1] >> http://haddocks.fpcomplete.com/fp/7.4.2/20130313-1/conduit/src/Data-Conduit-Binary.html#lines >> >> >> On Mon, Apr 8, 2013 at 8:44 AM, Magicloud Magiclouds < >> magicloud.magiclo...@gmail.com> wrote: >> >>> 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 >>> >>> >> > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > 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] GSoC Project Proposal: Markdown support for Haddock
It supports ```language blocks, but not autolink detection. I have not fully documented which features are supported. I also haven't done any performance analysis versus other tools, simply because my goal is in no way high efficiency. It is fast enough for my use cases, and I don't intend to spend significant time optimizing unless a problematic level of inefficiency is discovered. If anyone else wants to put together benchmarks, I'll be happy to lend some guidance. On Mon, Apr 8, 2013 at 12:50 PM, Niklas Hambüchen wrote: > Could you elaborate a bit on which markdown features you support (or > even better: write it into your module haddocks)? > > Thinks like > - autolink detection > - ```language blocks? > > Also, you build on performance-oriented libraries - it would be cool if > you could make a small benchmark comparing with the standard > C/Python/Ruby parser implementations; AFAIK there is a standard Markdown > test suite that this could run against. > > Concerning the project proposal: > > I especially find the last feature useful for programming documentation, > and would love to have them in a potential haddock succesor. I was also > pleasantly surprised that pandoc seems to handle all of this (even with > code syntax highlighting). > > On 05/04/13 02:10, Michael Snoyman wrote: > > In case it can be useful in any way for this project, my markdown > > package[1] is certainly available for scavenging, though we'd likely > > want to refactor it to not use conduit (I can't imagine conduit being a > > good dependency for Haddock). > > > > [1] http://hackage.haskell.org/package/markdown > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Conduit] weird action of leftover.
Thank you for the reply. I've learnt the code of "lines". So it is because how ByteString works, that the conduit is not a stream of bytes, but chunks, right? On Tue, Apr 9, 2013 at 12:12 PM, Michael Snoyman wrote: > It's a bug in your implementation of takeLine I believe. It doesn't take > into account that lines can span multiple chunks. When you call takeLine > the first time, you get "L1\n". leftover puts a chunk with exactly those > contents back. When you call takeLine the second time, it gets the chunk > "L1\n", and your splitAt gives you back "L1\n" and "". The "" is then > leftover, and the next call to takeLine gets it. > > Your takeLine needs to include logic saying "there's no newline in this > chunk at all, let's get the next chunk and try that." You can look at the > source to lines[1] for an example of the concept. > > Michael > > [1] > http://haddocks.fpcomplete.com/fp/7.4.2/20130313-1/conduit/src/Data-Conduit-Binary.html#lines > > > On Mon, Apr 8, 2013 at 8:44 AM, Magicloud Magiclouds < > magicloud.magiclo...@gmail.com> wrote: > >> 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 >> >> > -- 竹密岂妨流水过 山高哪阻野云飞 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] [Conduit] weird action of leftover.
It's a bug in your implementation of takeLine I believe. It doesn't take into account that lines can span multiple chunks. When you call takeLine the first time, you get "L1\n". leftover puts a chunk with exactly those contents back. When you call takeLine the second time, it gets the chunk "L1\n", and your splitAt gives you back "L1\n" and "". The "" is then leftover, and the next call to takeLine gets it. Your takeLine needs to include logic saying "there's no newline in this chunk at all, let's get the next chunk and try that." You can look at the source to lines[1] for an example of the concept. Michael [1] http://haddocks.fpcomplete.com/fp/7.4.2/20130313-1/conduit/src/Data-Conduit-Binary.html#lines On Mon, Apr 8, 2013 at 8:44 AM, Magicloud Magiclouds < magicloud.magiclo...@gmail.com> wrote: > 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 > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Prolog-style patterns
There is no fundamental problem with non-linear patterns using ==. (The functional logic programming world long ago generalised the idea of unification to 'narrowing'.) There _is_ a technical problem in Haskell about whether the == here is necessarily the one from the Prelude or whether it might be a different == that is in scope: what would import Prelude hiding (Eq) x == y = x < y member x (x:_ ) = True member x (_:ys) = member x ys member _ [] = False mean? What, if anything, would it mean when no == is in scope? This is something that could be sorted out with good will. For example, you could say that it is a compile-time error if this notation is used and Prelude.== is not in scope. But since guards make the linear pattern restriction less poctalgic than it is in say ML, people have found other maddened grizzly bears to stun first. We had similar questions about n+k patterns, a feature that I still love. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Prolog-style patterns
Hi, On Mon, 2013-04-08 at 07:06 -0700, Conal Elliott wrote: > What you're suggesting is called "non-linear patterns", and it's a > perfectly sensible, well-defined feature in a language with > pattern-matching. As you point out, non-linearity allows for more direct & > succinct programming. I've often wished for this feature when writing > optimizations on data types, especially for syntactic types (languages). AFAIK pattern-match overlap checking is well defined for linear patterns, but it is not fully implemented and buggy in ghc (I found ~10 open tickets, most of them are pretty old). Will not it be a nightmare to implement and maintain checker for overlapping/unused clauses for non-linear patterns? We already have a number of language extensions without good warnings (and even worse -- with incorrect warnings): view patterns, overloaded literals, GADTs, etc. Thanks, Yuras ___ 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 Mon, Apr 8, 2013 at 3:49 PM, Ivan Lazar Miljenovic wrote: > On 9 April 2013 05:08, MigMit wrote: >> >> >> Отправлено с iPad >> >> 08.04.2013, в 21:44, Evan Laforge написал(а): >> >>> Can't we just add some features to haddock? >> >> No, we can't. At the very least we should FIX haddock before adding features. > > How specifically does haddock need to be fixed? Well, many of my specific suggestions could be considered fixes, rather than features. E.g. better parse errors, smarter quotes. ___ 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 9 April 2013 05:08, MigMit wrote: > > > Отправлено с iPad > > 08.04.2013, в 21:44, Evan Laforge написал(а): > >> Can't we just add some features to haddock? > > No, we can't. At the very least we should FIX haddock before adding features. How specifically does haddock need to be fixed? > > >> There are a lot of ways >> to improve haddock a lot, and no one is doing them, so my impression >> is that haddock doesn't really have active maintainers. Adding a >> whole new backend seems risky, unless it results in new maintainers >> joining. >> >> For my personal bikeshed contribution, I would like to see haddock >> move in the way of fewer markup characters and rules, not more. Since >> haddock is not "statically checked", the only way to find out if I put >> in an error is to run haddock and then visually inspect the output, >> unless of course it was a syntax error, in which case the error >> message is often not very good. I can easily haddock individual files >> since I have a custom build system, but I imagine cabal users would >> have to haddock the entire project every time. I regularly see >> haddock errors in released packages so I'm not the only one. >> >> There are lots of ways to improve haddock a lot. For example, better >> parse error messages. Make ""s smarter so they don't try to link >> things that are obviously not modules. Or complain if it's not a >> module. Or better, get rid of them entirely and use single quotes for >> that. And make single quotes work for non-imported symbols. >> Incremental support for cabal. Perhaps even deprecate @ and use ' for >> that too. >> >> One thing I think HTML got right is that there are only two characters >> that need to be quoted. Of course that's at the cost of all the >> markup being wordy, but the more you move in the markup-style DWIM the >> more little rules you have to remember. >> >> >> On Thu, Apr 4, 2013 at 6:00 PM, Johan Tibell wrote: Would it be too much to ask that a notation be used which has a formal syntax and a formal semantics? >>> >>> We will document our superset, sure. That's what others did as well. >>> The point is using Markdown as the shared base. >>> >>> ___ >>> 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.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [haskell.org Summer of Code 2013] We're In!
Thanks for working on this again this year! On Mon, Apr 8, 2013 at 12:50 PM, Edward Kmett wrote: > We (haskell.org) have been officially accepted into the Google Summer of > Code for 2013. We should show up in the mentoring organization list as soon > as I get some information we need to finalize the listing. > > Shachaf Ben-Kiki has volunteered to help out as our backup org administrator > this year. > > If you are thinking about joining up as a mentor or a student this year, now > would be a good time to start brainstorming about project ideas! > > I'll follow up with more information as soon as the listing goes in. > > In the meantime there is the #haskell-gsoc channel on irc.freenode.net. Feel > free to pester me (or Shachaf) with questions! > > -Edward Kmett > > ___ > 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] Prolog-style patterns
* Conal Elliott [2013-04-08 07:06:17-0700] > What you're suggesting is called "non-linear patterns", and it's a > perfectly sensible, well-defined feature in a language with > pattern-matching. One issue with it in Haskell is that it'd lead to inconsistent semantics: myEq x x = True is not the same as myEq x y = case y of x -> True IINM, in Erlang they have non-linear patterns, and no name shadowing, to be consistent. Roman ___ 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 [RESOLVED]
… and this works just fine. \o/ At least cabal now installs/builds the llvm 3.0.1.0 package successfully. So, normality has been restored… any remaining problems are therefore my own :-) That last reference has to be changed with the install_name_tool -id option (rather than -change) as indeed the first entry in the self-identification, rather than the paths of dependent libraries. -- Luke P.S. It would be great if the HP could have more frequent patches for critical issues like this. I've no problem with 6 monthly 'feature release' updates, but there are bound to be big defects for which a 6 month cycle is a very long time. Another similar one is that I found that yesod's development server doesn't run on 7.4.2 due to a bug (allegedly long since fixed). On 2013-04-08, at 10:08 AM, Luke Evans wrote: > OK, thanks again. I'll give that a whirl. > > On 2013-04-08, at 7:48 AM, Brandon Allbery wrote: > >> On Mon, Apr 8, 2013 at 1:32 AM, Luke Evans wrote: >> 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. >> >> To itself; that's actually the internal reference that gets compiled into >> the others, and as such is the actual source of the problem. (In an ELF >> shared object, that would be the soname. Note that it *must* be a full path >> on OS X, unlike Linux/ELF.) >> >> -- >> 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] %==%, :==: and type equality in the singletons library
On Mon, Apr 8, 2013 at 9:59 PM, Richard Eisenberg wrote: > > > On Apr 8, 2013, at 3:12 PM, Paul Brauner wrote: > > > from the output of -ddump-splices I dont think it is the case but I'm > asking anyway: is there any way to deduce a ~ b from a :==: b? > > Not easily. You would have to write a (potentially recursive) function > that explicitly matches singleton constructors, similarly to what you > wrote. (You could say that this function is a (potentially inductive) proof > that the generated definition of :==: is correct.) Ok. > I agree that this is boilerplate and could easily be generated. I've added > it to the list of features to be included in the next version of > singletons. I'm surprised myself that it hasn't occurred to me to include > this before. > > Great! Paul > Richard > > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] %==%, :==: and type equality in the singletons library
On Apr 8, 2013, at 3:12 PM, Paul Brauner wrote: > from the output of -ddump-splices I dont think it is the case but I'm asking > anyway: is there any way to deduce a ~ b from a :==: b? Not easily. You would have to write a (potentially recursive) function that explicitly matches singleton constructors, similarly to what you wrote. (You could say that this function is a (potentially inductive) proof that the generated definition of :==: is correct.) I agree that this is boilerplate and could easily be generated. I've added it to the list of features to be included in the next version of singletons. I'm surprised myself that it hasn't occurred to me to include this before. Richard ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [haskell.org Summer of Code 2013] We're In!
We (haskell.org) have been officially accepted into the Google Summer of Code for 2013. We should show up in the mentoring organization list as soon as I get some information we need to finalize the listing. Shachaf Ben-Kiki has volunteered to help out as our backup org administrator this year. If you are thinking about joining up as a mentor or a student this year, now would be a good time to start brainstorming about project ideas! I'll follow up with more information as soon as the listing goes in. In the meantime there is the #haskell-gsoc channel on irc.freenode.net. Feel free to pester me (or Shachaf) with questions! -Edward Kmett ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] %==%, :==: and type equality in the singletons library
Hello, from the output of -ddump-splices I dont think it is the case but I'm asking anyway: is there any way to deduce a ~ b from a :==: b? Given data T = C1 | ... | Cn I can easily derive data EqT :: T -> T -> * where EqT :: a ~ b => EqT a b eqT :: ST a -> ST b -> Maybe (EqT a b) eqT SC1 SC1 = Just EqT ... eqT SCn SCn = Just EqT eqT _ _ = Nothing but this kind of replicates the boilerplate generated by the singletons library for %==%. However I can't see how to leverage %==% to inhabit eqT since I can't deduce a ~ b from a %==% b == STrue. Any idea? If there's no way to write eqT using what singletons generates, wouldn't it make sense for it to generate something that relates :==: and ~ ? Cheers, Paul ___ 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
Отправлено с iPad 08.04.2013, в 21:44, Evan Laforge написал(а): > Can't we just add some features to haddock? No, we can't. At the very least we should FIX haddock before adding features. > There are a lot of ways > to improve haddock a lot, and no one is doing them, so my impression > is that haddock doesn't really have active maintainers. Adding a > whole new backend seems risky, unless it results in new maintainers > joining. > > For my personal bikeshed contribution, I would like to see haddock > move in the way of fewer markup characters and rules, not more. Since > haddock is not "statically checked", the only way to find out if I put > in an error is to run haddock and then visually inspect the output, > unless of course it was a syntax error, in which case the error > message is often not very good. I can easily haddock individual files > since I have a custom build system, but I imagine cabal users would > have to haddock the entire project every time. I regularly see > haddock errors in released packages so I'm not the only one. > > There are lots of ways to improve haddock a lot. For example, better > parse error messages. Make ""s smarter so they don't try to link > things that are obviously not modules. Or complain if it's not a > module. Or better, get rid of them entirely and use single quotes for > that. And make single quotes work for non-imported symbols. > Incremental support for cabal. Perhaps even deprecate @ and use ' for > that too. > > One thing I think HTML got right is that there are only two characters > that need to be quoted. Of course that's at the cost of all the > markup being wordy, but the more you move in the markup-style DWIM the > more little rules you have to remember. > > > On Thu, Apr 4, 2013 at 6:00 PM, Johan Tibell wrote: >>> Would it be too much to ask that a notation be used which has >>> a formal syntax and a formal semantics? >> >> We will document our superset, sure. That's what others did as well. >> The point is using Markdown as the shared base. >> >> ___ >> 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 Apr 2013, at 14:52, Roman Cheplyaka wrote:
>> In my opinion, it is perfectly valid to have intentional preprocessor
>> directives inside Haskell comments.
>
> Could you give an example where this is useful?
> ... macro expansions inside the comments are rather exotic.
{- | Some module documentation.
#define WEBSITE
http://some.really.rather.long/and/tedious/URL/that_I_dont_want_to_type_too_often
You can find more information about Foo at WEBSITE/Foo and Bar at WEBSITE/Bar
-}
As you say, the #define could equally live outside the comment, but I don't see
why we should have an arbitrary restriction that it _must_ live outside the
comment. As you also say, "the liberty to write whatever one wants inside a
comment feels important", and if that includes the intentional use of CPP, why
not?
Regards,
Malcolm
___
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
Can't we just add some features to haddock? There are a lot of ways to improve haddock a lot, and no one is doing them, so my impression is that haddock doesn't really have active maintainers. Adding a whole new backend seems risky, unless it results in new maintainers joining. For my personal bikeshed contribution, I would like to see haddock move in the way of fewer markup characters and rules, not more. Since haddock is not "statically checked", the only way to find out if I put in an error is to run haddock and then visually inspect the output, unless of course it was a syntax error, in which case the error message is often not very good. I can easily haddock individual files since I have a custom build system, but I imagine cabal users would have to haddock the entire project every time. I regularly see haddock errors in released packages so I'm not the only one. There are lots of ways to improve haddock a lot. For example, better parse error messages. Make ""s smarter so they don't try to link things that are obviously not modules. Or complain if it's not a module. Or better, get rid of them entirely and use single quotes for that. And make single quotes work for non-imported symbols. Incremental support for cabal. Perhaps even deprecate @ and use ' for that too. One thing I think HTML got right is that there are only two characters that need to be quoted. Of course that's at the cost of all the markup being wordy, but the more you move in the markup-style DWIM the more little rules you have to remember. On Thu, Apr 4, 2013 at 6:00 PM, Johan Tibell wrote: >> Would it be too much to ask that a notation be used which has >> a formal syntax and a formal semantics? > > We will document our superset, sure. That's what others did as well. > The point is using Markdown as the shared base. > > ___ > 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] llvm-3.0.1.0 installation on Mac
OK, thanks again. I'll give that a whirl. On 2013-04-08, at 7:48 AM, Brandon Allbery wrote: > On Mon, Apr 8, 2013 at 1:32 AM, Luke Evans wrote: > 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. > > To itself; that's actually the internal reference that gets compiled into the > others, and as such is the actual source of the problem. (In an ELF shared > object, that would be the soname. Note that it *must* be a full path on OS X, > unlike Linux/ELF.) > > -- > 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] GSoC Project Proposal: Markdown support for Haddock
+++ John MacFarlane [Apr 05 13 16:04 ]:
> 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
Let me amplify my original comment with one more observation about
problems using markdown to comment Haskell code.
Markdown blockquotes start with '>' (usually in the leftmost column).
But this causes problems when your source document is bird-style
literate Haskell:
--
This is my literate Haskell module. As
someone said:
> literate Haskell is great!
Oops, that will be interpreted by GHC
as code, not comment.
> main = print $ reverse [1,2]
--
You can work around this by indenting the first '>' one space, which is
still valid Markdown, but it's a bit awkward. Obviously, we'd want any
Haddock markup successor to work in literate Haskell too.
reStructuredText has fewer potential conflicts and might be a more
sensible choice. But one would need to write a correct parser for
it. The pandoc parser doesn't cover 100% of rST, and differs in other
ways from the docutils parser (e.g. it allows markup inside links).
For full compatibility you'd probably want to copy the python module's
parsing algorithm exactly.
John
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Prolog-style patterns
This is a recurring theme, see also here: http://www.haskell.org/pipermail/haskell-cafe/2009-May/061498.html On 8 April 2013 16:53, Tom Murphy wrote: > > Also, for some history, this was discussed a while back: > http://www.mail-archive.com/haskell@haskell.org/msg03721.html > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Prolog-style patterns
On Mon, Apr 8, 2013 at 7:59 AM, Joachim Breitner wrote: > Hi, > > I believe one problem with non-linear patterns would be that the > compiler has to figure out what notion of equality you want here. An > obvious choice is (==), but the Eq instances might not do what you want. > Using pattern guards or view patterns explicates this choice. > What other types of equality would be possibilities? Also, for some history, this was discussed a while back: http://www.mail-archive.com/haskell@haskell.org/msg03721.html Erlang programmers have this feature without shooting themselves in the foot too often. That said, I'm happy without it. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Prolog-style patterns
Hi, I believe one problem with non-linear patterns would be that the compiler has to figure out what notion of equality you want here. An obvious choice is (==), but the Eq instances might not do what you want. Using pattern guards or view patterns explicates this choice. Also, without an explicit call to == the cost model of such a function definition might be harder to see; an innocent looking change to the patterns of a function could cause a considerable amount of extra work if == is expensive. Greetings, Joachim Am Montag, den 08.04.2013, 07:06 -0700 schrieb Conal Elliott: > Hi Jan, > > What you're suggesting is called "non-linear patterns", and it's a > perfectly sensible, well-defined feature in a language with > pattern-matching. As you point out, non-linearity allows for more > direct & succinct programming. I've often wished for this feature when > writing optimizations on data types, especially for syntactic types > (languages). > > As Ivan mentioned, there is some danger that people may accidentally a > non-linear pattern accidentally, and perhaps the early Haskell > designers chose the linearity restriction out of this worry. The > importance of such dangers is a subjective call, and certainly not one > carried out consistently in Haskell. Consider, for instance, the > choice that let & where bindings are recursive by default in Haskell, > unlike ML and Lisp. I like this choice, but I can understand > objections that it leads to accidental recursions, especially for > non-functions. > > > > -- Conal > > > > > On Mon, Apr 8, 2013 at 6:11 AM, Jan Stolarek > wrote: > > You can achieve something similar with the ViewPatterns > language > > extension. > > > > > member _ [] = False > > member x (((x ==) -> True) : _) = True > > member x (_ : xs) = member x xs > > Hi Tillmann, > > there are a couple of ways to achieve this in Haskell, for > example using guards: > > member :: Eq a => a -> [a] -> Bool > member _ [] = False > > member y (x:_) | x == y = True > member y (_:xs) = member y xs > > The goal of my proposal is to provide a concise syntax, > whereas ViewPatterns are very verbose and > guards are slightly verbose. I want something simple and > something that is very intuitive if > you've programmed in Prolog :) > > Janek > > ___ > 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 -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ 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 1:32 AM, Luke Evans wrote: > 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. > To itself; that's actually the internal reference that gets compiled into the others, and as such is the actual source of the problem. (In an ELF shared object, that would be the soname. Note that it *must* be a full path on OS X, unlike Linux/ELF.) -- 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] Prolog-style patterns
Hi Jan, What you're suggesting is called "non-linear patterns", and it's a perfectly sensible, well-defined feature in a language with pattern-matching. As you point out, non-linearity allows for more direct & succinct programming. I've often wished for this feature when writing optimizations on data types, especially for syntactic types (languages). As Ivan mentioned, there is some danger that people may accidentally a non-linear pattern accidentally, and perhaps the early Haskell designers chose the linearity restriction out of this worry. The importance of such dangers is a subjective call, and certainly not one carried out consistently in Haskell. Consider, for instance, the choice that let & where bindings are recursive by default in Haskell, unlike ML and Lisp. I like this choice, but I can understand objections that it leads to accidental recursions, especially for non-functions. -- Conal On Mon, Apr 8, 2013 at 6:11 AM, Jan Stolarek wrote: > > You can achieve something similar with the ViewPatterns language > > extension. > > > > member _ [] = False > > member x (((x ==) -> True) : _) = True > > member x (_ : xs) = member x xs > Hi Tillmann, > > there are a couple of ways to achieve this in Haskell, for example using > guards: > > member :: Eq a => a -> [a] -> Bool > member _ [] = False > member y (x:_) | x == y = True > member y (_:xs) = member y xs > > The goal of my proposal is to provide a concise syntax, whereas > ViewPatterns are very verbose and > guards are slightly verbose. I want something simple and something that is > very intuitive if > you've programmed in Prolog :) > > Janek > > ___ > 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
* Ivan Lazar Miljenovic [2013-04-08 10:18:32+1000]
> 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
This seems to be a different issue — about unlit, not cpp.
> > * 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
> >>
> >>
> >> ___
> >
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
* Malcolm Wallace [2013-04-08 10:00:11+0100]
> And cpphs strips C comments too. :-)
>
> But seriously, John's use-case is the exact opposite of what you
> suggest. John wants to keep the # inside the comment block. You
> suggest to remove the comment-block altogether?
No, my point was that the preprocessor has to be aware of the language's
comments, and treat them accordingly. In this case, "accordingly"
probably means leave them intact.
> When I checked the example with cpphs, it turns out that the # line is
> retained, generating a warning but not an error. I expect Gnu cpp is
> the software that throws an error.
>
> In my opinion, it is perfectly valid to have intentional preprocessor
> directives inside Haskell comments.
Could you give an example where this is useful?
#ifs and #ifdefs can be moved outside of the comment most of the time.
And macro expansions inside the comments are rather exotic.
On the other hand, the liberty to write whatever one wants inside a
comment feels important to me.
> On 7 Apr 2013, at 22: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.
> >
> > 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
>
Re: [Haskell-cafe] Prolog-style patterns
Hi Jan, On one hand, I've never really needed this. On the other hand, it looks like a nice syntaxic sugar addition, so if you implemented this I would probably give it a try. David. 2013/4/8 Jan Stolarek > > You can achieve something similar with the ViewPatterns language > > extension. > > > > member _ [] = False > > member x (((x ==) -> True) : _) = True > > member x (_ : xs) = member x xs > Hi Tillmann, > > there are a couple of ways to achieve this in Haskell, for example using > guards: > > member :: Eq a => a -> [a] -> Bool > member _ [] = False > member y (x:_) | x == y = True > member y (_:xs) = member y xs > > The goal of my proposal is to provide a concise syntax, whereas > ViewPatterns are very verbose and > guards are slightly verbose. I want something simple and something that is > very intuitive if > you've programmed in Prolog :) > > Janek > > ___ > 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] My first Haskell program
Hi John, I am not saying it's wrong, but something you could consider trying is using the RVars to generate the random numbers inside MonadRandom and using lift to lift the random number generation into the state Monad and use runStateT. The IO Monad is an instance of MonadRandom so any State + MonadRandom computation can be run inside the IO Monad. I will write a short piece of code to illustrate my point. import Data.Random.Distribution.Uniform import Control.Monad.State import Data.RVar ... randomState n = do let dist = uniform 1 n rNum <- lift $ sampleRVar dist put rNum runStateT (randomState 5) 0 Using RVars, you can generate numbers from numerous distributions. You can even have pure RVars which generate values according to a distribution once an initialization seed is given. I hope this information serves you well. Check out the RVar package in Haskell for more about generating random numbers. Best, Ernesto Rodriguez On Sat, Apr 6, 2013 at 6:50 PM, John Wood wrote: > Hello, Cafe > > I'm new to Haskell and the mailing list, and am wondering if I could get > some feedback on my first program -- a Markov text generator. The code is > posted here: > > http://codereview.stackexchange.com/questions/24791/haskell-markov-text-generator > > Thanks, > > John; > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Ernesto Rodriguez Bachelor of Computer Science - Class of 2013 Jacobs University Bremen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Prolog-style patterns
> You can achieve something similar with the ViewPatterns language > extension. > > member _ [] = False > member x (((x ==) -> True) : _) = True > member x (_ : xs) = member x xs Hi Tillmann, there are a couple of ways to achieve this in Haskell, for example using guards: member :: Eq a => a -> [a] -> Bool member _ [] = False member y (x:_) | x == y = True member y (_:xs) = member y xs The goal of my proposal is to provide a concise syntax, whereas ViewPatterns are very verbose and guards are slightly verbose. I want something simple and something that is very intuitive if you've programmed in Prolog :) Janek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Prolog-style patterns
Hi, Jan Stolarek wrote: If Haskell allowed to write pattern matching similar to Prolog then we could write this function like this: member :: Eq a => a -> [a] -> Bool member _ [] = False member x (x:_) = True member x (_:xs) = member x xs The meaning of pattern in the second equation is "match this equation if the first argument equals to head of the list". You can achieve something similar with the ViewPatterns language extension. See http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns and http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns. member _ [] = False member x (((x ==) -> True) : _) = True member x (_ : xs) = member x xs or member _ [] = False member x ((compare x -> EQ) : _) = True member x (_ : xs) = member x xs Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Prolog-style patterns
On 8 April 2013 21:11, Jan Stolarek wrote: > Hi all, > > consider this simple reimplementation of 'elem' function: > > member :: Eq a => a -> [a] -> Bool > member _ [] = False > member y (x:xs) | x == y= True > | otherwise = member y xs > > If Haskell allowed to write pattern matching similar to Prolog then we could > write this function > like this: > > member :: Eq a => a -> [a] -> Bool > member _ [] = False > member x (x:_) = True > member x (_:xs) = member x xs > > The meaning of pattern in the second equation is "match this equation if the > first argument equals > to head of the list". Many times I have found myself instinctively writing > patterns in this way, > only to get a compilation error. I was thinking about implementing language > extension for GHC > that would allow to write Prolog-style patterns. Would there be an interest > in such an extension? > Also, if I missed something obvious please let me know. My initial take on this is that such capabilities would be too easy to mis-use accidentally; e.g. refactoring and changing variable names, thus causing patterns to match when you don't mean them to. > > Janek > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Prolog-style patterns
Hi all, consider this simple reimplementation of 'elem' function: member :: Eq a => a -> [a] -> Bool member _ [] = False member y (x:xs) | x == y= True | otherwise = member y xs If Haskell allowed to write pattern matching similar to Prolog then we could write this function like this: member :: Eq a => a -> [a] -> Bool member _ [] = False member x (x:_) = True member x (_:xs) = member x xs The meaning of pattern in the second equation is "match this equation if the first argument equals to head of the list". Many times I have found myself instinctively writing patterns in this way, only to get a compilation error. I was thinking about implementing language extension for GHC that would allow to write Prolog-style patterns. Would there be an interest in such an extension? Also, if I missed something obvious please let me know. Janek ___ 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
Could you elaborate a bit on which markdown features you support (or even better: write it into your module haddocks)? Thinks like - autolink detection - ```language blocks? Also, you build on performance-oriented libraries - it would be cool if you could make a small benchmark comparing with the standard C/Python/Ruby parser implementations; AFAIK there is a standard Markdown test suite that this could run against. Concerning the project proposal: I especially find the last feature useful for programming documentation, and would love to have them in a potential haddock succesor. I was also pleasantly surprised that pandoc seems to handle all of this (even with code syntax highlighting). On 05/04/13 02:10, Michael Snoyman wrote: > In case it can be useful in any way for this project, my markdown > package[1] is certainly available for scavenging, though we'd likely > want to refactor it to not use conduit (I can't imagine conduit being a > good dependency for Haddock). > > [1] http://hackage.haskell.org/package/markdown ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Vector Fabrics is hiring!
On Mon 08 Apr 2013 17:19:08 SGT, Oliver Charles wrote: >> * Your friends and colleagues describe you as a "rockstar" programmer; >>your programming ability is way above average; > Good luck hiring smart people. I get a high score in http://areyouabrogrammer.com - does that qualify me for the above point? :D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Vector Fabrics is hiring!
On 04/08/2013 06:30 AM, Stefan Holdermans wrote: * Your friends and colleagues describe you as a "rockstar" programmer; your programming ability is way above average; Good luck hiring smart people. ___ 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
And cpphs strips C comments too. :-)
But seriously, John's use-case is the exact opposite of what you suggest. John
wants to keep the # inside the comment block. You suggest to remove the
comment-block altogether?
When I checked the example with cpphs, it turns out that the # line is
retained, generating a warning but not an error. I expect Gnu cpp is the
software that throws an error.
In my opinion, it is perfectly valid to have intentional preprocessor
directives inside Haskell comments.
Regards,
Malcolm
On 7 Apr 2013, at 22: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.
>
> 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
>>
>>
>> ___
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
On 6 April 2013 01:57, John Wiegley wrote: > > Johan Tibell writes: > > > I suggest that we implement an alternative haddock syntax that's a > superset > > of Markdown. > > Definite +1 from me too. > +1 Conrad. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
