[Haskell-cafe] Re: Haskellers.com idea: strike forces
Michael Snoyman wrote: In the recent discussion about the status of email support in Haskell, the idea of strike forces to tackle these big problems came up. I think one dilemma people face when trying to coordinate such a venture is the logistics: where to organize, how to advertise it, where to have discussions that can be publicly accessible. This may be something that the Haskellers website can help address. That's a great idea! Concerning the details of how things should work, it's probably best if you simply start a SIG yourself (you mentioned web development) and code everything that comes up on the fly. There is no better way to ensure usability of an application than to write it while heavily using it (and aiming for a large usability / features ratio). Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Edit Hackage
On Saturday 30 October 2010 03:42:27, Ivan Lazar Miljenovic wrote: On 30 October 2010 12:22, Lauri Alanko l...@iki.fi wrote: On Thu, Oct 28, 2010 at 01:55:12PM -0700, Don Stewart wrote: The number of subscribers to the Haskell Reddit, for example, is double the -cafe@, and there are comparable numbers of questions being asked on the Stack Overflow [haskell] tag, as here -- so anyone who only reads -cafe@ is already missing a lot of stuff. A lot of the community has already voted on the efficacy of mailing lists for large communities, by moving their discussion elsewhere. Do you mean that people have actually unsubscribed from the list in favor of only following web-based media? New people who only join the web forums do not vote since they may not even know about the mailing list. I know that this is a hopeless battle, but since I feel very strongly about this, I'll indulge in defending the mailing list even though this is rather off-topic. The reasons why I prefer mailing lists (and newsgroups, rest in piece) over web-based discussion forums: * Usability: mail and news clients provide a consistent interface to all the discussions, and the customizability and diversity of clients ensures that everyone can access the discussions the way they like it. In contrast, web forums come with their built-in interfaces, and if you don't like them, you are SOL. * Scalability: related to the above, since mail and news provide a consistent interface to all the discussions, adding new lists and groups to be followed requires minimal effort since they just show up as new items whose updates get tracked automatically. In the worst case, adding a new web forum to be followed requires visiting the site frequently to check whether new messages have arrived. RSS and similar syndication technologies help, thankfully, but support for them is inconsistent, and often incomplete (they might not notify about new comments, only new topics). I subscribe to tens of mailing lists without problems. I wouldn't want to try to follow tens of web forums regularly. * Archivability: with mail and news, it is trivial for me to get local copies of the discussions (and the messages I myself have written) which I can peruse and search to my heart's content later without being dependent on the continued functioning of some external service. Although it is possible to save web pages locally, this usually very inconvenient, especially if one wants the local copies to be kept up to date with ongoing discussions. * Offline support: related to the above, with mail and news fetching and sending messages are separate from reading and writing them. Hence one can read and write messages even when one is for some reason not online. Web forums practically require an online connection when one wants to read the discussions. * Neutrality: newsgroups are completely distributed and not controlled by any single entity. Mailing lists are a centralized service, but a purely technical one. The haskell.org mailing lists (like the rest of haskell.org) are directly maintained by the community. In contrast, external web forums like reddit and stackoverflow are owned by companies, and visits to the sites bring ad revenue to the companies. Moreover, the contents of these sites are subject to deletion (or perhaps even editing) by the whims of their owners. In short, the old technologies of mail and news are technically vastly superior to web forums, which have required additional technologies (e.g. RSS) to attempt to overcome the obstacles that mail and news solve directly. It is true that web forums are nowadays very popular and have some nice features that the older technologies don't. The main reason for this, I suspect, is money: mail and news are from the older, more innocent age when internet technology was driven by the desire to communicate efficiently instead of making money. They are by their nature so neutral that they provide no financial incentive to develop them or support them. The web, on the other hand, provides many opportunites to profit by offering services, so it is no wonder that web technologies have flourished in the commercialized internet. Perhaps this is inevitable, and it is certainly ok for the haskell.org front page to provide links to reddit and stackoverflow just to inform visitors that these sites might be of interest. But by saying I encourage people to use the online forums: Haskell Reddit and Stack Overflow you are effectively saying: please let Condé Nast Digital and Stack Overflow Internet Services, Inc capitalize on your interest in and knowledge of Haskell. I most strongly object to this becoming the standard policy of the Haskell community. +1; that's pretty much my opinion/arguments as well. +1; same here.
[Haskell-cafe] Re: Haddock API and .haddock interface files questions
2010/10/26 Claus Reinke claus.rei...@talk21.com: Some questions about Haddock usage: 1. Haddock executable and library are a single hackage package, but GHC seems to include only the former (haddock does not even appear as a hidden package anymore). Is that intended? Yes, I think that's so that GHC maintainers don't need to worry about API changes in Haddock when making new releases. The Haddock API is not very stable. 2. Naively, I'd expect Haddock processing to involve three stages: 1. extract information for each file/package 2. mix and match information batches for crosslinking 3. generate output for each file/package I would then expect .haddock interface files to repesent the complete per-package information extracted in step 1, so that packages with source can be used interchangeably with packages with .haddock files. However, I can't seem to use 'haddock --hoogle', say, with only .haddock interface files as input (No input file(s).). Haddock currently mostly works on GHC's front-end AST, called HsSyn, which is not stored in the .haddock files, so that's why you need sources. I say mostly, because the one-year old feature that we call cross-package documentation (allowing the user to re-export documentation from other packages), is implemented by taking information from GHC's .hi files, converting that to HsSyn. The syntax used in the .hi files is slightly less detailed than HsSyn so we loose some information about the exact declaration syntax used by the programmer (brackets in type expressions, infix/prefix declaration styles, etc - nothing that is semantically relevant). In theory we could continue along that road and let you build output from a combination of .haddock and .hi files. Or we could do as you say and just put everything in the .haddock files (in which case we could use the HsSyn type). 3. It would be nice if the Haddock executable was just a thin wrapper over the Haddock API, if only to test that the API exposes sufficient functionality for implementing everything Haddock can do. Yes, good idea. We haven't done that yet since the API started out as something quite experimental, and it's still in that stage although it has gained a lot more functionality recently. Instead, there is an awful lot of useful code in Haddock's Main.hs, which is not available via the API. So when coding against the API, for instance, to extract information from .haddock files, one has to copy much of that code. Also, some inportant functionality isn't exported (e.g., the standard form of constructing URLs), so it has to be copied and kept in synch with the in-Haddock version of the code. Right. We should export that. It might also be useful to think about the representation of the output of stage 2 above: currently, Haddock directly generates indices in XHtml form, even though much of the index computation should be shareable accross backends. That is, current backends seem to do both stage 2 and stage 3, with little reuse of code for stage 2. True. The index could be factored out of the Xhtml backend and added to the output of stage 2. It seems that exposing sufficient information in the API, and allowing .haddock interface files as first-class inputs, there should be less need for hardcoding external tools into Haddock (such as --hoogle, or haddock-leksah). Instead, clients should be able to code alternative backends separately, using Haddock to extract information from sources into .haddock files, and the API for processing those .haddock files. Are these expectations reasonable, or am I misreading the intent behind API and .haddock files? Is there any documentation about the role and usage of these two Haddock features, as well as the plans for their development? No documentation yet, but yes, the long term plan is to be able to split Haddock in parts: one program that creates data from sources, probably resulting in a .haddock file or maybe something text based, and backends that use those files. The API should provide a convenient way to read the files. It's not been fleshed out in detail yet, and the API is quite ad-hoc at the moment so we need think more about this and write documentation on the Haddock trac. Thanks for the input! David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Monads and Functions sequence and sequence_
The actual, entire, complete definitions of sequence and sequence_ are (or at least, could be): sequence [] = return [] sequence (m:ms) = do x - m xs - sequence ms return (x:xs) -- or, equivalently: sequence' = foldr (liftM2 (:)) (return []) sequence_ [] = return () sequence_ (x:xs) = do x sequence_ xs -- or: sequence'_ = foldr () (return ()) They're defined once for all monads, not once for each monad, so in some sense they behave the 'same' in that they use the Monad instance in the same way. It's just like, say, sort :: Ord a = [a] - [a] might do different computations to compare elements depending on what 'a' is, but always produces a sorted list regardless of that detail. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector-space and standard API for vectors
wren ng thornton schrieb: On 10/22/10 8:46 AM, Alexey Khudyakov wrote: Hello everyone! It's well known that Num Co type classes are not adequate for vectors (I don't mean arrays). I have an idea how to address this problem. Conal Elliott wrote very nice set of type classes for vectors. (Definition below). I used them for some time and quite pleased. Code is concise and readable. class AdditiveGroup v where zeroV :: v (^+^) :: v - v - v negateV :: v - v [...] I'd like to know opinion of haskellers on this and specifically opinion of Conal Eliott as author and maintainer (I CC'ed him) Looks like you are about to re-implement numeric-prelude. :-) Just my standard complaint: lack of support for semirings, modules, and other simple/general structures. How come everyone's in such a hurry to run off towards Euclidean spaces et al.? I'd rather see, class Additive v where -- or AdditiveMonoid, if preferred zeroV :: v (^+^) :: v - v - v class Additive v = AdditiveGroup v where negateV :: v - v type family Scalar :: * - * Vector (Complex a) is a vector with respect to both 'a' and 'Complex a'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell-Cafe Digest, Vol 86, Issue 63
Hello John, Thanks for your detailed answer. I finally understood this behaviour and got to the point where I need something like enumPair. About the scala implementation, it was this same blog post that arose my interest in iteratees :-) Regards, Arnaud On Wed, Oct 27, 2010 at 5:26 PM, John Lato jwl...@gmail.com wrote: Hi Arnaud, From: Arnaud Bailly arnaud.oq...@gmail.com Hello, I am trying to wrap my head around the concept of Iteratee reading the article by John Lato in Monad Reader issue 16 (http://themonadreader.files.wordpress.com/2010/05/issue16.pdf). I followed the advice on page 34: I have frequently heard reports from Haskellers (including highly-talented and experienced users) that the only way they could understand enumeration-based I/O was by re-implementing it themselves. and so reimplemented this code in Java which is, for better and worse, my current professional language (and there really is no point in writing my own 50th iteratee code...). I have a question about iteratees composition and their behaviour. I tried to use the throbber code to display progress while writing a file, without using enumeratees which are introduced later on in the article, but failed. I can bind the two iteratees together, but the writer iteratee consumes the stream of characters to write before handing over the control to the throbber iteratee which has nothing to count. Did I miss something ? This is the expected behavior. When iteratees are composed with bind, the first will consume as much of the stream as it needs to calculate its result, and only then will it pass the remaining stream to the next iteratee in the composition. Since streamToFile and throbber both consume an entire stream, they won't complete until EOF, and then will pass just that EOF to the next iteratee in the composition. The behavior you want is pretty common, and it can be accomplished by writing either throbber or streamToFile as an enumeratee. Then the enumeratee version would do the work it's supposed to but also pass the stream along to another iteratee. You could write a library function with type (following the types from the article) iterToEnum :: Monad m = Iteratee el m () - EnumerateeM el el m a which would do this for any data-sink type iteratee. A very similar approach is used in the iteratee package to define the enumPair function, enumPair :: Monad m = Iteratee s m a - Iteratee s m b - Iteratee s m (a,b) I consider enumPair to be one of the most powerful functions supplied in iteratee. Since you use Java, you may be interested in an iteratee implementation in Scala, http://apocalisp.wordpress.com/2010/10/17/scalaz-tutorial-enumeration-based-io-with-iteratees/ Best, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] commutativity
Hi, Below are two questions on commutative operations in Haskell. infixl 5 `com` com :: Int - Int - Int x `com` y = (x + y) commutative com a b = (a `com` b) == (b`com`a) -- 1 + 3 == 3 + 1 -- This gives true by virtue of the value of LHS and RHS being equal after the plus operation -- Question 1 -- commutative com 1 3 -- This also gives true. Is it because of commutative equation or because of the plus operation? -- Question 2 -- In Haskell can commutativity be specified as a property of infix operations? This message has been scanned for content and viruses by the DIT Information Services E-Mail Scanning Service, and is believed to be clean. http://www.dit.ie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Package regex-posix-0.94.2 suddenly failed to link
Hello, All of a sudden, the package regex-posix-0.94.2 failed to link after i installed a couple of other packages (http, json). When I try to reinstall it, I got the folowing errors: D:\projets\crete1941cabal install --global --reinstall --enable-documentation regex-posix-0.94.2 Resolving dependencies... Configuring regex-posix-0.94.2... Preprocessing library regex-posix-0.94.2... Text\Regex\Posix\Wrap.hsc:107:19: regex.h: No such file or directory Text\Regex\Posix\Wrap.hsc: In function `main': Text\Regex\Posix\Wrap.hsc:149: error: `regoff_t' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:149: error: (Each undeclared identifier is reported only once Text\Regex\Posix\Wrap.hsc:149: error: for each function it appears in.) Text\Regex\Posix\Wrap.hsc:149: error: syntax error before int Text\Regex\Posix\Wrap.hsc:384: error: `REG_NOTBOL' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:385: error: `REG_NOTEOL' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:389: error: `REG_EXTENDED' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:390: error: `REG_ICASE' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:391: error: `REG_NOSUB' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:392: error: `REG_NEWLINE' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:398: error: `REG_NOMATCH' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:399: error: `REG_BADBR' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:400: error: `REG_BADPAT' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:401: error: `REG_BADRPT' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:402: error: `REG_ECOLLATE' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:403: error: `REG_ECTYPE' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:404: error: `REG_EESCAPE' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:405: error: `REG_ESUBREG' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:406: error: `REG_EBRACK' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:407: error: `REG_EPAREN' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:408: error: `REG_EBRACE' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:409: error: `REG_ERANGE' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:410: error: `REG_ESPACE' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:447: error: `regex_t' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:481: error: syntax error before ')' token Text\Regex\Posix\Wrap.hsc:484: error: `regmatch_t' undeclared (first use in this function) Text\Regex\Posix\Wrap.hsc:510: error: syntax error before ')' token Text\Regex\Posix\Wrap.hsc:510: error: syntax error before int Text\Regex\Posix\Wrap.hsc:511: error: syntax error before ')' token Text\Regex\Posix\Wrap.hsc:511: error: syntax error before int Text\Regex\Posix\Wrap.hsc:525: error: syntax error before ')' token compiling dist\build\Text\Regex\Posix\Wrap_hsc_make.c failed command was: D:\Program Files\Haskell Platform\2010.2.0.0\mingw\bin\gcc.exe -c -D__GLASGOW_HASKELL__=612 -DHAVE_REGEX_H -DSPLIT_BASE =1 -ID:\Program Files\Haskell Platform\2010.2.0.0\lib\bytestring-0.9.1.7\include -ID:\Program Files\Haskell Platform\2010.2.0.0\lib\ base-4.2.0.2\include -ID:\Program Files\Haskell Platform\2010.2.0.0\lib/include -ID:\Program Files\Haskell Platform\2010.2.0.0\lib/i nclude -ID:/Program Files/Haskell Platform/2010.2.0.0/lib/include/ dist\build\Text\Regex\Posix\Wrap_hsc_make.c -o dist\build\Text\Re gex\Posix\Wrap_hsc_make.o cabal: Error: some packages failed to install: regex-posix-0.94.2 failed during the building phase. The exception was: ExitFailure 1 I am really clueless about the failure and what caused it. Thanks for your help, Arnaud Bailly ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector-space and standard API for vectors
On 30 October 2010 11:07, Henning Thielemann schlepp...@henning-thielemann.de wrote: Looks like you are about to re-implement numeric-prelude. :-) Ah, but Numeric-Prelude is huge though[*]. DavidA complains in the recent Cafe thread Decoupling type classes (e.g. Applicative)? that the Num hierarchy can't be replaced due to inertia. My own feeling is it can't be replaced because no-one can define an acceptable middle ground between the two extremes: miminal - Haskell currently (for discussion, we'll elide some of the problems such as the Show superclass constriant). huge - numeric-prelude or a mathematics system such as Aldor. [*] This is not a criticism - just an observation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package regex-posix-0.94.2 suddenly failed to link
Possibly related to this bug? http://trac.haskell.org/haskell-platform/ticket/137 http://www.haskell.org/pipermail/haskell-cafe/2010-August/082141.html I don't use cabal install, but maybe you could try just re-installing regex-posix, then once its working reinstall the dependencies. That seemed to be the solution in the Cafe thread. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fundata1 -- Karmic Social Capital Benchmark and Shootout
On Fri, Oct 29, 2010 at 1:17 PM, Daryoush Mehrtash dmehrt...@gmail.com wrote: In the lessons you say: Haskell proved too slow with String Map, so we ended up interning strings and working with an IntMap and a dictionary to disintern back to strings as a last step. Daniel Fisher was instrumental in bringing Haskell up to speed with OCaml and then beating it. Don Stewart provided awesome leadership and amazing modification of Haskell's core data structured before your very eyes. A quick tip for anyone who needs to work on large maps with string keys in the future: try Milan Straka's hashmap package. String comparison is expensive and using a size balanced tree causes O(log n) of them. The HashMap data type uses an IntMap internally and typically (in the absence of collisions) needs to traverse the string only once, to compute the hash, and can then perform O(log n) cheap Int comparisons. I'm working on a more efficient hash function for ByteString and Text: an implementation of MurmurHash. The HashMap data type and the need hash function together should give us good performance for maps with string keys. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package regex-posix-0.94.2 suddenly failed to link
On Sat, Oct 30, 2010 at 11:56 AM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hello, All of a sudden, the package regex-posix-0.94.2 failed to link after i installed a couple of other packages (http, json). When I try to reinstall it, I got the folowing errors: D:\projets\crete1941cabal install --global --reinstall --enable-documentation regex-posix-0.94.2 Resolving dependencies... Configuring regex-posix-0.94.2... Preprocessing library regex-posix-0.94.2... Text\Regex\Posix\Wrap.hsc:107:19: regex.h: No such file or directory This is the crucial line in this particular build failure, everything else is fluff. I really, really wish gcc would learn to stop compiling after a header file was missing, since it almost always results in large amounts of nonsense errors. It looks like cabal-install or possibly Cabal can't find your headers. I notice you're compiling with an explicit --global option - why is that? Is it currently installed locally or globally? You can use 'ghc-pkg list regex-posix' to check. You can also enable global installs and documentation by default by editing your config file, whose location is given in the output of cabal --help. You can also specify extra-include-dirs there if you need to do that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: darcs 2.5
Hi all, The darcs team is proud to announce the release of darcs 2.5. Darcs 2.5 contains many improvements over the 2.4 series. Most notable are the performance improvements in record and pull and the --bisect option for trackdown. The easiest way to install darcs 2.5 is using the Haskell Platform [1]. If you have installed the Haskell Platform or cabal-install, you can install this beta release by doing: $ cabal update $ cabal install darcs Alternatively, you can download the tarball from http://darcs.net/releases/darcs-2.5.tar.gz and build it by hand as explained in the README file. What's New -- A list of important changes since darcs 2.4.4: * trackdown can now do binary search with the --bisect option * darcs always stores patch metadata encoded with UTF-8 * diff now supports the --index option * amend-record now supports the --ask-deps option * apply now supports the --match option * amend-record has a new --keep-date option * inventory-changing commands (like record and pull) now operate in constant time with respect to the number of patches in the repository * the push, pull, send and fetch commands no longer change the default repository address by default * the --edit-description option is now on by default for the send command Issues resolved since darcs 2.4.4: * 64: store metadata as UTF-8 * 121: add --ask-deps support to amend-record * 643: darcs send -o outputs remote repo email address * 1159: avoid bogus repository cache entries * 1176: caches interfere with --remote-repo flag * 1208: add trackdown --bisect * 1210: global cache gets recorded in _darcs/prefs/sources * 1232: darcs convert copies _darcs/prefs/prefs * 1250: check for newlines in setpref values * 1277: percolate repository format errors correctly * 1288: the main darcs code now compiles and runs with witnesses * 1290: support diff --index * 1337: don't show unrelated patches in darcs changes on untracked path * 1389: change predist pref to point people to use 'cabal sdist' * 1427: accept gzipped patch bundles in darcs apply * 1456: make dist write more portable archives * 1473: make annotate accept '.' as argument * 1503: prefer local caches to remote ones * 1713: shorter interactive prompts * 1716: allow mail header lines of all whitespace in test * 1719: do not back up files when no conflict markers are inserted * 1726: don't consider all files with _darcs prefix boring * 1739: make ColorPrinter handle characters 255 * 1763: use correct filename encoding in conflictors * 1765: refuse to remove non-tracked directories recursively * 1769: add support for --match 'comment ...' * 1784: push and pull print remote address right away * 1815: work around Cabal sdist permissions issue * 1817: fix support for external merge tools * 1824: avoid PACKAGE_VERSION under Windows * 1825: do not omit important prims in unrecordedChanges w/ files * 1860: (un)applying move patches doesn't corrupt pristine * 1861: fix typo in --no-boring help * 1874: recognise network tests on cabal test command line * 1875: avoid accidentally setting default * 1879: notice unexpected commute failure on merge * 1887: add a missing newline to --list-options output * 1893: move fields of conditional builds within scope of condition * 1898: notify user when they can use set-default * 1913: sort changes in treeDiff Reporting bugs -- If you have an issue with darcs 2.5, you can report it via the web on http://bugs.darcs.net/ . You can also report bugs by email to b...@darcs.net. Kind Regards, the darcs release manager, Reinier Lamers [1]: You can download the Haskell platform from http://hackage.haskell.org/platform/ signature.asc Description: This is a digitally signed message part. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
Victor Oliveira schrieb: Hi Cafe, I really liked the new colors of haskell theme, but... Is really red a good color for links? At least for me, red links looks like broken or already visited ones. And the worst is hackage docs. It is really eye tiring to read. It's just a thought. Maybe it just with me. I'm also used to red=broken, blue=link, as in Wikipedia. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type class design
Hi Ivan, Another possible argument: large type classes can look daunting for both implementors and users, even if only one or two methods need to be defined for a minimal instantiation (I'm tring to work out what to do here myself, as I have some typeclasses that for efficiency reasons it might be nice to have more methods in the class, but it makes it a little overwhelming). But by putting just a small part of the interface into the class does not make the live of a user any simpler. The user usually has to know the whole interface of the module. Or am I missing something? Cheers, Uwe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
Sebastian Fischer schrieb: Maybe we can keep at least the docs without red links. Pick the Classic style in the style menu. It will remember your choice. I don't see a style menu. Does it require JavaScript? I find it still strange, that the unusal style is the default. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
On Saturday 30 October 2010 13:51:25, Henning Thielemann wrote: Sebastian Fischer schrieb: Maybe we can keep at least the docs without red links. Pick the Classic style in the style menu. It will remember your choice. I don't see a style menu. I do, top right, next to Index. In seamonkey, though, it's sometimes half hidden and displayed below the Source resp hackageDB links. Does it require JavaScript? It seems so. If I disallow scripts for haskell.org, I don't see it either. I find it still strange, that the unusal style is the default. Most people who responded when opinions were collected about the new theme preferred that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
On Sat, 30 Oct 2010, Daniel Fischer wrote: I do, top right, next to Index. In seamonkey, though, it's sometimes half hidden and displayed below the Source resp hackageDB links. Does it require JavaScript? It seems so. If I disallow scripts for haskell.org, I don't see it either. If I enable JavaScript in Konqueror, I still see no style menu. However I would like to get it without JavaScript. It can certainly be achieved using a cookie. I never understood why Cascading Style Sheets were used to configure the appearance of a website from the server side. To me it would make more sense if users could configure the colors of links in their browsers, like they configure fonts and font sizes. I find it still strange, that the unusal style is the default. Most people who responded when opinions were collected about the new theme preferred that. Possibly when seeing, how it looks like, people change their mind. :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package regex-posix-0.94.2 suddenly failed to link
Hello Ben, Thanks for your answer. What is strange is that I did not change anything wrt include dirs or gcc or whatever... I am using --global because I noticed ghc-pkg list gives me two locations for regex-xxx packages. I removed everything from --user though. I will try to reinstall regex-xxx. Thanks Arnaud On Sat, Oct 30, 2010 at 1:35 PM, Ben Millwood hask...@benmachine.co.uk wrote: On Sat, Oct 30, 2010 at 11:56 AM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hello, All of a sudden, the package regex-posix-0.94.2 failed to link after i installed a couple of other packages (http, json). When I try to reinstall it, I got the folowing errors: D:\projets\crete1941cabal install --global --reinstall --enable-documentation regex-posix-0.94.2 Resolving dependencies... Configuring regex-posix-0.94.2... Preprocessing library regex-posix-0.94.2... Text\Regex\Posix\Wrap.hsc:107:19: regex.h: No such file or directory This is the crucial line in this particular build failure, everything else is fluff. I really, really wish gcc would learn to stop compiling after a header file was missing, since it almost always results in large amounts of nonsense errors. It looks like cabal-install or possibly Cabal can't find your headers. I notice you're compiling with an explicit --global option - why is that? Is it currently installed locally or globally? You can use 'ghc-pkg list regex-posix' to check. You can also enable global installs and documentation by default by editing your config file, whose location is given in the output of cabal --help. You can also specify extra-include-dirs there if you need to do that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package regex-posix-0.94.2 suddenly failed to link
Hello, I managed to fix this issue reinstalling regex-posix (with a higher version) and then reinstall regex-compat (broken through the reinstall). Thanks a lot for the pointer, Arnaud On Sat, Oct 30, 2010 at 1:08 PM, Stephen Tetley stephen.tet...@gmail.com wrote: Possibly related to this bug? http://trac.haskell.org/haskell-platform/ticket/137 http://www.haskell.org/pipermail/haskell-cafe/2010-August/082141.html I don't use cabal install, but maybe you could try just re-installing regex-posix, then once its working reinstall the dependencies. That seemed to be the solution in the Cafe thread. ___ 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] Red links in the new haskell theme
On Oct 30, 2010, at 9:15 PM, Henning Thielemann wrote: To me it would make more sense if users could configure the colors of links in their browsers, like they configure fonts and font sizes. Most browsers support user style sheets: google.com/search?q=user+style +sheet Most people who responded when opinions were collected about the new theme preferred that. Possibly when seeing, how it looks like, people change their mind. During the poll, the new style was shown on a demo page. Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
On Saturday 30 October 2010 14:15:58, Henning Thielemann wrote: On Sat, 30 Oct 2010, Daniel Fischer wrote: I do, top right, next to Index. In seamonkey, though, it's sometimes half hidden and displayed below the Source resp hackageDB links. Does it require JavaScript? It seems so. If I disallow scripts for haskell.org, I don't see it either. If I enable JavaScript in Konqueror, I still see no style menu. In the Extras menu or in the global settings menu? If I disable JavaScript in the global settings in Konqueror, the Style menu is gone and no futzing with HTML settings in the Extras menu will change that, while if JavaScript is enabled globally, I can turn it on/off per site and the Style menu will appear/disappear according to the setting (requires a reload, though). I don't particularly like Konqueror's configuring behaviour, it's not easy to understand. However I would like to get it without JavaScript. It can certainly be achieved using a cookie. I never understood why Cascading Style Sheets were used to configure the appearance of a website from the server side. To me it would make more sense if users could configure the colors of links in their browsers, like they configure fonts and font sizes. I find it still strange, that the unusal style is the default. Most people who responded when opinions were collected about the new theme preferred that. Possibly when seeing, how it looks like, people change their mind. :-) Possible. But I don't understand how people can get so worked up on such things so much¹. Both look fine to me. [¹] Website design in general. Things look mostly so-so, until a professional designer comes in. Then, with a very few exceptions, things become horrible [that's not particular to _web_ design, it applies to all designers (post Wilhelm Wagenfeld)]. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
Henning Thielemann wrote: If I enable JavaScript in Konqueror, I still see no style menu. However I would like to get it without JavaScript. It can certainly be achieved using a cookie. Both stylesheets are linked to from the text of the HTML files: link href=ocean.css rel=stylesheet type=text/css title=Ocean / link href=xhaddock.css rel=alternate stylesheet type=text/css title=Classic / Firefox uses this information to populate a menu (View | Stylesheet) with the following choices: - no style - Ocean - Classic No need for JavaScript or cookies. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
On Saturday 30 October 2010 14:49:01, Daniel Fischer wrote: Both look fine to me. Oh and btw. Regarding the topic of this thread, I don't see red links in the new theme, they're an orange-ish brown here. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monads and Functions sequence and sequence_
* Mark Spezzano mark.spezz...@chariot.net.au [2010-10-30 15:37:30+1030] Can somebody please explain exactly how the monad functions sequence and sequence_ are meant to work? The others in this thread have already explained how these functions work, so I'll just give an example how they are used. Consider the following task: to read 30 lines from standard input. For one line you would use an action getLine :: IO String How to execute this 30 times? Haskell has a function replicate :: Int - a - [a] which takes a number and produces a list with that number of identical elements. So this is close to what we need: replicate 30 getLine :: [IO String] This is a list containing 30 'getLine' actions. But the list of actions _is not_ an action itself. This is what sequence does -- it transforms a list of actions into a single action which gathers the results into one list. As its name suggests, it does sequencing of actions. sequence $ replicate 30 getLine :: IO [String] Exactly what we need, an action producing a list of lines read. Now, let's consider this code: sequence [ putStrLn $ show i ++ green bottles standing on the wall | i - reverse [1..10] ] :: IO [()] This action prints 10 lines and also returns us gathered results, i.e. 10 '()', one from each putStrLn (recall that putStrLn has type String - IO (). Most probably we don't care about those '()', but they still occupy memory and introduce a space leak as explained here[1]. That's why a version of sequence is introduced which ignores the results of actions and simply returns (). It is called sequence_. sequence_ :: (Monad m) = [m a] - m () As a side note, we can rewrite our last example without using list comprehension in the following way: let p i = putStrLn $ show i ++ green bottles standing on the wall in sequence_ $ map p $ reverse [1..10] The combinations of sequence and sequence_ with map are so common that they have special names: mapM = \f - sequence . map f :: (Monad m) = (a - m b) - [a] - m [b] mapM_ = \f - sequence_ . map f :: (Monad m) = (a - m b) - [a] - m () [1] http://neilmitchell.blogspot.com/2008/12/mapm-mapm-and-monadic-statements.html -- Roman I. Cheplyaka :: http://ro-che.info/ Don't let school get in the way of your education. - Mark Twain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
On Sat, 30 Oct 2010, Tillmann Rendel wrote: Both stylesheets are linked to from the text of the HTML files: link href=ocean.css rel=stylesheet type=text/css title=Ocean / link href=xhaddock.css rel=alternate stylesheet type=text/css title=Classic / Firefox uses this information to populate a menu (View | Stylesheet) with the following choices: - no style - Ocean - Classic No need for JavaScript or cookies. This would be optimal for me, if it would work this way. From the answers I understood that the style menu is something that is part of the document body, not something of the browser navigation toolset. It seems that Konqueror does not let me choose between different styles. However it has a menu item for checking the CSS. :-) It forwards me to http://jigsaw.w3.org/css-validator/validator?uri=http%3A//hackage.haskell.org/package/base and shows 7 errors. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
On Saturday 30 October 2010 15:09:39, Henning Thielemann wrote: On Sat, 30 Oct 2010, Tillmann Rendel wrote: Both stylesheets are linked to from the text of the HTML files: link href=ocean.css rel=stylesheet type=text/css title=Ocean / link href=xhaddock.css rel=alternate stylesheet type=text/css title=Classic / Firefox uses this information to populate a menu (View | Stylesheet) with the following choices: - no style - Ocean - Classic No need for JavaScript or cookies. This would be optimal for me, if it would work this way. From the answers I understood that the style menu is something that is part of the document body, not something of the browser navigation toolset. It seems that Konqueror does not let me choose between different styles. Mine does, with JavaScript globally disabled or enabled: Ansicht - Stilvorlage verwenden * Autom. feststellen * Basisstil * Ocean * Classic However it has a menu item for checking the CSS. :-) I can't find that in mine, however. It forwards me to http://jigsaw.w3.org/css-validator/validator?uri=http%3A//hackage.haskel l.org/package/base and shows 7 errors. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: cabal mystery (#562?)
On Thu, 2010-10-28 at 15:33 +0200, Daniel Fischer wrote: On Thursday 28 October 2010 15:08:09, Conor McBride wrote: Any tips to keep the gremlins at bay gratefully appreciated. Don't feed after midnight, don't get them wet, I think were the tips. Don't expose to bright light. Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
Henning Thielemann wrote: Firefox uses this information to populate a menu (View | Stylesheet) with the following choices: - no style - Ocean - Classic No need for JavaScript or cookies. This would be optimal for me, if it would work this way. From the answers I understood that the style menu is something that is part of the document body, not something of the browser navigation toolset. Yes, the body of the document contains an additional style menu, so on well-behaving browsers, there are two style menus. See screenshot at http://www.informatik.uni-marburg.de/~rendel/style-menu.png Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
Some notes on the Haddock re-design: 1) HTML supports the concept of alternate style sheets. If present, then the idea was that browsers would give the user the choice, somewhere, to choose among them. While Firefox does this (View Page Style), and I'm told that Opera (View Style), and Konqueror (View Use StyleSheet) do, the other big-name browsers, IE, Safari, Chrome, do not. Since support is so lacking, the common thing to do, and what I implemented for Haddock, is to use Javascript to pull the alternate style sheet information out of the page and build a menu that is then placed back into the page. This is the Style menu in the top right of the page. If you have Javascript turned off, it won't appear as it is not part of the markup. The cookie, which is set from Javascript is so that you don't to re-pick the style on every page load. I'm assuming that those browsers that do implement a style sheet menu remember this per-site, but I don't know. It is a limitation of cookies that it can only remember your choice per-site. 2) What styles appear depend on what was specified when Haddock was run to produce the pages. By default it includes just the new Ocean theme. If --default-themes is specified (as it is on Hackage), then both Ocean and Classic are included. You can build your own themes and include them with --theme, alone or in combination with the built-in themes. If the resulting theme set is a singleton, then no Style menu will appear on the page. 3) Without really doing a tracking analysis (preferably by tracking eye movements, or at least mouse movements, and in all cases recording accurate view times and location of clicks), it isn't possible to optimize a web page down to the level of which menu links should be in in which order, or other such small changes. That isn't saying such changes won't have a big impact, only that it is hard to reason about them because the tracking results are often non-intuitive. In the absence of such things, all one can do is bring one's experience and design skills to bear. 4) While Haddock tries to minimize the use of Javascript, it still has some. There is a tension between wanting to produce pages that can be printed documentation, and creating a effective on-line reference. Between the theming ability, and the new LaTeX backend, it is now possible to achieve these two aims with separate Haddock outputs. In modern browsers, Javascript is very efficient and even moderate amounts of Javascript can be crafted to not affect load times. Haddock still has an issue here that the Javascript is repeated in every directory, thus ruining caching. When this is fixed, we'll be able to use more Javascript, which will enable us to make the reference easier and faster to navigate.[1] 5) It does not make sense for users to configure colors or fonts for web sites any more than it would for magazines or books. Effective presentation of information requires design including choice of fonts, colors, graphics and layout - and these vary by the information and intent of the content. There is no choice a user an make that works best for all. It is important for accessibility that those users that need to can override fonts and colors. All modern browsers allow this, and one of the major aims of the Haddock redesign was to output clean markup so that it worked in such situations, as well as with screen readers. In other words - if you want to override the fonts and colors you can now do so effectively. 6) Over the Summer the new style was made available on the web for people to look out for several months, and at one point I conducted a poll. In that poll only 81% preferred the newer look, and only 11% preferred the older. - Mark Haddock web scullion Lentczner [1] An example of an HTML reference work that is highly usable and uses plenty of Javascript (700k!) to achieve it, yet works very well: http://developer.android.com/reference/packages.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
On Sat, 30 Oct 2010, Tillmann Rendel wrote: Yes, the body of the document contains an additional style menu, so on well-behaving browsers, there are two style menus. See screenshot at http://www.informatik.uni-marburg.de/~rendel/style-menu.png Wow, I have also such a menu item Ansicht with sub-item Stilvorlage and subsubitem Ocean and Classic in Konqueror! I still wonder why Ocean looks red, and not blue. But ok, Classic looks as I like it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
On Sat, 30 Oct 2010, Mark Lentczner wrote: 5) It does not make sense for users to configure colors or fonts for web sites any more than it would for magazines or books. For fancy layouts we have PDF. For me, HTML is an online format that shall be as adaptive as possible to font size, window size, screen resolution and other parameters. 6) Over the Summer the new style was made available on the web for people to look out for several months, and at one point I conducted a poll. In that poll only 81% preferred the newer look, and only 11% preferred the older. Somehow I missed that poll, and it seems others have, too. Two notes on the Classic style: The package field names like Version, Dependencies, License are centered, which was not the case in the original style. Also in the original style the table cells had a grey background, what I found quite useful for recognizing the table structure. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Edit Hackage
Daniel Fischer daniel.is.fisc...@web.de writes: On Saturday 30 October 2010 03:42:27, Ivan Lazar Miljenovic wrote: On 30 October 2010 12:22, Lauri Alanko l...@iki.fi wrote: On Thu, Oct 28, 2010 at 01:55:12PM -0700, Don Stewart wrote: The number of subscribers to the Haskell Reddit, for example, is [...] In short, the old technologies of mail and news are technically vastly superior [..] +1; that's pretty much my opinion/arguments as well. +1; same here. I agree too, but not without pointing out that on SO, you'd just be clicking to vote up, rather than quoting the entire mail and adding one line. So there are some advantages. Ivan L. M. wrote: So you'd prefer to have the discussion about a blog post be made distinct from the blog post itself? The problem with blog comments and other web forums is, in addition to the hopeless interfaces they invariably are equipped with, that they are scattered. I very rarely check back to follow up on comments (except on my own site :-), and I rarely bother to register to add my voice. So, yes, I would like discussion to take place with some central coordinaton. Stack Overflow and Reddit are at least improvements over the traditional web forums, starting to acquire some of the features Usenet had twenty years ago. Much like Planet-style meta-blogs and RSS syndication makes it liveable to follow blogs. The important thing is making all the resources visible, and bringing stuff together. HWN is great, I don't follow Reddit, but I do click on the links that look interesting. Is there something going in the other direction, pointing SO users to mailing list threads, for instance? Most web-based email archives seem to suck - where can we point to a nice URL to get an overview of a -cafe thread? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
On Sat, Oct 30, 2010 at 05:26:33PM +0200, Henning Thielemann wrote: Two notes on the Classic style: The package field names like Version, Dependencies, License are centered, which was not the case in the original style. Also in the original style the table cells had a grey background, what I found quite useful for recognizing the table structure. This refers to the hackage package pages using the haddock style files, which have no provision for two-tone tables. The alignment is fixed now, though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
On Sat, 30 Oct 2010, Ross Paterson wrote: On Sat, Oct 30, 2010 at 05:26:33PM +0200, Henning Thielemann wrote: Two notes on the Classic style: The package field names like Version, Dependencies, License are centered, which was not the case in the original style. Also in the original style the table cells had a grey background, what I found quite useful for recognizing the table structure. This refers to the hackage package pages using the haddock style files, which have no provision for two-tone tables. I see. The alignment is fixed now, though. It's still vertically centered, which makes it difficult to see, e.g. where the dependency list starts and where it ends if it is several lines long. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Edit Hackage
On Sat, Oct 30, 2010 at 11:34 AM, Ketil Malde ke...@malde.org wrote: Stack Overflow and Reddit are at least improvements over the traditional web forums, starting to acquire some of the features Usenet had twenty years ago. Much like Planet-style meta-blogs and RSS syndication makes it liveable to follow blogs. Very much this. I mourn Usenet's potential as much as anyone, but life goes on. I'll also note that some private sites take reasonable steps to promote openness. To use Stack Overflow as an example again, all content on the site is under a Creative Commons license and they provide torrents of raw data dumps containing everything but private information about users. So if someone wanted, it'd be possible (probably even easy) to do something like mirror all the content in the [haskell] tag somewhere on haskell.org without any advertising or extraneous SO-related stuff cluttering it up, perhaps re-organized into a more structured FAQ format. The important thing is making all the resources visible, and bringing stuff together. HWN is great, I don't follow Reddit, but I do click on the links that look interesting. Is there something going in the other direction, pointing SO users to mailing list threads, for instance? Most web-based email archives seem to suck - where can we point to a nice URL to get an overview of a -cafe thread? Well, it's always good form to provide relevant links in SO answers, but I'm more likely to direct people to the wiki on Haskell.org, the online Haskell report, Hackage, various blogs, or occasional research papers. I have seen relevant -cafe threads mentioned on occasion, typically using the archive at haskell.org/pipermail and linking to a specific message. As you say, most email archives leave something to be desired. As far as I know, the best way to find anything in old -cafe threads is to do a google search with site:http://www.haskell.org/pipermail/haskell-cafe/;, and there's no good way to get an overview. Especially as topic drift leads to subject lines being uninformative (I mean, Edit Hackage? What?). - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Red links in the new haskell theme
On Sat, Oct 30, 2010 at 06:39:00PM +0200, Henning Thielemann wrote: It's still vertically centered, which makes it difficult to see, e.g. where the dependency list starts and where it ends if it is several lines long. Not any more. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How can we make Haskell-Cafe scale? (was: Re: Edit Hackage)
There's been some grumbling about users migrating from -cafe to Reddit and Stack Overflow in particular. First, as Don has pointed out, the fact is that people are moving away, and that's just the trend. But why are people moving? One reason is that Stack Overflow, Reddit, and -cafe all provide *different things*, with features tailored to specific purposes. I'll try to explain what those things are, why they don't threaten, but augment -cafe, and why we need at least one new mailinglist as well. 1. When Stack Overflow is Better Than -cafe Stack Overflow is *better* for a QA format. I can scan for questions I'm competent to answer or interested in answers to (and the rss feed helps with that), and be confident that for the most part there won't be thread derails, and that the title will maintain consistency with the discussion inside. If the title isn't informative, I can be confident that someone with sufficient rights (which are granted by accumulation of karma) will edit it to be informative. Likewise the question itself, if it evolves over time, can be edited to reflect what it should have been to begin with. And most importantly, if an answer to a question is provided on -cafe, it quickly gets drowned in surrounding traffic. And if an answer becomes out of date, there's no good way to annotate the archives to indicate that. I don't *need* to read all s.o. questions, on the off chance than an answer might become relevant to me later. I know that s.o. provides the right tools so I can find the answer when I need it. And I know that s.o. lets users update pages with new posts, or edits, so that answers don't become stale over time. A technical QA site serves different purposes than a mailinglist, and it needs different technology to do so. There are other, smaller, advantages to stackoverflow which I haven't even touched on. 2. When Reddit is Better Than -cafe As for reddit, while some people obviously treat -cafe as an anything goes place to crack jokes or pursue arguments of rather narrow interest, I'm acutely aware that every message sent to this list lands in the mailbox of thousands some multiple thousands of programmers, many very talented, and almost all with better things to do than wade through the massive traffic of -cafe for the few things of interest to them. So, generally, I tend to shy away from posting to -cafe. Reddit, on the other hand has (although maybe a bit too much) a bit more of the freewheeling atmosphere of, e.g., the #haskell irc channel. People are going to reddit during a long compile, or on a coffee break. There's an understanding that the conversation will tend to be casual, that there will be occasional trolls and occasional gems, and that the primary content will be in high-quality links to papers, blogposts, articles, etc., while the discussion threads will be a way to shoot the breeze about them. This distinction between content and chatter is in many ways a useful thing. Again, the medium of reddit facilitates this type of content. Because messages are shown in their threaded context with relatively high information density, they don't have to quote or indicate their surrounding context. The incremental cost of each message, both to reader and writer, is tiny, and this facilitates a more free-flowing conversational style than over email. Again, upvotes and downvotes (the dreaded ratings and karma) make it easy to see immediately which points others found useful or bogus, and to register simple agreement or disagreement without adding more semantic noise to the mix. 3. How -cafe Can Be Better than -cafe If Stack Overflow is better for QA and Reddit is better for link aggregation and casual chat, that doesn't mean that -cafe should lose subscribers, or pack up and go home. It means that -cafe can shed those aspects, and get on with what *is* better here. For example, the recent set of DSL conversations have been very rich and productive. And I can't think of an online fora besides -cafe where they could have taken place. In one sense, because -cafe has too many posts, it in fact has too few subscribers. Plenty of people who do great work in Haskell, either as academics or commercially, don't have the time and energy to devote to -cafe, even though there are conversations that would be perfect for them. -cafe has averaged about 50 posts/day for this last month. Of those, I'd say about 2/3 are on topic for what I'd like -cafe to be. Some followed from release announcements which led into discussions of some aspect of the project. Some were related to issues with standard libraries, widely-used packages or otherwise relevant to the whole of the Haskell community. Some were well served by taking the temperature of the Haskell community (e.g. the lambda-case discussion). And some were questions suited to generating a broad discussion rather than one or two correct single answers. The other third, by my