[Haskell-cafe] Re: Hiding side effects in a data structure
Cale Gibbard [EMAIL PROTECTED] writes: On 21/10/2007, Jon Fairbairn [EMAIL PROTECTED] wrote: No, they (or at least links to them) typically are that bad! Mind you, as far as fragment identification is concerned, so are a lot of html pages. But even if the links do have fragment ids, pdfs still impose a significant overhead: I don't want stuff swapped out just so that I can run a pdf viewer; a web browser uses up enough resources as it is. And will Hoogle link into pdfs? Swapped out!? What PDF viewer are you running on what machine? Currently, with a 552 page book open (Hatcher's algebraic topology), my PDF viewer (Evince) uses about 36MiB, If loading another 36MiB doesn't cause swapping, you're obviously not running enough haskell programmes. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hiding side effects in a data structure
On 10/26/07, John Meacham [EMAIL PROTECTED] wrote: Heh, the plethora of pdf papers on Haskell is part of what originally brought me to respect it. Something about that metafont painted cmr just makes me giddy as a grad student. A beautifully rendered type inference table is a masterful work of art. Did I mention I was a little odd? I am sure I did. http://xkcd.com/242/ Actually, yeah I kindof agree. It's quite interesting to see a language developed using rigorous, formal mathematical principles. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hiding side effects in a data structure
Hugh Perkins [EMAIL PROTECTED] writes: On 10/26/07, John Meacham [EMAIL PROTECTED] wrote: Heh, the plethora of pdf papers on Haskell is part of what originally brought me to respect it. Something about that metafont painted cmr just makes me giddy as a grad student. A beautifully rendered type inference table is a masterful work of art. Did I mention I was a little odd? I am sure I did. http://xkcd.com/242/ Actually, yeah I kindof agree. It's quite interesting to see a language developed using rigorous, formal mathematical principles. Lest anyone think otherwise, I most thoroughly approve of Haskell relying on rigorous foundations. I just want the foundations to be easy to inspect! -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hiding side effects in a data structure
On Thu, 2007-11-01 at 21:42 +, Jon Fairbairn wrote: Hugh Perkins [EMAIL PROTECTED] writes: On 10/26/07, John Meacham [EMAIL PROTECTED] wrote: Heh, the plethora of pdf papers on Haskell is part of what originally brought me to respect it. Something about that metafont painted cmr just makes me giddy as a grad student. A beautifully rendered type inference table is a masterful work of art. Did I mention I was a little odd? I am sure I did. http://xkcd.com/242/ Actually, yeah I kindof agree. It's quite interesting to see a language developed using rigorous, formal mathematical principles. Lest anyone think otherwise, I most thoroughly approve of Haskell relying on rigorous foundations. I just want the foundations to be easy to inspect! It doesn't strike me that math in HTML is easier to inspect than PDF. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hiding side effects in a data structure
On 21/10/2007, Jon Fairbairn [EMAIL PROTECTED] wrote: No, they (or at least links to them) typically are that bad! Mind you, as far as fragment identification is concerned, so are a lot of html pages. But even if the links do have fragment ids, pdfs still impose a significant overhead: I don't want stuff swapped out just so that I can run a pdf viewer; a web browser uses up enough resources as it is. And will Hoogle link into pdfs? Swapped out!? What PDF viewer are you running on what machine? Currently, with a 552 page book open (Hatcher's algebraic topology), my PDF viewer (Evince) uses about 36MiB, which is around 3.6% of my available memory, a rather pedestrian 1 GiB. Other documents produce very similar results. The largest I was able to make it with a PDF which wasn't pathologically constructed was about 42MiB, with a PDF that had lots of diagrams. Firefox uses about twice that on an average day. If your PDF viewer uses significantly more than that, I recommend looking for a new one. ;) - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hiding side effects in a data structure
On Tue, Oct 23, 2007 at 10:01:37AM +0100, Jon Fairbairn wrote: That sort of misses my point. Given the length of time I've been involved with it, I hardly need encouragement to use Haskell, but if even I find getting to the documentation off-putting, having to know a trick to do it isn't exactly going to draw the reluctant programmer away from its bad language habits. Heh, the plethora of pdf papers on Haskell is part of what originally brought me to respect it. Something about that metafont painted cmr just makes me giddy as a grad student. A beautifully rendered type inference table is a masterful work of art. Did I mention I was a little odd? I am sure I did. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hiding side effects in a data structure
Brandon S. Allbery KF8NH [EMAIL PROTECTED] writes: On Oct 21, 2007, at 6:29 , Jon Fairbairn wrote: No, they (or at least links to them) typically are that bad! Mind you, as far as fragment identification is concerned, so are a lot of html pages. But even if the links do have fragment ids, pdfs still impose a significant overhead: I don't want stuff swapped out just so that I can run a pdf viewer; a web browser uses up enough resources as it is. And will Hoogle link into pdfs? I prefer HTML for online viewing and PDF for offline. BTW, you might consider a trick: look up the PDF on google, use the HTML view. That sort of misses my point. Given the length of time I've been involved with it, I hardly need encouragement to use Haskell, but if even I find getting to the documentation off-putting, having to know a trick to do it isn't exactly going to draw the reluctant programmer away from its bad language habits. -- Jón Fairbairn [EMAIL PROTECTED] http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2007-05-07) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hiding side effects in a data structure
Jon Fairbairn wrote: A hyperlink of the form a href=http://.../long-research-paper.html#interesting-paragraph; interesting bit/a is far more useful than one of the form a href=http://.../long-research-paper.pdf;look for section 49.7.3/a. It may not seem significant, but when one is attempting to learn some new part of Haskell it's really off-putting. Pdfs are not that bad. You can hyper link into them too. It would look like: a href=http://.../long-research-paper.pdf#page=45; ... to open the pdf a position you on page 45 of it or like: a href=http://.../long-research-paper.pdf#anchorName; ... to open the pdf and position you on anchor anchorName You can do it from command line too: acrord32 /A page=45 long-research-paper.pdf acrord32 /A anchorName long-research-paper.pdf This of course requires the source to give you more precise link. But here there is no difference from html only ... possibly ... more people know about html linking than pdf linking. The above definitely works OK on windows, not sure about linux pdf viewers. Unfortunately I cannot find now how you can look at all anchors defined in a pdf (so that you can use something better than page=num). Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hiding side effects in a data structure
Peter Hercek [EMAIL PROTECTED] writes: Jon Fairbairn wrote: A hyperlink of the form a href=http://.../long-research-paper.html#interesting-paragraph; interesting bit/a is far more useful than one of the form a href=http://.../long-research-paper.pdf;look for section 49.7.3/a. It may not seem significant, but when one is attempting to learn some new part of Haskell it's really off-putting. Pdfs are not that bad. No, they (or at least links to them) typically are that bad! Mind you, as far as fragment identification is concerned, so are a lot of html pages. But even if the links do have fragment ids, pdfs still impose a significant overhead: I don't want stuff swapped out just so that I can run a pdf viewer; a web browser uses up enough resources as it is. And will Hoogle link into pdfs? The above definitely works OK on windows, not sure about linux pdf viewers. Works perfectly on my Fedora 7 systems. While this would be a definite improvement over having to search through the pdf, the delay and the fact that pdfs aren't as good as html for on-line viewing are still enough of an overhead that it's discouraging. If I'm using PHP (an execrable language), I can type the name (or something like the name) of any function into the search box on the PHP manual webpage and get useful (albeit often extremely irritating from a Haskell programmer's point of view) results straight back. Even including my language designer's distaste for PHP, this can make writing a wee bit of PHP a less onerous event than writing the same thing in Haskell -- definitely not what we want! -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hiding side effects in a data structure
Yes, htmls are better than pdfs (more lightweight, easier to work with if exact page layout is not important). I just wanted to point out that it is possible to link into some particular place of a pdf document. So the linking availability should not be the argument by itself. I would prefer html too but if pdf is required otherwise, it would be nice if link suppliers would provide more precise links. To spread the information that they can do so is the main reason I responded. Peter. Jon Fairbairn wrote: Peter Hercek [EMAIL PROTECTED] writes: Jon Fairbairn wrote: A hyperlink of the form a href=http://.../long-research-paper.html#interesting-paragraph; interesting bit/a is far more useful than one of the form a href=http://.../long-research-paper.pdf;look for section 49.7.3/a. It may not seem significant, but when one is attempting to learn some new part of Haskell it's really off-putting. Pdfs are not that bad. No, they (or at least links to them) typically are that bad! Mind you, as far as fragment identification is concerned, so are a lot of html pages. But even if the links do have fragment ids, pdfs still impose a significant overhead: I don't want stuff swapped out just so that I can run a pdf viewer; a web browser uses up enough resources as it is. And will Hoogle link into pdfs? The above definitely works OK on windows, not sure about linux pdf viewers. Works perfectly on my Fedora 7 systems. While this would be a definite improvement over having to search through the pdf, the delay and the fact that pdfs aren't as good as html for on-line viewing are still enough of an overhead that it's discouraging. If I'm using PHP (an execrable language), I can type the name (or something like the name) of any function into the search box on the PHP manual webpage and get useful (albeit often extremely irritating from a Haskell programmer's point of view) results straight back. Even including my language designer's distaste for PHP, this can make writing a wee bit of PHP a less onerous event than writing the same thing in Haskell -- definitely not what we want! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hiding side effects in a data structure
On Oct 21, 2007, at 6:29 , Jon Fairbairn wrote: No, they (or at least links to them) typically are that bad! Mind you, as far as fragment identification is concerned, so are a lot of html pages. But even if the links do have fragment ids, pdfs still impose a significant overhead: I don't want stuff swapped out just so that I can run a pdf viewer; a web browser uses up enough resources as it is. And will Hoogle link into pdfs? I prefer HTML for online viewing and PDF for offline. BTW, you might consider a trick: look up the PDF on google, use the HTML view. This is generally poor for documents with significant graphics, but works reasonably well for most Haskell papers (modulo math I usually can't figure out anyway, lacking the background many Haskellers have in set theory / rings / groups/semigroups etc.). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hiding side effects in a data structure
Simon Peyton-Jones [EMAIL PROTECTED] writes: I realise belatedly that my message might have sounded dismissive. My apologies; it wasn't intended to be. Good ideas are just that: good. Reinventing them is a sign of good taste. As to documenting GHC, we try to do that by writing papers. That's easy to motivate because we get research brownie points for papers. One of the irritating effects of this process is not that the reports are research papers, but that they are on-line sporadically and only very rarely html. The overhead of having to download a big file (or search through one's own copies) and fire up some other viewer (for .ps or .pdf) -- or worse find a printed copy or fork out £55.97 to read something online) is a significant obstacle when all one wants to do is to is check the syntax of something or look up a short bit of code. A hyperlink of the form a href=http://.../long-research-paper.html#interesting-paragraph; interesting bit/a is far more useful than one of the form a href=http://.../long-research-paper.pdf;look for section 49.7.3/a. It may not seem significant, but when one is attempting to learn some new part of Haskell it's really off-putting. -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
