[Haskell-cafe] Reminder to file Haddock bugs on Trac.
This is just a friendly reminder that if you have any issues with Haddock that you would like to get looked at, you should probably be making your way to the Haddock Trac[1] now. If you already have open tickets, you can probably get them looked at if you reply to this thread. Unfortunately there are a lot of old tickets so it's difficult to tell what's still desired, what's still a problem, what has been solved outside of Trac and not marked and so on. Thanks! [1]: http://trac.haskell.org/haddock/ -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen
need to solve a testing problem before I push it up. On the side I started to implement a Markdown implementation that Niklas seems very eager to have, even if that means a lot less features available when using it. Personally, I don't think it will be nice to use at all seeing that some Markdown AND Hadock features will be missing and some of the syntax has to be semantically altered so it's more of a proof of concept. Hopefully a Pandoc writer would solve this problem for us: considering how far along we are in the GSoC timeline, I'd much rather keep adding functionality and fix bugs than to add implementation and maintenance burden for a rather incomplete Markdown implementation. Please, do tell us what you need doing for the writer. Best way to do this is to file a ticket on Haddock Trac http://trac.haskell.org/haddock/ . If the ticket exists already, let me know (here or on Trac) and I'll see whether I could prioritise it a bit more. John +++ Mateusz Kowalczyk [Aug 30 13 02:30 ]: Greetings café, Perhaps some saddening news for Markdown fans out there. As you might remember, there was a fair amount of push for having Markdown as an alternate syntax for Haddock. Unfortunately, this is probably not going to happen for reasons listed on the post I just published at [1]. This thread is meant to be for discussion about the post as many people, myself included, felt that Markdown would be a nice thing to have. I feel like I covered the topic fairly well on the post but feel free to give suggestions or ask questions. I would also like to remind you that if there's something that you'd like to see in Haddock or something that you feel is broken, a good way express this is to make a ticket on the Haddock Trac[2]. I will close the relevant Markdown ticket on the Trac[3] in about 3 days, unless someone can come up with a reasonable solution that meets the initial intent of this part of the project: a widely known markup format that could be used as an alternate syntax for Haddock so that it's possible to write the documentation without learning the vanilla syntax itself. [1]: http://fuuzetsu.co.uk/blog/posts/2013-08-30-why-Markdown-in-Haddock-can't-happen.html [2]: http://trac.haskell.org/haddock [3]: http://trac.haskell.org/haddock/ticket/244 -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can I use String without in ghci?
On 01/09/13 07:02, yi lu wrote: I want to know if it is possible that I use strings without . If I type *Preludefoo bar* which actually I mean *Preludefoo bar* However I don't want to type s. I have noticed if *bar* is predefined or it is a number, it can be used as arguments. But can other strings be used this way? Like in bash, we can use *ping 127.0.0.1* where *127.0.0.1* is an argument. If not, can *foo* be defined as a function so that it recognize arguments like *bar* as *bar*? Thanks, Yi Lu You can't do this non-trivially. I think your only bet would be Template Haskell using the second approach and even then, it's a huge, huge stretch. I highly recommend against such ideas though. Do you really want anything that's not bound to be treated as a String? (The answer is ‘no’). I suggest that you get used to ‘’s. If you have deep hatred for ‘’, you could resort to spelling out the strings like ['f', 'o', 'o'] or even 'f':'o':'o':[]. It's a bit like asking whether you can do addition everywhere by just typing the numbers to each other (no cheating and defining number literals as functions ;) ). -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen
On 01/09/13 13:59, Niklas Hambüchen wrote: On 01/09/13 04:27, Mateusz Kowalczyk wrote: It doesn't have to be 1-to-1 but the features have to be expressible in both: it's useless if we have different features with one syntax but not the other. I don't find that useless. Markdown does not have definition lists, but we use a normal list to achieve the same documentation goals. Already being able to simply write basic markdown would bring me big practical benefits, and I would prefer minor theoretical misalignments not to outweigh them. I haven't considered it this way before. I'll try to implement it today as an experiment and hopefully show-off the result so we can see whether it's worth using. -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen
On 31/08/13 16:20, Carter Schonwald wrote: Is there an up todate copy of the haddock manual online anywhere? No. You can build your own documentation. In Haddock directory, go into ‘doc’ and read the README on how to build it. That is also outdated however: for example, it doesn't provide information about the image syntax (image). New documentation will be written soon as the stuff I have been doing added and changed quite a bit. This will most likely come out before any actual release is made because I'd like to include a small guideline on migrating your docs to the new version. Nothing big should break and in huge majority of cases you shouldn't need to do anything but there are a few quirks that are gone that might change how your things look under some cases (mostly in cases of ill-formed docs). On Saturday, August 31, 2013, Omari Norman wrote: On Thu, Aug 29, 2013 at 9:30 PM, Mateusz Kowalczyk wrote: Greetings café, Perhaps some saddening news for Markdown fans out there. As you might remember, there was a fair amount of push for having Markdown as an alternate syntax for Haddock. This is a little off-topic, but the Haddock website apparently is years out of date. http://www.haskell.org/haddock/ says the latest version is 2.8.0 released in September 2010, but apparently I have 2.13.2 on my machine. The latest stable is indeed 2.13.2. Hopefully this will be updated fairly soon, AFAIK there was some miscommunication on who got the write permissions or something but I might just be misremembering. -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On Markdown in Haddock and why it's not going to happen
On 31/08/13 19:14, Niklas Hambüchen wrote: Hello, I disagree. That's fine, that's why the thread is here. While none of your detail points are wrong, they mainly focus on the fact that there is no 1-to-1 mapping between the existing haddock markup and Markdown. I don't think there needs to be. It doesn't have to be 1-to-1 but the features have to be expressible in both: it's useless if we have different features with one syntax but not the other. If Markdown can do something new, that something can be added; if something doesn't make sense in Haddock (like horizontal rules), we ignore them. This is precisely what I have been doing and why my post went over every point from the original Markdown documentation, talking about why each of these does or doesn't make sense. In the end, Markdown offers us nothing new feature wise and either forces us to make up new syntax for things it doesn't know about (definition lists) or makes us remove existing features all together. Once any not-HTML-specific (tags, rules) features that might be missing are implemented, we're left with something that looks very much like Markdown already. Alternate syntax would also look very much like Markdown but in a different, less known way. Not very nice. Basically, Markdown brings nothing new to the table that we can actually use and we're in fact making it less familiar by having to strip and add syntax. I don't think original and markdown syntax should be mixed in the same file. That would make everything impossible to parse and difficult to write. Agreed. See point above why this isn't practical anyway. We'd be piling features on top of Markdown, defeating the point of having familiar-to-others syntax. As for which markdown implementation to use: I think it really doesn't matter that much in practice. Github and pandoc can both render documentation to my pleasing; I have yet to find a difference between them that would be a practical problem for my documentation efforts. Unfortunately it _does_ matter in practice because each flavour solves Markdown quirks differently. On top of this, we have to accomodate for Haddock specific features. We're effectively creating our own flavour of Markdown + extra syntax. This sounds like… Haddock markup! Regarding module and type links: They are links, so probably just representing them as Markdown links would be cleanest. [SomeThing]() with an empty reference could make haddock automatically figure out what is wanted or default to a type, and you could be explicit with [SomeThing](module), [SomeThing](type) and [SomeThing](class). For headings, why is CPP a problem? CPP ignores haddock comments, haddock should ignore CPP. There is no reason to put CPP macros into comments. I have to admit that I did not explore this very carefully but you we can't simply guarantee that no one every will run CPP on their files by hand. Better safe than sorry. I actually implemented headings for function docs using the ‘ Heading 4’ syntax, avoiding this problem all together. Regarding emphasis, **foo** would simply not be a heading in an export list. Using markdown haddock, we will have markdown headings for that. But what if I want it to be a heading? Are we picking rules arbitrarily now? Markdown being claimed to be for editing documents for the Web doesn't make our efforts impossible. Pandoc can easily create latex output from it, and Github can use it as a documentation language for programming perfectly fine. So can we. That's because you can use LaTeX to render everything that HTML can (but not the other way around!). GitHub can use it because they don't have the burden of having to accommodate for an existing feature set of a different markup language. Note how GitHub Markdown doesn't have all the features of Haddock, therefore it is _not_ compatible with it. We can't just use their Markdown because it doesn't cover our use cases. Did I address all your points? You addressed some of them, but I hope I reasoned for them well above. What you haven't provided is how such Markdown could possibly look, noting the original goal of this: be an alternate syntax that's familiar to people already. If you can come up with such thing without losing any features and being distinct enough from Haddock markup to warrant it, I would love to hear it. Niklas -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] On Markdown in Haddock and why it's not going to happen
Greetings café, Perhaps some saddening news for Markdown fans out there. As you might remember, there was a fair amount of push for having Markdown as an alternate syntax for Haddock. Unfortunately, this is probably not going to happen for reasons listed on the post I just published at [1]. This thread is meant to be for discussion about the post as many people, myself included, felt that Markdown would be a nice thing to have. I feel like I covered the topic fairly well on the post but feel free to give suggestions or ask questions. I would also like to remind you that if there's something that you'd like to see in Haddock or something that you feel is broken, a good way express this is to make a ticket on the Haddock Trac[2]. I will close the relevant Markdown ticket on the Trac[3] in about 3 days, unless someone can come up with a reasonable solution that meets the initial intent of this part of the project: a widely known markup format that could be used as an alternate syntax for Haddock so that it's possible to write the documentation without learning the vanilla syntax itself. [1]: http://fuuzetsu.co.uk/blog/posts/2013-08-30-why-Markdown-in-Haddock-can't-happen.html [2]: http://trac.haskell.org/haddock [3]: http://trac.haskell.org/haddock/ticket/244 -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Building recent Cabal/cabal-install
Greetings café, There are some problems in Haddock to do with Template Haskell that I believe are being caused by Cabal. These were apparently addressed in 1.18 which came out recently. ‘Great!’, I thought. My problem is that I'm unsure how to use 1.18. I'm using GHC HEAD (well, 3 days old now) which is meant to come with Cabal 1.18 (the library) and in fact it seems to ship with it. Running ‘cabal --version’ however: cabal-install version 1.17.0 using version 1.17.0 of the Cabal library I'm unsure how to get it to use 1.18. I tried to build cabal-install from git but that just complains about dependencies not being possible to resolve: it depends on HTTP which depends on base 4.7 but 4.7 comes with GHC HEAD! I am baffled as to how I should go about using 1.18 and would love to hear from some people who have this up and running. -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle vs Hayoo
On 23/08/13 14:57, jabolo...@google.com wrote: It's a bit pointless, if I have to know the package, where I want to search in. Yeah! It does sound a bit pointless. Hoogle should search everything by default, and then you can refine your search by clicking on the '+' or '-' on the packages that appear on the left menu. Jose +1 to this, I never even knew this functionality existed. Why not have a checkbox or something along these lines to enable the search in all packages? This wouldn't change the old behaviour by default and it would allow for a wider search. -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle vs Hayoo
On 22/08/13 19:30, jabolo...@google.com wrote: Hi, I noticed Hayoo appears as a link in the toolbox of http://hackage.haskell.org and also that Hayoo seems to display better results than Hoogle. For example, if you search for 'PublicKey' in Hayoo, you will get several results from Hackage libraries, such as, 'crypto-pubkey' and 'crypto-api'. However, the same query in Hoogle displays no results. Is Hayoo the default Hackage search engine ? Is Hoogle deprecated ? What the status ? Thank you, Jose You could also try the Hoogle hosted by FPComplete guys, it indexes more stuff. It's at [1]. I hear that Hayoo actually does a better job getting the relevant results but I am unsure how much truth there is to it. I always thought it was just Hoogle with more indexed docs. [1] - https://www.fpcomplete.com/hoogle -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: haskell-src-exts 1.14.0
On 20/08/13 09:48, Niklas Hambüchen wrote: Nice! I hope that haskell-suite will eventually become awesome and solve most of our automation-on-Haskell-code needs. Two questions: 1) My most desired feature would be a syntax tree that does not pluck pluck comments out and make me treat them separately. It looks much easier to me to have a fully descriptive tree and (filter . concatMap) / traverse them out in some way than getting a list of comments and having to insert them back in the right places myself. Is that possible? +1 for this. There was a small discussion relevant to this on café recently, if anyone is interested: http://comments.gmane.org/gmane.comp.lang.haskell.cafe/106768 2) Have you considered downloading the all-of-Hackage tarball and running haskell-src-exts over it to get a benchmark of how much HSE can already parse of the Haskell code out there? Thanks! -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: haskell-src-exts 1.14.0
On 20/08/13 11:02, JP Moresmau wrote: BuildWrapper has some code that tries to link back the comments to the declaration from the AST generated by haskell-src-exts and the comments. See https://github.com/JPMoresmau/BuildWrapper/blob/master/src/Language/Haskell/BuildWrapper/Src.hs. The unit tests provide some samples: https://github.com/JPMoresmau/BuildWrapper/blob/master/test/Language/Haskell/BuildWrapper/CMDTests.hs#L572-L638. Maybe this can help you. JP It certainly look like I might be able to learn from this. Thank you. -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: haskell-src-exts 1.14.0
On 20/08/13 11:56, Dag Odenhall wrote: Good stuff! Is there any way, or plans for a way, to parse a file based on its LANGUAGE pragmas? Last I checked e.g. HSP simply enabled all extensions when parsing, which can cause code to be parsed incorrectly in some cases. Can you give any examples of such cases? I had recently been asked about this and could not come up with much at all. -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] inv f g = f . g . f
On 17/08/13 10:11, Christopher Done wrote: Anyone ever needed this? Me and John Wiegley were discussing a decent name for it, John suggested inv as in involution. E.g. First thing I thought was ‘inverse’… inv reverse (take 10) inv reverse (dropWhile isDigit) trim = inv reverse (dropWhile isSpace) . dropWhile isSpace That seems to be the only use-case I've ever come across. I do this a lot as well. Why not skip the ‘g’ all together and have ‘f . reverse . f’ if that's all we're doing? You could even call it fromEnd at that point and we end up with a rather intuitive ‘fromEnd (drop 10)’. Maybe even just have an operator. There's also this one: co f g = f g . g which means you can write trim = co (inv reverse) (dropWhile isSpace) but that's optimizing an ever rarer use-case. Is this a proposal for addition to something or is it just general discussion? -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock multiple definitions
On 15/08/13 23:07, jabolo...@google.com wrote:
Hi,
I cannot find a similar ticket, so it seems that no one has filed this
issue before. As a general comment, I think this issue is a good
example that perhaps docstrings should go in the AST.
In any case, I would ask someone with a trac account in Haddock to
submit this ticket for me. I apologize for the inconvenience, but,
for privacy concerns, I don't want an account in Haddock trac and it
does not seem possible to submit a ticket without first creating one.
Thanks,
Jose
On Fri, Aug 16, 2013 at 12:51:35AM +0300, Roman Cheplyaka wrote:
In any case, it shouldn't fail with a parse error, since this is valid
Haskell.
Please file a ticket at http://trac.haskell.org/haddock (but first see
if it hasn't been reported before).
Roman
* jabolo...@google.com jabolo...@google.com [2013-08-15 15:24:23-0400]
Hi,
I am using
GHC: 6.12.1
Haddock: 2.6.0
and the following does not work with Haddock (GHC is fine!):
-- Main
-- | Blah blah blah
(x, y, z) = (1, 2, 3)
$ haddock ...
/tmp/Main.hs:2:0: parse error on input `('
Is this a bug? Or it's just not part of Haddock?
This seems like an interesting feature to document several definitions
together, for example, error codes:
-- | Syscall error codes for blah...
--
-- errA when blah
-- ...
(errA, errB, errC) = ...
Cheers,
Jose
In the future, please try with more recent version of GHC.
This is no longer a parse error with HEAD or 7.6.3. Instead, given
-- | 'y' and 'x' are here
(x, y) = (1, 2)
you get documentation generated for ‘x’ and Haddock doesn't seem to
have any idea where to link ‘y’ (but it does know it's in scope c). I
think this behaviour is understandable considering that ‘x’ is the
first ‘function’ after Haddock comments so the comment belongs to ’x’.
If you want a different behaviour, please file an enhancement request
against a recent version to have it considered.
I don't understand your concern over privacy in this case: you're
getting a lot more exposure just posting on café than you ever would
by posting directly on the low-traffic Haddock Trac. You're free to
register with a temporary e-mail.
http://trac.haskell.org/haddock
--
Mateusz K.
0x2ADA9A97.asc
Description: application/pgp-keys
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock multiple definitions
On 16/08/13 08:16, Mateusz Kowalczyk wrote: In the future, please try with more recent version of GHC. This is no longer a parse error with HEAD or 7.6.3. Instead, given -- | 'y' and 'x' are here (x, y) = (1, 2) you get documentation generated for ‘x’ and Haddock doesn't seem to have any idea where to link ‘y’ (but it does know it's in scope c). I think this behaviour is understandable considering that ‘x’ is the first ‘function’ after Haddock comments so the comment belongs to ’x’. If you want a different behaviour, please file an enhancement request against a recent version to have it considered. I would like to add onto this that we can actually get the Haddock documentation generated for ‘y’ by exporting it in the module and then we can easily link to it, you're simply not getting the Haddock comment along. I don't understand your concern over privacy in this case: you're getting a lot more exposure just posting on café than you ever would by posting directly on the low-traffic Haddock Trac. You're free to register with a temporary e-mail. http://trac.haskell.org/haddock Apologies for consecutive posts. -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock multiple definitions
On 16/08/13 11:08, Roman Cheplyaka wrote:
* Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk [2013-08-16 08:16:35+0100]
In the future, please try with more recent version of GHC.
This is no longer a parse error with HEAD or 7.6.3.
Uhm, actually there is, with 7.6.3.
% cat haddock.hs
-- Main
-- | Blah blah blah
(x, y, z) = (1, 2, 3)
% haddock haddock.hs
haddock.hs:4:1: parse error on input `('
% haddock --version
Haddock version 2.13.2, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008
It's great that it's fixed in HEAD.
Roman
Strange.
/tmp $ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.3
/tmp $ cat Test.hs
module Main (main, y, x) where
-- | this is a main 123 function
main :: IO ()
main = return ()
-- | Haddock likes 'y' and 'x', 'foobar'
(x, y) = (1, 2)
/tmp $ ghc Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
/tmp $ haddock --version
Haddock version 2.13.2, (c) Simon Marlow 2006
Ported to use the GHC API by David Waern 2006-2008
/tmp $ haddock Test.hs --html
Haddock coverage:
Warning: Couldn't find .haddock for export Main.y
50% ( 2 / 4) in 'Main'
Warning: Main: could not find link destinations for:
GHC.Types.IO GHC.Integer.Type.Integer
/tmp $
Well, it's a high possibility that my Haddock version isn't the stock
one that comes with 7.6.3. In any case, I'm glad that you say it's
fixed in HEAD. Thanks for checking.
--
Mateusz K.
0x2ADA9A97.asc
Description: application/pgp-keys
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Retrieving Haddock comments with haskell-src-exts
I'm writing a small tool to help to analyse Haddock comments in Haskell source files to help me to indicate any potential breakage to documentation in existing source files. Currently I'm doing the parsing with the GHC's ‘parser’ function with Opt_Haddock set and I filter out everything I don't need. There are problems with this approach: determining any extensions and options used is vital for valid parsing of the files and a large amount of source files outright fails to parse without this information. Fortunately, haskell-src-exts exists and it can deal with all (or most) of this for me. Unfortunately, there doesn't seem to be any way to get it to recognise Haddock comments and the only option available is all comments or no comments at all. It's not easily possible to stitch these together without analysing the whole parse result. Currently I'm thinking of parsing out extensions and pragmas used using haskell-src-exts and then feeding those to GHC, effectively parsing the second time. Is there a way to avoid this? There's ‘lexTokenStream’ but I believe it has similar problems to ‘parser’, that is, needing to know the extensions beforehand. -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Retrieving Haddock comments with haskell-src-exts
On 14/08/13 19:02, Niklas Broberg wrote: Hi Mateusz, haskell-src-exts is not haddock-aware I'm afraid, so I don't have any real solution for you. The one you mention, i.e. going through the whole parse result and stiching things together manually seems like the best bet if you want to use haskell-src-exts throughout. The main problem with this approach is that we get comments (and their SrcLoc) as a separate list. While it's trivial to check whether the comment starts with a ‘|’ or ‘^’ and it's not even hard to find any lines immediately following it, Haddock comments can appear in weird positions and trail until a line of code is encountered. Right now, it's rather hard to tell -- | Foo -- bar and -- | Foo someCode = undefined -- bar apart. I think this is the only option at the moment if I'm to use haskell-src-exts. In the longer run, it would be nice to have haddock support in haskell-src-exts, so ideas regarding what kind of interface you would like to see are most welcome. :-) For my use, I do not care about anything but Haddock comments. I don't care where or why they appear, what they are attached to c. With my current method, I just throw all this information away (it's given by GHC). For general use, I imagine that it'd be useful for the program to combine multi-line Haddock comments into a single one and attach it to whatever it is documenting. I'm not sure how haskell-src-exts is implemented but I don't think it's plausible to do this without going out to GHC and asking it for the information. Incidentally, this is precisely the problem I'm trying to solve with help of haskell-src-exts. Cheers, Niklas Thanks! -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock GSOC project progress
On 31/07/13 06:37, Roman Cheplyaka wrote: Hi Mateusz, This looks great — I'm especially excited about List entries no longer have to be separated by empty lines! Glad to hear that. However, the decision to use Attoparsec (instead of Parsec, say) strikes me as a bit odd, Parsec has a dependency on Data.Text that you can't easily get rid of. With Attoparsec, I was able to simply get rid of the modules I was not interested in (anything with Text) and only keep the ByteString part. as it wasn't intended for parsing source code. We're not parsing source code. As I mention, we get comment content out from GHC and parse the markup there. In particular, I'm concerned with error messages this parser would produce. Currently there exist only two error messages: one for when module header parsing fails and another one for when parsing of anything else fails. Currently the parsing functions have the type ‘DynFlags - String - Maybe (Doc RdrName)’ and if we get out Nothing then you get a generic error message and no guidance. This is also the current behaviour. Now, I agree that this sounds horrible BUT in actuality, there's not much information we could ever give. This isn't the case of inability to do so: I could simply add a (| fail error message) to relevant parts and it would get propagated up. The reason why I said that this isn't much of a problem is because there are very few cases where parsing actually can fail: in most cases if your markup isn't valid semantically, it's probably valid syntactically as a regular string. I mention in my post that we will now accept a bit wider range of syntax. In the past, this: some text exampleExpression result would fail and you would get the unhelpful error messages. With the new parser this will simply be accepted as a regular string. In fact, I actually can't think of a comment that would result in parse error with the new parser. Just to check, I just ran 500 randomly generated strings using QuickCheck through each of the two parsing functions exposed to the rest of the program and none of them caused a parse error. It's up to the developer to visually inspect that their markup produced what they wanted – we can't read minds (and frankly, the rules are fairly simple). Roman * Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk [2013-07-30 23:35:45+0100] Greetings cafe, As some of you might know, I'm hacking on Haddock as part of Google Summer of Code. I was recently advised to create a blog and document some of what I have been doing recently. You can find the blog at [1] if you're interested. The first post goes over the work from the last month or so. Future posts should be shorter and on more specific topics. There's an overview of what has happened/changed/will change at the bottom of the post if you're short on time. Thanks. [1] - http://fuuzetsu.co.uk/blog I would also like to take this opportunity to say that there is one more change that I forgot to mention. Obviously invalid strings between double quotes will no longer be treated as module names and blindly linked. The checking will only be on the syntax of the string so it will still create hyperlinks to syntactically valid module names that might not actually exist. -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock GSOC project progress
On 31/07/13 08:21, Mats Rauhala wrote: Is Data.Text as an extra dependency really that bad? Remember that you are parsing comments, prose, human produced text, where Data.Text is way more useful than ByteString. It has to come with GHC boot packages and it currently doesn't. I have updated my post accordingly to mention it. ByteString indeed has its problems (I have to be quite careful to make sure unicode doesn't get mangled) but that's just how it is at the moment. If Text ever makes it in, the transition will be trivial. We're not doing anything fancy to the text we get out anyway so any performance difference it might bring is negligable. The only difference I can think of would be that we would no longer have to worry about preserving unicode by hand. It's an inconvenience, but that's about it. Nothing mission-critical. -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haddock GSOC project progress
Greetings cafe, As some of you might know, I'm hacking on Haddock as part of Google Summer of Code. I was recently advised to create a blog and document some of what I have been doing recently. You can find the blog at [1] if you're interested. The first post goes over the work from the last month or so. Future posts should be shorter and on more specific topics. There's an overview of what has happened/changed/will change at the bottom of the post if you're short on time. Thanks. [1] - http://fuuzetsu.co.uk/blog -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell.org down?
On 29/07/13 18:39, Paul Koerbitz wrote: Dear list, I am not sure if this is the right place to post this, but I just went to haskell.org and got a Sorry! This site is experiencing technical difficulties. error message. cheers Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Yep, it's down. Sit tight. I recommend using Google cached versions of the pages. -- Mateusz K. 0x2ADA9A97.asc Description: application/pgp-keys ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Sneaky method for var-arg fns?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/07/13 22:08, Micah Cowan wrote:
So, just for fun, I came up with a way to abuse the language in
order to define a function whose argument is optional:
-- dirty-trick.hs - A sneaky way to do var args fns in Haskell
{-# LANGUAGE FlexibleInstances #-}
class Hello a where hello :: a
instance Hello (String - String) where hello = (\str - Hello
++ str)
instance Hello String where hello = hello World
In ghci,
putStrLn $ hello
gives Hello World, while
putStrLn $ hello There
gives Hello.
.
I was wondering if there was a way to do it in pure Haskell
(i.e., no GHC pragmas required), and also the specific reason for
why the above example doesn't work without the pragma (I think it's
just that in general a - b is not syntactically allowed for type
specifiers within instance declarations)?
I'm also interested in alternative approaches to creating
variable-argument functions, if there are any.
.
If anyone's curious, this was prompted by a discussion with a
friend (copied), about Haskell and Clojure. He mentioned that
Clojure can accept variable arguments, though AFAICT all Clojure
functions basically act like they take a list (that supports
variable types), so accepting an empty argument list is a bit
analogous to Haskell accepting an empty list, rather than no
arguments.
Part of the reason Haskell can't really take variable arguments
is that all Haskell functions really just take one argument. But I
figured you could use the contextually expected type to decide
whether to return a simple value (not /technically/ a function in
that case), or a function expecting further arguments, which could
then be extended to define a function taking any arbitrary number
of arguments.
Cheers! -mjc
___ Haskell-Cafe
mailing list Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
You might be interested in Oleg's
http://okmij.org/ftp/Haskell/polyvariadic.html
- --
Mateusz K.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
iQIcBAEBAgAGBQJR8ujnAAoJEM1mucMq2pqXe00P/jdRyQCD3CSwW2/7vqpFyQsn
HGx4RAxAQWssyQ9UP6vv+rXAVay7uzVARYUgHoP76FcVrgIN2T+5F9pAIn9YOZK6
MCXCRMpsX8qRB83s11RiydUyFGTUiTKPrw+SDz4ZSK2zy4M6kTWA1X2CwnYtQpwM
ghqxuTSSJbmLCyDxSqMbg/BORJdcmPmWAuNNEI2euhVanDaRJGb7uqBsAW/scqcr
D//HNPs81wG7weDE8f3ANAsh6cP/91wQ5VFPigQSKwiwlG8ZQZ6QUT8GnDotvwMx
gc8mVu9ArHGgJcrTc6q6tw17P2BvrDeOKyQeoc6RVLcA+Usp9McdcUb9K55nHfdP
TZUO1i3+YgefpIVEkfnMW9S0lRkU9Avd0K3KTVeAa3u2TxqBLQ592+rbvZPbJ5Fd
XvAkNZdh3SRIIZ2TFCQXTcQIi4TmuC/GG7SwfFvpPQrow8WrF8C+UwKPJ1CpAlpb
CXp8WWtagJQ/NL0GunygXwK2WiI5OhWUdfyoz5OVzAzztA1q+Ld0b3dBsWlmRPHj
XH1jBgxFB8cNi9GzkC51LE4u0p13k3IS0x/dzesYFEBPW9Cn3wl9AtgItyhF1Kyx
TnNrkKfiJD/Vhq5c0/Lky4C99/kx/g78lGVdpwzV8INwgCH1AVGGQi0jjN0PRUbF
sCuWGqPXDD1hvYvaOEE1
=o29R
-END PGP SIGNATURE-
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] same function's type accepted in top level, but rejected in where clause
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/07/13 19:50, Chaddaï Fouché wrote: On Fri, Jul 5, 2013 at 11:03 PM, Ömer Sinan A?acan omeraga...@gmail.comwrote: There's an implicit quantifier in type of `f`, like this: `f :: forall a. a - ListF a a`. When I add `ScopedTypeVariables` and `forall a. ...` in top level definition, it's like all `a`s in scope of top level definition are same, except when explicitly defined as `forall a. ...`. Is my intuition correct? Yes it is ! :) ScopedTypeVariables is a very nice and non problematic extension, it may even be made part of some future Haskell standard. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Is this just speculation and wishful thinking or has there actually been discussion about it already? I think it'd be great if it was the part of the standard but I'm sure there are tens of naysayers ready to repaint my shed. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJR2wu9AAoJEM1mucMq2pqXM64P/RGQR+/qItSQumuUCXkagp5V jMx3UaoJIyjOlcDBAmbHitZH4gTSNKFh3toWH7brb8SPfMpzgl1rGFtCsr4pzvOS 3GzM2giTvw9cs8rGv5f1O7h2hSpaNgU9xVxzpYxRd4g/h3sMEuWji++jJDhDY6mo SkOmtMGozi4AwhtMrybDjeNhsno82mKPU9SQF8fKz1yj/MMJY9BwWGs6k3OlvxWM eNqyRfoyQtgRLB2Th1dJqIV30dakmnMSCX9ALnD0Pg8/lQnqj0iJ1O7b1S2iqn/e UtxTTyOgwNF56K4CnUpt/os//bHyqsQFFQyFBkdZMstcro57Ta7wcXcPqzhuySNQ GOerfMkVAOApVkXO6t78XLgy1vkc+RXaxY5obICXN+nRu4WuZBLow0HdxlkKffHE cwXHigU3KkKIeoyvgpI9pEFSUMPJcBvI7SG9MqWIb5sOxuZhFv2KmDSanptL1bA8 yccRb0yN2vfmL3+hLIBKTfn9TWKCpnEaCpwPBCCM9kFvA31D0Rul5EZT5H8IB2/9 t5DGTOXlACgKbr8GODCFdtLQUCXaKYj7N83yQHt9kBC6PfVe9ECOJjnZrfvnA1na sTPzzxNFWdAmKQBhZBlldwYvLNtIO7UK0H+l01gacKd5KOldS6u1K+5EDT0WuIg5 LPxtoY8kYIJlwUmZgAqZ =ZaDI -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Testing invasive proposals with Hackager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/06/13 23:13, Maksymilian Owsianny wrote: Hmm... I'll have to look into it, but it looks promising. Now if we could make hackage run such fixes automatically whilst sending pull requests to authors... then maybe we could even fix The Great Num Fiasco of 98. I don't know about automatic pull requests (perhaps e-mail to the maintainer with a patch is a far better and easier to implement idea) but something to let maintainers know that their package no longer builds on GHC HEAD (per request of the maintainer) or with a new proposal in place would be a very useful tool to have. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRuk0qAAoJEM1mucMq2pqX0IAQAINWmBK4ZI62+zPkEkyH9lGh hs0Hb876GOv/BJBGiVAzttWjeuMXTiUGrNcc+ZH6AKxiSmaVBBAqNdvFWAIobGY0 6WfHWF6gqUtidY4dboQXGg6vWRw2ONaD7yH9CUbpTSUVb9zFBKO/OLc+4i41vrwZ 0ZCx4lNZiM0MvBtnyJTuEkUb0hYeAW1ty32gFEEwNwqeInyGXr77TElXCVyXUOXC BpW+pZv7AeCnuQZQpTZKTGQd40SCv0byrn6frFB+kZBJVO/Qga7/6DhbXDuuke07 VjG9Jt7EMmqFy6E2UZMZZYjU6k7g/brUkylV0SDBVheeWpJpxId9eFXuyYQAhpBf y/sjW9p7PcvPBESTXi7sjQtq/qY3gwdc0tZXbrgEBzhkWj4XYojJ4SxsULTkmPPo NWjCYmaFgV84ODtedsekNP5n1pJZCD+HPZWkIKw24lJvhT/MoG0Yj2EsMt2h/VZR U7M5tk5/XhjC4s9JeXdfNk3TdX6SccRT0a1cqxpOznZGR3jDwSjbN9dLu77k7r1w LQ6NVZJvYo0IRDs6KhxBS0UpvRKxSUcNRvlgamtUbNGhRGHmHCTN5BQY/4DrYpZo LEtZjtdM9Ndj8FBwzyfzeOLzDKCpn2uOAT2MoiHBgq0pM3WhNNHOxBH3cJSony0l tbuiW4Mj83vL1rYthXDR =g9we -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNOUNCE] rainbow - print colored text on UNIX-like systems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/13 19:10, Omari Norman wrote: Hi all, rainbow is a simple package to help you print colored text on UNIX-like systems. It's different from packages like terminfo (upon which it is based) and ansi-terminal in two ways. First, rainbow assumes you print text one chunk at a time. The properties of the terminal are reset with every chunk. That way you do not need to remember what the terminal's properties were before you print a new chunk. One chunk does not affect the next chunk. It's a state-free model that fits in well with functional programming. Second, rainbow makes it easy to use both 8- and 256-color terminals. Some sample things you can do in ghci: :set -XOverloadedStrings :m +System.Console.Rainbow putChunkLn $ Hello bold green world! f_green bold putChunkLn $ Red on 8-color, pink on 256-color f_red c256_f_201 mapM_ putChunk [green on blue f_green b_blue, , blue on green f_blue b_green, \n] So, add some color to things: http://hackage.haskell.org/package/rainbow ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe For whatever reason, your Haddock documentation is not visible on Hackage. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRtMj1AAoJEM1mucMq2pqXogkP/24iaGWcDxf4q2IV/lxrRujF YW8qP6XPx72K1DJsDwk0ZeHQ9UBZEnFxz9vY248l6f8Rg9rTdHpXX8zWHSebxtVM 7D7lt0PmtxT5PnTVQGNc75j4hqUH6Gh5Ig6hUm4vKLH2jyAAzkQ6VNA7k/oPAxMP uHTGV2Kt8FCfiwtTY4MAlch3emnexPWRtjBHtJoVXwSgxTnUoXm6MoPJTyPTqaX3 zfd/YBC38VJNAzIHzbnh3KHymcfgCD9XyrGPxKzX/NF5T6zEPymsJw7aMUjVN7bc wlry1gRGXu02zj6n52SI1W6cYWrHMuxUPYufoPM4GZ9cb0Cqb7hAa1AcE4b/HOoU sY7vczBND+85Dgyf3HkjSWEtLszjxDMf6hPc5mGTcgwoDMqwXybImx8kVZZ2EAcJ 59QYTNjDkdpI5nvQ0qN2GzK4ZPeHHhiwrZ0foff7zmQ+sp9gwvYHoTMFHpP4VN69 MoiKedtc68WFXfpLfb4VkLdkUOyMBsJE93j3kStx2m6L7zkss70QE72jfeOqWnHk GOmAA/kPj4/4IB4DcuRwcXQsgdeb5lQo5duF7gwhfP6QyvcqbGe1WgM27m02MvRc W010UXwQh991K5wH8YSNU/OybyPg3iozA4/73lwQ8D9KVcIa+Kn31rPKB45ka1P5 QVo/WwBbGiaXlr2Apb+L =RDjX -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: standalone-haddock-1.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/13 13:15, Roman Cheplyaka wrote: I am happy to announce the first release of standalone-haddock. http://feuerbach.github.io/standalone-haddock/ standalone-haddock generates standalone haddock Haskell documentation. When you simply run `cabal haddock`, the resulting HTML documentation contains hyperlinks to other packages on your system. As a result, you cannot publish it on the internet (well, you can, but the links will be broken). standalone-haddock takes several packages for which you want to publish documentation. It generates documentation for them with proper links: * links to identifiers inside this package set are relative * links to identifiers from external packages lead to hackage Thus the resulting directory with HTML is relocatable and publishable. **TL;DR**: it just works. See the [haskell-suite][] documentation for an example output. [haskell-suite]: http://haskell-suite.github.io/docs [snip] I could have really used this about 2 days ago. Oh well. Do you have any idea about how well this will work on all of the GHC source? That is, are there any known issues that would prevent it from working or require a special setup? - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRs0rmAAoJEM1mucMq2pqXFXwP/3y5IPR/6DElHRCKSWkXV5k+ 7LaABSTJOVaEWzyI9NqhB47GDMLe8V3GD83/xaKoeVdTobgoYG1PpMWudOA9k05n BO829mMxqNWS+2s+tgwgEXr0UXerKwCcQDnSvFEFiyhyQo5eaZnDnbjupTJs3ES+ DqdEaQxgf2BSCnzHEtsMH9vqhnduMIRjclMcVHtcKn2PZ4ivGn9Igm6KLc6Cq8U/ lay/geO3rIoFNmlF5RzzDXMT4k2pIeABu/xKTkcdc+zxtQK/G5TD5kYJXM7LhyrK A8sAHtBISUu00p9MCX08iuFs6cUwW1L8djPpU4dT8kAPRW95BsQVILS28ChOTakv kZzCRY1UP+GtQ9uAE/xBHPv7EACpzeXeZTAwj2KC/xRkW9zQ5J8IqpQ8m8BsHwhr uqQoHZR/RytEAEOoHdeR9sOczjawuKEiIfCahuHeClF4qOHWAui2eiFQ58rckF28 kyPd2gfj2w67j1JR2voG4sk3nvcYvdHcAL7no0ZSxjSRJj26SmKB96+Y7jSiJ+d/ Do90mGUaJYTLcgW13shkJ6ZHvco2P9Yq56GR1g9Pd3nbQ5JRUwarUX/bjmeM48u6 skP7+GWgB5XQUeZ3gQ39M5o5NGw7FgySSdMUVvNhisdmQqn1yYzCerFUhwO3uxL4 gBhOR7JWYb9dCaz4V4py =joYv -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] lifted-base linking failure with GHC HEAD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, I'm attempting to build lifted-base (as a dependency for ghc-mod) but cabal-install fails every time during the linking phase. I pasted the full log of `cabal install lifted-base --verbose' to hpaste at [1]. I'm attempting to build it with GHC HEAD. Now, I should note that I have different directories for each ghc version in my ~. So, for ghc 7.6.3 I would have ~/ghc-7.6.3 with appropriate bin, lib etc. in there. I thought that might have made `ld' confused but I just tried to `cabal install lifted-base' with 7.6.3 and it succeeded. Any ideas about what might be wrong? [1] - http://hpaste.org/89046 - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRqTOjAAoJEM1mucMq2pqXt+QQALM9oWexq5NrWwOmcIj+m+08 DdNpj37KYx+M+3SUZYQ7RVyW7pf7ounsl/1OtGGndhGBeBpeamOMeZxaYvIZr7da IUjd3Vgnl0W44G+T9Wg64g+MIgyy75oLFPNnP0BGbcLzDk5wVgAl/xl+H193lLmu LbBJGAzAE+YHIx1mM+mNGsYgr80dhpGTs5jGdauAEdsnZFdFGj86sxBeFBeKVF78 md0PA1HDwJSVo2FyAAULWhgPDpwBrScjNjTU2etMpegMto1aDaV7rwvJeNeewv15 89o19tpWTvdwxtddOI6YlBKFTL0u80IBlCRQ+NWwu7PB35wR67MbOchXx4qGJSOt TxNelfW+C3h0BW7KLskQjqcEPUKD1hYB5lAnOH2VOaTSFEN9QN66GhC3BHLJCBiu UWZBRyUikAsjRvWL6eQI+vc8fnPSieNa5K2jdPe410uHojr7Eq28WCCXsejaQ3e+ TviDUWLmGfJk97Zmz2NPy4oGqwNYvOQqXKZ4GIpzD1/UHfNUw9wykPuDCapuvXPl OcSlSyjPk70jG32aLEalVZKPYZ1g15VSY6d6WYquZO0mGpwL15Gvc8V7SlZfNpvT 8maX5CQEeNXqfEbl2PwnkfoCwvW7x2p7uD+M2MHxOozkn5vtUonXqFCOVCftE/nL KsYrafRMuMzNRCn4kE/M =OCEQ -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc-mod v2.0.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21/05/13 04:15, Kazu Yamamoto () wrote: Hi Niklas, Just one note: The emacs link on the left is not found. Fixed. Thank you. --Kazu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe While we're on topic of ghc-mod, why does the emacs front-end give `Cannot guess type' when the point is on the very first letter of the function? foo 5 = 2 ^ foo x = 3 Is this a feature or a bug? It does fine on the second (or any) letter after that point. Great work, I love this mod. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRmu90AAoJEM1mucMq2pqX6SQP/RwlcHx0ZsMYf69m5hrdVeIQ 44gy/CSG9ZdQAVaN6aJ4zy9kNNzw9KlKUKyNCTwrpqn3X8s/GKDdLhX+lCOK1OrP YjCYK2ijLXFEPcNmpVdTk/chPW6qYHqSCmJMxQbUoLzUkiVFN85tM8r21e1KOvZx NHAxWyM6ofCN/fT6zLanhy8sBSyGEOzLnk2YWdAK9iZfMLyq/FNp4hcfB4ha1j7p 3HXatjL0AbtrQsDCJzVA7X+ip2lHM7Lz9Ekof61YhGGhTyoRIlsYoHUwhuAy+2kJ ztbrrmdCHwUjPFhDFclrtAEkS4EAlfHsHnh8BO6QGgA2j+U256O7v1zofPZhKvH/ MbYjEXRmjp7Lt1t77uaDMo5+lfzim2i6I5e6NJJF3EYkT0Wf0FklEXWOK5GeGvVO SW9n96bd52asiIQHJMse6bpGnBs4Oi00wFmrXyd2WxrnYtTmcPmFTfooBD2DHESR Y5HE/7eEPEsXD/bSwALhc54gF9kNDTTVBRsWpfH0V/C4wRQ929fYNdGeSn90FclO Oe/XV0W506q5VTcKKLmA7YX/hylwG2plj4lB2Z/6po/mBN+rtC5uLfnCv7hfNq6G 5HnJZP0h+74rXCYr2rXJpyRTuYdK+41ZrDhOm4BSHwE8u87821f5EDzvpWjiPqdg ybjFOs9OMVMckbC+i5WL =yt7E -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-deterministic behaviour of aeson's parser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/05/13 17:25, Roman Cheplyaka wrote: I am observing a non-deterministic behaviour of aeson's parser. I'm writing here in addition to filing a bug report [1] to draw attention to this (pretty scary) problem. To try to reproduce this problem, do this: git clone https://gist.github.com/5604887.git aeson cd aeson ghc aeson.hs ./aeson | sort | uniq -c This is my result: 32 Left key \module\ not present 55 Left When parsing the record SymValue of type Main.SymValueInfo the key fixity was not present. 1913 Right () Can others reproduce this in their environments? Does anyone have ideas about where the bug may lie? Many aeson's dependencies do unsafe IO stuff that could lead to such consequences. Roman [1]: https://github.com/bos/aeson/issues/125 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Here's my result: 3 Left key \module\ not present 8 Left When parsing the record SymValue of type Main.SymValueInfo the key fixity was not present. 1989 Right () - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRl7RYAAoJEM1mucMq2pqXt+AQALBsY3qgOawn4lHWK4myxXms ofwxyED2fJC+4BjjdfMrbHcWYpEM43K+QlAElx7sQcM/VCCjqRiJ61zHyLnicILE PwxF0/J0QQOkLF3/Q4ND7zgKqxbJWjOW2V6tf/WQulL4eKl1o40Xl4wuhoNqFrIA g5GKcY/MPdBzbcnOwep6DdRhm42SrO+WnmmWoNYPNWA43dZwatlBsCklS3Pj+SdS AYl10ZwNkMBT8Pj4N5A/z9C8LPKiZUDjuZxpMQT+PY4Ct318HtZVWDX3fM5QGvuE HVqBPlBZIQn+VWBDFVe3LqhfvAVpvmflJ99DVGeO73kBhEf4FMhVfnXcGDayYYn9 PGF4n7L7MP4hNVlQtQhWkLKgWz0Z+VND+6c8yGceEpak4WqpzSmBKXIpMa8fw7tz UXHUdJiVt6ZLGr1LjqDD3399+DCySj56XfyQk57xTn5gRjHtfz7QPSzgydDZzsJJ 8WHwQG1yHzNDfPATQwuZWss8FR53TXZbsn7zPfcJsro8bogNc2OH53HiVKoOm8l3 xH+A0D7169VCcKLvcVLmOb8gzAS2PiClm9/9H3/ho7iaU7gcYkZTaUO3JNz72mpn Z0dS2YIdgmUdEY6Ws5DSmySOmP0QdFUt7xMK2lfExugdPLatcT0D+CGvNRJpfNXB uL4I9+taoheV+3SLbM6M =iGjG -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] list comprehension doesn't work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/05/13 16:59, John wrote: is'nt it possible, to write it in one line without any nested functions in WHERE? If it's possible I'd prefer that... any idea? Thanks -- View this message in context: http://haskell.1045720.n5.nabble.com/list-comprehension-doesn-t-work-tp5730158p5730170.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I'm sorry but you should at least attempt a solution yourself and ask for help if you get stuck. Furthermore, this topic is a bit more appropriate on the Haskell beginners mailing list. You should also probably read a bit more about the language before asking about the very basics (such as the `||' operator). You can define any non-recursive functions inline with lambda functions. There really is no reason to avoid `where' just for the sake of having it inline though. It's bad practice to have very long lines and it's horrible for readability. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRkmmxAAoJEM1mucMq2pqXjh0P/j2OlvpSfggL3z9qkQEscTK/ BrDCLGTE4YaEm1BRSIt7HOPZUebZdrKUkulVAE2E2W59qSnW7kDtAKuAa7sEz/BG gvnwrJynMmCRJiZfHUfiO1OCdmbyXomzJxG3exwW1ovLrd1bk8uFO9Kc7Eyrr1n0 moTvtAVbYuPYz0WooJOHES2uaW8tdJgJVCh+q0Fv0hPrQIGFCx038C2TmGHrTHzE 1c/0c36L6uOiHGMWNz32Qpkxg9a0f9NENv6jJGUryP27cpqG+whZ4TeAWYr+57lS x40XC6s5+WY1eLHCxBMNCQGf9/JwDwcXosOtiz9kpnggee7ck7DjK2K2wRT/mUVv fRHmUyUM9i5RxJABrXy0vwgRhnDGfHHwB5w2JAvpTxUDCvffavgZnqnbKyo5R4NQ inxf4u5luRZtcCVVBNVUznvraddK8GJkVVMrCuSb2SqXHO34MrFIMkUzx20Ba/nH fmO8nvjVym92+gOSuX9OWQHzSDEmkrmNmeWSKwIxa1W6VMebir4thMygSM6Y5QZg hr+Op1aICBJEUelgQltB30shAY+Pvnn7Q9C45JICLq850W5KHvCRd/sC2+5pCzgR iOFGULTW5fKX0M2OsumJoCU2t9JbNxbbxlfSyEHcPB3Z/8PO2VWQPd9a03J1eDiN yKoDgIncc/HRqmLgObxG =plBj -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] list comprehension doesn't work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/05/13 17:53, John wrote: thanks for your tips. As I said, I'm at the very beginning of Haskell. I try it to understand as much as I can, however the topic is very new to me. Sorry about my silly questions... You said, their is a mailing list for beginner? Could you please tell me I get to that? Thanks -- View this message in context: http://haskell.1045720.n5.nabble.com/list-comprehension-doesn-t-work-tp5730158p5730172.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe You can sign up to the list at [1]. If you're new to Haskell itself, I recommend that you first read [2] before asking questions that are out in the open for anyone to discover on their first few days with the language. Good luck [1] - http://www.haskell.org/mailman/listinfo/beginners [2] - http://learnyouahaskell.com/ - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRknAOAAoJEM1mucMq2pqX6VMP/RAEm+Ktkzv7wUHeBwI4+H9O h+Hpt4HL5lqwmxEY5bQ3tqHmAhg6oeUiWwNXFJiHd6AQ/V8dRS0NuYlj5+ULwa7L wruwNblNMAo6V3VcvOLHmJuXDWC73XnpAuGHfBqL45e6GauHdP0XmhWOuqTPbruC nz3L2JartkMeovPzHPUYaI+sNQR+mee1sdGXt+LkaKQq7hKwHXl6QhQaHbczUa1F p5XHJUWDxN1ErXqRQvwKUnvwkWGLQ6QPztfzDoYhrXR2fd2lTb0ALeYZBGaq7Al5 PBAK+q5w9UXEDOue0TyCmj2xV/926IFdD1/QsSw3USG2fTXmlyBUr805lTYQUKkz sudh5X2KRpSJr0WGEk1Qc7/ugJeTADMSE2sm+e23R0I5FsISKE13vjt8tYppQ5Ya bQqb6EDSq/JAV+Hrn+lH7XrZcdT4gGEArmCqsUHxnQeAx1dj4ciWIzL4YdZ3Jj1E HHiJW76WzIwtFJFn7kMIMO0cJZOCxWU+BIfQKOD3CbjSZYYBk6X2SETOx4g3tI01 t2ohDC6khxAzMveoZZRqTNaqvczjF5FNtOOEo0RFZweOtFknb1t0hD4OYcw0kPoj oLq0PnW5ZMJBb5xGdnYT3iDllyUgwer9XVx5elCTm5XLLjGRS+YOVBrLtlqWY5ww 4EISZV/uPyNoum42CFqi =TXHj -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] list comprehension doesn't work
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/05/13 18:18, Jerzy Karczmarczuk wrote: MATEUSZ, There is nothing wrong with sending beginner questions to h-café! After all, a FRIENDLY community is for whom? For Simon PJ only? Notice that John got more than a dozen answers, people TRY to help him anyway. == On the other hand, the original requester *should* have thought on: 1. Putting down in a concise, but explicit manner what was for him the expected result. And also: 2. Writing what were the errors signalled by the system. But no, we had just help!, nothing works. This should be avoided, some people are reluctant to analyze situations too obscure, even if one almost-syntax error was clear... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Sorry but I never said these questions don't belong here. I simply said that beginner questions are more appropriate on a list created specifically for that purpose. You might argue what `beginner' means per-person basis but I don't think there's much to argue over in this very case. I simply pointed the OP to the list (and some resources) when he asked about it as he wasn't aware it existed. John got more than a dozen answers _after_ he showed that he tried something. The post I was replying to simply had no visible attempt at a problem and it was something that is covered in pretty much every Haskell tutorial. I don't think my post was out of order at all and I don't understand why it sparked such an... energetic response - that wasn't my intent at all. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRkrPjAAoJEM1mucMq2pqXQhYP+gNCSbYgFJv6FhT14SpPH+4e XxSVEoH3Q1BHb9USJMPCmQmvITVfyDQmbDCyVxkwONFrMhFQjl9bLwjYiTVOlYFp NxtQi9WJi932PrrNWawflN6xBPGqtMVksRia1XEjHNhqOPUA6CslsyGzOjAtxq8L gzcreJXxj5mEcA3h8h1Ulm8145F4OO+iEyNzylmmmW8a2jerXJuLC0LYDcCLAGVN rUk3l6cn9UnicFdmcScO3btp5/vMuimaql/lZkULF2vscuiNvtAaNuasOMFmbZK8 EhVI7Oflj0upOmKDwlOWfavdbAFmB7baLyR7QUeg73399o2TLGGtVT9/hoqetkdZ 2JpwYiDqt/aw49ENOqVfZmj1QVOLRUGPBHZHytN4va8A9TfJ1+tGeZuBBBkLdJwR VnvTQE/moWC4HY8gSZq21vBy7QPT85+QD93mFbY9tvC5TB4Y/QuE4dvaNSSiyJS1 nm0pqlxV3hcpOtrgJqZSlafqoDVFNA+1lDCha//H9gRrXwpVNBxrB8ZViqkc90rQ ZLW6cpREF5i9oDE9tF+dAV0uByYmpstbCmHoO6uKzvYwZ7sdEKQATt1N5TIcvk23 IcQdTLP6AquW/qNBrqYRguDFxm40o7Mtu5ipc0A7viXad+j6rXmjnpisjAA5Hvt5 F1Hr108vtUwEVojmmuvm =gfod -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Typeclass with an ‘or’ restriction.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Greetings, We can currently do something like class (Num a, Eq a) = Foo a where bar :: a - a - Bool bar = (==) This means that our `a' has to be an instance of Num and Eq. Apologies for a bit of an artificial example. Is there a way however to do something along the lines of: class Eq a = Foo a where bar :: a - a - Bool bar = (==) class Num a = Foo a where bar :: a - a - Bool bar _ _ = False This would allow us to make an instance of Num be an instance of Foo or an instance of Eq to be an instance of Foo. The compiler currently complains about multiple declarations. Is there currently a way to achieve this? The main issue I can see with this is that given an instance of both, Num and Eq, it wouldn't be possible to pick the correct default implementation. Purely a theoretical question. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRjP0hAAoJEM1mucMq2pqX30wP/0d0TQHs4S3G5TBw+T1baI6n g/5k/YlPmSgS3FaO8JMQsb2uqL8dGPZGUN7d2ohwcigtXS88KWH4u4rTjrs1+p8o ktS+vIE4kEEedTAX6wmP2Zn+rvK2zFGboCafaX/a/IxT5CbwYZ97RrWCjzz1jlPs S/VlhNHcTQ7Cf/0pa0xJ1kbao+vBHiWtWjxcdzCT/6zS86+jm9vz8qrYT3TWUd3y AJXPBjRuXeyz+RDv18yrth7hMlAvaeoWzmC4gbGFHC68/Oq2l8kz+4dt6ApN+mIy l73wNjrU185YoZ2dkuKTIph8/BadgkD+9ktkgZZ/NlqxElc596BdbOcMfVk4rz4A 0nWqaLa4QctIthghJ1UNfKS8lQzkVVRT6e03LYdgPkqJm1HQxkjHL/WieV2NEoRf 1K9S4SVW8Aq/ML/Gmx782Z3jMECfnYWntf9gSOwFASB64tVej1iUxb7UsfxJAL1t ysf9MjcbZsHe3M/JAq4f8HtHoZoiIG/TTjD0yo74owssJDfOTDqmYMriyelcnUf6 hDCPZyUqLPMTNVx07T+gwfXJoE1HK20hzVe2o1dPBZ8Kb2KJbNg0+sUSB3/v6O8e EJ6w7aQ3OnZUACd1i2uLZiphMF8d8va4T8eTFUyROODHvaPv6netzr8gPcIXhpVO 5OwyMfO54cinZYen7+HR =iAYY -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/13 06:57, Ben wrote: sorry, i was only trying to make a helpful suggestion! just to clarify: i'm not championing asciitext (or any other format) -- i only heard about it recently in a comment on http://www.codinghorror.com/blog/2012/10/the-future-of-markdown.html i checked it out and it sounded cool, so i thought it'd be a helpful pointer to whomever is working on new haddock -- they are of course welcome to ignore it. totally understand that overmuch debate is not helpful (though i'm not sure it's fair to call it bikeshedding, since it is a primary feature of the proposed project!) best, ben On Apr 27, 2013, at 2:02 PM, Bryan O'Sullivan wrote: On Sat, Apr 27, 2013 at 1:47 PM, Ben midfi...@gmail.com wrote: asciidoc has been mentioned a few times in comments, i think it's worth looking at. This is the problem I was afraid of: for every markup syntax under the sun, someone will come along to champion it. The choice of one or N syntaxes is ultimately up to the discretion of the student, guided by their mentor. It is in our collective interest to avoid prolonging a bikeshed discussion on this, as a long inconclusive discussion risks dissuading any sensible student or mentor from wanting to pursue the project in the first place. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe These two posts are exactly why I believe that extending Haddock itself would be of more benefit than simply adding a Markdown extension to it: with addition to core features, integrating any of the N syntaxes that people want suddenly becomes the question of just writing reader and writer modules for Pandoc instead of a full project on marshalling yet another markup as an extension directly to Haddock. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRggwfAAoJEM1mucMq2pqXHmAP/R2nHmXiNHDVqWEAoLQHSNeC psgcNm2hAclo6AxYprPsNHkqIUYh4HVpsc8FZw+RsAwkpUrGiaaMD/OTNB5857V+ 296lzHNOLNvge7B77FfVTa5wx1j2M+N0+pcOzcxr8qX5opfJNOcMPPtaXqD0nMS7 6EsBac/pQAjOHVYOTHEpsxAbl70s/QFBa/kW6tZPJmWKdHp6c3VmL5qx9CY9lZO4 1QKmyKqQMhxN0hmxcFHcYsa/IsohSAFewrs6JDErShn5ffIvtkhEM0UKVCBM26G4 Eu4Hadrv/AyoDT6UdtMgVllzY0XrykfLJ1nXzpp0QklYml0/SMmNrwqO9wfooMfF XKWiW2T8QWN5dFJO4kM9JA6UqpQ2uvrK6qWREL3jv8/jbEvg0WVko3zTW/BNzjF2 /Pn/9Z1vxYEee4A3Oa0sT7NGhKqK9KRtIgdfuXvTCnctvFYBxwtGHCcKuxgHVNNM GIJAqMtUtwr1Kjt37Gf0F+r1TBQfOsJL7tzRPayZKYPl7uA/ugrHHnYxL5JqIyAq bMUqLxAsDNW2tXIPzmNi4QYPqaopaUmwAD8IPvFk9e/1vI0QnU8b1URLjt5zl3O+ mFyWYTQd/UuaFOmOEmfLMJz+n2tRqL51LOCYcHwEjpH10WuTpX1DS3LWErcwppO5 bUZggQ5DwewgRIfCNEfS =nnP/ -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/13 09:26, Andrew Butterfield wrote: My 2c (before such coins disappear...) On 2 May 2013, at 09:14, Petr Pudlák wrote: Hi, Personally I'd incline to choose some existing, well-established markup language with formal specification that supports math (hopefully there is one). So TeX/LaTeX is out then :-( Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Foundations Methods Research Group Director of Teaching and Learning - Undergraduate, School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe With a reader and write module for new Haddock, you should be able to write LaTeX and convert that to Haddock and vice-versa. Some kind of Markdown was requested by popular demand but if we end up going the Pandoc way, we'll end up getting the plethora of already supported formats basically for free. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRgifxAAoJEM1mucMq2pqXtS0P/Rxx/JHS0vprqi0oCVDPcVTG 0ZCzptgVUYGlbVfdJYsbFChC+7SjWnb6/AXlsEfVnwhpVTparlwRdWu11+LxWWaH sHWqWX6mHk236rBcxllbpE92u/WqOcn4YsOLArClz8xbTVw2YkUHzFUBnnSGvClS V7Qq2jf0xnJWzPcFw1WY9/UdIhcOUif526VW41pkggXCzxp6/gr2VtKJbWJ/ljHX YCdrRRZXypT9UZKKt1oeKWp+XCs5Oh6nBZuJNNTeBQo03wyap4SYrnDlAnhPu911 Fb8+eqGTJKDsKIstERwgWfVSO/qzWUfOTc0orsvJHvy9SCATGKNkwRIvWX2SZj12 bl1D1Z0YQhHl3yRb2G7ZZXGcC6GXfAMk9/I/tgu74HtqM0hxHvZwGwPCX0Ql30EU GJsVBgabv8v6TS96/iipRTZTAUphqSTopl/JWhg0n+p5OVtZKOu/OI/xefmgqI26 Hx1I4yZKDMHkzYJFYhoi9QBLy+XzwlRctjNcEZClse+St1hlgR6lLLjhLHJQoRDg V5TWkzkaO3SvrnKFeObaRdt/Q8BxNgfOcWqyLcioobbu4Un0j6ncpcHZnAFHF0i7 FkE0CGxMiwLrB9F8sw+VTgFnCk3xm0QwgfpDeQVifhD83Jk51pJc8L/vg63ANEGN FI4KKji7k/J2NbfQHxDG =2xQm -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/13 20:52, Carter Schonwald wrote: indeed. That approach seems like the most likely to be successful within the scope of a single summer. That said, this does raise the question of what needs to be fixed up / added to the haddock grammar to a) make it a rich target for pandoc b) make sure the augmented haddock grammar is human friendly and we can give helpful syntax errors etc. Whats the status of this proposal for this years GSOC? Done well / right, it'd be super valuable for the community -Carter On Thu, May 2, 2013 at 4:46 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.ukwrote: On 02/05/13 09:26, Andrew Butterfield wrote: My 2c (before such coins disappear...) On 2 May 2013, at 09:14, Petr Pudlák wrote: Hi, Personally I'd incline to choose some existing, well-established markup language with formal specification that supports math (hopefully there is one). So TeX/LaTeX is out then :-( Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Foundations Methods Research Group Director of Teaching and Learning - Undergraduate, School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe With a reader and write module for new Haddock, you should be able to write LaTeX and convert that to Haddock and vice-versa. Some kind of Markdown was requested by popular demand but if we end up going the Pandoc way, we'll end up getting the plethora of already supported formats basically for free. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Last time I checked, there are two proposals filed for this. One, to extend Haddock with features that have been long missing and extend it with things like GADTs etc. Then implement a Markdown notation alongside it. The other one is to extend Haddock to be... compatible with Pandoc and writing the modules. Only then, if time allows, any new extended features will be put in. Both effectively reach the goal of allowing Markdown but the first one provides support for just Markdown and now the ability to write the Pandoc modules if desired while the second one provides support for whatever formats Pandoc currently works with and allows for feature extensions from that point. I think that if more time was given and both projects were worked on independently, they would eventually reach the same level of features. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRgtUoAAoJEM1mucMq2pqXOvkQAJspywchNrrcphMUG6Rnk2pF 0ExpkcVGgbxeGLRBIlH3obi00yWdyPmaei4axbeMSdBB/fKvhb4pVxMKdlwr5mXc x+VAFPOuk5a+3C7FvAd+npkbQJumBGKWhtwKofJe45V8bYIVq+FlSBc/Z/Q4fmbH YFHt/kQy4oEmotxt2Y9BXNw+CNlx7PRMjXTj4I/C4rVjl3KOnna0pM6bJr2KHcp1 wqmDWo4GdoQQRfOkReBInuukZhIo2nfwkMH0NdC89Y4syiKHW4i1x2B7Yedp8H3u dB8H+K5WcX5T4WGzTexAi0yX08KKj11ZJ+d486Io89hmaCR64kMsfmwDpaP9npwX aUTO5dco4YziN5NFYFdM1ol5YgQlGpBMTbSiZQlY+HAHjfS9U04wU/pcijrxmxVh g0m0tbzcHRoEkdC97EsTpxPwjx7HFc8epu9W63bz8Q2Mu4CpxjL2XKl5qtiwfDig HV/v0tnvnH2l0Daz0+6SuFxn3st4H/UV/rnus1ZSb112rMu4XzROKLgyBj4BhRwb l0f+kLNF4dyBmRMuvfA8JG1ZnznN22tL0FDZEgYM+BkSwsyyUC9gEAj8sMFwG7+Y ch2yqxgKEQICFi0ryJanXOvU78ijDNVBgGUi6zDrgX5HySDiZkr4ggDYLGDM989o zxufPmUUXBzVEGlT4KPr =ijHF -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc-7 -fPIC error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/04/13 03:05, Christopher Howard wrote: Hey guys, this probably isn't the official GHC mailing list, but I've been trying to build and install a new GHC on an old RHEL5 system, as mentioned in my previous Cafe thread. I was able to make some good headway: I installed a ghc-6.8 binary, and then used that to build ghc-6.10 source, and then used that to build ghc-6.12 source. The idea is to keep going until I get to ghc-7.6. However, when I get to 7.0, my builds all eventually die with this error: quote: /usr/bin/ld: rts/dist/build/RtsStartup.dyn_o: relocation R_X86_64_PC32 against `StgRun' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status After this failed the first time, I tried adding -fPIC to SRC_HC_OPTS, GhcStage1HcOpts, and so forth in build.mk. But ultimately I get the same error. I tried skipping a version and building ghc-7.2 instead, but the same error pops up. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe There's a separate mailing list for GHC that might prove a bit more useful for GHC problems: glassgow-haskell-users - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRf7XoAAoJEM1mucMq2pqXqdAP/jjs0pSstTPa8EstKs1ZfmcN PcDCgL+QfIe5eSQv1JROyq/dN43Q9zd7fBiuSi0wMU0ROdFG1coyK0xhXHkvr1Lc 4hESy0IHlrCZGXEqMIPMjpB6MmOqS7fzLWxTOAV6u2BG0GomoeRp7qe9JpX5J4uQ M0RXzT1OXqAmAOWKVbUb2qJzUAkY3iC0uxvko4tLXPQiFgqoNde0yTRis0y2FXDR wDoFoZcTWic3SU4ZOmj4SuUAFjaMqKtLjtyFJ1kIAj3U9QhNkwu1v6vNBu+nNDRf aX6zArpDEOP8oMNcrjjsnfqIDeWmdL6cMU14+GdZDHcKeJR3gLc90g5dtzFIqGTH HlocoXnm3PwetCk7CYxP1e7brWyM0nAl17OSEf/Ze13czlr5NKfH/Hr1I4WenBMG SA/HDzP9Y/TS/crJSF8b9MMU8juOUqFtADCglJVFEK8Jawsizsgh/ZW9ljwT+r7d gIhKdQW8SeMrBKPvB60LS2zyDf0naE99lehBoc/sk9CkT8JI3tW4oD42t2wW/XjE f8X5JBWSitxcDnL9aWTIcftF7MXSRP2hbs7WRL+D4fwr4VRAvRJBVg9ljcXxL5p9 /8lX4s8gXked+vfoHr21DzMVI3iSjjKN5bUC+2ePmhIfMGb39HoWwUed7/KkOD6O hvamdJEtWiUMdNXSuTL1 =H2In -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/04/13 00:08, Joe Nash wrote: Managed not to send to all: I think the reason markdown was the original suggestion was due to the fact it is a very widespread and popular syntax, and as Johan commented in the original thread, has to an extent won. Having a consistent, standard documentation syntax for Haskell is of course important, but this project also seeks to standardise the syntax beyond Haskell. I don't think standardising it beyond Haskell is the goal at all. I think that coming up with Markdown that doesn't repeat the mistakes of all the flavours out there is quite difficult in itself, but coming up with such Markdown AND making it making it flexible enough to be of any use with Haddock as is? I think it might be a little out of scope. Extending Haddock itself and providing a writer (and a new reader) for Pandoc will let you write Markdown if you please and then convert it to (and from) many of the formats supported by Pandoc. It may be hedging our bets, as a lot could change and markdown could suddenly fall from fame, but I believe the large variety of opposing markup languages are failing to gain traction in comparison and it is indeed a safe bet. While I don't think it will fall from fame overnight, it would be a shame to restrict people to just using Markdown because that's how all the extensions were implemented. If the flexibility of having it pandoc compatible is a desired feature, can this not be achieved through implementing markdown for haddock as well? Depending on what haddock specific features were required to be added to the superset, it may require only minimal changes to an existing markdown reader/writer in pandoc already. It can, but the restriction comment applies here as well. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRfPllAAoJEM1mucMq2pqXaKAP/20x2549NvfJgib9oitm1Qn8 CCpGRHdSw4xlIh0pHUE1MKyiJrGGgchuUErN2CJBOKXPhn1fgCWFKJyfOhcPbyr7 2Tpb9t++9G9u0JtIb6/UQpgy6RDXQAqOUs78KxRx3DCb3rYuT5TNpr5ynS58T1+9 7eGQXeUQwhCkKZH6EuIF0qTwxPTsMOAT66oRVnaZJFl2+rOBcw8ZmxMsHnk3bX9t VAR+ySwN4FWce6QZwGU43tMwFHoIxsKrmZ3ZydQPfwdQjJjFjCdTaZhtEYS1Hcvu gg0yU5mjO/1frauqjgC/qo4ez/JrJr5aYHrV91o5S2w0Wl7jfUADAIRDLfhAnTe6 shbiPPBPJeY7EAt6JEytHBmlbwZLyE3zrB0GhlhyaKY344Z5k5Woq2u6zInPx5gi rtiWOUbuerBl8autaKwnPa9i+DSmRwMD8esFIyUMyCbPOMj89YirZtxWGD+ol71i cnBXV8DbX9aYfR8c8U3WNeR8FTOvxKYEC8cc3xErsustrwFlDKzlJD41VGHVZvjB qayuRIR/qMy+fy+8UrxzCFQA32gtZ/ZmjfyHWXHhe2DujThmTi95PtgpLHe1Y2Nh hYuGhj6fqzFvSvSJkE2uWlNPVIu7viBcF1bQEZz07OdYuvU+GbA8OK8q3EzCq+l3 l5uWSedwC4cdyNRxigFS =cgRe -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28/04/13 11:57, Joe Nash wrote: On 28 Apr 2013 11:33, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: If the flexibility of having it pandoc compatible is a desired feature, can this not be achieved through implementing markdown for haddock as well? Depending on what haddock specific features were required to be added to the superset, it may require only minimal changes to an existing markdown reader/writer in pandoc already. It can, but the restriction comment applies here as well. Does it? If it is suitable to write in another markup and convert to haddock with pandoc, why is it more restrictive to write in another markup and convert to pandoc-markdown? Have I missed a point here? Extending core Haddock allows us to: 1. Write in any of the Pandoc supported formats, including Markdown 2. Convert it to pure Haddock. This can then be converted back into a different format if need be. Extending Haddock with a Markdown extension allows us to: 1. Write the documentation in any of Pandoc supported formats (including our new Markdown) 2. Convert it from a Pandoc supported format to our Markdown extension as Haddock isn't expressive enough as is to be used. It's a question of being able to go from `Many formats - Pandoc - Many formats' and `Markdown extension - Pandoc - Many formats'. I think these are starting to form two projects with tangential, but slightly differing goals. It would be interesting to see the results if we diverged here and a proposal was submitted for both ideas. I think the goal is still the same: in the end, people will be able to use Markdown to document their code. The means of achieving the goal would give us a different final product that achieves the goal in a slightly different way. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRfQWCAAoJEM1mucMq2pqXSDYQAJDgstjhoDNctcvbQ6OagkOe TVrJ6V7jmSKHYHsQQziGAeEOmXgZ18UX5TEu5w+ZJ//Yf3zCulhMzAjy+jOqGFPY nOJM5kZL6e7udf/rfmrD8r4GKb3yQAvufJIVLZ8UmMZ3vCAqbOiUs7cKOVcgsoD/ nVs11ySfYfLrF64RGcMqJ6Y9AZMcv05UOOSI3aM++0rj96/34TWRwC5XvQqG08Y+ 8eEB0FZijpKFRwMS8eSrTvCTx93pZkRJpMuHawT19zmylvqoME5WCBkeiXrGUuXE VpYAU5ZZxkW03l65yHb8Ir6IB4kTvD09NprhReR5MRf0J4lbL7TX5WZhP/3APFPk on8gPn4XGqVyn93Y9GplfCCOGr6A1271xEwqOF5YV7Y6NkI/c+SBcPGitgBBE1SO 03BIjr02S9wUtk+Su3szXZ0rmU5/zTLgCAcH2aG1MfbV7tDTKrL6m/J80wjzNULQ nhfHPvqEtT/iH6G2BmyLTSuNUgakDYzA10LPRIuxgoCBaZr9mGcJ6wye/xWx6tud RcuG1a8BS02Xau+zPFKgbdp1UQ8sRW2wiqPsbvwHVMoXvJ1j8ro+Xcxv0+vmar67 tWnYRHH4WgG209j1mX3ssj0gWcFUaFHrPYR9Gpv154NxdOEFq32w9eZO1pXndo8f zW9RmOLRpqh30fX3E2iX =0um2 -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/04/13 10:23, Alistair Bayley wrote: How's about Creole? http://wikicreole.org/ Found it via this: http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-language/ If you go with Markdown, I vote for one of the Pandoc implementations, probably Pandoc (strict): http://johnmacfarlane.net/babelmark2/ (at least then we're not creating yet another standard...) Alistair I'd very much like to avoid creating yet another Markdown flavour but I don't think it will be possible to use an existing one in its entirety. The issue (?) with Creole is [1], where you're allowed to tack on anything you want in the parts not covered in the spec. If you ask me, this sounds exactly like what the case was with the original `specification' of Markdown: the documentation was just too damn vague and ambiguous so we ended up with every company interpreting it themselves in a way that was favourable to them. Is there any reason in particular why you'd like Pandoc (strict) Markdown rather than any other flavour? - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRfAZrAAoJEM1mucMq2pqX9vgQAKdOnxJgMoT7GpUEyWGZqNt5 2k2yANgjDIcCDcmK+g8B6USTDAV/guDXyLxK6b/gfGYApBqxzyegE/ogxh6zquoq bdaa0BoIQCRsguHy136WX+uwgNH8KN6L684bVpW0960yrtuRK3ow0uklM6wkvQR3 5V8BU7vhKyVxldgEkPQMLMI+u8ppVDUp6RUW/7EQctunmgWwzaO3LMhrc8eBjumc saee0SR9yUlpFq8zEQIw+EGqsokY5lPbbhfUJwDYbqtm/LRgL5rw+NhptIf1GgFm hGvLqsUsdRRLx5GH/FN2PoQNt4xnqjoPEOXL60p5SYtBvDmfFOFkJ+1oGCrM0JLl Yy4BtcXJpRxFEaWYq/TGaDWdIRSpRZ2JvSwlnHW+EpnXKnPVnReKOzIa4iPD94qS WdX+uK/v6ikmRbht1rkNvV3a+oWYpwx7dIhk+XzcMKxsb1DJ5bmI2/SxfhARcWxJ zXhhYJSB/TpsvPAlKcT3emLJUwaigxr59JxlDmnq9goYl/MZVZDe4ihCH8JwC/hE oHrG7TL5HPLxWjiJ/cmyOsoVgcwgu0SxH4vsHqtFs66uYZ1gPahw6ILJlS0y3lbb XH9w4dkZybXUYPohD5ZZZXtWTKP+xGGNPdvC8D2K0yYNDTXBvXhl9R6S+oBRFIZs G/VgHSOw3givgsrQT+BZ =vZF9 -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/04/13 22:18, John MacFarlane wrote: I agree with Chris that it would be better to have a standard syntax for Haskell documentation. Especially if the alternative is ten different markup languages. (Remember, all of these need to be supported in haddock, which is a basic piece of infrastructure.) Here's a thought. Instead of adding support for markdown, why not enhance the existing haddock markup, making it more expressive, so that it could encode the same range of structural features as markdown? If this were done, we could add a haddock writer to pandoc. There is already a haddock reader in the development version, but a writer is difficult because haddock is so much less expressive than other formats. For example, unless I'm mistaken, it doesn't allow list items with multiple paragraphs or other block elements, or nested lists, or images, or blockquotes. With a pandoc reader and writer for haddock, it would be easy to write your documentation in any format you choose (several variants of markdown, reST, textile, LaTeX, HTML, mediawiki) and produce equivalent haddock markup to paste into the source file. It would also be easy to convert the documentation in your source file to any of the formats supported by pandoc. So, you could generate a man page from your haddock markup, or a web page or blog entry, or a LaTeX document. It seems to me that this would provide most of the advantages people who want a markdown extension for haddock are looking for. But it would not require taking sides in markdown/reST/asciidoc/creole wars, and it would not lead to the fragmentation of documentation formats in Haskell source code. If the extensions to haddock markup were done carefully, it wouldn't even require a special PRAGMA, since all existing markup would have the same interpretation in the extended markup. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I was under the impression that Markdown specifically was requested due to its high popularity, ease of writing and being very readable to a human. As you mention, currently Haddock is not expressive enough to have a writer and would need extending first. The advantages of extending Haddock this way are obvious: people write the documentation in whatever they want and then use Pandoc to convert it to a format they want to distribute in. I'm unsure however whether such an extension is strictly a good thing: what's more readable in source: Haddock with even more stuff tacked on or Markdown with some already present Haddock constructs? There are a fair few complaints about how unwieldy Haddock currently is and I'm worried that extending it for the sake of (a really nice) ability of conversion between formats with Pandoc might make it even more unwieldy. Yes, you can write the docs in any of the billion formats Pandoc supports and then convert it but many people simply want to write docs right into their source files, right as they write actual code without reliance on external tools -- something Markdown would excel at if implemented. So in the end, it just comes down to to what the community _really_ wants: more expressive core Haddock with ability to convert between the formats or yet another Markdown flavour tacked onto Haddock as an extension. It should be noted that this would probably end up serving as a basis for the Pandoc module anyway so why duplicate the effort? Pandoc already handles Markdown, as Christopher Howard pointed out. Discussion on the topic will is most welcome. I am one of the students interested in this project and I have already written a draft proposal with the idea of implementing Markdown as an extension because that's what it seems the community wanted in previous threads and discussions. Is this _really_ what we want though? Personally, I think the benefits of extending Haddock itself and writing a writer module for Pandoc not only cover everything a new, Haskell specific Markdown could do but provide even greater flexibility. I'd also prefer to work on extending Haddock rather than just tacking an extension to it that might not get used because some people might dislike Markdown and would miss out on any new features. The SoC proposal deadlines are on 3rd of May so it'd be great to hear some opinions on this within the next 3 days or so, after which point I will adjust my proposal accordingly, cross my fingers and hope for the best ;) - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRfFXcAAoJEM1mucMq2pqX8kkQAI+xRwMOVsq9T14bKLZ3Wiv7 citbn/hWDYSC8zpSnFIGW87On9/phBIhXaBA5F878mao0AAOMmN0S2ZfcTusaRjk zXm2Dfof6ZKa38xTTjcoBuNWvv7mNwY8592krRPKden2if+II+2bXEd8kqSOX2zi JibaTlXE1ud8sKiUB9hMlE+dcYm3J/G5FJqTFJv45kX2XeApni7J4/4M6ST0X/8z
[Haskell-cafe] Markdown extension for Haddock as a GSoC project
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greetings,
In light of fairly recent discussion, on this mailing list, I decided
to investigate the topic of Markdown support for Haddock. The archives
of the recent discussion can be seen at [1]. This post aims to
summarise the current state of discussion. I do aim to file a proposal
for a GSoC project on this issue but it'd be foolish to file a
proposal for a project aiming to benefit the community without
consulting the community itself.
Here are some main points and ideas gathered:
* reSt seems to have a small following - quite a bit smaller than the
Markdown community. In fact, there seems to be a significant amount of
people pushing for Markdown which contrasts what we can read in a
topic from 2008 at [2]. I guess it just shows how much Markdown has
gained in popularity in recent years.
* There are issues with using Markdown even before we attempt to use
it for Haskell documentation:
* There exists no formal specification or semantics. It would seem
that a significant number of Markdown parsers are creating by reverse
engineering an already existing parser. This is bad because we end up
propagating the bugs and workarounds around ambiguity that the
original parser has.
* As a follow-up to the previous point, the (vanilla) Markdown is
ambiguous and there is nothing to resolve it. As Richard A. O'Keefe
pointed out, there exist situations where it's not possible to infer
the semantics of Markdown from its official implementation and the
result is parser/writer-specific [6].
* John MacFarlane has already written a Markdown parser in Haskell. It
can be read at [3]. This means that the new extension would not need
to rely on Pandoc. He says ``I have an experimental thing here that
could be used as a basis (it's 7x faster than pandoc and uses 1/5 the
memory, BSD licensed)''. This is great! The post can be seen in full
at [4].
* An alternative idea was to simply write a writer module for Pandoc
for Haddock.
* A reader module is already present.
* According to John MacFarlane, Haddock is not expressive enough to
take advantage of this. Furthermore, Pandoc doesn't have some
constructions that Haddock does [4].
* Comes back to the problem on relying on such a large package as
Pandoc.
* Yet another proposal was rather than introducing Markdown to
concentrate on fixing current issues and adding features to Haddock as
it stands [8]. This is one of the options listed at the short blog
post at [14] by Johan Tibell.
* David Waern, one of Haddock maintainers admits that Haddock lacks
active development and it has been that way for a longer time. Having
said that, he seems to believe that Markdown integration is a project
that can realistically be completed over summer. Such project would be
able to use the existing HTML backend in Haddock. [9].
* Math expressions were requested and MathJAX was suggested as a
solution at [5]. math.stackexchange.com uses MathJAX and it works
quite well. Personally, I believe that Haskell documentation would
benefit from this simply due to the academic nature of the language.
* Support for Literate Haskell would be a welcome addition as
suggested by Andrew Butterfield at [7].
* There are issues with CPP and LHS in regards to using Markdown in
documentation. They are pointed out at [10] by John MacFarlane and
others that he's replying to.
* As pointed out 5 years ago at [11], we'd have to do some
preprocessing on current, fairly critical sections of comments used by
Haddock. I believe these are fairly useful and it would be a shame to
see them go.
I hope I haven't missed anything of high importance in a list above.
When researching the topic, issues with Markdown quickly become
apparent. Today, there are tens of different Markdown flavours: each
company has different needs and each company interprets the vague
original documentation in a way that's convenient to them. In these
situations, topics, e-mails and blog posts like this one happen. There
is a call to action from October 2012 at [12] but there seems to be
absolutely no progress on any of the miraculous things mentioned in
the post. As a result of that post, a W3C community was formed at
[13]. It's clear that the community is inactive and no progress
towards a solution was made.
Having considered all information gathered here, I believe this would
make a good GSoC project. There has been interest in this for Haskell
since 2008 judging by the size of the last thread, it's clear that the
community interest is high. In fact, it surprises me that this hasn't
been done in previous years.
The main issue that I see with using Markdown is the fact that we
can't simply add a {-# HADDOCK Markdown #-} and let some parser rip
through it. There are many issues that need to be resolved that I
outlined above. This will no doubt result in a Markdown flavour suited
to documenting Haskell rather than the wonderful, standardised
Markdown that [13] is talking about. Is this different in
Re: [Haskell-cafe] Fwd: GSoC Project Proposal: Markdown support for Haddock
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/04/13 21:50, Johan Tibell wrote: On Tue, Apr 9, 2013 at 12:40 PM, Joe Nash joen...@blackvine.co.uk wrote: I would be interested in discussing this project with a potential mentor if one happens to be reading. I'm a second year Computer Science student at the University of Nottingham, very interested in doing a haskell.org SoC project. Normally I would volunteer to mentor any project I propose, but my schedule doesn't allow for it this summer. Perhaps Mark Lentczner is interested. He did some Haddock work before. I'm happy to provide input on what I think the feature should be about (in fact, I will probably write a blog post about it, like I do every year before GSoC). -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Have you written the post? I'm interested in applying with this as a project and it would be nice to be able to have a read beforehand. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRc/bJAAoJEM1mucMq2pqXzO4P/jET1Khe/H+rOWe7HVdGrLbq x+fPETfhhFZGatRtsKm2HaO8CgLOAyZcV21x5gCRgdoNhAQb9cXeYKRRKEaQYIit joiOGLtn5t45RYt+7d/C3/45CpjaukI2BJ819lLnFHNTebiGEi3UhANzdp6W2uJJ K34tucRxChUL+Th7RzgyvkkgdiVbA8/arDhTCHLX1mQ1DQVm3T0y7M4GxzAc6OqV bb15QA0tH/3/rKGnVc3y+po7EHs+oO5H4XKGvibbdNH0fz8M0XzxnK8oZ0SU2eYE PyELmfI3z7jlKVhnOy+LPw+7+mMP2Ju/lFCWB4S+aotEjPFb4VszUCPwrvqxQsrB nZ2Ekt76IBV58och/lPFG138C1pFwVG+HVE3JMRnWPC271meTiyMtMz9ZMEkDRVL Hq9Djb7IUxgp0G8Z676U4jFH+PzmVVxXi39JIO05aTSxfrJAlYbpRUX5sizCiMv0 xi6osV8PQHurMXIm04CpRFcrqpdiMo9jpIpZyntBTEmJAiIZR7sTIYoqdaI0UmNl bQGdr1fqm5EZm8Iz8x99BQjJrbGrL6UT0qTFmaWJ+o8HPu5zW+ekbWa7G8yMCiq+ tTnN4kH0uVZwwzG5tcM70RUg2bsg3bJSMgfE8Qf340d9lfALeMyPiGoQ+o5CDJ1l hJXAjpXFaP8tWPyW5Kld =syxC -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible GSoC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/13 12:35, Ketil Malde wrote: Hi, I proposed a bioinformatics GSoC project involving Haskell using OSC as the mentoring organization. Typically, haskell.org projects concern infrastructure rather than applications, and I don't know if I'm allowed to submit both places :-) Anyway, as this is a likely place to find prospective students and (co-)mentors, I thought I'd mention it here. But if anybody is interested, I think it makes for a quite focused, solvable problem, which I belive would be quite useful. It could also likely result in a scientific publication of some sort. A quick writeup (that I'll probably update) is here: http://biohaskell.org/Google_Summer_of_Code#optimizing-transalign -k What would you say is the level of bioinformatics understanding that one would have to have to even consider applying? - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRXYwYAAoJEM1mucMq2pqXSzcP/3RfYhPwAQU1LsI3tKa/sRni fBxGOSyPnySqUHzvDIGTw+1Ym3p9Kdy7Mv6l4zh65fcjqBPzRfK6gWWTJ6vYbGT9 poko8LzSmUsXPUnI+jca9W/iWJaR3pTI4iQkhqfpGz9qU2I9OKg0D3oNbFg4rkaS REXRXz0UEioMPh17OkX+O2KXP7SrX2cu879n6AIKptLDCkiUr4dY758PtfbgVE7N z4TNAquZ4ytsajgOD1dBpys8U1aaxNna9MBxhFpglDQXs9CBCZOkK+2DWo99dGD5 opP133bJnhja/fOcUAPW4BhUy28q7Tf78lXet9vWgurWOV1hlv8sRUinosT2UET1 +9nTDD0Y9p93KAysV0YPO+LKrQnwhp/6Qcug48FbqwkfMcJmGgdaq+Yx+LLmEKK2 31Qh8oSnr3Ye782XFXDKtBRtBlima1lPg8tykk3jiFrKqRhjBCPtpWIb6jYTyOTJ 792fyXeMzwUgvZyV3jU7axS5+F44v72i0yKmCrD8gmdNNVMbP4wIVFR7MU/THVo+ FF1qoHc7jiAlLn5/z75CuL7aCi5VTq2x1cxv0EeyRyqOfAxXoNDq0d96J24mVvsF Dar6nfqiH9VOcEnTf/N0WWN3AqSQJ+144NlgFtV5d2pFN4n/5s+DcGIooy68jZbg wdk3DX0s7/IkAT3T/rwz =W2wV -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type level natural numbers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 About two weeks ago we got an email (at ghc-users) mentioning that comparing to 7.6, 7.7.x snapshot would contain (amongst other things), type level natural numbers. I believe the package used is at [1]. Can someone explain what use is such package in Haskell? I understand uses in a language such as Agda where we can provide proofs about a type and then use that to perform computations using the type system (such as guaranteeing that concatenating two vectors together will give a new one with the length of the two initial vectors combine) however as far as I can tell, this is not the case in Haskell (although I don't want to say ?impossible? and have Oleg jump me). - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRXIYYAAoJEM1mucMq2pqXT00P/imTf/Wd7UZ0T0ZPUbM6i3Nj P5ffEUvUGf5V1jmXub/ibVFv6QHkTigsF/K9VPo13ChtA7u4qnxH7pd+zbTCp6c4 +A4dgKLVvlB+tGSvKzmsJxEtRh/rtv0UMP2RtvKoB7DH2mMv99EDkKmndWaxOI2z VjAvYFqdi//3O0P9bN9/93KZNUZviHh/5IP8f6HcpCWVDu+Z5CKbzUM6roxsBNM1 a1y6RjQp2SnUFMlJnKbWepRbn2p12dzmMrXzF2UINkTkDTytP+ZIK1ZpS8/qh6i6 q44GUBa2doHxhX9H+Vo3Vims3S0otyVmTQX/b2J1R7FoBl6fsPa+XUeE8RJwfSzm 0Ho75AX39rynO9AJ+/hZQdk6G6VkED/JszWBSnfC56VNB0vdYI4e2mBGny4uL9MU PnVb+fYk0xuSw7wAqLnVo2ZQqyvN79uNDT4x0uf/6zvkQ8LoSzMr99YwjWI5jo2X 8dqphjPPArX9MV0xCPdkpU6wPHSvEK4fOxJcqDq104+ssJdNr8PXbhtIifa/KE/C B2jhmwRllbtbg1HGXQ8zWlY+VbE+sc5O2AvhrV14fKF8xkNtLRzvhAWR/cOTXLZ0 hA7r6Jjf4mzQnUBgb/BW8pH6N+UnjkV/JgJ45WHB3PSADU3JspyuG7uJUOCod75e D/849dOCHHrkYsYEPdJq =JCfK -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type level natural numbers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/04/13 20:42, Mateusz Kowalczyk wrote: About two weeks ago we got an email (at ghc-users) mentioning that comparing to 7.6, 7.7.x snapshot would contain (amongst other things), type level natural numbers. I believe the package used is at [1]. Can someone explain what use is such package in Haskell? I understand uses in a language such as Agda where we can provide proofs about a type and then use that to perform computations using the type system (such as guaranteeing that concatenating two vectors together will give a new one with the length of the two initial vectors combine) however as far as I can tell, this is not the case in Haskell (although I don't want to say ?impossible? and have Oleg jump me). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Forgot package link - http://hackage.haskell.org/packages/archive/type-level-natural-number/1.1.1/doc/html/TypeLevel-NaturalNumber.html - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRXIcPAAoJEM1mucMq2pqXRX4QAILITsFLspe6Fd95uV8HUbSv rwoCalPkaUaYBsJ2tAC27dlBPjmom25u6ISIaiiDI+XHyoQiMza+hQostIny6pR3 vjlhxuBFZQYHxJHJd90hUdDQ4+OXt+aPJbMvgwbA72yJsb95Kv1CVagF3U3wGb3X VPSAAgbAf0NXNbVeOF7n73g1iCCfdf4QylKc64WsJInVgqBOc7XKHLGwXuhtJ+IF 1UAoS0AOYoKe7LCoDRjkKOQYqbUs6nY8GdgDNEsDdcev7GWQ3zFafGXAfVPYoe1u I1Af5puQEJFsyvVF/AwDPR5INiVGPR6bTYAJ/oW3/3tpEswK8+tvJsqYjsPWzY8Y 7R39oYcglFe4QoixtpDtoNB9up6rT4hWbUF1TQml20IceNIvbi3+DIyZEIwgUfXg d+CpBe1AAyCZQreF1LpQbrJc1by7pHS9+LYq4od+VClXFZJPjQLUR3qZjS6PgH4m n5zpPzvatKY/HfMcApxW8v25ZKfOLLJGUFZ6tl8Z5go8CN9i9ptkeyrJYTyRs6FQ K66RBQlghNFaCYTJnC6+TtNRUdKAwm0+kGMjHGrp0MGY6yasHddhD7NZ177iIKwV MOmqXsWrFPcEuhq08OzUZd0lQL+KgQF5XEnf3mTXo1Bj1lQPoUY2ERCvtfZl6B/V 6XkP7asJSYUKXYhAp/cJ =fw3P -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GSOC application level
Greetings, It seems that the Haskell community consistently participates in the Google Summer of Code project. I (and probably many others) am interested in taking part in one of such projects but I have a question in regards to the expertise. I know that this year's projects aren't up yet but by looking at the past results, the expertise required seems to vary pretty widely. Can someone that has been around for a bit longer comment on what level of experience with Haskell and underlying concepts is usually expected from candidates? Are applications discarded simply based on the applicant not having much previous experience in the target area? What is the level of the competition for places on the projects? It's not my first week of meddling with Haskell (and studying the ideas behind it) but I can't say that I would be able to confidently take on any project that might be put out. I do however realise that the project is open to students so I don't imagine the requirements specify something like couple of years with type theory research either. Any insight about the topic is appreciated. I'd much rather flip bits than do labour this summer and if it can be done using the language I'm interested in, even better! -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] layers: A prototypical 2d platform game
On 19/02/13 13:39, Daniel Trstenjak wrote: On Tue, Feb 19, 2013 at 02:15:33PM +0100, Vo Minh Thu wrote: Screenshots obviously ;) Hurray! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Eh, I expected a game where we get to catch combinators and other cool stuff. How about a game where you collect functions that compose with each other and you lose points on those that don't. The implementation might be tricky but I think it's a nice spin-off from the typical formula. -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] xml conduit
Hmm, I just tried with a 112MB file and I ended up having to kill it after it chewed through 3GB of memory. That's rather worrying. Hopefully someone on cafe can point out whether it's an inherent issue with the package, a bug or whether we're just doing something wrong. On 09/02/13 15:30, grant wrote: Mateusz Kowalczyk fuuzetsu at fuuzetsu.co.uk writes: I don't know about xml-conduit but I know that such thing is possible in HXT. See the `Modifying a Node' section at [1] for a trivial example. You probably will have to read the whole page to somewhat understand what's going on though. [1] - http://adit.io/posts/2012-04-14-working_with_HTML_in_haskell.html Thanks for the tip, which looks really promising. The problem is that I cannot get large xml files to load with HXT. I tried a 24mb file and it ran out of memory, whereas with xml-conduit it took 15 seconds to load. Is there something I'm missing? Grant ___ 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] xml conduit
I don't know about xml-conduit but I know that such thing is possible in HXT. See the `Modifying a Node' section at [1] for a trivial example. You probably will have to read the whole page to somewhat understand what's going on though. [1] - http://adit.io/posts/2012-04-14-working_with_HTML_in_haskell.html On 08/02/13 23:31, grant wrote: Hi, Is there a nice way to update xml. I want to be able to use xml-conduit to find a location in the xml and then add/update that node. eg xpath from //d/e/f and then change the content at 'f' or add a new node a ... d e fsome data to change /f /e /d ... /a Thanks for any help, Grant ___ 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] How far compilers are allowed to go with optimizations?
You don't reason about the bits churned out by a compiler but about the actual code you write. If you want to preserve such information during the compilation process, you probably want to run the compiler without any optimization flags at all. At the moment, with the way you are thinking about it, you'd have to reason about every program based on every compiler version it can go through. What happens instead is that people prove their program correct and other people prove the compiler correct. What it does behind the scenes doesn't matter: it's meant to preserve the exact semantics and if it does extra stuff on top that doesn't change those (like optimisation) you should be happy as now it will run more efficiently in practice, and not just on paper. On 06/02/13 11:45, Jan Stolarek wrote: programmer wouldn't be able to reason about space behaviour of a program ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with code blocks in the description field in a .cabal file
I don't understand why you're putting it in your .cabal file. Isn't
something like 3.8.5 over at [1] what you're trying to achieve?
...
I had a look at a package ([2]) that I know uses a multi-line code block
example. Here's what I found in its cabal file:
An example:
.
runShpider $ do
download http://apage.com;
theForm : _ - getFormsByAction http://anotherpage.com;
sendForm $ fillOutForm theForm $ pairs $ do
occupation =: unemployed Haskell programmer
location =: mother's house
.
Depending on your mail client, the `' signs might get quoted.
[1] - http://www.haskell.org/haddock/doc/html/ch03s08.html
[2] -
http://hackage.haskell.org/packages/archive/shpider/0.2.1.1/doc/html/Network-Shpider.html
On 04/02/13 12:30, Josef Svenningsson wrote:
Hi,
I'm putting together a cabal package and I'd like to have some code
examples in my description file. In particular I would like to have a
code block containing markdown containing a code block of Haskell, like
this:
~~~{ .haskell }
module Main where
main = putStrLn Hello World!
~~~
When I put the above code in my .cabal file and do `cabal haddock
--executables` I get the following error:
haddock: failed to parse haddock prologue from file:
dist/doc/html/codeExtract/codeExtract/haddock-prolog31969.txt
In general I can provoke the parse error from haddock whenever I have
something inside curly braces.
So the error seems to stem from haddock. I've tried to track down what
happens inside haddock but I've run out steam. I'd like to know if there
is anything I can do to be able to write something like the above as
part of the description in my .cabal file.
Thanks,
Josef
___
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] Up-front Unit Testing in Haskell
Quite informative, thank you. It was nice to see how to combine the suites together as most places only show how to use one. The mention about Travis CI is also much appreciated; it seems like a really good project and I will definitely be using it in the future. Mateusz Kowalczyk On 21/01/13 02:55, Kazu Yamamoto (山本和彦) wrote: #Resending due to the lack of URL. Hello cafe, Just FYI: I wrote an tutorial, Up-front Unit Testing in Haskell. It is about how to use doctest, hspec and Cabal. https://github.com/kazu-yamamoto/unit-test-example/blob/master/markdown/en/tutorial.md Enjoy! --Kazu ___ 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] Backtracking in HXT
Ah, zeroArrow looks exactly like what I need here!
Thanks, this helps.
Mateusz Kowalczyk
On 01/01/13 01:08, dag.odenh...@gmail.com wrote:
( is my GHCi prompt, might be a bit confusing for an arrow example.)
On Tue, Jan 1, 2013 at 2:05 AM, dag.odenh...@gmail.com
mailto:dag.odenh...@gmail.com dag.odenh...@gmail.com
mailto:dag.odenh...@gmail.com wrote:
Use arrow notation and zeroArrow, like so:
{-# LANGUAGE Arrows #-}
import Text.XML.HXT.Core
getA =
hasName a proc elem - do
text - getText getChildren - elem
if text == Hello Two!
then getAttrValue href - elem
else zeroArrow - ()
runX $ readString [] htmla
href='example.com/somelink.html
http://example.com/somelink.html'Hello One!/aa
href='example.com/anotherlink.html
http://example.com/anotherlink.html'Hello Two!/a/html
deep getA
[example.com/anotherlink.html http://example.com/anotherlink.html]
On Mon, Dec 31, 2012 at 3:36 PM, Mateusz Kowalczyk
fuuze...@fuuzetsu.co.uk mailto:fuuze...@fuuzetsu.co.uk wrote:
Hello,
I'm not sure if this is the right place to ask this but here goes.
I'm currently working with HXT and I quite like it. There's
one issue I
can't solve (at least now without some dirty, dirty hacking)
and I'm
sure it's fairly simple.
Consider the following mark-up
a href=example.com/somelink.html
http://example.com/somelink.htmlHello One!/a
a href=example.com/anotherlink.html
http://example.com/anotherlink.htmlHello Two!/a
Now, what I'm trying to achieve is to get the href based on
the text. I
can test for what the text is by traversing as, then using the
getChildren getText arrow. What I can't figure out is how
to check
the text and then get the href as by the time I get to the
text, I'll
further down the tree!
I imagine it would look something along the lines of
(getChildren getText ?* Hello Two) `guards` getAttrValue
href. ?* is just a random operator I made up for illustration
purposes that works as a predicate over arrows.
Is this the right approach? Is there a built-in that already
does what I want? It
seems like a common task...
Mateusz Kowalczyk
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org mailto: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] Backtracking in HXT
Hello, I'm not sure if this is the right place to ask this but here goes. I'm currently working with HXT and I quite like it. There's one issue I can't solve (at least now without some dirty, dirty hacking) and I'm sure it's fairly simple. Consider the following mark-up a href=example.com/somelink.htmlHello One!/a a href=example.com/anotherlink.htmlHello Two!/a Now, what I'm trying to achieve is to get the href based on the text. I can test for what the text is by traversing as, then using the getChildren getText arrow. What I can't figure out is how to check the text and then get the href as by the time I get to the text, I'll further down the tree! I imagine it would look something along the lines of (getChildren getText ?* Hello Two) `guards` getAttrValue href. ?* is just a random operator I made up for illustration purposes that works as a predicate over arrows. Is this the right approach? Is there a built-in that already does what I want? It seems like a common task... Mateusz Kowalczyk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mancunian Haskellers out there?
Greetings, I'm currently residing in Bury, a metrolink ride away from Manchester. Unfortunately, I'm only here for Christmas holidays and am leaving tomorrow so a meeting is unlikely. I don't think that I'd be a good conversation partner anyway as my knowledge is still quite limited. I'd love to hear whether you find any other people though. It would be nice if some Haskell talks could be held in the area if there are enough people. Good luck on your search, Mateusz Kowalczyk On 30/12/12 14:38, Alfredo Di Napoli wrote: Morning Cafe, I've been living in Manchester for 1 month now and I'm wondering if some on you are from the Greater Manchester area, so that we could chat about out beloved language in front of a glass of ale / tea :P Happy new year to everyone! A. ___ 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
